LINUX.ORG.RU

[функциональщина тред][вопрос к специалистам] что выбрать?


0

1

На работе занимаюсь обработкой текстов на естественном языке.

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

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

А раз так, задумался я над тем какой язык выбрать для реализации. Собрав задницу в кулак и мозг в голову, я прошерстил интернет на предмет того каким решением можно воспользоваться в данной области, по результатам были отобраны следующие языки: Prolog, OCaml, Lisp, Scheme, Haskell и, как это ни странно, Python и Erlang.

Маленькое уточнение: требуется кроссплатформенное решение (windows, linux, macos) с возможностью компиляции в байт-код, хорошо бы иметь потоки, GUI не особо нужны, но будут плюсом, ide - неважно. Ещё один важный момент: наличие коммерческих реализаций с целью дальнейшего на них перехода или, как вариант, серьёзного бэкграунда.

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

  • Prolog - собственно существуют довольно вменяемые открытые и коммерческие реализации, однако общее состояние дел большее напоминает заброшенную ферму (например, разные реализации интерпретатора могут использовать разный синтаксис).
  • OCaml - неплохой претендент, немного стагнирует в своём развитии, но имеет существенную поддержку в лице INRIA (и небольшой буст со стороны в виде F#).
  • Lisp - весьма разносторонний язык, есть весьма вменяемая свободная реализация (Clozure CL; SBCL, увы, *nix oriented) и мега-буст с точки зрения коммерческих реализаций (Allegro CL, LispWorks), есть так же реализация под Java VM.
  • Scheme - сводный брат Lisp, ситуация обстоит приблизительно так же, хотя непонятно что с коммерческими реализациями и вообще Scheme имеет репутацию академического языка.
  • Haskell - довольно молодая и таки тёмная лошадка, есть некоторый зоопарк в реализациях, коммерческие средства отсутствуют, присутствует некоторый перекос ориентации в сторону *nix.
  • Python - довольно годный язык, но поддержка функциональной парадигмы там реализована довольно слабо + наличествуют всякие выкрутасы (типа GIL).
  • Erlang - годный Prolog-like язык, но меня смущает его ориентация на телеком.

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

Сам пока склоняюсь к Lisp.

Собственно, товарищи опытные функциональщики, нужен Ваш совет относительно данной ситуации, что бы использовали Вы (что использовали Вы), что будет более/менее годное для решения подобного класса задач, какие есть подводные камни. И, самое главное, какие по Вашему мнению языки вляются более перспективными, на какие в первую очередь стоит тратить своё время.

Уф! Дописал. Всем откликнувшимся большое спасибо заранее. :)

ЗЫ brainf*ck и иже с ним не предлагать.

★★★★★

Посмотри на проекты LKB и KPML как на практические реализации в данной области. Язык Common Lisp.

Zubok ★★★★★ ()

> Prolog ... например, разные реализации интерпретатора могут использовать разный синтаксис.

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

Ещё можешь глянуть на Mercury, эдакая помесь Prolog и Haskell.

runtime ★★★ ()

я бы посмотрел на Clojure. Причины - переносимость, поскольку JVM, доступ к существующим библиотекам (например, lingpipe), наличие инструментария (IDE, etc), можно купить коммерческую поддержку в лице Clojure/core, более функциональный чем другие Лиспы, поддержка конкурретного программирования на уровне языка

Вот пример программки на кложуре для NLP - http://writequit.org/blog/?p=365

ott ★★★★★ ()
Ответ на: комментарий от runtime

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

ott ★★★★★ ()

Я бы выбирал между F#, Scala и Clojure. Если кроссплатформенность очень важна, то между последними двумя. Обе работают на Java. Эстеты даже могут сочетать их :) Хорошая интеграция с Java в обоих направлениях. F# по своей мощи ровня, но там нет истинной кроссплатформенности, ибо моно технически ненадежен.

dave ★★★★★ ()

1. Пролог не является ФЯ.

2. Эрланг можно считать Пролог-лайк разве что по части синтаксиса, не более.

3. Можно еще посмотреть на Фактор, всё заявленное, кроме коммерческой реализации, там есть.

dmsh ()
Ответ на: комментарий от dmsh

не все знают термин «декларативное программирование» :-)

ott ★★★★★ ()

ott уже посоветовал clojure и я бы прислушался к его совету. Для JVM есть еще Scheme-реализации - kawa и sisc. Если хочется, можно и jython, но он может тормозить хотя мне он нравится, например, нет проблемы c GIL.

cab ★★★★ ()

>Маленькое уточнение: требуется кроссплатформенное решение (windows, linux, macos) с возможностью компиляции в байт-код, хорошо бы иметь потоки, GUI не особо нужны, но будут плюсом, ide - неважно.

Java без вариантов.

anonymous ()

В копилку Питона:

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

Например есть Natural Language Toolkit и книжка "Natural Language Processing with Python".

GIL в вашей задаче не помешает. К тому же есть multiprocessing.

ntp ()

> Lisp - весьма разносторонний язык, есть весьма вменяемая свободная реализация (Clozure CL; SBCL, увы, *nix oriented) и мега-буст с точки зрения коммерческих реализаций (Allegro CL, LispWorks), есть так же реализация под Java VM.

Clozure CL нативно работает на windows x86/x64_64 включая треды.

SBCL треды под windows активно пилятся dmitry-vk.

Erlang - годный Prolog-like язык, но меня смущает его ориентация на телеком.

еще один миф. Erlang/OTP прекрасно подходит, как язык общего назначения.

anonymous ()

Посмотри еще Scala. Это язык удачный во всем. Наиболее близок по моему субьективному мнению к идеалу.

vertexua ★★★★☆ ()
Ответ на: комментарий от Zubok

Посмотри на проекты LKB и KPML как на практические реализации в данной области. Язык Common Lisp.

спасибо, выглядит довольно интересно, будем копать

+1 lisp

shty ★★★★★ ()
Ответ на: комментарий от Legioner

А какие конкретно фичи в языке, в сравнение с С++, могут вам помочь?

дело в том что в данной предметной области довольно много неопределённостей разного рода и, соответственно, проще определить «условия игры», чем предусмотреть все варианты

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

shty ★★★★★ ()
Ответ на: комментарий от wxdas

Посмотри на библиотеку Antlr и язык scala

немного в сторону, но тоже можно почерпнуть идейки, спасибо

shty ★★★★★ ()
Ответ на: комментарий от runtime

Prolog ... например, разные реализации интерпретатора могут использовать разный синтаксис.

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

возможно, это было просто моё ощущение :)

Ещё можешь глянуть на Mercury, эдакая помесь Prolog и Haskell.

интересный, язык, но, к сожалению, малораспространённый, а значит у него сравнительно небольшая кодовая база и значит будет «приветвелосипед»

shty ★★★★★ ()
Ответ на: комментарий от ott

я бы посмотрел на Clojure. Причины - переносимость, поскольку JVM, доступ к существующим библиотекам (например, lingpipe), наличие инструментария (IDE, etc),

а насколько плотно он тянет за собой яву? то есть если я потом захочу пересесть на тот же LispWorks во что мне это может встать? или такая пересадка не имеет особого смысла?

спасибо :)

shty ★★★★★ ()
Ответ на: комментарий от shty

а зачем переезжать на LispWorks? Стоит отметить, что Clojure лиспообразный язык, но не совместима с Common Lisp - в ней хватает своих плюсов и минусов. Но плюсы имхо перевешивают :-)

P.S. http://fprog.ru/2010/issue4/alex-ott-clojure/ - введение в Clojure, я скоро эту статью выложу у себя на сайте, с обновлениями для версии 1.2. Вот еще слайдкаст про Clojure - http://www.slideshare.net/alexott/clojure-margincon-2010

ott ★★★★★ ()
Ответ на: комментарий от dmsh

1. Пролог не является ФЯ.

спасибо, я в курсе, и, если Вы внимательно посмотрите, в моём исходном сообщении он нигде не называется ФЯ :) хотя, каюсь, такой вывод можно сделать из моего сообщения, но тем не менее я осознаю разницу (хотя может и не то что бы во всей полноте)

2. Эрланг можно считать Пролог-лайк разве что по части синтаксиса, не более.

эм, ну он скорее сильно расширенный пролог, а почему Вы считаете что что они совсем не похожи?

3. Можно еще посмотреть на Фактор, всё заявленное, кроме коммерческой реализации, там есть.

кстати да! правда у него странный довольно синтаксис %)

shty ★★★★★ ()
Ответ на: комментарий от ott

а зачем переезжать на LispWorks?

1) вот я и пытаюсь понять :) настолько ли он хорош? вообще пробовал триалки и LispWorks и AllegroCL, был весьма впечатлён и, если бы не сравнительно «аццкие» цены и, мягко говоря, не очень разумная политика лицензирования я бы уже давно на одном них сидел

2) принимать окончательное решение об использовании платформы будет начальство, а начальство чтобы было «солидно» (правда начальство не очень любит платить много денег, но если надо - заплатит)

Стоит отметить, что Clojure лиспообразный язык, но не совместима с Common Lisp - в ней хватает своих плюсов и минусов. Но плюсы имхо перевешивают :-)

P.S. http://fprog.ru/2010/issue4/alex-ott-clojure/ - введение в Clojure, я скоро эту статью выложу у себя на сайте, с обновлениями для версии 1.2. Вот еще слайдкаст про Clojure - http://www.slideshare.net/alexott/clojure-margincon-2010

спасибо за материалы, поизучаю с пристрастием

shty ★★★★★ ()
Ответ на: В копилку Питона: от ntp

Re: В копилку Питона:

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

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

Например есть Natural Language Toolkit и книжка «Natural Language Processing with Python».

кстати, да! совсем забыл :) надо будет тоже поковырять, спасибо

shty ★★★★★ ()
Ответ на: комментарий от shty

ну насчет «солидности», то тут наоборот можно аппелировать, что платформа энтерпрайзная :-)

P.S. если будут вопросы, то можно почтой или jabber - alexott at gmail.com

ott ★★★★★ ()
Ответ на: комментарий от anonymous

Lisp - весьма разносторонний язык, есть весьма вменяемая свободная реализация (Clozure CL; SBCL, увы, *nix oriented) и мега-буст с точки зрения коммерческих реализаций (Allegro CL, LispWorks), есть так же реализация под Java VM.

Clozure CL нативно работает на windows x86/x64_64 включая треды.

это в нём и подкупает :)

SBCL треды под windows активно пилятся dmitry-vk.

насколько я знаю он пока не особо работает под windows, хотел сам заняться, но не доходят руки и слишком много поднимать надо

> Erlang - годный Prolog-like язык, но меня смущает его ориентация на телеком.

еще один миф. Erlang/OTP прекрасно подходит, как язык общего назначения.

да, умом я это понимаю, но смущает же :)

shty ★★★★★ ()
Ответ на: комментарий от ott

ну насчет «солидности», то тут наоборот можно аппелировать, что платформа энтерпрайзная :-)

и на ту же чашечку весов 2000-4000$ за каждое «коммерческое» рабочее место для лиспа + лицензионные отчисления за каждый проданный продукт (хотя это в нашем случае не имеет значения)

P.S. если будут вопросы, то можно почтой или jabber - alexott at gmail.com

с удовольствием, большое спасибо :)

shty ★★★★★ ()

вот мне просто любопытно - кто первым назвал Erlang Prolog-подобным языком, и какие вещества он перед этим употреблял

jtootf ★★★★★ ()
Ответ на: комментарий от shty

я осознаю разницу

Если честно, не похоже.

эм, ну он скорее сильно расширенный пролог

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

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

правда у него странный довольно синтаксис

Я вот тут писал про синтаксис. Все гораздо проще, чем кажется. http://www.linux.org.ru/forum/development/5163288#comment-5163883 (комментарий)

dmsh ()
Ответ на: комментарий от shty

дело в том что в данной предметной области довольно много неопределённостей разного рода и, соответственно, проще определить «условия игры», чем предусмотреть все варианты

Тогда смотри варианты, где есть полноценный REPL. Просто немерянно сокращает время на разрешение неопределённостей. Ещё я бы сразу отбросил варианты, где целочисленные типы привязаны к машинным ограничениям (типа Int - это 32 или 64 бита). Bignum, ratio должны быть из коробки, и переход между форматами должен происходить прозрачано.

mv ★★★★★ ()

На работе занимаюсь обработкой текстов на естественном языке.

В памяти всплывает SnePS

Маленькое уточнение: требуется кроссплатформенное решение (windows, linux, macos) с возможностью компиляции в байт-код, хорошо бы иметь потоки, GUI не особо нужны, но будут плюсом, ide - неважно. Ещё один важный момент: наличие коммерческих реализаций с целью дальнейшего на них перехода или, как вариант, серьёзного бэкграунда.

Я за Common Lisp. В комерческих реализациях всего и мого + встроенный prolog в довесок. Для открытых реализаций несколько «вместо прологов». На cliki.net посмотри. Про SNePS уже говорил. SBCL не на линуксе штука относительная, и не только из-за тредов. Но для винды есть вполне рабочий colinux, но 32-bit only. Если именно байт-код то может быть ecl? Вполне себе кросплатформенен. GUI самосборные gtk или qt. Совать haskell в enterprise ИМХО аккуратно имея опыт набитых шишек.

antares0 ★★★ ()
Ответ на: комментарий от jtootf

наверное сам автор языка? Особенно если вспомнить, что первая версия эрланга была написана на прологе :-) History of Erlang - очень интересная статья

ott ★★★★★ ()
Ответ на: комментарий от jtootf

вот мне просто любопытно - кто первым назвал Erlang Prolog-подобным языком, и какие вещества он перед этим употреблял

Joe Armstrong, про вещества не в курсе

Erlang Factory: Joe Armstrong: Keynote - What are the Important Ideas in Erlang?

1985-1989

[..]

Decided to add reduction methodology to Prolog using term rewriting. Allowed calculations to be suspended at any time.

1986-12-18 version 1.06 of Erlang is out.

взято отсюда

shty ★★★★★ ()

[quote] переходом на следующий уровень (синтаксический анализ, автоматическая генерация правил, синтез исходных понятий и т.д.) стало ясно что количество «матана» начинает зашкаливать и реализовывать это «в лоб» (на С++) конечно можно попробовать, но будет грустно и непродуктивно. Соответственно появилась идея попробовать решить задачу в функциональном стиле, есть ощущение что решение получится красивое и волне себе лаконичное. [/quote]

Вопрос что подразумевется под «матаном» «функциональным подходм» и то и другое в лиспе своеобразно. И желательно некоторое понимание как это реализуется в лиспе, ато может получится такой «удобный с++» вместо красивого и лаконичного

antares0 ★★★ ()
Ответ на: комментарий от dmsh

эм, ну он скорее сильно расширенный пролог

Да ничего подобного. В эрланге нет т.н. «логических переменных» [..]

...и немножко обрезанный :)

хотя, как сам Joe Armstrong сокрушался

Big Mistake

Lost too much prolog.

shty ★★★★★ ()
Ответ на: комментарий от mv

дело в том что в данной предметной области довольно много неопределённостей разного рода и, соответственно, проще определить «условия игры», чем предусмотреть все варианты

Тогда смотри варианты, где есть полноценный REPL. Просто немерянно сокращает время на разрешение неопределённостей.

да он сейчас практически везде есть в той или иной форме :)

тут неопределённость в самой задаче скрыта, например вот:

Теперь о множественности разбора. В принципе, это та же самая проблема, но с другой стороны. Если пытаться построить все допустимые деревья разбора, мы проваливаемся в ту же «экспоненциальную яму». Понятно, что вариантов разбора будет два-три, ну четыре. Однако в процессе попыток склеить что угодно с чем угодно возникают очевидные накладные расходы :)

Понятно, что многие слова неоднозначны, но их трактовка не влияет на вид дерева, то есть на синтаксический анализ: «я держу деньги в банке». Здесь разбор однозначен: держу деньги (где?) — в банке. При этом неважно, стеклянная банка у меня или каменное здание банка.

Есть «промежуточные» варианты. «По улице шла девушка с косой». Можно всегда разбирать так: девушка (с чем?) — с косой. А можно выбирать: девушка (какая?) — с косой (если речь о причёске); девушка (с чем?) — с косой (если речь о металлической косе).

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

взято отсюда

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

Ещё я бы сразу отбросил варианты, где целочисленные типы привязаны к машинным ограничениям (типа Int - это 32 или 64 бита). Bignum, ratio должны быть из коробки, и переход между форматами должен происходить прозрачано.

возможно, но я с текстом работаю, у меня чисел считай и нет

shty ★★★★★ ()
Ответ на: комментарий от antares0

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

Вопрос что подразумевется под «матаном»

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

Трибанки

Теперь ещё пару слов о таком важном явлении как трибанки (treebanks). К сожалению, в них я пока слабо разбираюсь — всё руки не доходят.

Мы тут уже рассуждали о том, откуда берутся правила грамматики. Понятно, что их можно либо сочинять вручную, либо «каким-то образом» извлекать из существующих текстов. Простые статистические подходы (наводящие на меня тоску) просто анализируют чистый текст в первозданном виде, опираясь на довольно условные «эвристические» критерии. Например: стоящие рядом слова с большей вероятностью зависят друг от друга, чем слова, стоящие поодаль. Мне кажется, далеко на таких принципах не уедешь; для себя я пользуюсь таким критерием: можно ли на идеях предлагаемого парсера естественного языка написать парсер несравнимо более простого Паскаля? Если нельзя, то, по-моему, тут и говорить не о чем.

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

Логичным образом трибанки делятся на phrase-structure treebanks и dependency treebanks. Вероятно, самый известный пример банка первого рода — Penn treebank, синтаксис аннотаций которого является де-факто стандартом для «хомскианских» трибанков. Dependency treebanks — явление более свежее, их пока явно меньше. Наверно, чаще других упоминается The Prague Dependency Treebank чешского языка. Есть и другие, конечно (см. проекты со словом «dependency» в названии). Для русского, как обычно, какая-то работа «в процессе», но ничего конкретного сказать пока нельзя.

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

[..]

(это, кстати, уже ближе к моей задаче)

отсюда

что подразумевется под [..] «функциональным подходм»

что-то вроде такого:

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

и то и другое в лиспе своеобразно. И желательно некоторое понимание как это реализуется в лиспе, ато может получится такой «удобный с++» вместо красивого и лаконичного

не, ну без мозга лучше из дома не выходить, «забыл? - вернись одень» :)

просто я уже сейчас ощущаю с каким скрипом это всё будет писаться на С++ и каково будет отношение результат/затраченные_усилия и мне уже не хочется такого развития событий

shty ★★★★★ ()
Ответ на: комментарий от shty

не-не-не - такие вещи лучше всего писать в REPL, а на С/С++ (а еще лучше на OCaml) можно переписать то, что будет сильно тормозить...

ott ★★★★★ ()
Ответ на: комментарий от shty

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

Отличный способ навешать кому-нибудь лапши на уши :)

Ни один язык (даже пролог, который емнип создавался для машинного перевода) не даст тебе волшебного способа решить задачу просто так, предоставив только ее «описание» (что бы это ни значило).

Я так понимаю тебе нужен более гибкий (чем кресты) язык, в котором можно было бы отдельно задавать «описание» понятий/правил/отношений/whatever в относительно свободной форме и отдельно программировать «решатель», который по входным данным и «описаниям» давал бы ответ. Если так, то пролог подходит вроде.

Как dsl'и делаются на факторе можно посмотреть тут: http://factor-language.blogspot.com/2009/09/survey-of-domain-specific-languages-in.html

dmsh ()
Ответ на: комментарий от ott

наверное сам автор языка?

правда, что ли?

первая версия эрланга была написана на прологе

что говорит только о том, что автор хорошо знал Prolog

History of Erlang

почитаю

jtootf ★★★★★ ()

А в каком виде будет поставляться твое решение? Это либа или отдельное приложение? Если либа, то с чем она будет линковаться? Если приложение, то как оно будет запускаться? Что это, вообще, из себя будет представлять?

Думаю, ответив на эти вопросы, можно будет отсеять список претендентов :)

dave ★★★★★ ()

обработкой текстов на естественном языке

Лисп

pseudo-cat ★★★ ()

Странный набор языков - динамически и статически типизированные в одном ряду.

Из предложенного списка я бы выбрал ничего или Ocaml :) Ну а вообще - Scala, ибо доступ к Ява-библиотекам.

tailgunner ★★★★★ ()

А можно нескромный вопрос: ты с С++ насколько хорошо знаком? И еще: пример задачи можешь привести? Уверен, что необходимый набор алгоритмов и абстракций можно реализовать на чем угодно с относительно небольшими затратами, если с с «матаном» и языком разберешься до конца. Я не думаю, что весь твой перечень языков удовлетворяет нужным критериям. Во-первых, на любом из них придется изобретать велосипед, во-вторых, о кроссплатформенности можешь забыть. Чтобы не говорили местные завсегдатаи, но тот же CL (точнее его реализации)- нифига не перносим, ДА, блин! Когда не работает банальный asdf:install под виндой - это ппц. Ну или плати за LW. В любом случае, имхо, зашкаливший уровень матана никак не коррелирует с выбором языка. Нифига не очевидно, что если ты возьмешь супер-пупер функциональный язык, то сразу кодинг станет легче и «матан» станет понятнее. Ты не задумвался над тем, сколько тебе предется угробить времени на освоение эффективного (подчеркиваю, эффективного) кодинга на ФЯ? И это не говоря о том, что для большинства из них существует только рудиментарная поддержка среды разработки.

А так да, сейчас тут тебе насоветуют...

cathode ()
Ответ на: комментарий от dmsh

>> Ни один язык (даже пролог, который емнип создавался для машинного перевода) не даст тебе волшебного способа решить задачу просто так, предоставив только ее «описание» (что бы это ни значило).

+2^10

Иногда складывается такое впечатление, особенно после всяческих туториалов про язык (любой, но особенно ФЯ), что, блин, стоит только подумать, и оно все само напишется. Топикстартер не представляет сколько будет е*ли с переходом на ФЯ.

cathode ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.