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

потому как реальный мир императивен

я ждал этого комментария)

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

наглое 4.2

R.

groovy

пішу как на java с элементамі функціональшчіны, когда надо

Что мешает писать на Хаскеле императивно, если это решает проблему лучше?

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

А мне кложура больше понравилась.

Так ты как раз подтвердил слова анонимуса.

А не, сорри, перепутал.

Те же Erlang и Scala применяются и достаточно активно.

А императивен ли реальный мир - вопрос философский.

По крайней мере в нём есть побочные эффекты.

Посыл был в том, что вычислительные выражения сложнее нотации do

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

ок, поищу сам

Я посмотрел книжки. Там по-моему простые примеры. Но имеющийся небольшой опыт программинга на F# и Haskell говорит о том, что sequence expression должны позволять то, что придется хардкодить руками в Haskell. Что-нибудь насыщенное циклами. В Haskell циклы для монад - не проблема. Есть такие функции. А вот с моноидами sequence, list и array, где операцией является склейка или накопление результатов - ситуация сложнее. Вероятно, нужно городить State или Write. Я бы где-нибудь в этом направлении искал. Нотация do же много проще, и она ориентирована на монадичекую связку.

По крайней мере в нём есть побочные эффекты.

Все «побочные эффекты» - это и есть сам мир, который шаг назад не тот, что сейчас, и через шаг вперёд тоже. Итого - банальный IO. Получили «чистую функциональщину» )))

А вот с моноидами sequence, list и array, где операцией является склейка или накопление результатов - ситуация сложнее

Вместо чего-то вроде

seq { for i in 0 .. 10 do for j in 0 .. 10 do if even i then if odd j then yield (i, j) }

можно использовать list comprehensions:

s1 = [(i, j) | i <- [1 .. 10], j <- [1 .. 10], even i, odd j]

что является краткой записью такой do-нотации:

do
  i <- [1 .. 10]
  j <- [1 .. 10]
  guard (even i)
  guard (odd j)
  return (i, j)

где guard это функция определённая для MonadPlus, то есть как раз для тех монад которые являются также моноидами. Есть ещё mfilter, например:

evens = [1 ..] >>= mfilter even . return

тоже для MonadPlus.

Прочие расширения list comprehensions тоже, наверное, можно в do-нотации выразить.

реальный мир императивен

Реальный мир конкурентный, а изменяемое состояние - просто поток сменяющих друг друга состояний с зависимостью следующих от предыдущих.

Это были примитивные циклы. Надо брать какой-нибудь двухэтажный while с трехэтажным for в перемежку. Особенно while должен быть неудобен. Конструкция отчасти императивна.

Надо брать какой-нибудь двухэтажный while с трехэтажным for в перемежку.

while это скорее для IO или STM, а for - для последовательностей, если вперемешку, то нужен трансформер вроде ListT.

Во, примерно о том и я :)

То есть вместо того, чтобы взять язык, где исполнение всех перечисленных там rules гарантировано компилятором, надо использовать сишку, где исполнение этих правил никто не гарантирует и нам придется верить «зуб даю» разработчика? Прекрасный пример забивания гвоздей пряником, как метко выразились выше.

Ну вы же верите инженеру, построевшему сам самолет/ядерный реактор и т.п. Так какие основания у вас не верить инженеру, который разработал для этой системы софт? Тем более, что там жесткие стандарты и не менее жесткие проверки. Хотя возможно, что Cyclone в подобных проектах применяется. Ибо тут и сишечка, и проверки компилятора...

Ты быдло. Тупое, убогое быдло. Иди и читай снова code guidelines от NASA - там четко объясняют, почему именно Си, и почему все твои аргументы воняют говном.

Там применяются очень зверские системы статического анализа кода. А их проще делать именно для тупого Си.

очень зверские системы статического анализа кода

Может есть смысл в этих словах?