www.open-tager.ru

Поделка от Galois, Inc. по контракту с NASA и при поддержки NIANET
http://illumium.org/node/127

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис

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

В некоторых местах наследие попыток внедрения функционального программирования даже создаёт неудобства. Типичный пример - синтаксис шаблонов в C++: попробуйте-ка написать самодельный аналог std::bind, не употребляя веществ.

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

Другими словами, ИМХО, не нужно тратить время на изучение этой экзотики. Если только не произойдёт чудо, и мир не изменится...

А как вам такая эзотерика как Алгоритмический язык ДРАКОН ?

_________________
Нет предела совершенству, но ресурсы заканчиваются быстро.

Это будет тяжёлый холивар...
Давайте зубы с другой стороны организма удалять будем
Зачем извращаться и вставлять в С++ функциональные возможности, средствами неприспособленного для этого языка, куда проще взять нормальный язык и добавить в него пару модулей на С++, если очень уж приспичило БПФ например считать .

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

Незнаю как там яйцеголовые считают факториалы, ниразу так и не пробовал, мне на научную деятельность наплевать, но функциональные языки уже давно очень коммерческая область и на них пишутся реальные зарабатывающие деньги системы, внедрить SQL инъекцию в код веб сервера на Хаскеле, получится только если автор сам реально захотел чтобы была такая возможность По скорости обработки БД быстрее только С++. Распаралеливание алгоритма проги органично понятная возможность, а не суровое испытание для пятой точки. Время экономится радикально, если прога собралась, то она 100% не упадёт, может быть как то не так ,будет работать но точно не повиснет, ошибки рантайма находятся моментально. Для коммерческого применения просто идеальная вещь, быстро и надёжно, любой пионер может быть допущен к работе - если специально вредить не будет - ничего не сломается. Сам лично втихушку приделываю модули на хаскель к своим прогам на java, начальство пока про это не знает, но когда узнает буду рьяно агитировать за него

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис

Не-не-не-не-не, я не хотеть холивар

Я всего лишь обратил внимание на факт, что встроенный в C++ язык программирования шаблонов - функциональный, и что это создаёт трудности. При чём тут факториалы, я не понял. Шаблоны - это совсем про другое. Например, про такие фишки: http://www.cplusplus.com/reference/functional/bind/ . Ну std::bind - это основы STL, всем известные. А реализован он очень извратно.

Очевидно одно: не существует языков программирования, которые будут думать за программиста и не существует "серебряных пуль" для всех задач. Уязвимости были, есть и всегда будут, по крайней мере пока код пишется человеком. Это касается и SQL, и многопоточности, и чего угодно.
С SQL и, особенно, с высокопроизводительными параллельными вычислениями я знаком не по наслышке, но убеждать ни в чём не буду.
Если приведете хоть одну реализацию SQL-сервера на Haskell, буду рад. Те, что на слуху (MariaDB, Oracle, Microsoft, Percona, Postgres, Berkley, ...) написаны на C или C++


LISP вообще на десяток лет раньше появился, чем C.

О теперешней популярности в enterprise говорят цифры: 0,05-0,1% вакансий на крупных хайринговых сайтах приходятся на функциональные языки в последние годы, это о чём-то говорит. Примерно такой процент программ и пишут на них. Всё это - специфические ниши. Кстати, Scala и Erlang в разы популярнее хаскеля (например, https://dev.by/lenta/main/v-poiskah-sam ... mirovaniya , хоть и не свежак).

Вы думаете что функциональные языки никому ненужны, на самом деле они окружают нас со всех сторон
Электронная промышленность много лет вовсю использует функциональное описание сруктуры микросхем. На выпушеную партию микросхемок патч уже не накатить и апгрейд по инету не закачать - придётся всю партию в помоечку везти. Релейные схемы в ПЛК, уже лет 60 применяют, а по сути это чистая функциональщина. И только потому что применён такой подход станки,заводы, котельные, электростанции и прочее более менее всё таки работают - ошибки "перевариваются" языком без непосредственного указания программиста.

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


ЗЫ. Вообще то тема про написание скриптов поведения для Лазертаг оборудовани.
Скриптов которые явно не выделяют какая строка за какой будет выполнена - только поведение от входных воздействий.

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис

И что же за вакансии? Может не тем занимаюсь )))))

ИМХО, изучение этой экзотики очень сильно расширяет кругозор программиста... В "филосовском" смысле ))

Чисто ради расширения кругозора, мне кажется, целесообразно начать с функционального программирования под PC, благо учебников и видеокурсов хватает, и экосистема богатая. Если конечно функциональное программирование в вашем личном списке "неплохо бы изучить" стоит на первом месте.
Также, стоит бегло просмотреть курс лямбда-исчисления, чтобы понимать причины.