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 и иже с ним не предлагать.

★★★★★

Ответ на: комментарий от ahonimous

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

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

>А ведь никакого «крутого метапрограммирования» здесь ещё не было, просто использование стандартных возможностей STL.

Это не метапрограммирование, а «продвинутые макросы», для чего, собственно, шаблоны и использовались до первого прихода не-помню-какому-безумцу. Использование шаблонов в таком виде, кстати, не сильно убивает время компиляции. А вот стоит #include <boost/some_shit.hpp>, как начнется. Хотя даже в бусте есть пара вменяемых моментов.

В реальном коде вложенность в 30 шаблонов возникает сама собой, даже в довольно обычном коде.

За std::vector<std::map<blah,std::set<blah>>> надо жестоко карать.

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

> За std::vector<std::map<blah,std::set<blah>>> надо жестоко карать.

Хорошо, предложите достойную альтернативу такому шаблону:

std::map<std::string, std::vector<std::string> >

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

> для чего, собственно, шаблоны и использовались до первого прихода

не-помню-какому-безумцу


Не знаю насчёт того, кто первый придумал, но популяризовал, вероятно Александреску. Но что плохого в его идеи проектирования на основе стратегий? А списки типов ведь шикарная идея, которая позволяет порой избавиться от очень большого количества лишних строк кода. Вообще, весь смысл шаблонов в борьбе с дублированием кода. Для этого их и используют. Или вы предпочитаете раздувать код, лишь бы не было «страшных» шаблонов?

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

> Какие библиотеки из boost попали в стандарт?

thread, smart_ptr

вы из гопоты?

«обзываетесь» и «ярлыки развешиваете» через пост (или даже чаще).



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

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

> Или вы предпочитаете раздувать код, лишь бы не было «страшных» шаблонов?

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

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

> как раз это ваша привычка - вы уже не раз переходите на личности

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

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

> Если вы не способны выдерживать дискуссию в техническом ключе

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

и постоянно используете слова типа «секта», «латентный»


один раз в течении разговора написал - и у вас нервный срыв? не знал, что вы такой ранимый

и при этом ведёте себя по хамски


вы обиделись на слово «латентный»? ну так оно не обидное если-что

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

>Хорошо, предложите достойную альтернативу такому шаблону:

std::map<std::string, std::vector<std::string> >

std::map<std::string, std::tr1::shared_ptr<std::vector<std::string> > >

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

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

>Вообще, весь смысл шаблонов в борьбе с дублированием кода.

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

Для этого их и используют.

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

Или вы предпочитаете раздувать код, лишь бы не было «страшных» шаблонов?

Я предпочитаю, чтобы код был ясным без гадания на кофейной гуще на тему: и какой же, б$#ть вариант шаблонной перегруженной функции вызовется в этой строке.

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

>вы обиделись на слово «латентный»?

Конечно! Воинствующий лиспер обижается, когда его принимают за латентного.

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

>а в чем тут смысл shared_ptr?

Во-первых, почитай стандарт (описание STL же входит в плюсовый стандарт?) и покажи мне стрчку, где написано, что хотя бы std::basic_string должен использовать подсчет ссылок. После этого можешь попытаться найти реализацию STL, где хоть один контейнер (basic_string контейнером не считать) использует подсчет ссылок для избегания копирования содержимого.

>в том же Qt - данные расшариваются, но есть COW

У тебя куте головного мозга?

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

> Во-первых, почитай стандарт (описание STL же входит в плюсовый стандарт?) и покажи мне стрчку, где написано, что хотя бы std::basic_string должен использовать подсчет ссылок. После этого можешь попытаться найти реализацию STL, где хоть один контейнер (basic_string контейнером не считать) использует подсчет ссылок для избегания копирования содержимого.

много слов - а ответа на простой вопрос нет, еще раз - «в чем тут смысл shared_ptr?»

У тебя куте головного мозга?


нет - я даже не пользуюсь их контейнерами, потому-что stl рулит и педалит

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

>много слов - а ответа на простой вопрос нет, еще раз - «в чем тут смысл shared_ptr?»

Избегание дорогого копирования.

нет - я даже не пользуюсь их контейнерами, потому-что stl рулит и педалит

Тогда я совершенно точно не понимаю, к чему пассаж про CoW

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

> Избегание дорогого копирования.

с учетом хранения указателя в несколько местах, с тем, что изменение в одном месте затронет все остальные? не совсем типичная задача как для массива строк

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

> У него C++ головного мозга.

а у тебя CL + неизлечимый алкоголизм, и что?

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

>не совсем типичная задача как для массива строк

Вообще-то вполне себе типичная. К примеру, словарь синонимов.

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

не привыкну к лор-синтаксису.

typedef std::vector<std::string> myStrings;

std::map<std::string, myStrings>

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