Выбор языка

Я уже хорошо подзабыл хаскель (много лет даже не вспоминал про него), но монада IO у меня прочно ассоциируется именно с императивщиной, когда мы не можем достичь функциональной чистоты при взаимодействии с внешним миром, мы просто вводим объекты спец-типа, которые потом сквозным образом передаём между всеми функциями, и которые как бы являются объектами состояния внешнего мира и за счёт передачи которых мы упорядочиваем вызов функций. do,>>= и пр - это просто синтаксический сахар. Возможно я просто тогда не так понял понятие монады. Понятия монад - это одна из самых сложных для изучения областей в хаскеле, особенно то, что относится к операциям над монадами.

Насчёт сеточных методов: в разы понятие растяжимое (порядок и два порядка тоже можно разами обозвать). Кроме того плюсы совсем не показатель скорости, даже со спец библиотеками. Одни из самых шустрых методов расчета получаются на схеме в сталине (https://engineering.purdue.edu/~qobi/software.html). Зачастую проги на схеме скомпиленные сталином дают фору даже сишным вручную соптимизированными прогам (именно про математику речь).

На Java там все пишут. Что тут думать то. Кто туда ваш хаскель или сипипи пустит.

Во-первых, и IO-то чиста (если не использовать unsafePerformIO, название которой намекает), во-вторых, монад много, и далеко не все они реализуют global mutable state (к которому можно свести императивщину).

Кроме того плюсы совсем не показатель скорости, даже со спец библиотеками.

Никто без библиотек не пишет, только выжившие из ума люди и школьники.

в разы понятие растяжимое (порядок и два порядка тоже можно разами обозвать).

В разы - очевидно, меньше, чем на порядок.

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

А можно ссылки про инструментарий банков для обработки данных. Реально интересно.

Насчёт языков: недоязык, язык - это интересная терминология. По каким критериям, интересно, вы разбиваете языки на эти классы?

Языки характеризуются определённым набором свойств, например, порог вхождения и простота освоения людьми с определённым уровнем образования. Это тоже важное свойство. Мне как бизнесмену, например, будут абсолютно не интересны академические языки для программирования (будь они трижды мега-крутые) для которых я не смогу найти персонал под проект.

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

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

А можно ссылки про инструментарий банков для обработки данных. Реально интересно.

http://www.haskell.org/haskellwiki/Haskell_in_industry - там много крупных контор, сразу оговорюсь: где-то он primary language, а где-то один маленький проектик на нём.

Насчёт языков: недоязык, язык - это интересная терминология.

Недоязыком я назвал исключительно R.

Никто без библиотек не пишет, только выжившие из ума люди и школьники.

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

В разы - очевидно, меньше, чем на порядок.

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

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

Недоязыком я назвал исключительно R.

Даже насчёт R, всё-равно критерии такого деления для меня неясны. На мой взгляд, вполне себе нормальный язык (от грамматики, кстати, я тоже не в восторге) для своей области.

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

не всё так грустно на самом деле. вон известный в узких кругах dmz рассказивал недавно о найме хасскелят: http://dmzlj.livejournal.com/163223.html?nc=7&style=mine

Для среднего и мелкого бизнеса проект на хаскеле - слишком высокий риск.

С этим я не спорю.

Посмотрел быстро информацию по ссылке (подробнее чуть позже посмотрю). А чего-нибудь по-актуальнее и по-подробнее не найдётся? Всё-таки с 2009 года прошло почти 3 года, да и информация там уж слишком общая, сложно даже подробно судить о характере решаемых на хаскеле задач.

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

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

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

Так что в общем случае велосипеды не нужны.

Так что в общем случае велосипеды не нужны.

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

Часто бывает ограничение на набор инструментов для решения конкретной задачи. Например, есть отличная плюсовая библиотека, но у нас жёсткое ограничение на язык для всего проекта: используем только C. Или есть отличная матлабовская библиотека, но цифровой фильтр нам нужно реализовать в плисине на vhdl или verilog.

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