LINUX.ORG.RU

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

 , , ,


1

0

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

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

Первые четыре статьи — Дмитрия Зуйкова, Дмитрия Астапова, Сергея Зефирова в соавторстве с Владиславом Балиным, и Алексея Отта — вытаскивают на поверхность «кухню» нескольких компаний. Статьи демонстрируют, что функциональные языки находят применение в промышленном программировании в самых разных нишах. Конечно, использование «нестандартных» языков накладывает на проекты некоторые сложно оценимые риски, и далеко не все из них рассмотрены в статьях. Но если статьи этого номера позволят развеять хоть часть сомнений, мифов и предрассудков и поднять дискуссию о применимости функциональных языков в промышленном программировании на новый уровень, мы будем считать свою задачу выполненной.

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

Завершающая статья Романа Душкина в большей степени ориентирована на теорию: она познакомит вас с концепцией алгебраических типов данных (АТД) в Haskell и других функциональных языках.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

monad :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тоже плохо:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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