Вышел 2-й выпуск журнала «Практика функционального программирования»

> Результат одной операции идёт на вход другой.

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

> А Дозор-JET? А серверные приложения на Эрланге?

На Эрланге они не потому, что он функциональный, а потому, что он Эрланг. Мощная платформа, заточенная под concurrent programming, востребованная в телекоме, для которой функциональные плюшки - вторичны.

Мы же не кричим, что-де "куча десктопного, системного и серверного софта написана на функциональном языке - Питоне!" Если уж на то пошло, современные практические языки успешно инкорпорируют самое удачное из функциональщины, и такие гибридные мультипарадигменные языки как Scala пользуются успехом действительно в самых разнообразных нишах промышленного программирования.

Удел же "чистой" функциональщины (такой как Haskell) - компьютерная лингвистика, логика, AI. Все. Так выглядит мир без розовых очков.

> Работать надо пока не сделаешь или пока видишь что делать. Бежать надо не "10 кругов" а "в темпе 150 ударов сердца в минуту до выделения нужного кол-ва пота"...

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

> и да, что такое "читать до конца страницы"? :)

(я про браузер и лор), сути дела эти рассуждения не меняют.

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

Т.е. до реальной работы мы так и не дойдем.

> foreach - это всё равно цикл, т.е. "брать по одному и разбивать", а map - это именно "разбить каждое".

> Цикл - это последовательная обработка, а map можно выполнять параллельно.

Это где вам такое сказали? foreach спокойно распараллеливается, если там конечно side -effects нет.

> Да, и как насчёт фильтрации по условию?

[ for x in list if predicate(x) ] прокатит?

> Сейчас очень многие идеи функционального программирования в традиционные языки перекочёвывают.

Т.е. работа со списками и list comprehansion это прерогатива только ФП? :)

> Т.е. работа со списками и list comprehansion это прерогатива только ФП? :)

list comprehansion было создано в рамках ФП, а то, что императивные языки заимствуют функциональные идеи тридцатилетней давности, то совсем другой вопрос.

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

А где мы при жарке яиц "вычисляем", если не секрет? А как же сайд-эффекты, после того, как ты разбил яйцо - его уже не вернуть, и нельзя несколько раз разбить одно и тоже яйцо. Или это неважно?

> Тебе не кажется, что с твоим определением императивности что-то не так?

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

> list comprehansion было создано в рамках ФП, а то, что императивные языки заимствуют функциональные идеи тридцатилетней давности, то совсем другой вопрос.

И какая разница, что там было создано в рамках ФП? Почему бы хорошую идею и не использовать? Почему бы не использовать в императивном языке pattern matching, например, ведь язык как был, так и останется императивным.

> anonymous (*) (29.09.2009 16:21:07)

А ну марш к доске - переменка давно закончилась!

> А противоречие то в чём?

Functional programming подразумевает отсутствие side-effect и состояний, заворачивая их в монады.

> А где мы при жарке яиц "вычисляем", если не секрет?

Эспешиал фор ю:

прежде чем вызвать функцию sin нужно вызвать функию exp, а перед этим необходимо вызвать фукцию log. Доволен?

> А как же сайд-эффекты, после того, как ты разбил яйцо

Слушай, может ты что-нибудь уже почитаешь по ФП? Бо воюешь ты с монстрами, существующими исключительно в твоей голове.

> Какбэ - программа задана в виде четкой последовательности

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

> А где мы при жарке яиц "вычисляем", если не секрет? А как же сайд-эффекты, после того, как ты разбил яйцо - его уже не вернуть, и нельзя несколько раз разбить одно и тоже яйцо. Или это неважно?

Пример про приготовление пищи я привёл в ответ на утверждение, что человек мыслит императивно. Про сайд-эффекты отдельный разговор.

> Почему бы хорошую идею и не использовать?

Используй конечно. Только факта, что императивные языки на десятилетия отстают в развитии это не отменяет.

> http://happstack.com/ - фреймворк для веб-программирования. там у них есть ссылки на проекты, которые его используют

Забавно, там хвастают, что не используют RDBMS. Но все равно посмотрю.

> Functional programming подразумевает отсутствие side-effect и состояний, заворачивая их в монады.

Что за бред? Как можно завернуть отсутствующее? :-D

В Хаскелле есть и то и другое. Да, там используются монады. Что не так?

>>Результат одной операции идёт на вход другой.

monad :)

>> Цикл - это последовательная обработка, а map можно выполнять параллельно.

> Это где вам такое сказали? foreach спокойно распараллеливается, если там конечно side -effects нет.

Умничка. :) Скоро сам поймёшь, почему выгодно иметь четкое разделение на код с сайд-эффектами и без.

> [ for x in list if predicate(x) ] прокатит?

Да, ФП прокатит. :)

>> Сейчас очень многие идеи функционального программирования в традиционные языки перекочёвывают.

> Т.е. работа со списками и list comprehansion это прерогатива только ФП? :)

Нет. Прочти ещё раз, на что отвечаешь.

> Что за бред? Как можно завернуть отсутствующее? :-D

haskell - pure functional, там нет side-effects, нет и все. Чтобы хоть как-то общаться с реальным миром - придумали монады.

> Умничка. :) Скоро сам поймёшь, почему выгодно иметь четкое разделение на код с сайд-эффектами и без.

Давно уже понял.

> Используй конечно. Только факта, что императивные языки на десятилетия отстают в развитии это не отменяет.

Мм, это же какие, интересно?

сколько лет назад и где впервые появилось хотя бы то же list comprehansion ?

> сколько лет назад и где впервые появилось хотя бы то же list comprehansion ?

википедия говорит, что в миранде, потом в хаскелле, common lisp'e а потом через пару лет в питоне. Или питон и cl - не императивныe? :)

> прежде чем вызвать функцию sin нужно вызвать функию exp, а перед этим необходимо вызвать фукцию log. Доволен?

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

> Слушай, может ты что-нибудь уже почитаешь по ФП? Бо воюешь ты с монстрами, существующими исключительно в твоей голове.

Я немного почитал, иногда оно полезно.

> любой функциональный язык с аппликативным порядком вычисления аргументов функции задан в виде чёткой последовательности вызовов функций. Читайте маны, они рулят.

вырезал самое основное, молодец :)

> Пример про приготовление пищи я привёл в ответ на утверждение, что человек мыслит императивно. Про сайд-эффекты отдельный разговор.

см мой предыдущий ответ угодаю.

>да и продакшен вряд ли пострадает от этого.

Не - вот этот ужос: https://lampsvn.epfl.ch/trac/scala/ticket/2392

>Кстати, ты в Киеве на тусовку LtU не собираешься?

Ага-так. Если выздоровлю до того времени - наверное схожу.

> https://lampsvn.epfl.ch/trac/scala/ticket/2392

E.P.I.C. F.A.I.L.

>Есть какие-нибудь Ъ-ФП либы для GUI?

Есть fudgets но я его не одобряю за >+< и прочее >==<-подобное.

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

Нет. Это "что это есть", а не "как это вычислить". Уж не говоря о том что когда вступит call-by-name это может и никогда не будет вычислено.

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

просто имей в виду, что вселенных более чем одна.

> просто имей в виду, что вселенных более чем одна.

у фанбоев хаскелла своя вселенная с блекджеком и шлюхами?

[ for x in list if predicate(x) ] прокатит?

И при чем тут функциональное программирование - да?

Т.е. работа со списками и list comprehansion это прерогатива только ФП? :)

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

Например в том же log4j конструкция:

log.debug( some.complex() * expression )

обладает очевидным недостатком - даже если этот уровень отладки не включен, параметр все время будет вычислятся. И очевидно же что подход, который принят при вычислении if здесь тоже был бы полезен. И очевидно что в любом языке поддерживающием call-by-name этой проблемы нет. Из этого с очевидностью следует что call-by-name - нужен.

Что меня всегда удивляло - так это то что народ даже не вытается проводить обобщения когда делает какие-то штуки.

Например одно из возможных «усовершенствований» жабы - это итерация по Map. Выглядит она приблизительно так:

for(String k,String v : map) ....

То есть они вполне готовы создавать конструкт языка сходу - надо по мапе - сделаем модификацию компилятора.

А если мне понадобиться итерироваться по чему-либо где 3 значения? Нет бы чуть задуматься и обобщить что итерация по мапе, ровно как и итерация по линейному списку - это частные случаи итерации по последовательности возвращающей таплы, реализовать один раз универсально и не долбать мозги. Пример на скале:

scala> val l = (1,"a", 'a) :: (2, "b", 'b) :: (3, "c", 'c) :: Nil
l: List[(Int, java.lang.String, Symbol)] = List((1,a,'a), (2,b,'b), (3,c,'c))

scala> for ( (i,c,s) <- l) println(i + "-" + c + "-" + s)
1-a-'a
2-b-'b
3-c-'c

Так нет - они будут фигачить частные случаи в язык.

тётки-бухгалтершы "программирующие" на экселе переплюнут числом всех жабо-цпп-пыхпых кодеров вместе взятых.

>E.P.I.C. F.A.I.L.

Да ладно - ну намутили в компиляторе бреда немножко с генерацией кода исключений:) Ошибка ж чисто техническая - поправят - дальше поедем.

> haskell - pure functional, там нет side-effects, нет и все.

Есть. С помощью монады IO.

> Чтобы хоть как-то общаться с реальным миром - придумали монады.

Придумали их не для этого. Просто они хорошо подошли. И есть ещё много других монад, кроме IO.

Ты так говоришь, как будто монады - это нечто чужеродное в Хаскелле.

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

Гы. Тебе надо в армию, тебе понравится. Думать не надо, исполняй себе алгоритмы. :)

> Не - вот этот ужос: https://lampsvn.epfl.ch/trac/scala/ticket/2392

Ого. Интересно, если try-finally без catch?

>Гы. Тебе надо в армию, тебе понравится. Думать не надо, исполняй себе алгоритмы. :)

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

А если он очевиджно знает что хочет получить, и шаги состоят в том чтобы получить это когда нужно и делает это когда понадобиться "для приготовления амлета надо взбить яйца, для взбития яиц нужн взять их из холодильника" - то это классическое развертывания декларативного дерева с call-by-name. И даже яйца приготовленные зараннее вписываются сюда в качестве немутабельных структур данных, а сам амлет выглядит как функция от ингридиентов - то есть вполне вписывается в идиому черного ящика.

Ого. Интересно, если try-finally без catch?

Тоже плохо:

scala> try { println("try") } finally {println("finally"); error("error")}
try
finally
finally
java.lang.RuntimeException: error

>Тем более он рассказывает сказки. Если бы ему было удобно думать императивно - это значит что он бы выполнял рецепт посрочно не задумывась что нужно для чего и когда.

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

> тётки-бухгалтершы "программирующие" на экселе переплюнут числом всех жабо-цпп-пыхпых кодеров вместе взятых.

Кстати да, это к вопросу о нераспространённости и изотеричности ФП. :)

> Это была бы конкретная шизофрения если бы люди так мыслили - то есть выполняли действия ради резульата, который неизвестно ли понадобиться и не зная для чего он нужен вообще до момента когда понадобиться.

А что по-твоему такое инстинкты?

> Тем более он рассказывает сказки. Если бы ему было удобно думать императивно - это значит что он бы выполнял рецепт посрочно не задумывась что нужно для чего и когда.

Это ты уже придумал сам. Императивность не означает бездумность. Как вообще связано создание алгоритма, целеполагание человека и представление этого алгоритма в голове?

> А если он очевиджно знает что хочет получить, и шаги состоят в том чтобы получить это когда нужно и делает это когда понадобиться "для приготовления амлета надо взбить яйца, для взбития яиц нужн взять их из холодильника" - то это классическое развертывания декларативного дерева с call-by-name.

Создание алгоритма и его реализация - разные вещи. Как вообще это можно смешивать?

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

Как это яйца иммутабельны? они ой как мутабельны.

>А что по-твоему такое инстинкты?

Классический черный ящик. Реакция на входной сигнал. Просто без участия сознания. При императивном подходе ты бы сначала что-то сделал а потом воспринял причину действий. То есть инстинкт функционален - руку от огня отдергиваешь по причине наличия входных данных - больно. Императивно - это значит ты бы приготовился отдернуть руку без наличия причины, а потом когда появился огонь - отдернул бы ее. А вдруг бы огонь не появился?

Инстинкты - функциональны. При чем чисто функциональны.

> Гы. Тебе надо в армию, тебе понравится. Думать не надо, исполняй себе алгоритмы. :)

Да, алгоритм, записанный в функциональном стиле станет совсем другим. Что еще придумаете? Программа, она и в Африке программа.

> Ты так говоришь, как будто монады - это нечто чужеродное в Хаскелле.

Нет, это костыль для обертки побочных эффектов.

> > Это была бы конкретная шизофрения если бы люди так мыслили - то есть выполняли действия ради резульата, который неизвестно ли понадобиться и не зная для чего он нужен вообще до момента когда понадобиться.

> А что по-твоему такое инстинкты?

вот мы и узнали как мыслят "императивные программисты" :)

кроме того инстинкт это скорее событие наступающее при условиях. А у мыслящих существ еще и лениво выполняющееся кстате.

> Да, алгоритм, записанный в функциональном стиле станет совсем другим. Что еще придумаете? Программа, она и в Африке программа.

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

On Tue, 29 Sep 2009, Antonio Paredes wrote:
> > Can somebody give a hint on how to speed-up the following loop:
> >
> >
> > for(j in 0:KM1)
> > {
> > k=j*60
> > for(i in 1:60)
> > {
> > dat$yvac[k+i]= rbinom(1,dat$nvac[k+i],dat$p.trt[j+i])
> > }
> > }
> >
> > K1=999

How about:

rbinom((KM1 + 1)*60, dat$nvac, dat$p.trt[rep(0:KM1, each=60) + 1:60])

HTH
Ray Brownrigg

> И при чем тут функциональное программирование - да?

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

>Императивность не означает бездумность

Императивность обозначает описание фокус на том _как_ нужно достич цели а не фокус на том _что_ такое цель по определению.

>Создание алгоритма и его реализация - разные вещи. Как вообще это можно смешивать?

При чем тут создание? Алгоритм можно описать двумя способами: в качестве последовательности шагов и в качестве определения того что есть результат.

Посмотри вот сюда:
http://ru.wikipedia.org/wiki/%D0%9A%D0%B2%D0%B0%D0%B4%D1%80%D0%B0%D1%82%D0%BD...

Формулы - это финкциональное описание. Мнемоника - это императивное.

>Как это яйца иммутабельны? они ой как мутабельны.

В каком месте?

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

функция как аргумент функции и функция как результат функции как минимум, и все это рекурсивно :). Подозреваю что это почти возможно :)

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

У бульдозера есть гусеницы - значит бульдозер - это танк? В корень смотреть надо а не на внешние проявления.