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

★★★★★

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

>> С asdf2 вещи стали проще.

К сожелению нет. Проверка через GPG таки не работает - это раз, как ни странно, но asdf-install ищет в *FEATURES* символы (типа :windows), которых нет в некоторых реализациях (благо решается тривиально), и в-третьих, оно часто заточено на implementation-specific вещи, котрые исчезают так же быстро как и появляются (а часто, как в sbcl под виндой, вообще не работают). Это я все из опыта общения с Сlozure CL и SBCL под Windows говорю, при этом в CCL таки удалось добится работы (без GPG), а в sbcl - нет.

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

не-не-не - такие вещи лучше всего писать в REPL

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

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

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

(а еще лучше на OCaml)

а, кстати, для каких применений хорош OCaml? я правильно понимаю что это эдакий Python по позиционированию?

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

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

рудиментарная поддержка среды разработки

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

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

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

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

OCaml? я правильно понимаю что это эдакий Python по позиционированию?

Сейчас тебя съедят.

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

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

не, ну ясно дело, но тут задача другая :)

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

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

всё так :) а как Вы считаете что в контексте этой задачичто подходит лучше Lisp или Prolog или даже Factor (мне он показался больше на работу с текстом заточенным)? или никакой разницы, были бы руки?

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

спасибо, обязательно подгляну :)

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

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

чаще как сервис, иногда как standalone, думаю что либа тоже будет востребована

Если либа, то с чем она будет линковаться?

скорее всего будет тягаться из чего-нибудь типа Perl

Если приложение, то как оно будет запускаться?

либо как сервис, либо через консоль

Что это, вообще, из себя будет представлять?

хотел бы я знать :) тут вопрос какой - надо решить задачу, а потом как надо_будет/попросят - так и сделаю :) в конце концов биндингов понаделать или через сетку организовать общение - не проблема

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

У тебя всё закончится написанием DSL(я/ей). Ну ты понял, какой язык выбирать надо ;)

на всякий случай спрошу: Lisp? :)

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

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

меня динамическая/статическая типизация не смущает, на качество решения задачи тоже особого влияния я не вижу, а если так то какая разница какая там типизация?

Из предложенного списка я бы выбрал ничего или Ocaml :)

нескромный вопрос: а почему OCaml? (мне он в общем то нравится, но всё никак не решусь потратить время на изучение)

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

> меня динамическая/статическая типизация не смущает, на качество решения задачи тоже особого влияния я не вижу

Я вижу.

нескромный вопрос: а почему OCaml?

Гибридный, не-ленивый (этакий Питон среди статически типизированных ФЯП :) Правда, у Ocaml с библиотеками беда, насколько я могу судить.

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

а как Вы

Ну зачем вот это вот?

в контексте этой задачичто подходит лучше Lisp или Prolog или даже Factor (мне он показался больше на работу с текстом заточенным)? или никакой разницы, были бы руки?

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

Могу еще показать пример большущего dslя на прологе: http://logtalk.org/ К слову о переносимости, по заверениям автора эта штуковина работает на десяти разных реализациях пролога без модификаций.

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

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

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

>> Не слишком ли громкие заявления?

Не выдерай из контекста.

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

IDE под Lisp вообще (любой) - Emacs. Конечно если не лень собирать конструктор - то в путь. А так, после, например, IntellijIDEA, ну или на крайняк NetBeans/Eclipse под жабу, и, пардон за моветон, Visual Studio под плюсы, Emacs выглядит как архаичное говно времен начала заката PDP-11.

Haskell - флаг в руки! ИМХО быстрее найти нужные алгоритмы и реализовать на плюсах (если знаешь плюсы), чем изучить Haskell во всей его красе. Примитивные вещи везде делаются примитивно, а что-то посложнее в Хаскеле требует не только хорошего знания ФП (что само по себе не имеет отношения к языку, и оно не так тривиально как кажется), но и умения обходить причуды Хаскеля (та же ленивость). IDE отсутствует (leksah пока еще убог).

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

Prolog - если за последние 10 лет ничего не изменилось, а оно по-моему так, то Пролог по уровню активности разработки и наличию инструментальных средств находится где-то там же где Algol68.

OCaml - ну Ocaml mode for Emacs, ничего особенного не предлагающий, ну еще пару OSS проектов с большими амбициями и все.

Erlang - хз не пробовал.

Я к чему все это пишу: ты начал не с того конца. Пресловутый «матан» надо изучать - это база решаемой задачи и ее понимание куда важнее чем советы на ЛОРе типа «Хацел наще усё». Выбор языка тебе тут не поможет и тем более ни кто за тебя ни чего не напишет. Ты думаешь, что взяв лисп в руки будет рай? Хрен там, весь тот матан тебе так или иначе придется реализовать хоть на лиспе, хоть на плюсах, только подход к кодингу может стать несколько другим, но не факт, что это сократит объем работы. Специфика работы будет другой - это да, а объем - вряд-ли. ИМХО, твои потуги с выбором языка - это попытка переложить с больгой головы на злоровую, не более того.

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

А можно нескромный вопрос: ты с С++ насколько хорошо знаком?

это сложный вопрос, Мейерса из себя изображать не стану, но и в исходниках STL/boost/whatever не запутаюсь

И еще: пример задачи можешь привести?

пока задача сформулирована в общих фразах, что-то вроде типа «автоматическая генерация правил для семантического анализа текста»

Уверен, что необходимый набор алгоритмов и абстракций можно реализовать на чем угодно с относительно небольшими затратами, если с с «матаном» и языком разберешься до конца.

да, можно реализовать, но на С++ на это уйдёт в 3 раза больше времени и в 10 раз больше сил

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

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

ну это Вы, батенька, погорячились :)

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

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

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

Нифига не очевидно, что если ты возьмешь супер-пупер функциональный язык, то сразу кодинг станет легче и «матан» станет понятнее.

в общем случае - нет, в случае конкретной задачи - вполне вероятно

Ты не задумвался над тем, сколько тебе предется угробить времени на освоение эффективного (подчеркиваю, эффективного) кодинга на ФЯ?

ничуть не больше чем на произведение операции на хрусталике через анальное отверстие, а нервов сберегу кучу, ЧСВ своё повышу, впишу строчку в резюме и повышу свою ценность для будущего какого-нибудь работодателя

да и вообще это интересно :)

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

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

на С++ :)

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

для eclipse плагины есть у многих, emacs хорошая среда, да и блокнотиком с синтаксисом я не гнушаюсь :)

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

это как бы и было целью создания данного треда :)

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

Ну насчет деревьев и графов - нормальные реализации на Java не сильно проигрывают С++ в производительности. А проблем с отладкой меньше. Поэтому же и Окамл лучше чем С/С++ - типизация дает некоторую защиту от ошибок, но при этом скорость работы - очень высокая.

Послушай вот этот слайдкаст - http://www.slideshare.net/j2a/ss-4625844, Лев Валкин рассказывает как они у себя применяют ФЯ и почему Окамл вытесняет С/С++

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

>> мне он показался больше на работу с текстом заточенным

Ты задачу какую-нибудь нарисуй, а то так для работы с текстом и перловка хорошо заточена, даже лучше чем большинство. Посоветовать тебе перл? )))

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

Топикстартер не представляет сколько будет е*ли с переходом на ФЯ.

Вы в этом так уверены? :)

и да, ТС представляет сколь @бли будет если решать задачу в лоб :)

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

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

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

> меня динамическая/статическая типизация не смущает, на качество решения задачи тоже особого влияния я не вижу

Я вижу.

хмы, сарказм... а почему это должно меня смущать?

> нескромный вопрос: а почему OCaml?

Гибридный, не-ленивый (этакий Питон среди статически типизированных ФЯП :)

это прекрасно, а практические профиты? :)

Правда, у Ocaml с библиотеками беда, насколько я могу судить.

это не беда - всё равно свои лисапеды писать

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

> glib,

Просто не нужен нигде, кроме Си

gtk

Уже есть в Ocaml

clutter, cairo, pango, atk, gstreamer - мало?

Даже не знаю... Cairo, вероятно, вещь полезная. Остальное мне лично точно не нужно, и, подозреваю, ТС'у тоже.

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

Я к чему все это пишу: ты начал не с того конца. Пресловутый «матан» надо изучать - это база решаемой задачи и ее понимание куда важнее чем советы на ЛОРе типа «Хацел наще усё». Выбор языка тебе тут не поможет и тем более ни кто за тебя ни чего не напишет. Ты думаешь, что взяв лисп в руки будет рай? Хрен там, весь тот матан тебе так или иначе придется реализовать хоть на лиспе, хоть на плюсах, только подход к кодингу может стать несколько другим, но не факт, что это сократит объем работы. Специфика работы будет другой - это да, а объем - вряд-ли. ИМХО, твои потуги с выбором языка - это попытка переложить с больгой головы на злоровую, не более того.

Во-первых, я не ОП. Во-вторых, его вопрос свелся к «на каком бы мне языке написать dsl с наименьшим количеством костылей». Про матан уже забыли, с матаном он разберется без нас и язык здесь, действительно, не причем. Читай внимательней, одним словом.

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

>> Эд, Франк, Джордж и Гарри пригласили своих жен [...]

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

ЗЫ. Таблицу нарисуй кто-там кого куда пригласил, ну или welcome to matan )) http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B7%D1%8A%D1%8E%D0%BD%D0%BA%D1%82...

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

Я к чему все это пишу: ты начал не с того конца.

о как! откуда Вы знаете с чего я начал, простите? :)

Пресловутый «матан» надо изучать - это база решаемой задачи и ее понимание куда важнее чем советы на ЛОРе типа «Хацел наще усё».

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

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

Выбор языка тебе тут не поможет

не согласен, ещё как поможет

тем более ни кто за тебя ни чего не напишет.

было бы глупо полагать обратное :)

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

сократит и ещё как, поверьте :) не верите? поробуйте написать приложение для сетевого взаимодействия на C++ и Erlang и почувствуйте разницу по времени разработки, количеству строк, количеству написанных велосипедов и т.д.

Специфика работы будет другой - это да

как раз этого я и добиваюсь

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

Ну насчет деревьев и графов - нормальные реализации на Java не сильно проигрывают С++ в производительности.

я имел в виду в сравнении с Lisp, конечно же

Послушай вот этот слайдкаст - http://www.slideshare.net/j2a/ss-4625844, Лев Валкин рассказывает как они у себя применяют ФЯ и почему Окамл вытесняет С/С++

о! спасибо :)

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

>> Читай внимательней, одним словом.

Стараюсь )) У меня тут тоже задача. На тумбочке имеется 2 пустых бутылки из под пива и 3 крышки от них. Вопрос: откуда еще одна крышка??? )))

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

для работы с текстом и перловка хорошо заточена, даже лучше чем большинство. Посоветовать тебе перл? )))

скорость неприемлема, у вас предложение в простой задаче по полчаса будет разбираться :) это в сравнении с десятками секунд на С++

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

>> как раз этого я и добиваюсь

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

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

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

это да, но применение зависит от задачи, к примеру, в морфологии 1-3 специализированных словаря нужны и обвязка к ним, на С++ пишется довольно просто (если не извращаться с fusion trees, array compacted trees и прочими придумками злых гениев ;)) а работает существенно быстрее

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

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

золотые слова :)

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

Стараюсь )) У меня тут тоже задача. На тумбочке имеется 2 пустых бутылки из под пива и 3 крышки от них. Вопрос: откуда еще одна крышка??? )))

неправильный вопрос, правильный - кто спёр бутылку? :)

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

>> золотые слова :)

Как вариант YACC/BISON не рассматривается? Придумай грамматику DSL, опиши ее в YACC, прегони программу на DSL YACCом в C и готово. Чем не джидайский метод, серьезно?

cathode ()

я бы последовал совету Alex Ott и взял Clojure, тот же Lisp (я знаю о различиях, но основы...), во-вторых это JVM, отсюда куча библиотек... ну а в третьих, очень быстро развивающееся комьюнити, наличие качественных книг, по которым нетрудно разобраться в языке, на мой взгляд это очень хороший профит... опять же, IDE, есть Emacs, который таки для лиспа подходит как ни что другое, ну а для любителей Eclipse есть и соответствующий плагин. Так что я считаю выбор уже сделан, начинай смотреть на Clojure ближе :)

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

конечно же не «профит», а «бинифит» %)) спать надо ложиться...

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

работает существенно быстрее

Кстати, о скорости. Если тебе предстоит упереться в скорость выполнения, то с прологом это произойдет скорее всего раньше, чем с остальными языками.

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

dmsh ()

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

Cy6erBr4in только вот что-то темнит, на аватаре эрланг, а сам кложуру нахваливает. Никак затеял что-то.

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

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

а лиспы я давно люблю, и Clojure сейчас мне нравится все больше и больше.

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

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

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

и да, реализуй сначало прозрачный I/O в распределенной системе (так как это сделано в Erlang), и чтобы было не через жопу, как ты выразился (кстати сказать я не понимаю тебя, что там через жопу-то, объяснил бы чтоли), и чтобы было быстро.

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

Erlang - хз не пробовал.

а потом вот так вот пытаются доказать обратное...

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

так все же пробовал, или заявление об медленном «черезжопу» I/O было сделано основываясь на знаниях почерпнутых из обсуждений на ЛОРе?

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

золотые слова :)

Как вариант YACC/BISON не рассматривается? Придумай грамматику DSL, опиши ее в YACC, прегони программу на DSL YACCом в C и готово. Чем не джидайский метод, серьезно?

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

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

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

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

я бы последовал совету Alex Ott и взял Clojure, тот же Lisp (я знаю о различиях, но основы...), во-вторых это JVM, отсюда куча библиотек... ну а в третьих, очень быстро развивающееся комьюнити, наличие качественных книг, по которым нетрудно разобраться в языке, на мой взгляд это очень хороший профит... опять же, IDE, есть Emacs, который таки для лиспа подходит как ни что другое, ну а для любителей Eclipse есть и соответствующий плагин. Так что я считаю выбор уже сделан, начинай смотреть на Clojure ближе :)

этот вариант рассматривается и очень серьёзно

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

Кстати, о скорости. Если тебе предстоит упереться в скорость выполнения, то с прологом это произойдет скорее всего раньше, чем с остальными языками.

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

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

с учётом того что фактор нормально допилен с точки зрения кроссплатформенности - это действительно круто

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

>> а потом вот так вот пытаются доказать обратное...

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

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

вспоминается опыт Viaweb

Забудь про это. Viaweb - чистой воды PR от Грэхэма.

во-первых почему Вы так считаете?

во-вторых я отнюдь не прочь чтобы мой PR купила какая-нибудь Yahoo :)

shty ★★★★★ ()
Ответ на: комментарий от cathode
Офигительная аргументация - поищи посты. А самому есть что сказать, или только будем слюньками брызгать?

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

http://gaperton.livejournal.com/11736.html

самому есть что сказать, на Erlang'е я пишу каждый рабочий день, и могу с уверенностью сказать, что за последние два года, которые я серьезно занимаюсь Erlang'ом, ни раз, подчеркиваю, ни разу не было проблем со скоростью I/O

Cy6erBr4in ★★★ ()
Ответ на: комментарий от cathode
Да, сам не писал, но знаю/видел как это делают другие и пользовался плодами их работы.

чтобы не быть голословным, ты конечно же приведешь примеры того что ты знаешь/видел, и какими же плодами на Erlang ты пользовался, да ведь? а то так совсем не солидно будет, если примеров-то не приведешь...

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