четверг, июля 03, 2008

Язык имеет значение

Все мы слышали, что есть Хаскел. Все мы знаем, что он крут. Крут настолько, что многие его даже боятся.

Все мы знаем, что программы на Хаскеле короче и быстрее пишутся. Те, кто писал на Хаскеле, уже с трудом могут заставить себя использовать другой язык.

Так какого черта мы пишем на чем-то другом?

Мне кажется, мы просто ссым!

Почему? Чем мы себя обманываем? Почему боимся «рисковать», когда риск заключается как раз в неиспользовании Хаскела?

Лично я сыт по горло от собственных же отмазок. Проведя анализ ВСЕХ своих проектов, сделанных за последние 9 лет, я пришел к выводу, что ВСЕ они (кроме драйверов и прошивок микроконтроллеров) могли бы быть сделаны на Хаскеле.

Но это не самое страшное. Самое страшное — это сколько времени было потеряно на низкоуровневые языки.

В проектах, написанных на C++, можно было бы сэкономить 30-40% времени разработки (а при наличии готовых библиотек, еще больше). Страшно вспомнить, сколько я их отлаживал, и, все равно, раз в месяц программа таки падала.

В проектах, написанных на C++, питоне и окемле, можно было бы срезать до 20-25% времени, только за счет отказа от С++ и питона. Переход на Хаскел дал бы еще минимум 10%.

Кстати, запомните — C++ и питон нужны только для того, чтобы подняться уровнем выше C. Если вы уже используете более высокоуровневый язык (окемл или хаскел), то за использование чего-либо, кроме C для самых критичных мест, надо сильно бить себя по рукам — вы просто тратите время зря. Все, что выше C надо писать на Хаскеле, а не С++.

Даже учтя, что последние 9 лет я не только работал, но еще и ходил в техникум и институт, все равно я потерял минимум 1.5 года жизни из-за ничем не оправданного применения С++ (и еще пару месяцев из-за питона). Я идиот. Не повторяйте моей ошибки, и не ссыте применять то, что действительно удобно, приятно и позволяет решать задачу, а не проблемы.

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

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

PS для менеджеров: вам дороги сроки сдачи проекта? Уже догадались, что надо использовать, а чему сказать нет?

41 комментарий:

Yuriy Volkov комментирует...

было бы интересно услышать побольше о самом анализе

Павел комментирует...

Мне несколько сложно оспорить ваш основной тезис, по причине того, что я не писал ничего на хаскеле, но тем не менее я попытаюсь. Я неоднократно встречал одно и то же мнение от людей, пробовавших хаскель в промышленном программировании. И выводы у этих людей простые:
1) Язык крут, время реально экономится, отладка проще, проще даются большие модификации на финальных стадиях разработки.
2) Синтаксис ввода-вывода в хаскеле реализован через жопу. Один товарищ, помнится прямо говорил - "я заебался оборачивать в монады".
3) Людей под хаскель найти почти невозможно. И что хуже всего, практически невозможно переучить имеющихся, т.к. язык реально сложен в освоении.

Общий итог этих разговоров был один - хаскель для промышленного программирования слабо пригоден. А что пригодно? Проверенные временем вещи - Common LISP, Erlang.

В принципе, я склонен согласится со всем сказанным - я немного писал на CommonLISP (мнение о его сложности преувеличено), сейчас пишу сервер на Эрланге (нравится), а вот книга Душкина так и стоит на полке.

dulanov комментирует...

C++ однозначно устарел и мы вообще отказались от него полностью, он реально не нужен абсолютно. Стандартная связка C и OCaml/Python/Ruby полностью все перекрывает. С автором по вопросу отказа от С++ полностью согласен.

Про Haskell труднее, в промышленное применение его я пока верю с трудом. Erlang - вот это да, это язык будущего и его применение только для теллекоммуникаций не совсем оправдано.

Мой текущий выбор: C (низкоуровневое программиорвание критических кусков кода), Objective C (MacOS X, iPhone), Ruby (скриптование и тулзы для десктопа Linux/Windows), RubyOnRails (Веб-разработка), Erlang (высоконагруженные сервисы в Интернете).

Про монады было бы интересно услышать, это реальный геморой же.

lg комментирует...

серебряной пули нет. Исплоьзовать нужно то что максимально подходит для решения задачи. Касательно C++, утверждаю что для ЛЮБОЙ задачи ВСЕГДА найдётся лучшее средство для её решения нежели C++. Неоправдано писать на C++ даже если уже есть огромная наработанная кодабаза на нём, которую нужно использовать. И здесь я с тобой согласен.

Касательно Haskell, есть задачи, для которых Haskell не очень хорош. С точки зрения самого языка Haskell смотрится выиграшней на фоне остальных, но есть много других факторов, которые нужно учитывать при выборе средства для решения конкретной задачи. Например, для того же Web ROR или django выглядят намного выгоднее нежели haskell и любой существующий web framework для него. Эта ситуация может измениться в будущем. Ещё, например тебе нужна какая-нибудь программа, которая дёргает данные откуда-нибудь, немного обрабатывает их и кладёт в базу. Нужно чтобы её могли запускать с компа, с openwrt устройств, с iphone и с nokia n800 - python идеальное средство тут. И эта ситуация можно измениться в будущем, но мы же живём в настоящем и решаем чаще задачи настоящего.

Кстати, вот вспомнился тред чела, который быстренько переписал Норвиговский спел-чекер на Haskell, а потом неделю разбирался почему он так плохо работает. Возможно, что даже для такой задачи python подходит лучше :)

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

sash_ko комментирует...

С++ конечно устарел, но пока еще не устарели кадры (в смысле люди, пишущие на нем). Поэтому врядли менеджеры прислушаются к совету. Собрать команду С++ (С# или даже python) программистов нааааамного проще и быстрее.

Интересно, на чем основаны цифры, определяющие сэкономленное время (30-40%, 20-25%)?

Vladimir Shabanov комментирует...

Синтаксис ввода-вывода в хаскеле реализован через жопу. Один товарищ, помнится прямо говорил - "я заебался оборачивать в монады".

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

Людей под хаскель найти почти невозможно.

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

И что хуже всего, практически невозможно переучить имеющихся, т.к. язык реально сложен в освоении.

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

А про обучение -- у нас человек смог где-то месяца за 1.5-2 освоить хаскел в достаточной мере, чтобы написать на нем GUI тулзу. И это человек, за плечами которого, кроме 7 лет работы системным администратором, только два года программирования, причем на С и без GUI.

Так что не так страшен черт, как его малюют.

хаскель для промышленного программирования слабо пригоден.

Может быть лет 10 назад, когда у него было совсем мало библиотек и был слабый оптимизатор, он и был мало пригоден, но сейчас уже нет.

А что пригодно? Проверенные временем вещи - Common LISP, Erlang.

Оба этих языка стоят ступенью ниже хаскела и производительность труда на них тоже ниже.

а вот книга Душкина так и стоит на полке.

Не читал, но народ говорит, что не самая лучшая книжка для начинающего.

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

Vladimir Shabanov комментирует...

Про Haskell труднее, в промышленное применение его я пока верю с трудом.

А что тут верить. Его надо применять. Может для начала не так промышленно. Можно начать с мелких проектов и постепенно переводить под него всё остальное.

Erlang - вот это да, это язык будущего и его применение только для теллекоммуникаций не совсем оправдано.

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

Плюс эрланга -- его относительная простота. Но это же и минус, т.к. высокоуровневые абстракции на нем делать уже тяжело.

Для одного из наших проектов был выбран эрланг, но мне думается, что хаскел показал бы себя там ничуть не хуже. Горячая замена кода там не нужна, огромное кол-во процессов тоже. А вот логики оказалось хоть отбавляй.

Мой текущий выбор: C (низкоуровневое программиорвание критических кусков кода)

Гуд.

Objective C (MacOS X, iPhone)

Про iPhone не знаю, а для маков хаскел есть, и вроде даже cocoa к нему прикручивали.

Ruby (скриптование и тулзы для десктопа Linux/Windows)

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

RubyOnRails (Веб-разработка)

Не пробовал, но имею некоторое недоверие ко всяким RAD и frameworks из серии all included. Они хороши, если большая часть функционала проекта в них уже есть. Но как только дело доходит до специфичной логики, приходится с большим скрипом вкручивать ее в фреймвок, да еще и писать ее на не самом удобном языке.

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

Erlang (высоконагруженные сервисы в Интернете).

Если только высоконагруженные. Хотя производительность эрланга вроде как оставляет желать лучшего.

Кстати, ты же вроде на java писал. Переквалифицировался? )

Про монады было бы интересно услышать, это реальный геморой же.

Рома (человек, про которого я писал выше -- с небольшим опытом в программировании, освоивший хаскел за 1.5 месяца) читая сегодняшние комментарии с непониманием сказал: "И чего это они все так монад боятся?"

В общем, не знаю кто пустил слух, что монады -- это страшно. Обычной IO монады просто не замечаешь (выше монады назвали просто "синтаксисом ввода-выводы"). А остальными я особо не пользовался.

Хотя буквально пару дней назад заюзал какой-то monad transformer и ничего сложного не увидел: чуть посмотрел сорцы, как у людей сделано, чуть почитал доки с примерами, и сделал.

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

А уж от того, насколько после этого код приятнее стал, я до сих пор тащусь.

Vladimir Shabanov комментирует...

Например, для того же Web ROR или django выглядят намного выгоднее нежели haskell и любой существующий web framework для него.

Про фреймворки я уже сказал чуть выше. Как только мы не укладываемся во фреймворк и как только нужна специфичная бизнес-логика, язык и производительность труда на нем выходят на первый план.

Нужно чтобы её могли запускать с компа, с openwrt устройств, с iphone и с nokia n800 - python идеальное средство тут.

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

Haskell отличный кандидат, но работы ещё много ..

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

Vladimir Shabanov комментирует...

было бы интересно услышать побольше о самом анализе
--
Интересно, на чем основаны цифры, определяющие сэкономленное время (30-40%, 20-25%)?
--

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

30-40% это очень приблизительно, для проектов, которые я делал лет 5-7 назад. В основном они были связаны со звукозаписью и звукообработкой. Думаю, на аудиоанализе и работе со специфичными железками я бы сэкономил очень много (50-70%, в основном за счет отладки, и замены кучи убогих классов, на обычные HOF-ы). С GUI-частью, наоборот, было бы сложнее, хотя в результате я получил бы нормальное разделение логики и отображения (а может даже хороший GUI toolkit для хаскеля). Драйвера/прошивки на хаскеле написать бы не получилось. Вот в среднем и вышло 30-40%. А главное -- программа записи не падала бы раз в несколько недель.

Кстати, уже тогда я где-то находил товарища, который аналогичный проект за бугром писал на окемле. Было завидно, думал: "куда же мне со всем этим legacy податься". А сейчас понимаю, что надо было не ссать, а начинать потихоньку переписывать кусочки, и все новое писать уже на хаскеле (кемл можно было бы пропустить).

20-25% -- это уже про последний более менее большой проект (полностью трехмерная слот-игра).

Там для 3D-рендера был выбран OpenSceneGraph, связь с которым шла в начале через готовые питоновские байндинги (PyOSG), которые уже дергались из ocaml (это было проще чем сразу писать байндинги к С++ на кемле). Также был опять выбран кемл, т.к. накопилось legacy от предыдущей игры. Т.к. в OSG плохо поддерживалась скелетная анимация был полностью переписан проект osgCal (С++). Кроме того скрипт для экспорта текстур был сдуру написан на питоне.

Что в итоге. От питона отказался из-за утечек памяти в Pycaml и заброшенности PyOSG. Потерял огромную кучу времени делая библиотеку скелетной анимации (которая в итоге потащила за собой еще много чего) на С++. Кроме того, все больше и больше подташнивает от кемла, понимаю, что тут можно type class вкрутить, тут монадку, а тут не будет ограничений вывода типов в кемле, связанных с мутабельностью.

В итоге я понял, что надо было сразу писать тупой байндинг к OSG, а все остальное писать уже не в С++. Питон вообще не следовало использовать ни в каком виде (это шаг назад). А также все legacy можно было запрятать в объектный файлик и юзать его из хаскела (что, кстати, и хотел сделать изначально, но затем зассал, т.е. застрял в С++ и окемле).

Вот таким образом, по моим прикидкам, можно было бы сэкономить 20-25% времени, и уж не знаю, сколько процентов нервов.

Павел комментирует...

Владимир, а ты http://www.wagerlabs.com/blog/ читаешь? Человек, который его ведет, реально пишет на большом количестве разных функциональных языков. Хаскель любит. Одну из разработок (сервер) он последовательно реализовывал на лиспе, хаскелле и эрланге. Остановился на последнем.
А вообще в блоге очень много интересных сравнений.

dulanov комментирует...

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

Кстати, ты же вроде на java писал. Переквалифицировался? )

Да, было такое, но java это исключительно для корпоративного применения, язык уже сильно устарел, но как платформа ещё долго будет существовать. В общем это современный COBOL со всеми вытекающиими. Просто сейчас сильно переориентировался на Интернет-проекты, намного более динамичный и интересный ранок, чем формочки клепать к базам сидеть :-)

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

Vladimir Shabanov комментирует...

Владимир, а ты http://www.wagerlabs.com/blog/ читаешь?

Это один из блогов в Planet Haskell, так что иногда читаю. Но не так давно.

Одну из разработок (сервер) он последовательно реализовывал на лиспе, хаскелле и эрланге. Остановился на последнем.

Причем эту разработку он сейчас продает, т.к. она ему не интересна.

Про хаскелл у меня сложилось впечатление, что он просто не умеет его готовить и своим неумением составил достаточно плохое мнение у community о хаскеле. С другой стороны, благодаря ему было найдено несколько серьезных глюков в ghc.

Vladimir Shabanov комментирует...

Я и у тебя вижу сильную переориентацию за прошедшие несколько лет с OCaml на Haskell.

Да, несколько лет назад, я так же боялся монад, и думал "а как же писать на хаскеле что-то реальное".

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

Ты заинтриговал, надо будет начать использовать Haskell потихоньку.

В добрый путь.

Vladimir Shabanov комментирует...

С++ конечно устарел, но пока еще не устарели кадры (в смысле люди, пишущие на нем). Поэтому врядли менеджеры прислушаются к совету. Собрать команду С++ (С# или даже python) программистов нааааамного проще и быстрее.


В целом мне жалко и этих кадров и этих менеджеров. Собирать С++ команду (или изучать С++) сейчас равносильно копанию себе могилы. C# -- промежуточный этап, который можно пропустить. Если очень нужен .Net, то под него есть масса более других языков. Про python я уже говорил выше.

Если нужна небольшая команда, то найти несколько человек достаточно легко (есть куча народу, которым сильно надоел C++/C#/python).

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

Я понимаю, менеджерам не хочется рисковать и что-то менять. Но оставаясь на месте они рискуют еще больше.

_winnie комментирует...

Haskell: «Монады - сложные», ...
Pyhton: «Опечатался - и через полчаса работы это обнаруживаешь», ...
С++: «Вы ж не видите, что пишете излишне сложно», ...
С: «Вы же любой участок памяти можете перезаписать», ...

BTW, ты слишком часто приводишь в пример одного студента, который смог научиться за несколько месяцев :)
В мире случаются и не такие удивительные вещи. Вот например http://www.lenta.ru/news/2008/07/01/mosquito/

Vladimir Shabanov комментирует...

Haskell: «Монады - сложные», ...

В общем, это с непривычки так кажется. Люди template metaprogramming-ом занимаются, а 3-х ф-ий боятся.

Pyhton: «Опечатался - и через полчаса работы это обнаруживаешь», ...
С++: «Вы ж не видите, что пишете излишне сложно», ...
С: «Вы же любой участок памяти можете перезаписать», ...


А что, нормальное такое краткое резюме мох слов ;)

BTW, ты слишком часто приводишь в пример одного студента, который смог научиться за несколько месяцев :)

Другого примера под руками нет -- остальные хаскел уже знали. Кстати, не совсем студент. 7 лет админом работал. Просто захотел податься в программирование не на C.

В мире случаются и не такие удивительные вещи.

Осваивание хаскела за 1.5 месяца -- это не очень удивительно. Зефиров говорил, что potan освоил вообще недели за три.

Вот например http://www.lenta.ru/news/2008/07/01/mosquito/

Интересно только, где он потом нашел 10000 "убитых человеческими руками" комаров, чтобы выдать людям заказы )

Алексей (rewritoff) комментирует...

Страшно вспомнить, сколько я их �
b90
�тлаживал, и, все равно, раз в месяц программа таки падала

Анонимный комментирует...

Ждал поста, чтобы поглядеть на список претензий к питону. Кроме того, что нет статической типизации, претензий нет, как я погляжу.
Опечатки и ошибки проверяются утилитами pylint и pycheker (это давно стало нормой).
То, что кто-то там библиотеку какую-то не такую написал - вина автора библиотеки, а никак не языка. Это и было тем отнятием времени? Если да, то получается, что питон времени лишнего и не отнял.
Не совсем понятно, в чем именно питон был шагом назад.

-- ysae.livejournal.com

dulanov комментирует...

Наверняка пользуешся Linux в качестве рабочей платформы, попробуй фреймового оконного менеджера xmonad - клона dmw на haskell - полный улет, я совсем недавно открыл для себя что такое фреймовые оконные менеджеры и просто в восторге диком пребываю.

Vladimir Shabanov комментирует...

Я уже достаточно давно пользуюсь ion-ом (это и было основной причиной перехода под линукс). Еще у нас народ пользуется dwm, но мне он как-то не понравился тем, что сбоку видны окна, которые на данный момент не нужны. До xmonad я как-то так и не добрался. Попробую посмотреть.

Я сейчас еще перешел на conkeror -- emacs-подобный браузер с такими же клавиатурными сокращениями. Тоже все никак не нарадуюсь. Хотя для неподготовленного человека будет тяжко.

Vladimir Shabanov комментирует...

Кроме того, что нет статической типизации, претензий нет, как я погляжу.

Для меня это достаточная причина, чтобы отказаться от использования языка.

Опечатки и ошибки проверяются утилитами pylint и pycheker (это давно стало нормой).

Не знал о таких тулзах. Оно умеет встраиваться в интерпретатор?

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

Это и было тем отнятием времени?

Если не считать части, где не хватило библиотек, то да.

Если да, то получается, что питон времени лишнего и не отнял.

Как раз питон-то и отнял. pylint/pychecker не часть питона, а внешние тулзы, о которых я, например, только сегодня и узнал.

Не совсем понятно, в чем именно питон был шагом назад.

Просто питон более низкоуровневый язык. Где у него алгебраические типы данных, pattern matching, type classes?

Если pylint/pychecker умеют встраиваться в интерпретатор и делать нормальный вывод типов, тогда может питон и можно для чего-то использовать (хотя кому он нужен без pattern matching). А при наличии хаскела смысла в питоне не вижу (только если есть технические причины, роде платформы или библиотек).

AQUAGNU комментирует...

Две поправки: судя по прочитанному, у Вас весьма посредственное знание Python, поэтому Ваше "шаг назад" это абсолютно интуитивное восприятие, похоже выросшее на ощущении, что "Python не такой как Haskell, значит он хуже".
Я в свое время посмотрел на Haskell и у меня он вызвал такое же интуитивное восприятие, как у Вас Python: мне он тоже показался шагом назад, особенно учитывая его возраст. Я считаю, что "шаг вперед" - это лаконичные языки. Haskell не лаконичен по сравнению даже с Python.
Мне не нравятся ни "структуры" ни "сигнатуры" и я не думаю, что они нужны в языке программирования (как в OCaml), если можно прекрасно обходиться без них.

Скажите, а Вы любите дискретную математику? И заметьте, программирование - это не математика и никогда не может ею быть.

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

Что такое type classes? Могу только предположить. В Python очень удобная и мощная система классов и метаклассов - это коррелирует с type classes?

Лично я не нашел абсолютно ничего в Haskell, что бы могло сократить время разработки и СОПРОВОЖДЕНИЯ по сравнению с Python (скорее наоборот).

Не хочу никого ни в чем переубеждать, но в одном я уверен: Haskell никогда не достигнет уровня зрелости даже Python, равно как и количество инструментария для него будет на порядки меньше, чем для большинства других языков.

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

Roman комментирует...

Что касается последнего комментария... я в таком случае просто советую человеку не полениться, и изучить Haskell. Поверьте, не пожалеете.
А писать функциональные программы Вы можете и на Python, но конечно же без монад, сигнатур и прочих условных ограничений, связанных с причудами самого языка, ограниченного лишь одной парадигмой.
Ни в коем случае не хочу наезжать на Python, но если Вы попробуете написать что-либо на Хаскеле, вы сразу почувствуете разницу. Что касается сигнатур и структур, то я что-то не припомню таковых в Хаскеле. В SML они есть (и в Ocaml тоже, только называются немного иначе). В Хаскеле их нет и они там не нужны! Там для этого есть список экспорта и уже упомянутые type classes, которые намного мощнее и гибче, чем сигнатуры/структуры. Что же до монад, и прочих условных ограничений, связанных с причудами самого языка, опять же, если Вы изучите Хаскел и напишите на нём хоть одно более-менее серьёзное приложение, Вам станет ясно, что нет никаких ограничений, нет никаких причуд. Пока же, Ваши выступления в адрес Хаскела не обоснованы.

temoto комментирует...

Товарищ использует xMonad - оконный менеджер на хаскеле. По-моему это вот оно и есть - самое лучшее применение хаскелю. Маленькие простые программки, использующие сишные либы там где надо и работающие/пишущиеся быстрее и приятнее.

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

Эрланг удивительно офигителен, наверно его надо продвигать. Если бы не угребищный синтаксис.

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

За статью вам спасибо.

Vladimir Shabanov комментирует...

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

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

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

И в принципе эрланг -- просто набор идей. Никто не мешает использовать их в других языках. Есть конечно еще OTP и mnesia. Но у хаскела кол-во библиотек в последнее время растет чуть ли не в геометрической прогресии.

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

temoto комментирует...

Да, функциональные нити это потрясающая вещь. И хаскель будет использовать все имеющиеся процессоры для своих нитей или как питон - только один? Вопрос актуален учитывая растущее количество ядер.

И эрланг таки сливает по скорости или просто есть догадка об этом, потому что (подставить любой тезис) ?

Типизация это наверно скорее холивар. Мне очень нравится динамическая. Я умею с ней обращаться и проблем от этого не возникает. Кому-то наоброт. Дай им бог здоровья.

temoto комментирует...

Уважаемому товарищу aquagnu, цитирую

А писать функциональные программы Вы можете и на Python, но конечно же без монад, сигнатур и прочих условных ограничений

Посмотрите wiki ФЯП. Смысл функциональщины не в условных ограничениях, а в том, что функции могут возвращать функции (это есть в Питоне, ага) и самое главное - отсутствие побочных эффектов. То есть нельзя изменить значение переменной. Последнее даёт немыслимую мощь паралеллизации. Например, эрланг может запустить 4 миллиона своих "процессов" (можете называть их потоками) за секунду. Товарищ Шабанов вот подсказывает, что в хаскеле то же самое счастье с легкими потоками.

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

Vladimir Shabanov комментирует...

И хаскель будет использовать все имеющиеся процессоры для своих нитей или как питон - только один?

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

И эрланг таки сливает по скорости или просто есть догадка об этом, потому что (подставить любой тезис) ?

Потому что интерпретируемый. Народ в erlang-овском мейл-листе убивался, что процессы мол параллельные там хорошо работают, а на вычислительно/алгоритмически сложных задачах эрланг тормозит.

Типизация это наверно скорее холивар. Мне очень нравится динамическая. Я умею с ней обращаться и проблем от этого не возникает.

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

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

Легкость процессов мне особо не интересна (задачи не те). А вот меньшая глюкавость функциональных программ, алгебраические типы данных, pattern matching, вывод типов -- вот это действительно удобно. Т.е. функциональность это прикольно, но это не единственная вещь. Мне в хаскеле больше нравится мощная система типов и возможность легко создавать DSL-и, чем чистая функциональность, хотя они и взаимосвязаны.

temoto комментирует...

Насрать на паралельную сборку мусора, сделают - молодцы, не сделали - ерунда. Главное, что легкие потоки есть. pattern matching из коробки тоже фапабельно.

Рефакторинг делается на раз-два-три с помощью утилит типа rope. А с помощью утилит типа pylint, pychecker можно заранее отловить не все ошибки. На самом деле, статическая типизация просто помогает делать рефакторинг. Но жестко отсечь его может только chmod -rw. Ты же не задумываешься о том, насколько сложно написать интерпретатор хаскеля? Это уже сделано за тебя. Так же и со всеми другими утилитами. Да, авторам pylint пришлось сложнее, чем авторам чекера хаскеля. Но меня волнует то, что эти проги работают, а не сколько пота сошло с авторов.

Я всё грежу идеями DSL, но пока к сожалению, ничего не сделано. Уверен, что эрланг в этом месте наименее полезное звено. Лучше будет питон или ваш хаскель, надо признать.

Igor комментирует...

ocaml не канает уже?
вообще 5 баллов, мне понравилось!))

Igor комментирует...

я начинал работать с ФП с хаскеля, и мне он очень понравился, но потом стал смотреть ocaml, тоже понравился.
Что же таки вы предпочли бы при прочим равных условиях и, желателньо, почему, пусть и собъективно ? :)

Vladimir Shabanov комментирует...

Предпочел бы Хаскелл.

Он просто гораздо более мощный. В кемле в принципе нет generic-операций (или ad-hoc полиморфизма), что не так удобно. Нет разделения мутабельных/чистых ф-ий (а оно хоть и непривычно, но позволяет срезать определенное кол-во глюков и вообще делает программы более чистыми). Стандартная библиотека, поставляемая с кемлом, сильно меньше стандартной хаскельной (хотя и более хорошо оттестирована). Система модулей в кемле вроде и мощная, но хаскельная гораздо удобнее (позволяет легко делать вложенные модули, раскиданные по папкам, а также очень удобно то, что, при перегрузке модуля в интерпретаторе, остальные модули, от которых он зависит, перекомпилируются автоматом). Также в хаскеле можно делать операторы из любой ф-ии и указывать им нужные приоритеты (очень удобно для EDSL). Из-за того, что хаскелл более высокоуровневый он также имеет и более высокоуровневые библиотеки (хотя бы те же ф-ии работы с монадами -- разных монад много, а ф-ии одни и те же, это как контейнеры и алгоритмы в STL). Ленивость по-умолчанию тоже иногда очень полезна. Возможность определить ф-ию в любом месте модуля (а не строго до использования) позволяет более удобно структурировать код (сначала самое важное, потом детали, а не наоборот). Ну и синтаксически Хаскелл посимпатичнее. Также теперь производительность программ на Хаскеле начинает догонять (и перегонять) кемл (все благодаря чистому коду -- в нем можно проводить очень мощные оптимизации).

Из минусов у Хаскелла -- это его чуть большая сложность по сравнению с окемлом.

Да и то, хаскелл скорее более объемный, а не более сложный. Чтобы писать на нем необязательно знать все тонкости (как в С++). Можно постепенно доучивать делали.

potan комментирует...

Низкоуровневые программы давно пора не писать, а генерировать из высокоуровнего описания задачи.
Как целевой язык генерации C не очень хорошо подходит - слишком сложный синтаксис. Лучше использовать prescheme или bitc.
А генератор можно писать и на Haskell :-).

У Erlangа есть хорошее свойство, которое помогает при разработке высоконагруженных систем. Он хоть и тормозной, но при высокой загрузке его производительность почти не проседает. При этом без больших усилий со стороны разработчика - все делает runtime.

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

Анонимный комментирует...

Почему Haskell не является языком будущего: http://lambda-the-ultimate.org/classic/message9361.html

miraz комментирует...

Потому что, что здесь непонятного!!!

zabivator комментирует...

1) http://community.livejournal.com/ru_lambda/97895.html
Прокомментируйте, пожалуйста. Как же это делается в Хаскеле по трушному?
2) Хаскель ступенью выше Ерланг. Значит, на нём можно писать не менее удобно, чем на Ерланге.
а) Скажите, а он на кластер автоматически параллелится?
б) А на лету код править, исправлять, обновлять, менять можно?

temoto комментирует...

Олег, я попробовал, хаскель действительно такой весь удобный, мощный. Очень приятный синтаксис (за исключением дебильных комментариев с -- и неравно /=).

Но вот годится, по-моему он на 9 из 10 для математических изысканий.
И, конечно, нет там такой паралельности, как в эрланге. Но легкие потоки есть. И есть готовые рецепты как нехитрыми путями выполнять код на многих процах и машинах.

#haskell подсказывает, что хотсваппинг кода *возможен*, но опять же, из коробки как в эрланге этого нет. Что такое хотсваппинг кода для математических теоретиков? Очередной нонсенс, который надо заткнуть в угол и обозвать понебезопаснее. :)

Vladimir Shabanov комментирует...

Прокомментируйте, пожалуйста. Как же это делается в Хаскеле по трушному?

Не бывает абстрактных тру-способов. Бывают наиболее подходящие для определенной задачи.

Практически все варианты там уже перечислены.

Самое простое -- сделать Config.hs и забить в него все константы. Обновление конфига -- просто перегрузка модуля в repl или перекомпиляция.

Можно сделать тупой шаблон "$COMPANY_NAME" и потом его заменять.

Есть unsafePerformIO, если все-таки хочется читать из внешнего файла. Но так получится считать один раз. Обновить будет сложнее.

Можно протащить параметр.

Можно протащить его неявно (state монада, или даже implicit parameters).

Много вариантов. И все, кроме unsafePerformIO являются чисто функциональными (да и unsafePerformIO тоже чисто функционален, если вызывается один раз).

Надо понимать, что фишка хаскелла -- полная функциональная чистота. Даже IO монада функциональна чиста. Не чиста только ф-я main.

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

Если хочется променять годы отладки на относительную легкость вставления мутабельности в любое место, то что же, ваш выбор )

Скажите, а он на кластер автоматически параллелится?

А эрланг параллелится? Автоматически?

А на лету код править, исправлять, обновлять, менять можно?

Это даже в Си можно. Хотя на эрланге, наверное, поудобнее.

Анонимный комментирует...

Спасибо Володя, за пояснение на тему ocaml vs haskell.
Со многим что приведено было отторжение и у меня по поводу "промахов" в дизайне ocaml.


Игорь

zhengxi комментирует...

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

Для dataflow programing есть замечательный LabView.

Почему вы зациклились в квардате из c++, хаскеля, ерланга и окамла ?
Да, они опенсорсные, это кошерно, согласен. И это всё?

Vladimir Shabanov комментирует...

Mathematica умеет делать запускаемые файлы, работающие без среды?

Имеется ли там хотя-бы какая-нибудь поддержка многопоточности? Какая система типов? Как много готовых библиотек (не математических)? Какое сообщество? Связь с Си?

Чем оно вообще лучше для не расчетных задач, чем тот же Хаскелл?