Функциональное программирование - оно нужно? Кому?

опять?

http://fprog.ru/

Зато Лисп живее всех мертвых.

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

Чисто функциональная парадигма - не знаю, а вот функциональные приемчики в определённых частях программы очень даже полезны, и улучшают логику и читаемость кода. Благо это возможно на Python-е и Си (через пень-колоду, но возможно)

Хотя Форт, конечно, не совсем функциональщина, но и императивщина там какая-то особая. Мне бы в детстве понравилось.

> O'Caml, судя по всему, дохлый

не, это ты упоротый :)

O'Caml — это такой недохаскель с более веселой производительностью. Нужен.

Боишься что люди зря время теряют? Расскажи это кому-нить более «бесполезному», их вообще >90%.

Ocaml и F# живее всех живых, как и Erlang.

Да я не боюсь. Просто сейчас буду это учить, а кому оно нужно (вообще) пока не понял :)

Нужен.

смотри доп. вопрос - «Кому?»

логика всякая (в том числе и бизнес), ии и тому подобные вещи :)

Нужно. Мне. Затем. Да.

Ненужность чего-либо конкретному шлололу не означает его ненужность вообще.

Капитан сегодня в ударе?

Не. OCaml нее нужен. Инфа 100%.

Erlang, Ruby, Haskell на худой конец. Возможно F# наберет обороты. Вот эти языки нужны. У них есть своя ниша. А OCaml не нужен. Он не эффективен.

Оно нужно и оно уже здесь многго лет.
Из много лет популярных: XSLT, С#, Javascript
Из молодых да ранних: F#
На подходе Java 8 где Оракл это задекларировал.

На подходе Java 8 где Оракл это задекларировал.

Тоже самое говорили про семерку.

OCamL живой ! pfff же :)

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

OH-SHI, не обратил вниманиена раздел. Но нямки всё-равно будет мало.

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

Говорят. Это почти правда. Я пробовал «заменять». Вот что я вам скажу. Пока у OCaml не появится нормальных библиотек для всего на свете, он с мертвой точки не сдвинется. У этого языка БЫЛ большой потенциал, но его угробили сами же его разработчики создав кастрированный рантайм и не обеспечив нормальную поддержку библиотеками. Как итог имеем язык с отличной производительностью и непривычным синтаксисом, который ФОРМАЛЬНО является высокоуровневым (в смысле высокоуровневым по сравнению с С++), но в котором по факту каждую мелочь приходится реализовывать самому.

F# родился из OCaml и учел все его ошибки. Правда перешел на .Net потеряв в скорости исполнения программ, но получив гибкость и хорошую поддержку. У него есть шанс пробиться на большую сцену. Для OCaml лучшие его годы остались позади.

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

И да, есть книжка «DSLs in action», можно скачать бесплатно без смс регистрации

>XSLT, С#, Javascript

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

вроде аналога GIL

И это в функциональном языке? Каким образом они этого добились?

Это в очень многих языках на самом деле есть. В том же erlang, например. Haskell, кажется, тоже не смог избежать этой участи. Так что в целом это не так уж и плохо. Проблема у всех этих языков общая: они проектировались в те времена, когда о многоядерных компьютерах еще даже и не думали. То есть были многопроцессорные машины, но их было мало и для них применялись другие технологии.

А сейчас наступила новая действительность и все чаще требуется реальная многопоточность. И тут выплывает этот GIL...

Справедливости ради стоит упомянуть, что в 99% случаев он не становится помехой разработчику и почти не влияет на производительность, но тенденции уже сейчас заметны.

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

Поправочка. В erlang не только зеленые потоки помогают обойти GIL. Там еще кластерная структура приложений очень мощный инструмент. Грубо говоря, ваше приложение может выполняться на целом кластере так, как будто оно выполняется на одном компьютере. Писать такие приложения не намного сложнее, чем однопоточные. Аналогов в других языках я не знаю.

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

Да, по теме. Функциональное программирование, конечно же, нужно. Это же просто шаг вперед после прямого указания процессору, что ему делать. Сначала писали в машинных кодах. Потом придумали ассемблер и стало легче,но ничуть не короче. Потом изобрели ЯВУ и программы стали короче при том же уровне сложности. Но уровень сложности стал расти и сейчас требуется создать новый инструмент, позволяющий создавать очень сложные программные продукты при сравнительно низких трудозатратах. У тут на сцену выходит функциональное программирование, как противопоставление императивному подходу. Теперь несколько инструкций «разворачиваются» компилятором в целые блоки кода в несколько тысяч строк на языке более низкого уровня (часто это Си или байт-код) или сразу в машинные инструкции (редко).

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

Про erlang я более менее в курсе а окамлю в глаза никогда не видел.

>Си/Си++ и других императивных языках

C++ настолько же императивный как и OCaml

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

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

Да, в OCaml тоже много лишнего можно делать с данными (там тоже есть указатели), но там контроля на порядок больше и есть альтернатива.

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

Декларативное программирование вообще — это будущее.

Кстати, советую J, очень классный язык, нигде не видел такой лаконичности.

>оно нужно? Кому?

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

Функциональным программистам.

#include <stdio.h>
#include <string.h>

#define not(a) !a
#define eq(a, b) a == b
#define if(c, t, f) c ? t : f

#define hello «hello world»

int main(int argc, char **argv) {
	return(not (eq (printf («%s\n»,
				if (eq (argc, 1),
				    hello,
				    argv[1])),
			strlen (if (eq (argc, 1),
				    hello,
				    argv[1])))));
}

> У Haskell это построение алгоритмов, результат работы которых можно описать математическими формулами (доказать, как любят говорить хаскелисты). Это даже не другой уровень программирования. Это просто другой подход к программированию.

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

Я использую просмотрщик pdf llpp, написанный на ocaml.

Что сказать-то хотел?

Это он привел пример кода, как писать не надо.

Вот это я взял из исходников твоего llpp, так что не зачет:

let cbgetg b circular dir =
  if cbempty b
  then b.store.(0)
  else
    let rc = b.rc + dir in
    let rc =
      if circular
      then (
        if rc = -1
        then b.len-1
        else (
          if rc = b.len
          then 0
          else rc
        )
      )
      else max 0 (min rc (b.len-1))
    in
    b.rc <- rc;
    b.store.(rc);
;;

Там такого много.

Мне нужно.

> На подходе Java 8 где Оракл это задекларировал.

Для того, чтобы там было нормальное ФП нужно выпилить ООП на корню. Поэтому «Оракл это задекларировал» для галочки.

1. Весело

2. Компактно

3. Очень высокоуровнево

4. Чистый ФП вызывает баттхерт у программирующего, в рамках мультипарадигменного ЯП - очень удобная вещь.

Бери Scala, уже неделю фапаю

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

После ассемблера они ни разу не магические.

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

Имхо, всё упрётся в средства разработки(компиляторы, IDE и прочию мишуру), а не в языки и их силу, хотя постепенно будут таскать фишки друг у друга. Но, имхо, пока есть IDEA и VS у Java и C#, то никакие Haskell их не вытеснят из мейнстрима.

п.с. ну и кол-во и качество документации + библиотек тоже решающий фактор.

> Ruby

Ты описался или серьезно считаешь руби функциональным?