ну, если все будут писать IDE и компиляторы, то кто же будет заниматься прикладными вещами? ;) А если серьезно: да проблема тут не в том, а в изобретении велосипеда. Если хочется свою IDE под винду, что мешает написать его для существующей зрелой реализации? Как говорил один мой знакомый: это стандартное упражнение для всех функциональщиков — написать интерпретатор Lisp'а (а потом соревноваться, у кого быстрее работает). Но делать из этого серьезный проект… да нет, конечно, вперед. Меня, просто, изначально заинтересовала мотивация, стоящая за этим: может, от не знания того, что есть, или какая иная (о чем я, к сождалению, так ине узнал).
у LispWorks есть версия для студентов.
IDE для LIsp под винду тоже есть. Тот же CUPS Plugin для Eclipse.
А сказать «с высоты олимпа», как вы говорите, стоит. Потому чтоб взоюраться на этот Олимп (пусть это даже какой-то не Олимп, а обычный холмик), приходится проходить через непонимание, заблуждения, предрассудки (как то: у Лиспа нет поддержки графики, нет IDE, нет того, третьего, десятого — а все то есть).
И еще, представьте себе, что кто-то прийдет и напишет: я тут на выходных сваял инетрпретатор Python, соответствующий спецификации версии 0.8, он на VBscript написан и имеет биндинги к виндовому гуи. Это проект, чтобы научить студентов, как нужно программировать, поскольку у Питона нет нормальных бесплатных IDE под Виндоус. Как бы это выглядело, смешно, да?
Тренировка мозгов — это, конечно, неплохая личная мотивация, не спорю. Однако, согласитесь, нужно еще и многие другие вещи тренировать. Например, NIH-синдром считается весьма вредным качеством для разработчика
А в чем смысл создания еще одного диалекта? Почему вы не приложилось к работе над реализациями существующих? Ведь язык сам по себе — это игрушка, пока у него не появляется сопутствующей экосистемы в виде разработчиков и написанного ими. Понять подобную разработку еще можно было, если бы вы хотели сказать какое-то новое слово (как, например, разработчик Lisp'а Clojure), однако в данном случае, похоже, происходит повторение «давного пройденного материала»…
спасибо за ссылку, прочитал не без интереса
возникли вопросы:
* причем здесь Хаскелл и его семантика, если:
— все описано на Python
— вместо названия «монада» можно было использовать концепцию замыкания (или я плохо понял)
* где, собственно, разбор библиотеки Parsec? :)
(т.е. вопрос был в том плане, чтобы увидеть разбор именно реального, а не игрушечного кода)
> Необходимо сымитировать состояние в языке, который это не поддерживает.
Это необходимость совершенно не связанная с алгоритмом, т.е. искусственная. Если язык не поддерживает состояний, то не нужно ничего пытаться имитировать: решайте без состояний. ;)
> Не используйте же. Кто вам мешает? :)
Покажите решение той задачи без оных сложных абстракций
> Это нам дает возможность выражать термины прикладной области в языке программирования. Простой пример: комбинаторный разбор (предиктивный рекурсивный спуск) с помощью Parsec. Сравните то, что написано вручную и то, что написано с использованием такой библиотеки, профит (модульность, reuse, etc.) очевиден.
Во-первых, это можно сделать и другими способами. Яркий пример: метапрограммирование. И оно работает, о чем могу сказать на своем опыте и показать, соответственно, на примерах.
Во-вторых, конечно же, код, написанный с помощью библиотеки будет намного лучше ad hoc кода, написанного вручную. Но это касается не только Parsec/Haskell. Во всех языках программирования есть библиотеки для парсинга. Если бы кто-то нашел самую лучшую библиотеу из другого языка (наверно, даже не функционального) и сравнил, было бы очень интересно. Вполне допускаю, что Haskell-решение намного лучше. Вот это я и хотел бы увидеть, а не алгоритм двудольности графа, который намного хуже аналогов
> Алсо, если вы не знаете, зачем нужны абстракции, то это как бы не значит, что эти абстракции возведены ради абстракций. Так-то.
Если их использование не обоснованно реальной потребностью, то они не нужны. Зачем подниматься на 10-й этаж, чтобы спуститься на 2-й?
> Да без проблем же. Напишите интерпретатор Пролога на Си и на Хаскеле и сравните.
А почему именно на С? С — это тот же ассемблер. Посмотрите на интерпретатор Prolog'а на Common Lisp (есть 2 варианта: в PAIP и On Lisp).
> Ошибки в программах были, есть и будут. Цель программиста при использовании языка — переложить как можно больше работы по обнаружению ошибок на компилятор.
С одной оговоркой: при прочих равных условиях
> По поводу сложности. Монады, функторы и прочая — это не язык как таковой, а шаблоны проектирования над языком, готовые, глубоко интегрированныые, легко соединяемые и хорошо отлаженные. Простые программы могут обойтись и без них
Без монад не может обойтись ни одна программа на Haskell. И даже простая программа про двудольность графа не смогла обойтись без более сложных конструкций (монадный трансформер). Вот тут то и возник вопрос: зачем? Т.е. каждой задаче должен быть адекватен уровень абстракции (не нужно подниматься на 10-й этаж, чтобы потом спустится на 2-й). Понимаете, если бы я не знал о других подходах (хинт: мета-программирование), я бы сказал, «да, наверно, при по-настоящему сложных задачах по другому не получится. А так я могу сказать: да, это один из подходов, возможно, работающий, но очень трудно проверить (вот сделал бы кто-то разбор того, как устроена библиотека Parseс, и где тут реальное преимущество от монад, которое нельзя бы было получить другим путем, стало бы намного легче об этом размышлять). И, все равно, есть и другие, возможно даже более продуктивные подходы. Стоит сравнивать… (конечно же, не с С, как предлагается в ветке выше)
естественно, каждый из нас высказывет свою «личную» позицию. Другое дело, что она может быть более или менее обоснованна. И в других ветках я раскрывал свои основания.
на счет этого алгоритма: моя трактовка другая и она обоснованна, ваша — как по мне, нет.
на счет хаскелл-комьюнити — примерно то же самое. Моя позиция: люди занимаются этим, чтобы разминать мозги, так давайте это и называть своими словами. К реальному программированию пока что имеет мало отношения.
На счет ваших придирок к словам, типа «нравится», «obscure». Вы не совсем обращаете внимание на контекст использования. Например, слово obscure было употреблено в контексте, что «нельзя сравнивать». А раз нельзя, то любое слово можно использовать. И obscure, и божественный…
Я как раз делал сравнение на реальном примере данного алгоритма. Можно сделать сравнение на других примерах. Перспективный вариант: сравнить darcs с git и mercurial. Например, на тему того, насколько расширяемые проекты, как проработано API, всякая статистика…
А предрассудки есть у всех. В какой-то степени Haskell-комьнити занимается троллингом глобально, поскольку:
* присвоило себе функциональную парадигму
* претендует на то, чтобы быть языком по-умолчанию в вузах
* ну и, разумеется, снобизм по отношению к другим языкам и подходам. «Тут все так круто, что ваш императивный код даже не стоит сравнивать». А давайте сравним, что ли? Есть случаи, когда очень даже выигрывает Haskell, а есть такие, где проигрывает. Проблема в том, что вы закрываете глаза на вторую часть, и считаете, что это все мелочи. «Если вам что-то не нравится в нашем языке, значит вы его, просто, недостаточно изучили, недостаточно понимаете, так что молчите в тряпочку», так?
(Ну а если следовать вашей логике, что «Для реальных проектов это не применимо. Для игрушечных не даёт достаточно данных.», то тогда зачем поднимать тему Haskell'а? Ну, еще один obscure язык, ничем не лучше и не хуже других: ведь остальные утверждения — чистая отсебятина тех, кто язык знает или не знает ;)
Ну уж, простите, что осмелился. Во-первых, если вы вчитаетесь, то наброс был больше на Haskell-комьнити. Во-вторых, то, что не делаю этого сейчас не значит, что вообще никогда не делал. Ну и, в-третьих, если по сути возразить ничего не остается, приходиться переходить на личности, да?
кстати, я не вижу ответа на вопрос «я знаю, что такие есть, но также знаю, что есть такие, где это дает наоборот проигрыш. Согласны?» желательно с хотя бы парой примеров того, где это дает существенный выигрыш
> ну хорошо это не только ваша проблема. это проблема кучи комментаторов. что изменилось?
изменилось то, что некоторые из них «имеет хоть какой-то опыт написания программ на Хаскелле»
> сюрприз! сюрприз! код на хаскле напрямую реализует алгоритм
наверно, мы с вами не совсем одно и то же понимаем под словом напрямую. Я имел в виду количество дополнительной абстрактной информации, которую нужно держать в голове, чтобы понять реализацию. Для варианта Лиспа нужно понимать, что такое анонимная функция, замыкание, map, хеш-таблица, список, пара. Для Python'а это примерно то же ± list-comprehesions. Все это нужно понимать и в случае с Haskell'ом, но тут еще добавляется монады, монадные трансформеры, pattern matching, что я еще забыл? Т.е. концептуальная нагруженность решения возрастает. А что это нам дает? (в данном случае вопрос риторический) И, вы знаете, этот пример очень показательный. Оказывается, что так бывает и не только в таких тривиальных случаях. Мой вывод из этого: не стоит городить абстракции ради самих абстракций. Покажите мне лучше задачу, где их применение дает реальные преимущества (я знаю, что такие есть, но также знаю, что есть такие, где это дает наоборот проигрыш. Согласны?)
> а когда в одной строке записано десять русских слов вас это не смущает?
нет, если это не 10 предлогов подряд
> вам синтаксис Haskell не нравится? ну не читайте, не пишите… никто вас не заставляет =)
спасибо за совет, я, в общем-то, так и делаю =)
Но это было одно из замечаний. Другие раскрыты в других ветках обсуждения.
Вам могу сказать в ответ: не нравится мое мнение, не читайте, не комментируйте ;)
> Во-первых, решения antilamer'а совершенно прозрачно для тех, кто имеет хоть какой-то опыт написания программ на Хаскелле
расскажите это тем, кто комментировал ;)
> Заметим, что код на Питоне кажется вам более понятным исключительно потому, что все императивные языки по сути дела похожи.
думаю, нет: потому, что он довольно таки напрямую реализует алгоритм
> при наличии определённой культуры чтения
когда в одной строке записано 10 операций — это очень трудно понять не зависимо от культуры. Оно либо клацает в мозгу (т.е. синтаксис просто «на слуху»), либ происходит переполнение стэка
> вы что утверждаете что PHP/Javascript/Shell/Lisp лишены особенностей
PHP/Javascript/Shell — полно, Lisp, Forth — почти нет, довольно чистые в плане синтаксиса языки — Python, Java. Вообще, этот вопрос нужно рассматривать по каждому языку отдельно. Проблема Haskell'а в том, что такой синтасис у него не по глупости (как в PHP или JS), а намеренно (из-за максимализма и, я бы даже сказал, аутизма)
если для вас то, что я сказал — очевидно, просто вы воспринимаете это по своему, то я не против (так, вообще, всегда :)
на счет регулярности синтаксиса: я имел в виду, разумеется, не регулярную грамматику, а регулярность в смысле английского слова uniformity, т.е. единообразность. Как пример можно привести… нет, даже не Lisp (с этим понятно), а Python, у которого весь синтаксис следует определенным базовым принципам. У Haskell'а везде операторы: где инфиксные, где префиксные (где, вообще, обволакивающие: типа `fmap` ;). Посмотрите, первая глава Real World Haskell посвящена тому, как правильно писать -1, чтобы не получить ошибки
trac.clozure.com/ccl
www.sbcl.org/platform-table.html
Вот IDE:
www.bitfauna.com/projects/cusp/
не говоря уже про Lisp Works: если вас смущает необходимость платить, то есть www.lispworks.com/products/lispworks.html#personal
lisp-univ-etc.blogspot.com
IDE для LIsp под винду тоже есть. Тот же CUPS Plugin для Eclipse.
А сказать «с высоты олимпа», как вы говорите, стоит. Потому чтоб взоюраться на этот Олимп (пусть это даже какой-то не Олимп, а обычный холмик), приходится проходить через непонимание, заблуждения, предрассудки (как то: у Лиспа нет поддержки графики, нет IDE, нет того, третьего, десятого — а все то есть).
И еще, представьте себе, что кто-то прийдет и напишет: я тут на выходных сваял инетрпретатор Python, соответствующий спецификации версии 0.8, он на VBscript написан и имеет биндинги к виндовому гуи. Это проект, чтобы научить студентов, как нужно программировать, поскольку у Питона нет нормальных бесплатных IDE под Виндоус. Как бы это выглядело, смешно, да?
Хотите сделать компиляцию в LLVM — сделайте backend для SBCL
(SBCL тоже с горем-пополам работает. Вот где, кстати, не помешали бы усилия...)
возникли вопросы:
* причем здесь Хаскелл и его семантика, если:
— все описано на Python
— вместо названия «монада» можно было использовать концепцию замыкания (или я плохо понял)
* где, собственно, разбор библиотеки Parsec? :)
(т.е. вопрос был в том плане, чтобы увидеть разбор именно реального, а не игрушечного кода)
Чистота — очень абстрактное понятие. Вот философские размышления на близкую тему: groups.google.com/group/comp.lang.lisp/msg/07b915645de0cec7
> Необходимо сымитировать состояние в языке, который это не поддерживает.
Это необходимость совершенно не связанная с алгоритмом, т.е. искусственная. Если язык не поддерживает состояний, то не нужно ничего пытаться имитировать: решайте без состояний. ;)
Покажите решение той задачи без оных сложных абстракций
> Это нам дает возможность выражать термины прикладной области в языке программирования. Простой пример: комбинаторный разбор (предиктивный рекурсивный спуск) с помощью Parsec. Сравните то, что написано вручную и то, что написано с использованием такой библиотеки, профит (модульность, reuse, etc.) очевиден.
Во-первых, это можно сделать и другими способами. Яркий пример: метапрограммирование. И оно работает, о чем могу сказать на своем опыте и показать, соответственно, на примерах.
Во-вторых, конечно же, код, написанный с помощью библиотеки будет намного лучше ad hoc кода, написанного вручную. Но это касается не только Parsec/Haskell. Во всех языках программирования есть библиотеки для парсинга. Если бы кто-то нашел самую лучшую библиотеу из другого языка (наверно, даже не функционального) и сравнил, было бы очень интересно. Вполне допускаю, что Haskell-решение намного лучше. Вот это я и хотел бы увидеть, а не алгоритм двудольности графа, который намного хуже аналогов
> Алсо, если вы не знаете, зачем нужны абстракции, то это как бы не значит, что эти абстракции возведены ради абстракций. Так-то.
Если их использование не обоснованно реальной потребностью, то они не нужны. Зачем подниматься на 10-й этаж, чтобы спуститься на 2-й?
> Да без проблем же. Напишите интерпретатор Пролога на Си и на Хаскеле и сравните.
А почему именно на С? С — это тот же ассемблер. Посмотрите на интерпретатор Prolog'а на Common Lisp (есть 2 варианта: в PAIP и On Lisp).
С одной оговоркой: при прочих равных условиях
> По поводу сложности. Монады, функторы и прочая — это не язык как таковой, а шаблоны проектирования над языком, готовые, глубоко интегрированныые, легко соединяемые и хорошо отлаженные. Простые программы могут обойтись и без них
Без монад не может обойтись ни одна программа на Haskell. И даже простая программа про двудольность графа не смогла обойтись без более сложных конструкций (монадный трансформер). Вот тут то и возник вопрос: зачем? Т.е. каждой задаче должен быть адекватен уровень абстракции (не нужно подниматься на 10-й этаж, чтобы потом спустится на 2-й). Понимаете, если бы я не знал о других подходах (хинт: мета-программирование), я бы сказал, «да, наверно, при по-настоящему сложных задачах по другому не получится. А так я могу сказать: да, это один из подходов, возможно, работающий, но очень трудно проверить (вот сделал бы кто-то разбор того, как устроена библиотека Parseс, и где тут реальное преимущество от монад, которое нельзя бы было получить другим путем, стало бы намного легче об этом размышлять). И, все равно, есть и другие, возможно даже более продуктивные подходы. Стоит сравнивать… (конечно же, не с С, как предлагается в ветке выше)
на счет этого алгоритма: моя трактовка другая и она обоснованна, ваша — как по мне, нет.
на счет хаскелл-комьюнити — примерно то же самое. Моя позиция: люди занимаются этим, чтобы разминать мозги, так давайте это и называть своими словами. К реальному программированию пока что имеет мало отношения.
На счет ваших придирок к словам, типа «нравится», «obscure». Вы не совсем обращаете внимание на контекст использования. Например, слово obscure было употреблено в контексте, что «нельзя сравнивать». А раз нельзя, то любое слово можно использовать. И obscure, и божественный…
Я как раз делал сравнение на реальном примере данного алгоритма. Можно сделать сравнение на других примерах. Перспективный вариант: сравнить darcs с git и mercurial. Например, на тему того, насколько расширяемые проекты, как проработано API, всякая статистика…
А предрассудки есть у всех. В какой-то степени Haskell-комьнити занимается троллингом глобально, поскольку:
* присвоило себе функциональную парадигму
* претендует на то, чтобы быть языком по-умолчанию в вузах
* ну и, разумеется, снобизм по отношению к другим языкам и подходам. «Тут все так круто, что ваш императивный код даже не стоит сравнивать». А давайте сравним, что ли? Есть случаи, когда очень даже выигрывает Haskell, а есть такие, где проигрывает. Проблема в том, что вы закрываете глаза на вторую часть, и считаете, что это все мелочи. «Если вам что-то не нравится в нашем языке, значит вы его, просто, недостаточно изучили, недостаточно понимаете, так что молчите в тряпочку», так?
(Ну а если следовать вашей логике, что «Для реальных проектов это не применимо. Для игрушечных не даёт достаточно данных.», то тогда зачем поднимать тему Haskell'а? Ну, еще один obscure язык, ничем не лучше и не хуже других: ведь остальные утверждения — чистая отсебятина тех, кто язык знает или не знает ;)
кстати, я не вижу ответа на вопрос «я знаю, что такие есть, но также знаю, что есть такие, где это дает наоборот проигрыш. Согласны?» желательно с хотя бы парой примеров того, где это дает существенный выигрыш
изменилось то, что некоторые из них «имеет хоть какой-то опыт написания программ на Хаскелле»
> сюрприз! сюрприз! код на хаскле напрямую реализует алгоритм
наверно, мы с вами не совсем одно и то же понимаем под словом напрямую. Я имел в виду количество дополнительной абстрактной информации, которую нужно держать в голове, чтобы понять реализацию. Для варианта Лиспа нужно понимать, что такое анонимная функция, замыкание, map, хеш-таблица, список, пара. Для Python'а это примерно то же ± list-comprehesions. Все это нужно понимать и в случае с Haskell'ом, но тут еще добавляется монады, монадные трансформеры, pattern matching, что я еще забыл? Т.е. концептуальная нагруженность решения возрастает. А что это нам дает? (в данном случае вопрос риторический) И, вы знаете, этот пример очень показательный. Оказывается, что так бывает и не только в таких тривиальных случаях. Мой вывод из этого: не стоит городить абстракции ради самих абстракций. Покажите мне лучше задачу, где их применение дает реальные преимущества (я знаю, что такие есть, но также знаю, что есть такие, где это дает наоборот проигрыш. Согласны?)
> а когда в одной строке записано десять русских слов вас это не смущает?
нет, если это не 10 предлогов подряд
> вам синтаксис Haskell не нравится? ну не читайте, не пишите… никто вас не заставляет =)
спасибо за совет, я, в общем-то, так и делаю =)
Но это было одно из замечаний. Другие раскрыты в других ветках обсуждения.
Вам могу сказать в ответ: не нравится мое мнение, не читайте, не комментируйте ;)
расскажите это тем, кто комментировал ;)
> Заметим, что код на Питоне кажется вам более понятным исключительно потому, что все императивные языки по сути дела похожи.
думаю, нет: потому, что он довольно таки напрямую реализует алгоритм
> при наличии определённой культуры чтения
когда в одной строке записано 10 операций — это очень трудно понять не зависимо от культуры. Оно либо клацает в мозгу (т.е. синтаксис просто «на слуху»), либ происходит переполнение стэка
> вы что утверждаете что PHP/Javascript/Shell/Lisp лишены особенностей
PHP/Javascript/Shell — полно, Lisp, Forth — почти нет, довольно чистые в плане синтаксиса языки — Python, Java. Вообще, этот вопрос нужно рассматривать по каждому языку отдельно. Проблема Haskell'а в том, что такой синтасис у него не по глупости (как в PHP или JS), а намеренно (из-за максимализма и, я бы даже сказал, аутизма)
на счет регулярности синтаксиса: я имел в виду, разумеется, не регулярную грамматику, а регулярность в смысле английского слова uniformity, т.е. единообразность. Как пример можно привести… нет, даже не Lisp (с этим понятно), а Python, у которого весь синтаксис следует определенным базовым принципам. У Haskell'а везде операторы: где инфиксные, где префиксные (где, вообще, обволакивающие: типа `fmap` ;). Посмотрите, первая глава Real World Haskell посвящена тому, как правильно писать -1, чтобы не получить ошибки
ps. и еще посмотрите дискуссию в моем блоге