> Да ну, фигня. Тормозит и течёт активно кажется только один браузер. Но там дело вовсе не в html и JavaScript.

FF?

s-выражения.

<ul>
  <li><a href="http://xynta.com">Cсылка. <b>Жирный шрифт.</b></a></li>
  <li><img src="http://xynta.com/xynta.jpg"></li>
</ul>

(ul
  (li ((a :href "http://xynta.com") "ссылка" (b "Жирный шрифт")))
  (li (img :src "http://xynta.com/xynta.jpg")))

> s-выражения.

Неэквивалентно

> Это субъективное мнение, основанное на привычке к SGML

Писать на CL и заниматься веб я стал примерно в одно и тоже время. Код на CL я редактирую чаще (намного чаще), чем правлю html. И у меня, человека постоянно работающего с s-выражениями, они никакого восторга сами по себе не вызывает. И часто синтаксис того же JavaScript мне нравится больше. Но на CL я пишу вовсе не из-за скобок. Я их просто принял, какие есть, без восторгов. И править разметку я лучше будут как html.

Ладно, пусть у меня это субьективное мнение. А ты претендуешь на объективность?

Ну да. Я вот придумал клевый такой стиль маркапа на S-выражениях.

elt ::= (name &rest attributes) | ((name &rest attrubutes) &rest content)
name ::= a symbol

>И у меня, человека постоянно работающего с s-выражениями, они никакого восторга сами по себе не вызывает. И часто синтаксис того же JavaScript мне нравится больше.

Ну, учитывая, что ты и макросы недолюбливаешь, немудрено...

А ты претендуешь на объективность?

Объективность в вопросе того, что s-выражения гораздо легче парсить, генерировать, что они гораздо менее error-prone, и что в большинстве случаев гораздо легче читаются? Да.

Опять лишние кавычки

где?

«Ссылка. » «Жирный шрифт» в хтмлмаркапе их нет

s-выражения гораздо легче парсить

Во что выльется хотя бы вот такое:

<script>function x(o) { o.innerHTML += " (append)" }</script>

<div onclick="x(this)">test</div>

> Ну, учитывая, что ты и макросы недолюбливаешь, немудрено...

И при чём тут макросы?

Объективность в вопросе того, что s-выражения гораздо легче парсить,

генерировать, что они гораздо менее error-prone, и что в большинстве

случаев гораздо легче читаются? Да.

Если 99% опрашиваемых скажут тебе, что нет, ты всё равно будешь уверен, что для них s-выражения будут легче читаться? А они ведь постоянно это говорят, а суровая практика не приняла эти s-выражения, хотя они и навязывались десятилетиямию И даже Маккарти их не любил. Интересный способ искажения реальности, она у тебя альтернативная?

Так понятнее?

object ::= list | atom
list ::= '(' object* ')'
atom ::= symbol | string
symbol ::= ':'? alpha*
string ::= '"' char* '"'

> Языки разметки вполне годятся для программирования.
Я тоже люблю программировать на HTML. Мечтаю портировать старый добрый Дум на XML.

99% опрашиваемых
а суровая практика не приняла эти s-выражения,

Суровая практика это кто? Стада хомячков, с радостью принимающие любое говно, будь оно в достаточной мере подслащено маркетингом?

Из твоих тезисов выходит что CL - никому не нужное говно, не приспособленное к реальности - его ведь тоже «суровая практика» не приняла?

>> Это вообще совсем другой подход к программированию

Принципиально новая система? А нескучные обои будут?

>(defun foo (object)

(pushback

Стоп. Что это? Какой браузер поймёт такой клиентский код?

> Стада хомячков, с радостью принимающие любое говно

Ты так говоришь о большинстве программистов? Кто ты такой, что бы так судить? Судить в такой форме и так категорично, не стесняюсь откровенной брани? Думаешь низкий уровень твоей культуры может считаться оправданием подобного поведения?

Из твоих тезисов выходит что CL - никому не нужное говно

Во-первых, я ничего не говорил про «говно». Я говорил о восприятии конкретного синтаксиса большинством людей, которым придётся с ним работать. И если для языка программирования определённый синтаксис может оправдываться предоставляемыми за счёт этого возможностями (как в случае с CL), то в случае языка разметки никакого оправдания использованию s-выражений нет и быть не может.

В этом вся проблема!

>Ты так говоришь о большинстве программистов?
В принципе, да.
Нет, конечно, я тебе предоставляю шанс меня разуверить в этом - скажи мне, что большинство программистов конечно же всегда осознанно выбирает язык под задачу, конечно же судит инструменты по техническим возможностям и преимуществам перед другими инструментами, а не по глянцевым обложкам сайтов Sun/Oracle/Microsoft, и так далее.

Кто ты такой, что бы так судить?

Ну я это я. Мне как бы этого достаточно чтобы судить о чем угодно.

Судить в такой форме и так категорично, не стесняюсь откровенной брани? Думаешь низкий уровень твоей культуры может считаться оправданием подобного поведения?

И что же такое «культура»?

Во-первых, я ничего не говорил про «говно».

Тем не менее, такой вывод из твоих рассуждений вполне себе следует.

Я говорил о восприятии конкретного синтаксиса большинством людей, которым придётся с ним работать.

Большинство людей хорошо воспринимает только то, с чем давно знакомо, и к чему привыкло.

И если для языка программирования определённый синтаксис может оправдываться предоставляемыми за счёт этого возможностями (как в случае с CL)

В CL, кстати, синтаксиса по факту нету. Он меняется как угодно, и так далее. Скобки - просто дань истории и обратной совместимости. А возможности там, те, которые ты, имеешь ввиду, предоставляются за счет неделимости кода и данных, и за счет инкрементальной компиляции.

то в случае языка разметки никакого оправдания использованию s-выражений нет и быть не может.

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

> в случае языка разметки никакого оправдания использованию s-выражений нет и быть не может.

В формате MIF для представления документов когда-то непревзойденного приложения FrameMaker использовался схожий с s-expr синтаксис. Жаль, что их потом Adobe купил, и фактически перестал развивать. В пользу своего PageMaker, если не ошибаюсь.

P.S. В качестве справки. Раньше вся документация по AutoCad поставлялась переводчикам в формате MIF. Не знаю, как сейчас.

> Большинство людей

Но зачем ты вообще о говоришь о «большинстве»? Что за жлобство? Ты знаком с «большинством»? Научись, прежде всего, говорить и отвечать за себя.

И что же такое «культура»?

Для начала не считать 95% людей идиотами.

А возможности там, те, которые ты, имеешь ввиду

Да ты телепат?

В случае языка разметки строго-типизированные деревья с

минимальным синтаксисом - самое то.

Ты эксперт в языках разметки? Защитил PhD на эту тему? Много работал с различными языками разметки? Так что же ты судишь о том, в чём не разбираешься?

> В формате MIF

А раньше было много форматов на базе s-выражений, только куда все делись? Не иначе, как мировой заговор против скобок!

То есть элементы такой разметки будут для браузера практически кодом, который будет возвращать объекты, вплоть до объекта «документ»?
Пример со списками был пожалуй красив, с обработчиком как-то пострашнее.
Несколько смущает мешанина кода с данными, хотя тут это выглядит довольно органично.

>Но зачем ты вообще о говоришь о «большинстве»?
А почему ты о нем говоришь? Не я первый начал.

Научись, прежде всего, говорить и отвечать за себя.

С этим у меня все прекрасно. А у тебя?

Для начала не считать 95% людей идиотами.

Неправильно. Культура это телеканал такой(совершенно дебильнейший, кстати говоря). И все. Ну и сферическая хренота в вакууме, тыкание в сторону которой есть вполне себе четкий симптом ГСМ.
И кто говорил про идиотов? Хомячков.
Стада хомячков.

Да ты телепат?

О! А что же ты еще то мог иметь ввиду говоря о синтаксисе, как не макросы и манипуляции кодом? Неужто CLOS? Смешно.

Ты эксперт в языках разметки?

А ты?

Так что же ты судишь о том, в чём не разбираешься?

А почему ты судишь о том, что кто-то не разбирается в чем-то? Ты что, телепат, или защитил PhD на эту тему?

>То есть элементы такой разметки будут для браузера практически кодом, который будет возвращать объекты, вплоть до объекта «документ»?
Ну по типу.

>s-выражения гораздо легче

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

Если интересуют примеры, то возьми канонический пример из руководства по Окамлу с карточными мастями.

Скорее всего, виной тому обычная алчность владельцев той фирмы, что произвела на свет FrameMaker. Не устояли перед предложением Adobe. А лет десять-пятнадцать назад у FrameMaker была существенная доля профессиональной книжной издательской документации для северо-американских соединенных государств.

Что характерно, FrameMaker работал очень шустро даже на весьма скромных пеньках. Кстати, был создан первоначально для юниксов, а потом портирован на другие платформы. Качество генерируемого документа просто обалденное. Я и сейчас не могу добиться ничего подобного ни с техом, ни, тем более, со всякими офисами. Хотя тех будет где-то рядом, если использовать свои шрифты, но он сильно другой. Без понятия, кто сейчас обосновался в той издательской нише. Прикупивший их Adobe и, наверное, еще кто-то.

>список-строка-символ-кейворд-атом.
Ты чето не понял.
Это, перечисленное - только внешнее представление. И перечисленным, кстати, не ограничивается, в современных лиспах.

А в тот базис, в какой тебе требуется.

Это чо, неужто в базис вот этой вот кучи нечитаемых инфиксных операторов из хаскеля(где-то список видел, типа сколько на всем хакадже используется инфиксных операторов, и каких - я чуть не усрался)?

А в тот базис, в какой тебе требуется.

В лиспе то как раз какой-угодно базис можно создать, с метаобъектным протоколом и тому подобным, а ф.я. ограничены маленькой кучкой не особо то крутых абстракци( выделяются разве что монады, да и то... )

Не иначе, как мировой заговор против скобок!

И один емахс как оплот свободы :) Я как-то удивился - откуда столько скобок в ~/.semanticdb, но потом стало понятно, откуда ноги растут.

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

+1, пожалуй.

Только вот CL (и Scheme) никак не мешают вводить АТД и описывать языки в их терминах, а не в терминах s-выражений (just like in Haskell). Это во-первых.

Во-вторых, описывая любой контекстно-свободный язык с помощью АТД мы описываем древовидную структуру, где типы АТД - семантические атрибуты. При этом это дерево АТД оказывается изоморфным s-выражениям. Что лучше - иметь одно унифицированное представление (s-выражение) которому изоморфны все остальные представления или просто разные представления?

Пример:

data Term = Lambda Symbol Term | Application Term Term | Symbol

Объект этого АТД будет представим таким s-выражением:

(:or
  (:lambda      [symbol] [term])
  (:application [term]   [term])
  (:symbol      [symbol]))

При этом s-выражения можно читать/писать, можно скинуть файл и восстановить потом оттуда (сериализация всего и вся из коробки), можно их передать как данные по сети (ну как HTML или JSON те же). В конце концов это данные - их можно обрабатывать.

Что будут делать в Haskell если нужно иметь текстовое представление АТД объектов? Видимо те же s-выражения использовать:

(Lambda (Symbol "a") (Application (Symbol "factorial") (Symbol "a")))

мало отличается от

(:lambda (:symbol "a") (:application (:symbol "factorial") (:symbol "a")))

Вот только первые, в Haskell, нельзя свободно читать/читать/выполнять (эй, где все эти полиморфные read, write, eval, apply, где класс типов Any которым можно перечислить *все* типы, в том числе ещё не определённые?)

>В лиспе то как раз какой-угодно базис можно создать

Нет, нельзя. Например, ты не сможешь определить S-выражение, сотоящее только из списка атомов, как бы твоей предметной области это не было потребно.

Метаобъекты это совсем из другой оперы. Да и опять, динамика и позднее связывание.

ограничены маленькой кучкой не особо то крутых абстракци

Не смешно. Особенно про монады.

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

На лиспе в подобном стиле писать не получится: система типов не подходит.

> Суровая практика это кто? Стада хомячков, с радостью принимающие любое говно, будь оно в достаточной мере подслащено маркетингом?

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

Однако в любом случае НЕ хомячки.

Инди-разработчика тоже нельзя отнести к хомячкам — они тоже хорошо знакомы с суровой практикой.

К хомячкам можно отнести только тех, кто работает «от и до» того, что приказал начальник, не принимает самостоятельных решений.

отступая от темы

> Инди-разработчика

Что это за люди?

Independent

>мало отличается от

Отличается, да еще как. Все дело в волшебных пу^W^W в типизации. И в хаскеле тебе придется либо определять конкретные версии read, write, либо использовать стандартный пакет Data.Dynamic (только не спрашивай как он работает, моего мозга на осмысление не хватает).

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

А когда программа пару раз вырубится из-за того, что ты написал (:lambda (:symbol «a») ((:application (:symbol «factorial») (:symbol «a»)))) вместо (:lambda (:symbol «a») (:application (:symbol «factorial») (:symbol «a»))) почему-то начинаешь резко уважать типы.

А за это при ходится реально платить. Вместо того, чтобы программировать в одном измерении, тебе приходится программировать в двух: сначала описываем спецификацию с помощью системы типов, а затем, собственно саму программу.

>Нет, нельзя. Например, ты не сможешь определить S-выражение, сотоящее только из списка атомов, как бы твоей предметной области это не было потребно.

Что значит «определить»? Если в какой-то конкретной области нечто определяется с помощью s-выражений, эти выражения как-бы неплохо верифицировать. Надо мне список не списков(вообще, что за дебильное деление? У меня ощущение создается, что я с человеком из 60х разговариваю), я беру и проверяю. Типа (unless (every #'listp expr) (error «xynta»)). Круто, да? И не надо даже типизацию выдумывать.

Метаобъекты это совсем из другой оперы. Да и опять, динамика и позднее связывание.

Метаобъектный протокол это из оперы подстроить объектную систему под свои нужны.
И это, хочу позднее, хочу что угодно compile-time делаю - специальные операторы для этого есть.

На лиспе есть средства абстракции поудобнее и повыразительнее, чем кучка комбинаторов. И, что самое важное, лисп позволяет создавать новые средства. Под предметную область.
И решать задачу.

А не надрачивать на типизацию, монады и эндофункторы.

На лиспе в подобном стиле писать не получится: система типов не подходит.

Это фундаментальное непонимание. S-выражения это способ записи данных и программ, представление, в которое строится изоморфизм из любого другого представления. Зачем строится - чтобы было одно единственное представление которое 1) является *данными* 2) всегда может быть *напечатано* / *прочитано*. Всё. Наличие в языке системы типов, абстракций лямбда исчисления, средств алгебраического и категориального программирования - всё это строго ортогонально «лиспам» и их s-выражениям. Все эти вещи в «лиспах» как раз легко могут быть библиотеками.

Можете представить программу на Haskell в скобочном синтаксисе (в тех местах где инфикс и layouts)? Монады от этого не пропадут. А вот на вопрос «как реализовать пользовательскую специальную форму со стратегий вычисления call-by-macro-expansion» будет конкретный ответ.

>в основном продвинутые программисты, хорошо знакомые с суровой практикой.
Да, да. С суровой практикой набрать кучу макак подешевле и склепать какое-нибудь говно побыстрее.

Ок. Это Метахомячки.

> Наличие в языке системы типов, абстракций лямбда исчисления, средств алгебраического и категориального программирования - всё это строго ортогонально «лиспам» и их s-выражениям. Все эти вещи в «лиспах» как раз легко могут быть библиотеками.

Ну так они в любом языке могут быть библиотеками.

только не спрашивай как он работает, моего мозга на осмысление не хватает

А, узнаю, phd-level-topic через каждые две главы :)

А когда программа пару раз вырубится из-за того, что ты написал

1) А если я в хаскеле напишу (Lambda (Symbol «a») ((Application (Symbol «factorial») (Symbol «a»))))

2) Может ещё молотком себя по башке ударить?)

3) Почему на выражение (:lambda (:symbol «a») (:application (:symbol «factorial») (:symbol «a»))) нельзя натравить type-checker в лучших традициях F-system? Можно ведь.

сначала описываем спецификацию с помощью системы типов, а затем, собственно саму программу.

Ну, я думаю что это хорошо, если хочется именно так. Не спорю.

> Ок. Это Метахомячки.

Метахомячки != хомячки

так что иди, отнаследуй конс-ячейку (ведь в лиспе все объект, как ты утверждал)

после и поговорим.

Ну так они в любом языке могут быть библиотеками.

В том то и дело, что нет. Будет уровень когда реализовать нечто будет возможно только с помощью бустрапа. В CL я не вижу такоого потолка (ну просто это моё такое наблюдение, всё может быть расширением с компиляцией в CL -> и т.д.).

Шаблоны в си? Алгебраические типы с автоматическим построением катаморфизма в Python? А в рамках принятой в СL схемы мета-вычислкений (reader -> macroexpander -> evalutor -> compiler, причём это цепочка может раскручиваться рекурсивно, на любом этапе) это возможно.

Угу, «новая» максима для «новых» людей: «Убей в себе метахомячка!».

> Наличие в языке системы типов, абстракций лямбда исчисления, средств алгебраического и категориального программирования - всё это строго ортогонально «лиспам» и их s-выражениям. Все эти вещи в «лиспах» как раз легко могут быть библиотеками.

Если взять цветной бумаги,
Краски, ножници, и клей,
И немножечко отваги --
Можно сделать сто рублей.

Успехов в приделывании к лиспам таких библиотек :-)

отнаследуй конс-ячейку

Пожалел бы уж бедную конс-ячейку :)

>> Ну так они в любом языке могут быть библиотеками.

В том то и дело, что нет.

...

А в рамках принятой в СL схемы мета-вычислкений (reader -> macroexpander -> evalutor -> compiler, причём это цепочка может раскручиваться рекурсивно, на любом этапе) это возможно.

Похоже, наличие компилятора в стандартном рантайме - это одновременно +10 к мегаломании -10 к интеллекту.

Успехов в приделывании к лиспам таких библиотек :-)

Считаешь что оно нужно? Может стоит пойти ещё дальше.

Например, на CL уже есть реализация metamath.

Но ты ведь на самом деле молчишь, да?