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

> Ну не является это исключительными признаками функциональных языков.

Вы не ответили про функции высших порядков.

> Если они абсолютно одинаковы (и перемешаны, чтобы исключить координаты из рассмотрения), то не смогу. А вы сможете?

Конечно, нет, но я не уверен, что на одной и той же кровати может спать 200 человек одновременно, ничего друг о друге не зная.

> Вы не ответили про функции высших порядков.

Да, они тоже не являются.

занятость (населённость?) кровати --- это тоже свойство.

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

> Вы не ответили про функции высших порядков.

def firstorderfunc(): return 'a'

def secondorderfunc(f): print 'MIGHTY SIDE EFFECT!!1' return f(2)

def anothersecondorderfunc(): print 'ANOTHER MIGHTY SIDE EFFECT!!1' def retfunc(): return 2 return retfunc

pure-ФП или не pure-ФП? Наличие функций высших порядков не гарантирует отсутствие побочных эффектов. Тоже самое можно сделать для мутабельности-немутабельности. Поэтому функции высших порядков не есть атрибут только лишь ФП-языков/программ.

> Наличие функций высших порядков не гарантирует отсутствие побочных эффектов

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

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

В свою пользую могу сказать, что lisp долгое время (да и сейчас ещё) считался флагманов ФП именно из-за наличия hof, а на его побочные возможности всем было плевать.

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

Вы сейчас имеете в виду, конечно же, чистые функции? Иначе под ваше определение функционального языка попадает, например, питон и c++.

я не зря написал два раза слово легко и один раз --- изящно. С++ не подпадает. На питоне я ничего (кроме пары учебных задачек) не писал, поэтому здесь промолчу.

> легко > изящно

это субъеквтиные вещи, как ни крути. люди очень разные (к вопросу о мышлении), кому-то одно легко и одно изящно, кому-то другое. по таким параметрам нельзя строить классификацию, потому что функция класисфикации в таком случае не чистая ;)

>> Я хочу, чтобы они перешли в состояние "разбиты" :)

> Это вообще-то очень странное желание.

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

Но даже независимо от ответа насчет лампочки - что "очень странного" в том, что я хочу объект с изменяемым состоянием? Ты считаешь, что в RW таких объектов нет, или их надо моделировать набором иммутабельных объектов? Или что?

Так-то оно так, но на практике языки заставляют писать в определённом стиле. *) Вот одни языки порождают желания написать функции для list comprehension, а другие --- обход массива в цикле по индексу.

_______________________________________________________________________________ ________

* Например, чуть больше чем все программы на Perl написаны в стиле: кошка заснула на клавиатуре. Вот фиг его знает отчего так бывает, но факт налицо. Хотя, в принципе, можно на перле и нормальные понятные программы писать.

> Но даже независимо от ответа насчет лампочки - что "очень странного" в том, что я хочу объект с изменяемым состоянием?

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

> Так-то оно так, но на практике языки заставляют писать в определённом стиле. *) Вот одни языки порождают желания написать функции для list comprehension, а другие --- обход массива в цикле по индексу.

> * Например, чуть больше чем все программы на Perl написаны в стиле: кошка заснула на клавиатуре. Вот фиг его знает отчего так бывает, но факт налицо. Хотя, в принципе, можно на перле и нормальные понятные программы писать.

Какое это отношение имеет к легкости и изящности?

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

Ответ не мальчика, но фанбоя.

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

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

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

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

Еще раз повторюсь, легкость и изящество это очень субъективные оценки. Во-первых, а во-вторых, гуру ц++, подозреваю, вполне могли бы вас опровергнуть, если бы им было дело до вас :)

> занятость (населённость?) кровати --- это тоже свойство.

Не знаю, но в хаскале может быть и такая уличная магия

Тип кровать - логический, говорит, занята она (True) или нет (False).

layOnKrovat - лечь на кровать, если она занята ошибка, если нет - занимаем ее.

[code] data Krovat = Krovat Bool deriving (Show)

layOnKrovat krovat@(Krovat False) = Krovat True layOnKrovat krovat@(Krovat True) = error "It is already busy" [/code]

А теперь сам фокус [code] *Main> let k = Krovat True *Main> let k2 = layOnKrovat k *Main> k Krovat True *Main> k2 Krovat False *Main> [/code] Опа, у нас две кровати, одна занятая, другая - нет. Круто, у нас из ниоткуда появилась кровать.

ЗЫ. Я знаю в чем тут ошибка.

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

Да и потом, ваша чистая функция может оперировать с БД, в которую пишут толпы людей? Ну, например, интересует чистая реализация поиска документов, имеющих внутри фразу Q.

Сегодня её выхлоп будет A, а завтра A+B. Где тут чистота?

Не знаю, но в хаскале может быть и такая уличная магия

Тип кровать - логический, говорит, занята она (True) или нет (False).

layOnKrovat - лечь на кровать, если она занята ошибка, если нет - занимаем ее.

 
data Krovat = Krovat Bool deriving (Show)

layOnKrovat krovat@(Krovat False) = Krovat True 
layOnKrovat krovat@(Krovat True) = error "It is already busy" 

А теперь сам фокус

 
*Main> let k = Krovat True 
*Main> let k2 = layOnKrovat k 
*Main> k 
Krovat True 
*Main> k2 
Krovat False 
*Main> 

ЗЫ. Я знаю в чем тут ошибка.

> Например, чуть больше чем все программы на Perl написаны в стиле: кошка заснула на клавиатуре. Вот фиг его знает отчего так бывает, но факт налицо. Хотя, в принципе, можно на перле и нормальные понятные программы писать.

Это точно :) Язык просто провоцирует. Даже те, кто может писать чисто и осознает необходимость в этом, порой срывается и выдаёт отменную какашку с оправданием: "Этот код конечно далёк от modern perl, но у меня не было времени, может позже перепишу." Поэтому в нашей конторе запретили Перл вообще, от греха подальше. Выбор языка чертовски важен. Даже если язык имеет все необходимые фичи, нужно ещё сто раз подумать, перед тем как его заюзать. Заливаюсь горючими слезами, когда приходится разбирать код на жабе. И даже не от индусов, а вроде бы от вменяемых инженеров. Я раньше думал, что "жаба головного мозга" - это шутка. Ан нет...

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

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

> Например, в том же руби, питоне, пхп HOF есть, пользоваться ими легко

В пыхе они есть весьма эфемерно :)

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

Потому что это единственное, что фп от ип отличает.

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

Или он собирается провести допрос третьей степени устрашения... метафоры такие метафоры.

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

Потому что мутабельность - это свойство объектов RW, и мне интересно, почему ее отражение в программах (ФП или ИП) кажется тебе "очень странным". Ну или если ты не считаешь, что объекты RW мутабельны - тоже скажи.

> Или то, что я хочу объект "лампочка" с состояниями "включена", "выключена", "перегорела", тебе тоже кажется "очень странным"?

Включенная, выключенная и перегоревшая лампочки - это разные объекты. Точнее - это объекты разных типов. У них свойства весьма разнятся, и набор возможных операций над ними разный. То, что в ООП такой объект скорей всего будет смоделирован в рамках одного типа - не есть хорошо. Те же замечания относительно корректности, что r приводил по поводу яичницы, здесь тоже уместны. Спор о том, что ближе к реальности: изменение состояния, или порождение нового объекта, скорее философский. Ну может физикам еще есть что сказать на этот счет. В контексте программирования намного важнее, какой подход проще для написания корректных программ. ИМХО, проще функциональный. Хотя и требует некого сдвига в мышлении.

> Да и потом, ваша чистая функция может оперировать с БД, в которую пишут толпы людей?

Да

> Сегодня её выхлоп будет A, а завтра A+B. Где тут чистота?

Если вам это вправду интересно, обратитесь к документации. Честное слово, оно того стоит. Займёт всего несколько вечеров (для начального ознакомления). Зато вы получите в своё распоряжение целый новый мир и коньки впридачу.

> Включенная, выключенная и перегоревшая лампочки - это разные объекты.

Ты хотел сказать "в программе этот объект RW представляется тремя объектами"?

> Точнее - это объекты разных типов.

Ты хотел сказать "это три объекта, каждый из которых вдобавок принадлежит к отдельному типу"?

> и набор возможных операций над ними разный.

Но имеет и что-то общее (опреция "разбить_об_стену" :)).

> Спор о том, что ближе к реальности: изменение состояния, или порождение нового объекта, скорее философский.

Здесь вопрос настолько ясен, что не о чем спорить :) Нужно считать, как выгоднее моделировать RW - при помощи "Modeling the world in states" (c) или <какой там слоган у ФП>.

> во-вторых, гуру ц++, подозреваю, вполне могли бы вас опровергнуть,

Зато гуру теории категорий гур ц++ положат но обе лопатки. :-)

> Если вам это вправду интересно, обратитесь к документации. Честное слово, оно того стоит. Займёт всего несколько вечеров (для начального ознакомления). Зато вы получите в своё распоряжение целый новый мир и коньки впридачу.

То есть вы пример привести не можете? Это совершенно вписывается в образ ФП-фанбоя. Здесь действительно понимает о чем говорит только r. У вас же абстрактные перефразировки набивших оскомину изречений известных людей. Только вот известные люди обычно знают о чем говорят, в отличие от вас. Ни одного примера от вас не получено. Очевидно, потому что вы не можете их привести. Разубедите же меня.

> Или он собирается провести допрос третьей степени устрашения

может быть, главное, молоток в себе, ему и тогда не нужен. Только результат его работы.

> Ну или если ты не считаешь, что объекты RW мутабельны - тоже скажи.

Фактов нет. Есть только их интерпретации. Мы можем считать яблоко и огрызок одним объектом в разных состояниях. А можем двумя разными объектами. Оба эти подхода равноправны. Но подход с изменямыми состояниями может превратить отладку и поддержку кода в лютый, расовый ад, а потому его следует избегать.

> То, что в ООП такой объект скорей всего будет смоделирован в рамках одного типа - не есть хорошо.

Да не обязательно он будет смоделирован в рамках одного типа - это зависит от задачи, и вообще не во всех ИЯП классы и типы одно и то же.

> Ты хотел сказать "это три объекта, каждый из которых вдобавок принадлежит к отдельному типу"

В общем да. При каждом переходе порождается новый объект. А что вас смущает? То, что при этом старые объекты не исчезают? Можно считать, что они остаются в прошлом.

>> и набор возможных операций над ними разный.

> Но имеет и что-то общее (опреция "разбить_об_стену" :)).

Безусловно, множества операций пересекаются. Однако ж операция "выкрутить" нежелательна для горящей ламочки. Не находите?

>> Спор о том, что ближе к реальности: изменение состояния, или порождение нового объекта, скорее философский.

> Здесь вопрос настолько ясен, что не о чем спорить

Ой ли? Тут сразу в голову лезут дурные вопросы вроде "что такое время", "можно ли что то изменить в прошлом и как это скажется на настоящем?" и прочая бурда. Спорить об этом я действительно не готов.

> То есть вы пример привести не можете?

пример чего? Функциональной программы, взаимодействующей с внешним миром?

вот вам http://hackage.haskell.org/packages/archive/pkg-list.html там вы найдёте и базы данных, и оконные интерфейсы, и вообще кучу всего.

Кстати, если вы вдруг не заметили, наверху написана новость про журнал "Практика функционального программирования". Там тоже много разных примеров функционального кода. Не ленитесь и будет вам счастье.

> Это совершенно вписывается в образ ФП-фанбоя.

А в какой образ складывается агрессивное неприятие новых знаний?

>Думаю полностью код приготовления яичницы (омлета) приводить не стоит?

Это было бы весьма интересно. Думаю ты обнаружил бы много интересностей о которых я говорил. А потом проанализировав ощущения ты бы понял (даже на примере этого яйца) - что делал что-то типа 10 правила гринспуна - только применительно к нашей ситуации.

PS:

>>> e = Egg()
>>> e.state = "broken"
>>> e._states.insert(0,"raw")
>>> e.state
'raw'

Хочу нобелевскую премию.

> Я знаю в чем тут ошибка.

Древняя мудрость гласит: программист на фортране способен написать на любом языке на фортране.

> А в какой образ складывается агрессивное неприятие новых знаний?

Где здесь агрессивное неприятие новых знаний? Я и журнал скачал и ФП давно интересуюсь. Меня огорчает вот такой подход к ответу на вопросы интересующихся. В чем профит не объясняют, но обильно выступают против императивного подхода.

> пример чего? Функциональной программы, взаимодействующей с внешним миром?

Пример того, как чистая функция будет работать с БД. Можно, например, на окамле, я пойму.

>> Ты хотел сказать "это три объекта, каждый из которых вдобавок принадлежит к отдельному типу"

> В общем да. При каждом переходе порождается новый объект. А что вас смущает?

Я просто выяснял, правильно ли понял.

> То, что при этом старые объекты не исчезают? Можно считать, что они остаются в прошлом.

Но в программе они остаются доступны ровно так же - подозреваю источник багов.

> Однако ж операция "выкрутить" нежелательна для горящей ламочки. Не находите?

Это операция с побочным эффектом "волдыри" :)

>>> Спор о том, что ближе к реальности: изменение состояния, или порождение нового объекта, скорее философский.

>> Здесь вопрос настолько ясен, что не о чем спорить

> Ой ли? Тут сразу в голову лезут дурные вопросы вроде "что такое время"

Я инженер, а это вопрос ученого :) Более того, это вопрос философа или узкоспециализированного физика.

Да блин, потому что это числа, у них нет никакого состояния, я это уже не раз повторял.

Серьезно?

>>> class N:
...     def __init__(self, n):
...         self.n = n
...     def prev(self):
...         self.n -=1
...     def succ(self):
...         self.n +=1
...
>>> n = N(5)
>>> n.succ()
>>> n.n
6
>>> n.prev()
>>> n.prev()
>>> n.n
4

ОМГ числа с состоянием! Куда катится мир!

Я не беспокоюсь, но x там каждую итерацию мутирует :)

Откуда ты знаешь?

Это иллюзия, скажите спасибо гипножабе.

Серьезно? Тебе дописать в питоне миетод который напакостит в реальность (помимо того способа что я указал)? Еще открой для себя в других языках концепцию open classes.

> Ну, например, интересует чистая реализация поиска документов, имеющих внутри фразу Q.

> Сегодня её выхлоп будет A, а завтра A+B. Где тут чистота?

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

> Это было бы весьма интересно. Думаю ты обнаружил бы много интересностей о которых я говорил.

Каких - о том, что нельзя произвольно менять код функции и она бы при этом оставалась рабочей?

> А потом проанализировав ощущения ты бы понял (даже на примере этого яйца) - что делал что-то типа 10 правила гринспуна - только применительно к нашей ситуации.

> Хочу нобелевскую премию.

За то, что поднакопил денег, сходил в оружейный магазин, купил пистолет и выстрелил в голову? Ну ничего можно сделать более железобетонно через __setattr__, но тогда конечно же останется лазейка self.__dict__[name], ведь тебя ничего не удержит от самоубийства? :)

Кстати, что там с unfry, или "так нельзя" менять функции? :)

> не является для человека естественным монадное мышление.

А что указатели, исключения, полиморфизм - являются?

Вот в Киеве на LtU выступал человек, который говорил, что у него есть опыт веб-разработки на Хаскелле около года, а на императивных языках - не вообще - он на них написал меньше 1000 строк. Код на Хаскеле для него прост и понятен: он даже назвал его "псевдокодом". И в том числе он утверждает, что монады и монадные трансформеры вполне просты и понятны.

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

>Почему ты считаешь, что не нарушаешь здесь алгоритм?

Я вмешался в работу библиотек с омлетом? Менял ее код? Дописывал новые функции? Нет - я воспользовался предоставляемой библиотекой возможностью. Потоков данных не нарушал. Я - злобный сайд эффект.


>И кстати, в варианте, который я запостил раньше - такая штука не пройдет.

Де моя нобелевская премия?

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

Обычно в документации и из исходников вполне уверенно можно сделать об этом выводы - особенно если читать глубоко и долго. И нахрена эту долбаную инкапсуляцию придумали, проверки входных параметров, всякую статическую типизацию? Это ж все никому не надо - надо просто написать в документации - вот сюда можно присваивать только то-то и то-то а после вызова этого метода - только эти три. И все ошибок не будет - в документации же описано! Ты зачем в своем питоновском коде эту бодягу со списком стейтов придумывал? Надо было вот так:

"""
Eto klass jajtso - state mojno privsvaivat' tolko posledovatelno
"raw" -> "broken" -> "fried"
"""
class Egg:
def __init__(self, state):
self.state = state


Коротко ясно. А в документации все описано - какие могут быть ошибки?


>Да, надо, только проверка входных данных нужна в любом случае

Где ты в моем посте увидел слово "входные данные"?

>Ты наелся жабы, теперь думаешь, что везде так.

Я тебе открою наверное новость - везде так.

> Серьезно?

Разницу между объектом в смысле оо программирования и числом в математике улавливаешь? Ты просто создал класс объектов, состояние которых описывается одним числом, ну и добавил парочку методов. Кстати, какое состояние у числа 42, кстати, что вообще такое состояние числа? :)

> Серьезно? Тебе дописать в питоне миетод который напакостит в реальность (помимо того способа что я указал)? Еще открой для себя в других языках концепцию open classes.

Да не надо, там же можно в динамике переопределить класс объекта, его методы, поля, даже immutable tuple можно поменять.

>Ну не является это исключительными признаками функциональных языков.

Не надо подменять понятия. Ты еще начни намекать что тут разборка идет хаскел vs питон/жаба. Нет - не идет. Разборка идет в двух разрезах - парадигматическая функциональщина vs парадигматическая императивщина, и способ мышлени человека.

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

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

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

>Никто не против хорошего высокоуровнего императивного языка :)

Только это уже не императивная модель. ЧИТД. Основное направление развития языков сейчас - уход от императивной модели.

>Вы сейчас имеете в виду, конечно же, чистые функции? Иначе под ваше определение функционального языка попадает, например, питон и c++.


Так надо убить это в зародыше. Мы говорим не о "функциональных" и "императивных" языках - это в конце концов обобщения по наличию некоторых свойств которые принято относить к той или иной сфере - а о подходах. Окамл принято считать функциональны = но не что не мешает мне там налабать императивную программу. С принято считать императивным - хотя ничто не мешает там налабать функциональную. Это ничего не дает - не надо сводить все к python vs haskell.

Дело в подходах императивном и функциональном.

> И нахрена эту долбаную инкапсуляцию придумали, проверки входных параметров, всякую статическую типизацию? Это ж все никому не надо - надо просто написать в документации - вот сюда можно присваивать только то-то и то-то а после вызова этого метода - только эти три. И все ошибок не будет - в документации же описано!

Примерно так и говорят пропагандисты динамических языков :)

>Ответ не мальчика, но фанбоя.

Ну ну. Моделирование реальности в программах вообще-то никакого смысла не имеет (спроси любого грамотного ООПшника). В программах нужна удобная модель для программирования задачи. Вопрос весьма корректен -какую выгоду ты рассчитываешь получить из состояния лампочки? Что стоит за решением сделать ее объектом с состоянием, а не ADT?

> Так ведь у вас входные данные разные

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