LINUX.ORG.RU

Потрогать палочкой функциональщину

 


1

4

Привет всем. На фоне последних тем про всякие там лиспы и хаскелли возникло желание тоже стать «крутым» (ибо знание линукса уже крутостью не является) и поглядеть какой-нибудь из них.

А если серьезно, то хочется какой-нибудь функциональный язык, но не древний как экскременты мамонта и такой, чтобы хоть с вероятностью 0.0001 я мог бы применить в разработке. Что посоветуете? F#? Haskell? Scheme? Lisp?

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

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

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

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

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

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

наглое 4.2

ymn ★★★★★ ()

groovy

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

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

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

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

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

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

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

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

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

ок, поищу сам

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

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

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

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

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

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

А вот с моноидами 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-нотации выразить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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