LINUX.ORG.RU

[вещества][лиспы]скобочный веб

 


1

4

Мечта идиота. Чтобы все эти разнабойные языки (html, css, js, xml, xlst, ...) померли и был один веб на s-expr. Макросы обязательно (и это лучше чем xlst)
Типичная вебстраничка была бы такой.

(html
  (head
    (title '(Web page))
    (style
      (match '(body .footer)
        :color red
      )
    )
    (script
      (alert 'Hello world')
    )
  )
  (body
    (div :id 'foo')
  )
)
Прошу прощения на неканоничные скобки. CL конечно же как скриптовый язык. html и css - доменные. И браузер на лиспе, расширяемый.
Что думают многоуважаемные лисперы? Подьемно сделать революцию?

★★★★

Ответ на: комментарий от Miguel

Задача браузера — показывать блоки страницы, причем раскладка, обновление элементов и перерисовка должны быть максимально быстрыми, с html такое в принципе невозможно (когда вижу, на что тратится драгоценное процессорное время в веб-приложениях, плакать хочется). Из-за этого и все неудачные попытки использовать html5 в мобильных устройствах.

С учетом этой же основной задачи — сайты для людей, а не для однострочников. А парсить бинарный расширяемый формат (пусть то же xml-подобное дерево) для программы быстрее, чем текстовый.

note173 ★★★★★
()
Ответ на: комментарий от note173

Из-за этого и все неудачные попытки использовать html5 в мобильных устройствах.

Слава богу, они в прошлом.

С учетом этой же основной задачи — сайты для людей, а не для однострочников.

А не скажи. Человеку-гику тоже проще (почему в таблице нет поля «цена»? Не может быть такого! Смотрим в исходник... ага, есть, только ширина некорректно прописана).

Человеку-негику всё равно, но его приятелю-гику проще.

когда вижу, на что тратится драгоценное процессорное время в веб-приложениях, плакать хочется

Неужели парсинг HTML так много съедает? Не верю.

А парсить бинарный расширяемый формат (пусть то же xml-подобное дерево) для программы быстрее, чем текстовый.

Не всякий. В конце концов, большая часть веба и так идёт в бинарном виде (пожатая gzip-ом), только никому от этого ни холодно, ни жарко.

Miguel ★★★★★
()
Ответ на: комментарий от ugoday

Похоже, эта идея приходит в голову всем, кто когда либо изучал лиспы.

Ничего удивительного, схожая манифестация при идентичном диагнозе.

Например, многие больные шизофренией жалуются на то, что чувствуют запах горелой резины. Так и тут.

anonymous
()
Ответ на: комментарий от anonymous

Люди, которые пишут «есть суть», должны работать

Дебилов, для которых html является «высокой материей», не следует подпускать к какой бы то ни было работе вообще. (хохохо)

alienclaster ★★★
()
Ответ на: комментарий от Miguel

Вот тут я не согласен. Этот «семантический веб»

Выделение значимого заголовка с помощью <h-N> логично, так же как заполнение тегов, отвечающих за описание страницы и скорость ее индексации в порядке приоритета поисковым роботом

причём по-нормальному разметить пьесу до сих пор нельзя

?

в то время как неприглядная правда такова: у HTML нет НИКАКОЙ семантики, кроме того, как он отображается.

Семантический веб - это такой, из которого семантическую составляющую для человека выбирают роботы при помощи машинной обработки данных, помеченных как семантические, с указанием (предполагаемой, рекомендованной) семантики

Поисковые системы и социальные медиа работают именно так, уже сейчас

alienclaster ★★★
()
Ответ на: комментарий от bga_

Это было написано только для самообразования. Много времени прошло с тех пор - мне это уже не интересно :)

bk_ ★★
()

Мечта идиота. Чтобы все эти разнабойные языки (html, css, js, xml, xlst, ...) померли
CL конечно же как скриптовый язык. html и css - доменные. И браузер на лиспе, расширяемый.

Ну так сделай, будь мужиком, блеять!

Сперва тебе придется написать свой валидирующий pull-парсер для S-выражений. Стандартный лисповый ридер не вернет AST, пока не распарсит все до последней скобки, а в вебе надо начинать интерпретировать по возможности сразу же.

Затем ты напишешь разборщик и валидатор своих DSL-аналогов HTML и CSS и начнешь реализовывать рендерер. В этот момент обнаружится, что для лиспа нет качественных биндингов к современным GUI-тулкитам. Сперва ты возьмешься за cffi-cairo и cl-cairo2, но выяснится, что они заточены под старые версии Cairo и не работают.

Ты станешь допиливать Cairo-биндинги, но однажды решишь, что Cairo семантически чужд лисп-парадигме и возьмешься писать свою кросс-платформенную библиотеку для поддержки высокопроизводительной векторной графики. Затем ты реализуешь аналог протокола HTTP, только на S-выражениях (назовем его SXTP), потому что HTTP с его убогими URL'ами и методами семантически чужд лисп-парадигме.

После этого встанет вопрос о написании веб-сервера, поддерживающего SXTP. Попутно ты напишешь template engine, аналоги XPath, XSLT, а также ORM и MVC-фреймворк. В этот момент выяснится, что традиционные SQL-базы данных семантически чужды лисп-парадигме, и ты начнешь разрабатывать собственную лисп-ориентированную БД.

В этот момент ты поймешь, что Common Lisp перегружен и недостаточно выразителен, его стандарт раздут, а макросы негигиеничны; что Scheme слишком минималистична и академична; что остальные диалекты лиспа либо маргинальны, либо требуют .NET/JVM. Тут тебе в голову придет идея создать собственный лисп. Ты потратишь несколько лет на разработку стандарта, реализацию языка и переписывание всего вышеперечисленного на твоем новом языке. После этого окажется, что все ужасно тормозит. И это, разумеется, исключительно по той причине, что операционные системы стандарта POSIX семантически чужды лисп-парадигме. Ты начнешь разрабатывать LISP OS.

В процессе разработки выяснится, что эффективная LISP OS для x86/ARM/MIPS не может быть создана в принципе, так как их семантика чужда лисп-парадигме. Ты возьмешься за изучение System C, Verilog, VHDL и в один прекрасный день создашь лисп-машину на FPGA.

В этот момент мозаика чудесным образом сложится. У тебя будут лисп-машина, лисп-OS, лисп-сервер и лисп-браузер. Ты восторженно оглянешься вокруг, и обнаружишь, что половина человечества уже переселилась на Gliese 581, а оставшаяся половина забыла про HTML/CSS/etc., как про страшный сон, и давно пользуется квантовыми компьютерами и квантовыми сетями. Но все это уже будет не важно. У тебя ведь будет лисп-браузер и полноценная замена HTML/CSS на S-выражениях.

Да и жить тебе останется не так и долго, потому что к этому моменту ты уже будешь дряхлым стариком.

anonymous
()
Ответ на: комментарий от Miguel

Из-за этого и все неудачные попытки использовать html5 в мобильных устройствах.

Слава богу, они в прошлом.

Наоборот, все только начинается...

А не скажи. Человеку-гику

1% глобальной аудитории, из которых 1% нужна фича -> не пройдет

когда вижу, на что тратится драгоценное процессорное время в веб-приложениях, плакать хочется

Неужели парсинг HTML так много съедает? Не верю

xhtml как разновидность (надмножество) xml'я. А xml - один из самых жрущих процессорное время форматов данных «удобный для пользователя» (сомнительный тезис)

А парсить бинарный расширяемый формат (пусть то же xml-подобное дерево) для программы быстрее, чем текстовый.

Не всякий. В конце концов, большая часть веба и так идёт в бинарном виде (пожатая gzip-ом)

... который на стороне клиента проходит процедуру декопрессии до исходного формата - и начаются тормоза на его рендеринге

alienclaster ★★★
()
Ответ на: комментарий от bk_

Это было написано только для самообразования. Много времени прошло с тех пор - мне это уже не интересно :)

А lisp используешь для real-world задач? // праздный интерес

alienclaster ★★★
()
Ответ на: комментарий от anonymous

Круто написал. А если серьезно - нужен только нормальный веб-фреймворк и обновленный стандарт CL... А лучше - фреймворк для написания лиспов на любой вкус.

alienclaster ★★★
()
Ответ на: комментарий от anonymous

но я же не лавсан. мне нравятся sexpr для верстки и я ценю мощность встроенных макросов но предпочитаю для реального кода все таки нечто хаскелеподобное

bga_ ★★★★
() автор топика
Ответ на: комментарий от bga_

но я же не лавсан. мне нравятся sexpr для верстки и я ценю мощность встроенных макросов но предпочитаю для реального кода все таки нечто хаскелеподобное

Хаскель? Ну тогда замени все вышеперечисленное на «переписать стандартную прелюдию, чтобы по крайней мере все рекурсивные схемы (катаморфизм, параморфизм, зигоморфизм, хистоморфизм, препроморфизм, анаморфизм, апоморфизм, футуморфизм, постпроморфизм, хиломорфизм, крономорфизм, синкрономорфизм, экзоморфизм, метаморфизм, динаморфизм) были выражены через комонады». Этого как раз хватит до старости.

Шутки шутками, а вот по крайней мере об эффективном pull-парсинге и параллельном с ним рендеринге было сказано абсолютно серьезно. Поразмысли на досуге об этой проблеме. И это мы еще даже не говорили о JIT-компиляции скриптов, о безопасном их выполнении, об эффективной перерисовке страницы (когда скрипт меняет ее часть), о векторной анимации, о видео и аудио (HTML5), об оптимизированном хранении и поиске по history, о расширяемой архитектуре.

Я это все к тому, что задача отнюдь не такая простая, какой кажется, а лисп — не серебряная пуля. В подобных задачах важны в первую очередь архитектура, структуры данных и алгоритмы, а язык — вторичен.

anonymous
()
Ответ на: комментарий от anonymous

это если я буду все писать с 0. но если я просто прикручу sbcl к вебкиту то это не так много времени.

bga_ ★★★★
() автор топика
Ответ на: комментарий от alienclaster

А если серьезно - нужен только нормальный веб-фреймворк и обновленный стандарт CL...
нужен только нормальный веб-фреймворк и обновленный стандарт
нужен только

Это ваше «нужен только» с головой выдает в вас человека, не имеющего никакого отношения к профессиональной разработке ПО. Я бы рекомендовал воздерживаться от подобного рода публичных заявлений, так как они сразу вскрывают дилетантизм заявляющего. О реальных (а не розово-фантазерских «фреймворках для написания лиспов на любой вкус») проблемах поставленной задачи см. в предыдущем посте.

anonymous
()
Ответ на: комментарий от bga_

это если я буду все писать с 0. но если я просто прикручу sbcl к вебкиту то это не так много времени.

Ну так прикрути, кто запрещает-то? А мы посмотрим. И время засечем.

anonymous
()
Ответ на: комментарий от anonymous

Хотел ответить на это сообщение, но подумал, что ты клинический дебил - и пожалел дальнейшего времени на разведение с тобой любых дискуссий (предметного общения все равно не выйдет, а шанс на то, что ты сможешь «переоценить ценности» строго отрицательный) -> ПНХ

alienclaster ★★★
()
Ответ на: комментарий от alienclaster

Хотел ответить на это сообщение, но...

...но не смог. Слив засчитан.

anonymous
()
Ответ на: комментарий от archimag

mod_lisp

Мёртвая и совершенно бесполезная херня.

Хорошо, что в Дебиане твоим мнением не интересуются.

anonymous
()

Подъемно сделать революцию?

Какая ешё революция? Те же я*ца, только вид сбоку.

Посмотри на http://www.google.ru/ig?hl=ru и посмотри код страницы.

Революцией будет переработка архитектуры и семантики, чтоб отрисовка не тормозила (кстати, какие ресурсы имеются у пользователя?), ожидая дополучения полного набора данных, а начинала красиво отрисовывать сразу, по частям. Ожидания ответов баз данных, кусков информации с других сайтов, подключение новых внешних движков на стороне клиента и сценариев их работы, загрузка встраиваемых приложений на одном или нескольких языках программирования, и прочих сервисов не должны тормозить отрисовку и ломать дизайн при получении новых данных. При этом желательно иметь шустрое интерактивное взаимодействие с ресурсами пользователя и однозначную идентификацию пользователя и его сессий.

Проблема интеграции сервисов, как remote предоставленные серверами, так и local у клиента (например, наличие 3D, размер и тип экрана, тип устройства ввода информации), взаимодействия их между собой и с пользователем, и дизайн их представления на стороне пользователя - вот о чём следует думать.

anonymous
()
Ответ на: комментарий от bga_

Для этого достаточно в начале страницы написать

(in-package :z)
ugoday ★★★★★
()
Ответ на: комментарий от Miguel

Неужели парсинг HTML так много съедает? Не верю.

Сам парсинг — нет, но анимации с десятками обновлений через создание и парсинг строк для стилей — явно не самый оптимальный путь. И так везде; без нормальных способов работы с интерфейсом применяется разная строковая и dom-магия. И после этого веб-программисты думают, что так и должно быть.

большая часть веба и так идёт в бинарном виде (пожатая gzip-ом)

Тут главное не размер, а однозначность.

note173 ★★★★★
()
Ответ на: комментарий от Deleted

Обычный XHTML - это тоже XML, если что. И ничего общего с S-выражениями.

О чем это ты? Я тебя не понял. Или ты меня.

В Scala Lift страница обрабатывается не как текст, а именно как xml, что действительно не очень далеко от того, как если бы обрабатывалось само s-выражение. Такая особенность Scala - уметь работать с xml почти как с s-выражением.

dave ★★★★★
()
Ответ на: комментарий от Miguel

У меня Iceweasel 9. Только потому, что вокруг меня каждый второй сайт такой, что верстальщшикам надо руки отрывать.

Deleted
()
Ответ на: комментарий от alienclaster

xhtml как разновидность (надмножество) xml'я. А xml - один из самых жрущих процессорное время форматов данных «удобный для пользователя» (сомнительный тезис)

XML (а значит, XHTML) парситься достаточно просто. Во всяком случае, намного, намного проще, чем битый HTML.

Deleted
()
Ответ на: комментарий от Deleted

Что-то типа иммутабельного DOМа с паттерн-матчингом, доступом к полной библиотеке коллекций (scala.xml.NodeSeq - это и последовательность Seq[Node]), а также возможностью создавать неизменяемые значения XML на-лету. В Common Lisp в принципе все то же самое, только нет паттерн-матчинга из коробки, хотя есть мощный DESTRUCTURING-BIND.

Что интересно, в этом самом Scala Lift вставляются управляющие теги и проходит несколько этапов обработки. На вход каждого этапа поступает xml, на выходе получаем новый xml. Внутренние теги - из своего пространства имен. В итоговом xhtml их не будет. В Common Lisp это просто были бы символы из внутреннего пакета или даже ключевые слова. Вполне себе хорошая аналогия.

Просто я не совсем понимаю, чем не понравились архимагу s-выражения для генерации HTML.

dave ★★★★★
()
Ответ на: комментарий от alienclaster

Уродство с версткой и логикой вперемешку

1. Можно и без логики
2. Кому-то на практике нужна вёрстка без логики?

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

Хорошо, что в Дебиане твоим мнением не интересуются.

В дебиан с точки зрения лиспа нет ничего интересного, пакеты древние и убогие.

archimag ★★★
()
Ответ на: комментарий от dave

На вход каждого этапа поступает xml, на выходе получаем новый xml. Внутренние теги - из своего пространства имен.

Т.е., изначально на вход подается некий высокоуровневый собственный XML, из которого в конце-концов получается низкоуровневый XHTML? Что ж, неплохая идея, выглядит красивее, чем обычные шаблоны, и гарантированно получается нормальный XHTML, где нет незакрытых тегов.

Deleted
()
Ответ на: комментарий от alienclaster

почему предполагаемая разметка именно такая? Потому что

Слишком суровая аргументация, даже для тебя

Ты всерьёз предлагаешь искусственным образом ограничивать разметку?

Miguel ★★★★★
()
Ответ на: комментарий от Deleted

Только Scala Lift ограничен тем, что приходится данные сериализовывать через xml. Common Lisp этим не ограничен, и здесь открываются новые возможности. Во время обработки можно вставлять в s-выражения, вообще, любые объекты, например, функции. Кстати, для аналогичного поведения в Scala Lift кодируется в xml имя метода, а потом на одном из последующих этапов обработки вызывается этот метод через рефлексию, что совсем не есть хорошо.

В общем, я считаю, что подал хорошую идею энтузиастам :)

dave ★★★★★
()
Ответ на: комментарий от alienclaster

> причём по-нормальному разметить пьесу до сих пор нельзя

?

Я как-то пробовал выяснить у профессионалов, как сделать такую разметку:

                 Шура
Остаться можно мне?
                Кутузов
                    Лет, позабыл я, сколько
Тебе?..
                 Шура
        Семнадцать!
                Кутузов 
                    Да-с... А коль узнает кто,
Как этот граф, что ты... ну, не мужчина?
                 Шура
Шестой я месяц тут. Никто за время то
Не заподозрил ни лица, ни чина!..
Ничего разумного так и не получил.

Поисковые системы и социальные медиа работают именно так, уже сейчас

Не-а. Если бы у Гугля хватало ресурсов, чтобы отрендерить все страницы во всех браузерах и напустить на них OCR — они бы так и делали. Таких ресурсов у них нет, но они очень стараются понять именно как должна ВЫГЛЯДЕТЬ страница.

Miguel ★★★★★
()
Ответ на: комментарий от alienclaster

Наоборот, все только начинается...

Ой ли? Mobile Safari нормально показывает 99% интернетов.

А не скажи. Человеку-гику

1% глобальной аудитории, из которых 1% нужна фича -> не пройдет

У обычных юзеров как правило есть «техподдержка» — приятели, разбирающиеся в компах.

А xml - один из самых жрущих процессорное время форматов данных «удобный для пользователя» (сомнительный тезис)

Про удобство для пользователя — согласен, про жручесть попрошу пруфлинк. Что именно парсинг xml занимает кучу времени.

Miguel ★★★★★
()
Ответ на: комментарий от ugoday

Откуда такое ограничение?

Ну, ты же явно считаешь, что один раз протестировали — и на всю жизнь хватит, с гарантией. А если контент динамический, то сколько ни тестируй — всего не выловишь, даже в теории.

Miguel ★★★★★
()
Ответ на: комментарий от Deleted

У меня Iceweasel 9.

Значит, ты лицемер. Призываешь пользоваться строгими браузерами, а сам этого не делаешь.

Miguel ★★★★★
()
Ответ на: комментарий от Deleted

Ъ-браузер должен не показывать невалидные страницы, чтобы разработчики задумались

как вариант - в вебсервер должен быть встроен тот же валидатор, что и в браузеры. Отдаёшь контент - проверь, то ли ты отдаёшь, или нет. А если чо - в коммон лиспе рестарты есть, можно как-нибудь разрулить

lazyklimm ★★★★★
()
Ответ на: комментарий от note173

Что мешает перевести разметку в бинарное представление и впредь работать только с ним?

quantum-troll ★★★★★
()
Ответ на: комментарий от Miguel

Нет, я призываю не пользователей пользоваться строгими браузерами, а разработчиков - делать ТОЛЬКО строгие браузеры. Или хотя бы при заходе на фиговый сайт выбрасывать окошко «Этот сайт - дерьмо. Все равно попытаться отобразить?»

Deleted
()
Ответ на: комментарий от lazyklimm

а какое отношение он имеет к разметке?

А при чём тут?

Просто он ведь тоже отдаётся сервером.

Miguel ★★★★★
()
Ответ на: комментарий от Deleted

а разработчиков - делать ТОЛЬКО строгие браузеры.

Ну вот, один такой есть. Знаешь, на каком он месте в статистике использования?

Miguel ★★★★★
()
Ответ на: комментарий от lazyklimm

Если идею ТС относительно лиспа реализовать, то получится невозможно нарушить закрытость/открытость тегов, а при некотором допиле возможно сделать, чтобы полная валидация, в том числе относительно уместности использования тегов, происходила автоматически.

Хотя браузеры и так отказываются открывать кривые XHTML, если сервер их отдает правильно (т.е., как application/xml+xhtml)

Deleted
()
Ответ на: комментарий от Miguel

Знаю. Но если разработчики все вместе сделают это, то верстальщикам бежать будет некуда.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.