Хаскель плох (+)

Хаскель конечно же плох. Но сравнивать parsec и antlr некорректно, это разного класса вещи. Сравнивать надо Happy и antlr, а они вполне сравнимы. Кажется даже оба GLR умеют (мне то пофиг, я bison использую).

Где ты там взял ручные оптимизации и замусоренный код? Решение совершенно наивное.

Ну и бред -- parsec к antlr вобще никакого отношения не имеет. А вот с happy я готов сравнивать.

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

Да и потом, выходит, haskell ничуть не выразительнее явы и си, раз его средств метапрограммирования не хватает для создания эффективных парсеров, и приходится применять всё те же кодогенераторы. А с ленивостью, выходит, надо постоянно бороться. Что-то здесь нечисто, ребята.

Все чисто. Просто не надо путать комбинаторы на бектрекинге с генераторами стейтмашин.

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

Вот например: мои самопальные парсер с лексером явы 1.0 на alex/happy съедают 280k кода в секунду. Не думаю, что это быстрее аналогичного на yacc, но во всяком случае -- сравнимо. И это при том, что я не занимался никакой оптимизацией, наоборот, мои структуры данных весьма убоги.

>Что-то здесь нечисто, ребята.

Это у вас в нечистых языках все нечисто, а у нас как раз все чисто.

Да конечно затачивать программы на скорость сложнее чем в других языках, но можно, если сильно нужно. Но чаще всего читабельность и гибкость кода заруливает оптимизации (которые как известно корень всех зол). Зато насколько проще писать парсеры на parsec'е. И на неучебных задачах его скорость вполне приемлема для большинства применений.

Хаскель плох, потому что плох GHC. А GHC плох, потому что Хаскель чрезмерно усложнён. Его создателям не хватает здорового чувства меры и гармонии, поэтому они тащат в свой язык всё, что ни попадя, чисто ради интереса. Ну, в этом есть смысл, пускай Хаскель будет экспериментальным языком, из которого можно заимствовать удачные фичи и идеи. Или спецязыком для быстрого решения определённого класса задач. А на эффективную компиляцию надеяться просто не стоит, тогда и разочарований не будет.

А ленивость и чистота отнюдь не означает неэффективность, даже на нынешних фон-неймановских машинах. Неэффективность GHC - исключительно от кривых рук разработчиков. Вон, Clean, при том, что его создатели сплошь махровые вендузятники и маководы, нечеловечески шустр, а по выразительности и концептуальной чистоте местами даже превосходит Хаскель. И берусь заявить, его uniqueness typing - гораздо более удачная концепция, чем пресловутые монады. Кстати, Clean наконец-то портировали на AMD64, так что рекомендую.

> И берусь заявить, его uniqueness typing - гораздо более удачная концепция, чем пресловутые монады.

А что, uniqueness typing тоже позволяет делать парсеры?

А ты, умный. По-твоему, на клине нельзя делать монадические комбинаторы, лол? Вылазь из танка, фанбой, там прямо в коробке есть пара библиотек.

> А GHC плох, потому что Хаскель чрезмерно усложнён.

Простите, но я сейчас оборжусь. Хотя, может быть, вы Явы и С++ не видели?

> И берусь заявить, его uniqueness typing - гораздо более удачная концепция, чем пресловутые монады.

Не осилили монады кроме State?

Монады не Ъ - arrows наше фсио

> Монады не Ъ - arrows наше фсио

А еще функторы и моноиды :-)

> Простите, но я сейчас оборжусь. Хотя, может быть, вы Явы и С++ не видели?

Говорить: "А у соседа ещё хуже!" - не признак ума. Давайте сравним, например, с CL и Схемой. Компилятор схемы я сам вполне в силах написать, если жизнь заставит, да и без меня их написано немало. А компилятор хаскеля в машинный код пока существует только один, наш любимый чудовищный GHC, а после того, как я заглянул к нему внутрь, мне даже PHPшный кошмар MediaWiki больше не кажется кошмаром. Всё познаётся в сравнении, друг мой.

Да я их даже на жабоскрипте делал, только выглядели по-уродски. Просто uniqueness - это вариации на тему "как сделать монаду State". И всё.

А уж до чего просто писать компилятор с языка ассемблера...

> Давайте сравним, например, с CL и Схемой.

Ухаха, квотирования, специальные формы, куча диалектов типа CLOS -- это простой язык? А как насчет MAPCAR, DEFUN, SETQ, CAR, CDR?

> Компилятор схемы я сам вполне в силах написать, если жизнь заставит, да и без меня их написано немало.

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

> А компилятор хаскеля в машинный код пока существует только один,

http://haskell.org/haskellwiki/Implementations -- там еще четыре компилятора в машинный код, плюс yhc в байт-код. Конечно, они все не "production", но эксперименты на них обкатываются прекрасно. Так и должно быть -- сообщество же не может, как лисперы, распылять силы на десяток реализаций-диалектов.

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

Вот и для Хаскеля, при всей его расчудесности, хороших компиляторов нет. Это означает, что язык плохо подходит для нынешних реалий и практического программирования. Создатели Clean, напротив, при всей своей вендо-макинтоидной неотёсанности (чего стоит только каталог Clean System Files, например), вполне умеют сопоставлять свои фантазии с жестокой фон-неймановской реальностью, и выдают на-гора быстрый компилятор и удобный язык. И да, uniquess typing заведомо проще реализовать эффективно, чем вашу монаду state. И научиться эффективно пользоваться им тоже проще.

В общем, нужен грамотный баланс между концептуальной чистотой и практичностью. В Clean он есть, в OCaml есть, в Питоне есть, а вот в Хаскеле - нет.

Остальные три - это HBC, Helium и Jhc? Один игрушечный, второй экспериментальный, а третий не поддерживается, спасибо, достойно. Чем ещё можете похвастать?

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

Вот этого не надо. Где не распыляют силы, так это в сообществе OCaml.

> Вот и для Хаскеля, при всей его расчудесности, хороших компиляторов нет.

Еще раз, медленно и для тупых: чем плох ghc? Тем, что медленнее компилятора clean на четверть? Или тем, что писали не для обучения, и в код надо смотреть с подготовкой?

> Остальные три - это HBC, Helium и Jhc?

Я же пишу, они существуют для экспериментов, а не для распыления сил.

Повторю ещё раз: GHC плох тем, что заставляет думать не столько о решаемой задаче, сколько об особенностях самого GHC. Наивный же код чаще всего вылетает по нехватке памяти.

И да, он становится лишь на четверть медленнее только в результате нетривиальных и уродливых ручных оптимизаций. На простом наивном коде он отстаёт от Клина ГОРАЗДО сильнее.

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

Если вы будете отрицать, что код самого GHC уродлив, я вынужден буду счесть вас обыкновенным троллем.

Хватать то их хватает, теоретически, а на практике никто аналога Happy на Template Haskell не реализовал.

Разница же в том, что Parsec - это вообще не метапрограммирование, это обычные конструкции языка, тогда как Spirit вполне себе метапрограммирование, с возможностью кой каких оптимизаций во время компиляции. Они не очень сопоставимы.

Не поевришь, эту фигню можно даже на Схеме делать, у которой вообще карринга нет.

> Если вы будете отрицать, что код самого GHC уродлив, я вынужден буду счесть вас обыкновенным троллем.

У меня нет оснований считать вас не-троллем, причем разбирающимся в коде ghc. Simon Peyton Jones по мне авторитетнее.

> Повторю ещё раз: GHC плох тем, что заставляет думать не столько о решаемой задаче, сколько об особенностях самого GHC. Наивный же код чаще всего вылетает по нехватке памяти.

Ага, а вот и вскрыли -- не осилили ленивость в foldl? ;-)

> И да, он становится лишь на четверть медленнее только в результате нетривиальных и уродливых ручных оптимизаций. На простом наивном коде он отстаёт от Клина ГОРАЗДО сильнее.

ГОРАЗДО -- это бред, конечно же. Не спорю, у Клина компилятор весьма хорош -- скорее всего потому, что его авторы занимались оптимизацией, пока авторы ghc тратили время на GADT, short cut fusion, functional dependencies, associated types, existentials и прочие замечательные научные изыскания.

Честно говоря, я не склонен верить, что код на хаскеле "без извращений" будет медленнее чем аналог на клине более, чем в два раза. Желаете доказать, приведите пример.

Ты что-то пропустил, или не знаешь, что жабоскрипте карринга ТОЖЕ нет?