Кто что думает на тему языков функционального программирования (в частности Haskell?)
( //ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%B… )
( //ru.wikipedia.org/wiki/Haskell )
В каких по-вашему областях это полезно?
Кто что думает на тему языков функционального программирования (в частности Haskell?)
( //ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%B… )
( //ru.wikipedia.org/wiki/Haskell )
В каких по-вашему областях это полезно?
Клуб программистов работает уже ой-ой-ой сколько, а если поточнее, то с 2007 года.
24 января 2009 в 2:03
Встроенный DSL средствами С++
Пример взят из статьи
martinfowler.com/articles/languageWorkbench.html.
Код лежит вот здесь:
github.com/gaidam/reader_dsl/tree/master.
Templates намеренно не используются, а используются исключительно
C-ные макросы (да, да "грязные" хаки). Метод туп до невозможности,
но в данном случае работает вроде неплохо.
Итак, берем некоторую конструкцию языка, которая по свойствам
напоминает то, что хотим получить, адаптируем ее для того,
чтобы она выполняла необходимую функцию (в данном случае -
конфигурировать объект Reader-а), после чего минимизируем "синтаксический шум" при помощи #define-ов.
Три приведенных способа разложены соответственно по папочкам
dsl1-3. В каждой папочке по два файла: файл с кодом поддержки и файлс самим кодом "встроенного" DSL. Думаю, можно ещё найти варианты,
получше да понадежней, но мне было лень их искать.
Какие конструкции были синтаксической основой:
- функции со списком аргументов переменной длины (еще один С-шный "хак")
- синтаксис инициализации массива структур
- перегруженные операторы
По поводу "отлаживаемости" #define-ов, думаю, могу заявить,
что отлаживать тут особо-то и нечего.
Да, забыл сказать. Разумеется тут нет ничего нового,
подобные вещи встречаются сплошь и рядом. И разумеется такой
"DSL" не претендует ни на что другое, кроме того, чтобы выглядеть
более наглядно, чем исходный код на С++. Но ведь этого мы и добиваемся, не так ли?
20 июня 2008 в 15:00
В продолжение темы, нашёл тут забавное высказывание у М. Фаулера в блоге:
So why is there an unreasonable fear of writing parsers for DSLs? I think it boils down to two main reasons.
* You didn't do the compiler class at university and therefore think parsers are scary.
* You did do the compiler class at university and are therefore convinced that parsers are scary.
21 мая 2008 в 18:03
> Просвети, в двух словах, что ты знаешь о таких возможностях?
Есть несколько реализаций Коммон Лиспа и Схемы, предназначенные как раз для встраивания.
В МГУ есть разработка библиотеки, реализующей Лисп и встраиваемой в C++ практически непосредственно в "скобочной нотации" – очень впечатляет.
Есть язык Q, который так же оч. хорошо подходит для встраивания и используется в этих целях.
21 мая 2008 в 0:05
Хе, а мне сегодня посчастливилось на работе написать – пусть, мелкую – но утилиту на хаскелле
> Просвети, в двух словах, что ты знаешь о таких возможностях?
Прямо-таки интерпретатор? Ну, про хаскелл могу сказать, что можно (через задницу) вызывать его из C++, и что можно с помощью hs-plugins делать eval. Насколько это практично – не знаю, но боюсь что не очень.
Про другие языки не знаю; думаю, что перлы-питоны при желании можно использовать в функциональном стиле более продуктивно, нежели С++, а встраивать их вроде бы легче.
21 мая 2008 в 0:04
> не писать же на каждый DSL – компилятор в машинный код?
Да уж, несомненно.
> Я не вижу тут "resulting constraints".
Он имеет в виду, что на встроенный DSL будут наложены ограничения, связанные с базовым языком (особенно если вы пишете на C-языках).
> А докуда?
) Иногда хочется сделать что-то в чисто функциональной манере. Для этого было бы неплохо иметь возможность встраивать интерпретатор какого-нибудь функционального языка в программу на С++. Просвети, в двух словах, что ты знаешь о таких возможностях?
До регистровых машин, дальше пока не сподвинулся. Практиковаться надо, опять время. Вот думаю, как бы на работе ФП заиспользовать, чтоб на легальной основе его изучать, не теряя в зарплате
> Очень рекомендую.
Непременно воспользуюсь, спасибо.
20 мая 2008 в 17:04
Ну что ж, поскольку никто не торопится вывешивать список областей, где применяется ФП…
Erlang активно (очень активно
) применяется в телекоме.
В последнее время на ФЯ начали писать веб-фреймворки и приложения, во многом в связи с интересом к continuation-based фреймворкам. Есть HappS, UnCommonWeb, ErlyWeb ("Erlang on Rails"
).
Есть система OMake, написанная на OCaml.
Про то, что ФЯ используют для написания обычных приложений, в том числе GUI-oriented, для чего создают интереснейшие с концептуальной точки зрения GUI-библиотеки (Fudgets, например), и говорить не нужно.
Есть FreeArc – архиватор на Haskell. Автор утверждает, что по производительности обошёл RAR и многих других. К вопросу о тормознутости ФЯ.
20 мая 2008 в 17:03
2 Кирпичев:
Я же писал, что не смотрел реализации на Си!
Интересно, конечно, какие там такие хаки, которых нельзя сделать на Haskell, а тем более Common Lisp? Неужели у этих языков есть ограничения?
2 Гайдамович:
Если такое утверждение не ввергнет сообщество в повальную пенисометрию. 
Чесно говоря, собственно Пролога я не знаю, поэтому то, что я видел может оказаться упрощённой версией. Впрочем, я уверен, что и полная версия Пролога на Лиспе намного короче Сишной.
Ну а в качестве eDSL и урезанный Пролог является хорошим примером.
20 мая 2008 в 13:01
> Ну я бы не говорил за всю Одессу.
Это то, что я чаще всего видел в опенсорс-проектах и в коде коллег. За остальной мир не ручаюсь
> Ах, мы уже и на интерпретатор согласны! Красота!
Ну разумеется согласны, не писать же на каждый DSL – компилятор в машинный код? Его не на каждый "просто" язык-то пишут! Разве изначально речь шла о компиляторе? Правда есть еще вариант "кодогенератор в си итп" – ну, кодогенераторы на функциональных языках тоже проще писать.
Статья про DSL довольно неплохая; но с выводом я не согласен:
> Using internal DSLs reduces the tool cost – but the resulting constraints on the DSL itself can also greatly reduce the benefits, particularly if you are limited to C-based languages
Я не вижу тут "resulting constraints". Они, наоборот, гораздо меньше, чем в случае external DSL – т.к. internal DSL забесплатно уже интегрирован с языком и может использовать все его возможности.
> Я-то только раз прочитал, и то не полностью…
А докуда?
> Рекомендуешь? У тебя есть полностью текст?
То, что там выложено – это и есть приведенный полностью текст, написанный авторами к настоящему моменту. Очень рекомендую. Меня за уши не оттянуть от нее, так что я предпочитаю на работе на зачитываться
Про применения подумаю как получше сформулировать, и отвечу.
20 мая 2008 в 3:00
>> Возможно; можешь показать удачные примеры?
Сторонние примеры лень искать, могу сам сделать, могу из наших проектов надёргать. Наверно, возьму какую-нибудь статью про DSL и покажу, что можно сделать на "плюсах". В любом случае, если сделаю это, то в группе по С++, что, наверно логичнее. Мы и так тут уже маленько по дереву растеклись.
>> Правда, этот способ нельзя назвать распространенным.
>> Почему-то все предпочитают вместо and(a,b) – new AndLogicRule(new >> AndVariableReference(a), new AndVariableReference(c)).
Ну я бы не говорил за всю Одессу.
>> Ну вот это-то уж точно через задницу
))Иногда без них просто никак.
>> Их невозможно отлаживать, они не обладают
>> сколько-нибудь приличной семантикой.
>> Это просто грязный хак.
Семантика, отладка, подумаешь! Обозвали грязным хаком! Всё равно, они очень славные, любименькие мои макросы
>> А вот для написания интерпретатора пригодятся.
Ах, мы уже и на интерпретатор согласны! Красота!
Кстати, вот тут мне понравилось перечисление плюсов и минусов как внешних, так и внутренних DSL:
//www.martinfowler.com/articles/languageWorkben...
>> Вроде бы, общепризнан тот факт, что парсеры и компиляторы
Я вот и пытаюсь добиться от тебя, как человека трижды прочитавшего SICP, в чём суть преимуществ этих. Я-то только раз прочитал, и то не полностью…
>> на функциональных языках тоже проще писать.
Вроде бы, да
>> Издержки на интерпретацию обычно пропорциональны объему интерпретируемого кода.
Охренительное наблюдение! Нет, правда. Пять баллов!
>> Замечу, что domain-specific languages удобны везде, где есть domain – т.е. везде
Я вообще-т не про DSL спрашивал, а по основной теме нашего заседания, поднятой ещё тов. Nar Ilfirin. Кстати, предлагаю вернуться к этой основной ветви, если ещё есть интерес. ФП применяется для DSL наряду с динамическими языками и внешними DSL по классической схеме с парсерами-интерпретаторами, это номер раз. Что ещё? Я понимаю, что можно ответить: "Искусственный интеллект, бла-бла-бла". А поконкретнее? Я имею в виду не вычислительные модели, а их применения.
Кстати, Александр, а где можно посмотреть полстраницы кода Пролога на Лиспе? Очень любопытно. Помнится, я пытался объяснить своему знакомому, что нельзя сжать любой файл до размера одного байта. Неужели Пролог можно ужать до пол-страницы? Только Пролога, а не простенькой иллюстрации продукционного подхода.
>> А ты посмотрел книжку Real World Haskell?
Не-а. Ну я сейчас нашёл выложенные главы, начал читать. Времени маловато. Рекомендуешь? У тебя есть полностью текст?
19 мая 2008 в 13:01
Вообще-то, к сожалению, он будет таки намного медленнее сишного. Для хорошей реализации пролога нужно много хаков – ты читал код gnu prolog, например? Я его видел только одним глазком, но – код хороший и аккуратный, но там жопа.
19 мая 2008 в 12:04
Как пример eDSL на ФЯ хочется вспомниь Пролог на Лиспе. Полстраницы кода. А на C сколько? Я не смотрел сишные реализации.
Кстати, учитывая, что для реализации Пролога на Си потребуется пресловутая "половина Комон Лиспа", я не думаю, что скомпилированный SBCLем или Haskellем Пролог будет намного медленнее сишного…
19 мая 2008 в 10:02
Про Ruby ты прав, я упустил из виду еще один мощный инструмент для DSL – динамические языки.
> Если ты скажешь, что этого нет в С++, то я тебе скажу, что ты просто не умеешь им пользоваться.
Возможно; можешь показать удачные примеры?
> используя только средства языка, совершенно не сложно.
Я, собственно, часто как-то так и пишу на джаве – с некоторым количеством классов типа FPUtils и морем статических импортов из них 
Правда, этот способ нельзя назвать распространенным. Почему-то все предпочитают вместо and(a,b) – new AndLogicRule(new AndVariableReference(a), new AndVariableReference(c)).
В общем-то да, этот язык поддается реализации и на традиционных языках
> Даже на обычных Си-шных макросах можно добиться многого в этом плане
Их невозможно отлаживать, они не обладают сколько-нибудь приличной семантикой. Это просто грязный хак.
Ну вот это-то уж точно через задницу
> "фишки функциональных языков", как базис, нам совершенно не нужны.
Как базис – да. А вот для написания интерпретатора пригодятся. Вроде бы, общепризнан тот факт, что парсеры и компиляторы на функциональных языках тоже проще писать.
> 2) который будет не очень сложный;
Необязательно. Хотя смотря что понимать под сложностью. Во всяком случае, замечу, что заменить это предложение на "который будет не очень мощный" – определенно нельзя. Если он будет допускать вкрапления исходного языка (а он, скорее всего, будет), то он может быть сколь угодно мощен.
> 3) который будет медленный
Зависит от языка. Издержки на интерпретацию обычно пропорциональны объему интерпретируемого кода. Если мы моделируем скорее императивный язык типа javasсript, где много циклов и т.п., и интерпретируемая единица (инструкция) выполняет очень мало работы, то да. А если мы моделируем что-нибудь вроде J, где примитивы – это весьма крупные единицы – то скорость будет зависеть лишь от того, насколько оптимально мы реализуем эти примитивы и насколько хорошо их скомпилит компилятор исходного языка.
> Интересно, для чего ещё их можно применять.
Замечу, что domain-specific languages удобны везде, где есть domain – т.е. везде
А ты посмотрел книжку Real World Haskell?
19 мая 2008 в 3:00
Ну смотри, что получается. Ты смягчил формулировку от "DSL возможен только на функциональном языке, либо через задницу" в направлении к "чтобы реализовать DSL, построенный целиком на возможностях исходного языка, нужны фишки функциональных языков". Это уже конечно не то же самое, но опять ты не прав! Яркий пример – Руби. Многие любят Руби именно за возможность делать DSL "без парсеров-интерпретаторов-компиляторов". Да, он заимствует элементы ФП. Но погугли "ruby metaprogramming" или "ruby dsl", и ты увидишь, что отнюдь не только то, что заимствует Руби у функциональных языков, используется там для этой цели.
Для "встроенного DSL" нужно в первую очередь что? Возможность в языке добиваться прозрачного изложения в терминах проблемной области, привнести этакий специализированный синтаксический сахар для того, чтобы скрыть сложности использования "другой модели вычислений". Всякие там идиомы, позволяющие писать текст программы так, чтобы он выглядел нагляднее. Если ты скажешь, что этого нет в С++, то я тебе скажу, что ты просто не умеешь им пользоваться. Я согласен, что boost::spirit – это белая горячка. Не less code, однозначно. Мне вообще помойка под названием boost не очень-то нравится. И из этого ты выводишь, что на С++ "нормальный встроенный DSL" не сделать. Конечно же, это не так.
Взять хотя бы твой пример. Вот эту запись:
Rule *rule = (Rule*)malloc(sizeof(Rule));
rule->kind = RULE_KIND_IMPLIES;
rule->nodes[0]=a;
rule->nodes[1]=b;
превратить в эту:
implies(and(a,b), c)
, используя только средства языка, совершенно не сложно. Да, конечно, там появится в конце точка с запятой. Но идея-то сохранится.
Возможно ты скажешь, что идиомы С++ – это и есть "через задницу". Ну так это ведь дело вкуса. Некоторые люди этим самым словом называют Лисповские заборы из скобочек. Наверно те самые, кто в них счастья не видят
Да что там С++. Даже на обычных Си-шных макросах можно добиться многого в этом плане, хоть они и не такие гибкие, как в Лиспе, не рекурсивные и проч.
Попробую закруглиться
Итак, если нам требуется реализовать произвольный DSL, и при этом мы не накладываем то ограничение, что он обязан строиться на возможностях исходного языка (то есть быть "встроенным"), то "фишки функциональных языков", как базис, нам совершенно не нужны.
И наоборот, для разработки DSL:
1) который будет базироваться на исходном языке (лучше даже, чтоб онбыл его подмножеством);
2) который будет не очень сложный;
3) который будет медленный
- так вот для разработки такого DSL нам действительно понадобится функциональное программирование. Сдаюсь! Ты меня убедил!
Одну из областей применения функциональных языков мы очертили достаточно отчётливо. Интересно, для чего ещё их можно применять. У кого какие мнения?
Артёму, по поводу "на С++ вообще крайне трудно написать что-нибудь хорошо работающее": как говорит мой шеф, жить вообще порой нелегко
Стоит ли приписывать это свойство жизни?
18 мая 2008 в 21:04
> а под встроенным DSL разве нельзя понимать любую программную библиотеку?
Можно, в принципе. Если достаточный для решения DSL отличается от исходного языка только набором функций. А если он отличается наличием каких-нибудь абстракций более высокого уровня, скажем – или наличием отличающейся модели вычислений – и т.п., то обычно нельзя.
Например, если в задаче очень сложная логика со множеством правил "Если это, то вот то", то подходящий DSL должен содержать в себе абстракцию "правила" и должен уметь с ней обращаться – то есть, содержать в себе механизм логического вывода. И обращение с ней не должно быть загрязнено "утекающими" деталями реализации.
Например, если правило "Если А и B, то C" записывается как "implies(and(a,b), c)", то это можно назвать более или менее полноценным DSL.
А если так:
Rule *rule = (Rule*)malloc(sizeof(Rule));
rule->kind = RULE_KIND_IMPLIES;
rule->nodes[0]=a;
rule->nodes[1]=b;
…
то на DSL это не тянет.
18 мая 2008 в 20:00
а под встроенным DSL разве нельзя понимать любую программную библиотеку? (ведь задачу пишем в терминах этой библиотеки — например, графические API, типа OpenGL/Direct3D)
и о boost::spirit, код которого я читал и даже временами понимал, что и зачем. там самая большая проблема — борьба с багами разных компиляторов (ну и, конечно, с шаблонами — то Koenig lookup не устраивает, то еще что..). по-моему, boost::spirit просто яркий пример неправильного выбора языка для решения задачи.
>Он отлично раскрывает и тот факт, что на С++ приличный встроенный DSL сделать крайне трудно
но причины использования мейнстрим-язык супротив экзотического (тот же D), думаю, всем ясны.
да, крайне трудно. на С++ вообще крайне трудно написать что-нибудь хорошо работающее,
18 мая 2008 в 10:02
Под встроенным DSL я понимаю DSL, построенный целиком на возможностях исходного языка, а не отдельный язык с парсером-интерпретатором-компилятором. Преимущество такого языка – в том, что 1) он сохраняет все фишки исходного и их не приходится реализовывать заново и 2) он требует куда меньше усилий – т.к. не надо писать парсер-интерпретатор-компилятор
> на практике достаточно обыденный и повседневный элемент
Именно потому, что на практике обычно используются языки, на которых встроенный DSL сделать очень сложно.
Яркий пример встроенного DSL – boost::spirit. Но, е-мое, ты попробуй почитай его исходники! Он отлично раскрывает и тот факт, что на С++ приличный встроенный DSL сделать крайне трудно. Поэтому в основном и пользуются yacc/flex/ragel/.., а не spirit.
> Не видят, где счастье-то.
Думаю что видят, но не могут себе позволить его использовать – т.к. боятся, что не смогут найти программистов, или не хотят переписывать миллионы строк на новом языке, или не доверяют текущим реализациям функциональных языков. Все эти опасения вполне обоснованы.
> По причине производительности этого самого интерпретатора.
Да, скорее всего. Если от DSL требуется высокая производительность, и DSL обладает такой сложностью как javasсript, то лучше его написать на си. Если же ее не требуется, и есть возможность использовать функциональный язык, то лучше использовать его.
> для DSL – единственно ФП,
Для встроенных DSL. Для таких, где нам надо побыстрее получить работающий мощный DSL, и нет требований, запрещающих такую реализацию – например, критичность к скорости или то, что весь остальной проект написан на каком-нибудь VISUAL COBOL PRO.
18 мая 2008 в 1:03
Моё высказывание очень просто. Говорить, что DSL можно делать либо на функциональных языках, либо лисповыми макросами, а остальные пути – это"через задницу", так вот так говорить глупо.
Не знаю, что ты подразумеваешь под "нормальный встроенный DSL", с какой стороны он должен быть нормален и куда встроен. Я подразумеваю под DSL реализацию следующей идеи. На языке проблемной области решение задачи формулируется гораздо проще, чем на языке программирования общего назначения, поэтому мы создадим язык программирования, предельно близкий к проблемной области, чтобы убрать случайную сложность максимально. Я надеюсь, тут мы сходимся во мнениях?
Какой это будет DSL – понятно, что it depends…
Как реализовать эту идею – тут много вариантов. Что во что встроить – это дело вкуса, практического опыта, а главным образом, требований, что должно получиться в результате.
Разработка "специальных парсеров-интерпретаторов-компиляторов", о которых ты говоришь в том ключе, что это всё "через задницу", – на практике достаточно обыденный и повседневный элемент технологии создания ПО на императивном С, для этого имеется множество инструментов. Более современный С++ значительно упростил решение этих задач, создав себе армию поклонников, и неспроста.
Вопрос. Почему так делают люди годами и большинство промышленных реализаций DSL выполнено именно так? Неужели все, начиная с исторических бородачей из Bell Labs, пребывают в неведении относительно того, что каждодневный свой труд они выполняют через это самое место, безо всяких красивых концепций ленивых вычислений и лямбда-исчисления? Ну просто бедные духом, слепые люди! Не видят, где счастье-то.
Возьмём, например JavaSсript. Это ведь тоже изначально DSL, хоть и очень близкий к языку общего назначения. Не думаю, что будет сложно написать красивый пример интерпретатора JavaSсript на Scheme, очень компактный, идеальный для учебного примера. Так вот, если такой встроить вбраузер, то его можно будет сразу же отнести на помойку. По причине производительности этого самого интерпретатора.
Это как бы вопрос веры. Я в этом свято убеждён и об этом спорить не собираюсь. Я не отношу себя к упёртым приверженцам императивного программирования, и искренне хотел бы получть выгоды от ФП, хотя бы с точки зрения быстрого прототипирования и вообще, расширения кругозора. Я нисколько не против ФП, напротив, мне оно очень нравится, и тем больше нравится, чем больше я с ним знакомлюсь.
Но говорить вот так, с бухты-барахты, что для DSL – единственно ФП, а остальное – "через задницу", это, извините, что-то навроде революции 17 года, которая именно туда нас и завела.
17 мая 2008 в 23:03
Нет, не через задницу – я не так выразился: DSL можно делать либо на функциональных языках, либо лисповыми макросами.
17 мая 2008 в 21:04
Я вот не столь продвинут как тут говорящие… к томуже большие пробелы в теории… Не поясните основные концепции… эт для тех кто в танке как я!
А то шибко интересно, а… знания теории нехватает.
17 мая 2008 в 20:05
какая развязка!
браво!!!
17 мая 2008 в 19:02
2 Кирпичев:
Т.е. лисповские макросы – это через задницу?
17 мая 2008 в 18:03
Не понял твоего высказывания.
Я утверждаю, что чтобы сделать нормальный встроенный DSL и не писать для него специальных парсеров-интерпретаторов-компиляторов, необходимы фишки функциональных языков – ленивость, мощная система типов, замыкания и т.п. Или лисповые макросы.
17 мая 2008 в 17:05
>> … DSL'и – а это, фактически, возможно только на функциональном языке, либо через задницу.
Ну такая альтернатива – это глупость полнейшая. Как ты говоришь, DSL и ФП – это разные вещи
17 мая 2008 в 15:02
А, NLP это да. Для него обычно, похоже, создают DSL'и – а это, фактически, возможно только на функциональном языке, либо через задницу.
17 мая 2008 в 13:02
Лично я думаю, что ФП – светлое будущее всего человечества.
Только человечество до этого будущего ещё не дожило, да и ФП – тоже.
Достоинства и недостатки ФП разобраны в упомянутой статье Why not FP.
Принципиально оно применимо в любой области. Чтобы понять, в какой области его можешь применить лично ты, нужно попробовать. На это нужно немало времени и сил. Потому что Haskell это совсем не то же самое, что Erlang и они вместе радикально отличаются от Lisp (Scheme).
17 мая 2008 в 12:04
>> Парсеры и information extraction это разные вещи
Я и не утверждал обратного. Просто первое можно с успехом применять для второго. Собственно, я и не знаю, как без них там. Я имею в виду конечноNLP. Надо же как-то разбирать человеческие документы.
17 мая 2008 в 7:02
Парсеры и information extraction это разные вещи
Парсеры действительно пишутся превосходно; насчет information extraction не знаю – сам не пробовал, статей не видел.
Вот, еще накопал примеров //flyingfrogblog.blogspot.com/2007/09/functiona...
Возможно, еще одна проблема ФП – в том, что оно постоянно развивается, гораздо более бурно, чем обычные языки – постоянно появляются новые, все более эффектные и сложные фичи языков, все больше ученые находят связей между ФП и теоркатом, и т.п. – в результате 1) со стороны создается впечатление, что чтобы писать программы на функциональном языке, надо знать теоркат, высшую алгебру, топологию, дифференциальную геометрию и вышивание крестиком и 2) нет единого устоявшегося стиля, про который можно было бы сказать "Пиши вот так – не прогадаешь" – каждый пишет как умеет. Это создает впечатление ненадежности.
17 мая 2008 в 1:01
Ну так это. В каких областях полезно ФП? Объясните для тупых вроде меня. Ну пожалуйста. Я сейчас по работе соприкасаюсь с Information Extraction, слышал, что на Hascell быстро можно писать всевозможные замечательные парсеры, но сам так и не сподвинулся… Вот и доп. вопрос к тому, кто знает.
17 мая 2008 в 1:01
Во, Женя уже просветил. Интересно, почитаю…
17 мая 2008 в 1:00
Большинство не знает – но те, кто знают – творят чудеса. Гугл знает, Гугл изобрел MapReduce. Microsoft знает, у микрософта написан на окамле верификатор драйверов. Sun знает – они умудрились прикрутить к джаве генерики – т.е. теоретико-категорную систему типов Хиндли-Милнера, хоть и кривовато (в дотнете прикрутили как следует). kx.com знает и делает – и их продукт используют в армии США потому, что он считает их отчеты в сотни раз быстрее, а язык запросов настолько мощнее sql, что об этом и говорить как-то неудобно.
17 мая 2008 в 1:00
Facebook знает – и пишет серверную часть чата с 70млн пользователей в онлайне на Erlang.
16 мая 2008 в 21:04
Да все о том же – никто не знает, что это такое + GOTO #3
16 мая 2008 в 21:03
И о чем это говорит, по-твоему?
16 мая 2008 в 21:02
Ты конечно прав. Но есть еще один фактор – рынок. Зайди на какой-нибудь сайт поиска работы (хоть на наш, хоть на буржуйский) и посчитай количество вакансий для программистов С/С++ (можешь даже искать програмистов Linux) и количечство вакансий программистов Erlang
16 мая 2008 в 21:00
Я вижу проблемой не "другую идею написания кода", а закостенелось программистского образования в наших универах. ФП просто (почти) никто не преподает.
Никому же не приходит в голову из всей математики преподавать линейную алгебру – тогда бы при преподавании матанализа были бы проблемы с "другой идеей вычислений", и с тем, что "нет матриц", "не все линейно", "какие-то непонятные производные" – а вот из всего программирования преподавать только семейство си почему-то считается нормальным.
16 мая 2008 в 21:00
Точнее, ФП "преподают" – но это еще вреднее, т.к., по крайней мере у нас, это был просто фарс – идиотские задачи, даже не пытающиеся раскрыть суть самого ФП; преподы, ничего не понимающие в ФП вообще.. В итоге у всех осталось впечатление, что ФП – это какая-то непонятная хуйня, которую непонятно зачем преподают.
16 мая 2008 в 20:04
Основной проблемой вижу принципиально другую идею написания кода
Все таки Pascal, C/C++, Java, PHP вещи почти идентичные, отличающиеся только синтаксисом (и то в основном Pascal – остальные близнецы братья) и списком функций. Поэтому люди свободно мигрируют между этими языками и не переходят на друугие именно из-за другой логики. Особняком стоит SQL, который вроде и другой, но чем-то напоминает базовые языки. ASM имеет принципиально другой синтаксис, понятие функции крайне размыто (имеются в виду библиотечные функции), НО логика все та жа: получил значение, записал его в регистр, сравнил с чем-то
Первый (и пока единственный) "другой" язык, который мне попался был XSL/ Не помню, сколько я с ним мучался (полгода так точно). У меня просто в голове не укладывалась принципиально другая концепция, но в один прекрасный день, я постиг его ДАО
И теперь легко им оперирую (другими словами я стал думать в терминах XSL)
Одно время мы посматривали в сторону Erlang (очень заманчив был его параллелизм), но тогда меня остановило три вещи – отсутствие переменных (с XSL я тогда не дружил), невозможность компилирования в исполняемый независимый код и то, что при переходе пришлось бы переписывать многие вещи, т.е. работы на пол-года хватало.
Вот так. Может немного не по теме, может немного сумбурно (устал я), но в целом картину вижу именно так.
16 мая 2008 в 15:02
К тому же сейчас готовится книга Real World Haskell: //book.realworldhaskell.org/beta/index.html . Мне почему-то кажется, что когда она выйдет, то это будет бомба и на хаскелле начнут писать что-то реальное гораздо больше людей.
16 мая 2008 в 15:00
Оставить сообщение в теме
16 мая 2008 в 15:00
Статья хорошая; рекомендую всем ее прочитать. По названию может создаться впечатление, что это статья "почему функциональные языки плохи". Это вовсе не так: она их хвалит и повествует лишь о том, о чем повествует – почему их мало _используют_.
16 мая 2008 в 14:05
Можно для тех, кто в танке? Как на комментарии подписаться?
16 мая 2008 в 14:02
//softcraft.ru/paradigm/fp/whynotfp.shtml — изложение причин, по которым никто не использует функциональные языки
16 мая 2008 в 13:03
*пока лень писать самому, но подписываюсь на комменты*