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

> Его значение. Мало? Могу дофига придумать - история его изменени и всяка ятакая фигня. Сначала у меня было X денег. Потом стало Y. Я купил на это товары A,B,C по такой-то стоимости и подал ничему. Что - сложно представить как это все инкамсулируется в 1 объект?

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

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

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

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

Ты функциональное программирование почему-то пытаешься противопоставить boilerplate код - что-то вроде ассемблера, где каждый может все изменить, а не реально императивное программирование. Я за модульность, сокрытие реализации и прочие прелести - функциональность сильно способствует модульности (каждая чистая функция оказывается отрезанной от внешнего мира и не может на него повлиять, и он на нее не может), я в этом отношении с фп, но эту же модульность можно достигнуть не только с помощью иммутабельных данных и чистых функций. Те же лексические замыкание невозможны без присваивания, они как раз позволяют создать "железобетонное" сокрытие реализации и еще один уровень абстракции поведения. Функция rand не является чистой функцией, - а я себе с трудом представляю практическое программирование без нее. С другой стороны всем известны проблемы со скрытым изменением состояния. Для параллельного программирования выгода от иммутабельных данных однозначна, однако есть же STM, которая проблему для мутабельных данных решает. Чистота должна быть там, где она уместна, также как и использование императивности должно быть уместно.

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

Подход тут простой - какая используется модель вычислений. Все. Нет никаких некоторых свойств (я так подозреваю имеются ввиду всякие hof immutable data, lazy evaluation, pattern matching). И именно в этом ключе я пытаюсь спорить. Я уже не раз давал определение того, что я считаю ( и не только я) императивным, и что считаю функциональным.

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

> Это ничего не дает - не надо сводить все к python vs haskell.

Да никто к этому и не сводит, была бы моя воля я бы свел к Ocaml vs Haskell. Ибо на мой взгляд ocaml - чуть ли не лучший императивный язык, хотя все его считают функциональным (type inference, strict evaluation, optional (im)mutability, oop, pattern matching и прочее).

> Объекты RW такие какими на данный момент времени удобно рассматривать их - человек на лету делает теоретическую модель. Я приготовил рагу - что это? Это картофель и морковка в стейте бойлед? Или рагу? Я кладу его на тарелку - что это? OMГ - рагу размножается - часть в кастрюле часть в тарелке.

Зависит от того, что тебе важно и какая модель тебе лучше подходит, все просто.

> Код на Хаскелле читается, как рассказ.

потому что там есть ADT и pattern matching, а питон динамический и в нем даже repaet until нет, не говоря уже о том, что циклы там приходится писать с помощью for x in xrange(10).

> Ну и замечение по реализации: а если будут ещё и варёные яйца?

Как смоделируешь, так и будет.

> e - это _одно и тоже_ яйцо?

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

> Может и x=2 нужно передавать клонируя число - а то как же это ты одно и тоже число передал в 2 формулы - этож ужос - числа размножаются...

Вот в этом-то все и дело, объекты обладают поведением (состоянием), а числа - нет.

> Только это уже не императивная модель.

Для тебя императивная модель - это отсутсвие функций и модульности вообще, я так понимаю.

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

Уход от низкоуровневого программирования к высокоуровневому.

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

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

> А что указатели

нет.

> исключения,

да.

> полиморфизм - являются?

да.

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

да.

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

Блин, что ты относишь к "парадигматичной императивщине"? No functions, no modules, no encapsulation, no polymorphism? Чистый си без функций, fortran, наконец?

ЗЫ. Мне кажется, мы начинаем ходить по кругу.

Вспоминается анекдот:

В: Мальчику Васе дали 3 яблока. 1 он съел. Сколько яблок у Васи?

О: Неизвестно, т.к. чёрт его знает сколько у Васи было яблок до этого.

Но это не правильный ответ, на самом деле у Васи lambda.x x-2 яблока.

P.S. Почто на лоре подстановка λ не работает?

> Блин, что ты относишь к "парадигматичной императивщине"?

Сойдёмся на том, что в программе, написанной в рамках императивной парадигмы, целью каждого действия является изменение состояния памяти программы?

> Сойдёмся на том, что в программе, написанной в рамках императивной парадигмы, целью каждого действия является изменение состояния памяти программы?

Если принять это определение, мы получим, что императивен _только_ машинный код или ассемблер, где каждая строчка программы обозначает действие и изменение памяти программы. В яп выского уровня - это не так. Конструкция if, декларация типа переменных, определение класса, определение функции ну уж никак нельзя назвать действием, посему их можно спокойно отнести к функциональным/декларативным.

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

> Но это не правильный ответ, на самом деле у Васи lambda.x x-2 яблока.

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

λfx.x -> 0

λfx.f x -> 1

λfx.f (f x) -> 2

λfx.f (f (f x)) -> 3

>> Ну и замечение по реализации: а если будут ещё и варёные яйца?

> Как смоделируешь, так и будет.

Я имел в виду, что "красивое" решение со стеком в общем случае не подходит.

>> исключения,

> да.

Приведи жизненный пример. Только пример, а не аналогию. Речь идёт о *естественных* понятиях, а с помощью аналогий можно и про указатели рассказать.

>> полиморфизм - являются?

> да.

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

>> Сойдёмся на том, что в программе, написанной в рамках императивной парадигмы, целью каждого действия является изменение состояния памяти программы?

> Если принять это определение, мы получим, что императивен _только_ машинный код или ассемблер, где каждая строчка программы обозначает действие и изменение памяти программы. В яп выского уровня - это не так. Конструкция if, декларация типа переменных, определение класса, определение функции ну уж никак нельзя назвать действием, посему их можно спокойно отнести к функциональным/декларативным.

Это подтверждает тезис r о том, что в высокоуровневом языке больше декларативных конструкций, да.

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

Формально - да, но пишущий от этого как правило абстрагируется.

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

> λfx.x -> 0

> λfx.f x -> 1

> λfx.f (f x) -> 2

> λfx.f (f (f x)) -> 3

Числа Чёрча. В Хаскелле всё ок, они не такие. :)

> Числа Чёрча. В Хаскелле всё ок, они не такие. :)

Да, но это ни коем образом не влияет на их полностью абстрактную сущность.

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

В сях - практически вся программа - это описание функций. Он - декларативен?

Вызов функции - это действие?

> Формально - да, но пишущий от этого как правило абстрагируется.

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

> Приведи жизненный пример. Только пример, а не аналогию. Речь идёт о *естественных* понятиях, а с помощью аналогий можно и про указатели рассказать.

Когда я нес яйца из холодильника до сковороды, я их случайно выронил и рабил. Это исключительная ситуация, которую следует обработать.

> Да вроде бы должен быть. Однако, насколько я помню свою группу в институте (специальность была не программистская), многих почему-то это понятие вводило в ступор.

Наверное, потому что рассказывали в контексте ооп, которое тут не сильно причем.

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

О-па! А дай-ка определение понятия "монада".

> О-па! А дай-ка определение понятия "монада".

Это тебе рассказать, про монадные законы и какие вообще бывают монады? А смысл?

Не. Что такое - монада. Сама по себе. С математической точки зрения.

>Число - это совершенно абстрактное понятие,

У тебя сколько денег на счету? Не поделишься абстракцией?

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

По твоему наличие яиц в холодильнике не описательная характеристика?

Вот забавно откуда беруться люди которые делят вещи на реальные и абстрактные. Уход совершенно абстрактных чисел с твоего счета совершенно реально оставит тебя без яичницы и кровати.

>Ты из тех людей, что в микроволновке сушат котов?

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

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

Любой инструмент которым можно воспользоваться неправильно - будет использован неправильно. Дальше все сводится к удобству инструмента.

>а не реально императивное программирование.

Реально императивное программирование обладает реально императивными свойствами - ключевое из которых - мутация состояния. Если исключить это ключевое ствойство - это уже _не_ императивный подход. В который раз - не надо путать "императивный" язык и императивный подход. Ту же яишницу можно написать на С так что там не будет ничего императивного,

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

Где я такое говорил? ООП вообще _никакого_ отношения к императивщие не имеет.

>Зависит от того, что тебе важно и какая модель тебе лучше подходит, все просто.

ТАк во имя каких богов вы сделали яйца объектами с состоянием?!?!

>Вот в этом-то все и дело, объекты обладают поведением (состоянием), а числа - нет.

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

>Для тебя императивная модель - это отсутсвие функций и модульности вообще, я так понимаю.

Для метя императивная модель - это вычисление путем мутации состояния.

>Уход от низкоуровневого программирования к высокоуровневому.

Высокоуровневое и низкоуровневое - бузвордны с нулевым конкретным смысловым значением. Как "хороший" и "плохой".

>что естественно не влияет на качество самой программы

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

>Блин, что ты относишь к "парадигматичной императивщине"?

То что входит в ее определение и соответствует этой модели вычислейний.

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

Тадааааа!

>В яп выского уровня - это не так.

Потому что они развиваются _уходя от_ императивной модели. Тадаа! Говорилось Н страниц назад.

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

Тада!! Потому что эти все вещи описываются _чем является_ по сути, а не как этого достичь. То есть _декларативно_.

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

>Также как насичет интерпретируемых языков?

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

> В сях - практически вся программа - это описание функций. Он - декларативен?

На чём ты пытаешься меня подловить? :)

Объявление сигнатуры функции вполне себе декларативно. Сам код можно писать как в императивном стиле, так и в декларативном.

> Вызов функции - это действие?

Ты имеешь в виду, императивен он или декларативен? Смотря с какой стороны посмотреть. :)

1. Функция с сайд-эффектами.

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

С функциональной точки зрения на входе функции мы имеем один мир, на выходе - другой. Только практической пользы от такой функции мало: доказать корректность работы, оптимизировать или даже просто оттестировать её нормально малореально.

2. Чистая фунция.

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

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

Т.е. код, написанный в одной парадигме, может соответствовать и другой парадигме. Можно на процедурных сях писать и в ООП и в функциональном стиле. Только каждый раз абстракции в голове для одних и тех же вещей будут разные: для одного программиста это будет структура с указателями на функции, а другой в ней увидит таблицу виртуальных методов.

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

Когда я нес яйца из холодильника до сковороды, я их случайно выронил и рабил. Это исключительная ситуация, которую следует обработать.

Exception in thread "main" world.bird.hen.EggBrokenException
        at world.bird.hen.Egg.fall(World.java:8437)
        at world.mammal.ape.HomoSapiens.bringEggs(World.java:85744)
        at world.mammal.ape.HomoSapiens.cookOmelette(World.java:92823)
        at world.mammal.ape.HomoSapiens.getFood(World.java:64374)
        at world.mammal.ape.HomoSapiens.live(World.java:4733)
        at world.planet.Earth.breedAndMultiply(World.java:21345)
        at world.stars.Sun.runEarth(World.java:1745)
        at world.Universe.createSolarSystem(World.java:134)
        at world.World.createUniverse(World.java:9)
        at world.World.main(World.java:5)
god@heaven:~/projects/homework#

:)

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

Я тоже очень люблю парадоксальные определения. Но объясни, плз, что такое "функциональный стиль".

>с помощью тех же монад

Объясни, плз, что такое монада.

>Мне кажется, мы начинаем ходить по кругу.

Если ьы ты школу не прогуливал и пытался думать головой (хоть иногда) а не жопой - ты бы не "ходил по кругу"

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

Я тоже очень люблю парадоксальные определения. Но объясни, плз, что такое «функциональный стиль».

Использование функций высшего порядка, рекурсии, list comprehensions. Отсутствие сайд-эффектов и изменяемого состояния.

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

Объясни, плз, что такое монада.

Понятие из теории категорий. Хорошее определение монады дано в википедии:

Монада в программировании — это абстракция линейной цепочки связанных вычислений. Она описывается полиморфным контейнерным типом с одним параметром, стратегией «поднятия» значения в монаду и стратегией связывания двух вычислений, второе из которых зависит от параметра, вычисляемого первым.

Попробуй думать об "объектах" как о событиях, а о функциях как о реакциях на события.

Пришло число -> возвести в квадрат и кинуть его дальше

Пришла деталька -> просерлить отверстие и передать следующему рабочему на конвеере

Событие "пришла эта, конкретно эта" уникально. Оно произошло всего раз и больше не повторится никогда. Может возникнуть событие "пришла такая же деталька", но это будет уже другое событие. А у соседнего рабочего будет своё уникальное событие "пришла деталька с отверстием". И своя, спецефичная реакция на это событие.

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

>Использование функций высшего порядка

Странно как-то получается. Scala - объектно ориентированный, но все вышеперечисленное там имеется. OCaml - функциональный, но сайд-эффекты и изменяемые состояния переменных там присутствуют, а list-comprehensions по-умолчанию отсутствуют. И даже на С++/STL можно забабахать функции высшего порядка, поддержку списков и т.п.

>Монада в программировании

А пи в военное время равен 3-м, а иногда 4-м. Типкласс Control.Arrow отлично обеспечивает вышеперечисленное (хотя монадой не является ну ни разу). Цепочка вычислений моделируется с помощью f(g(h(x)))) или ((h.g.f) x), где (.) - оператор функциональной композиции. Определение "контейнерный тип" - полная бредятина, только уводящая от истины.

Так что такое "монада"?

> Так что такое "монада"?

afaiu, монада — это функтор с одной категории на другую, для всех объектов которой:

1. f(f(x)) -> f(x)
2. x -> f(x)

http://en.wikibooks.org/wiki/Haskell/Category_theory#Monads

То есть, применив монаду на некоторую категорию A, мы получим новую категорию B; применив эту же монаду на B, всё равно получим B.

Ну а "монадное мышление" — это сильно :-) Хотя... можно придумать аналогию: упёртость и неприятие иных точек зрения, кроме своей, сведение всех событий к своей интерпретации :-) Хех, если я правильно понимаю, что такое монады, то "монадное мышление" для многих людей очень даже естественно :-)

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

> Странно как-то получается. Scala - объектно ориентированный, но все вышеперечисленное там имеется. OCaml - функциональный, но сайд-эффекты и изменяемые состояния переменных там присутствуют, а list-comprehensions по-умолчанию отсутствуют.

Scala и OCaml - мультипарадигменные с хорошей поддержкой функциональной парадигмы, не? Даже на ICFP по ним воркшопы были.

> И даже на С++/STL можно забабахать функции высшего порядка, поддержку списков и т.п.

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

Yet another C++ flood с участием хаскеллистов и лисповодов идёт полным ходом здесь: http://www.linux.org.ru/view-message.jsp?msgid=4088836 Чего-то начинать ещё один тред на эту тему не хочется, лучше туда пойти.

> Определение "контейнерный тип" - полная бредятина, только уводящая от истины.

> Так что такое "монада"?

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

> Уход от низкоуровневого программирования к высокоуровневому.

Так в этом всё и дело.

Самое "высокоуровневое" решение — вообще ничего не решать (оно уже решено :-) Затем идёт декларативное описание (x — это a,b,c,...; выдай мне "нормальное", понятное мне x). Затем — функциональное описание (x — это f(m,n,k), m — это g(p,q), нужно задавать способ вычисления). Потом идёт алгоритмическое описание — последовательность действий, которые нужно совершить для того, чтобы получить x: сделай A, если Q, то B иначе C, ... Нужно описывать, _как_ получить x, а не то, _чем_ является x, и не то _что_ такое x вообще.

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

Скорее уж не мутация состояния, а концепция инструкции, пошагового вычисления (которое, конечно, изменяет состояние, но и функциональные программы тоже могут иметь дело с состояниями).

>Скорее уж не мутация состояния, а концепция инструкции, пошагового вычисления

Без состояния - визуально неотличимо от функционального подхода.

>монада — это функтор

Браво! Только не функтор, а эндофунктор: F: A -> A. И еще два преобразования: mu: F^2 -> F и eta: 1 -> F, где 1 - единичная категория, содержащая только один объект.

Осталось решить что это за мифическая категория "А", т.е. что там является объектами и что там является морфизмами (стрелками).

> эндофунктор: F: A -> A.

Такие вещи пока за пределами моих возможностей :) Рискну предположить, что эндофунктор отображает категорию в себя (?)

> И еще два преобразования: mu: F^2 -> F и eta: 1 -> F, где 1 - единичная категория, содержащая только один объект.

Хмм... то есть естественные преобразования? Это значит, что функции, оперирующие с "составными" типами являются естественными преобразованиями?

> Осталось решить что это за мифическая категория "А", т.е. что там является объектами и что там является морфизмами (стрелками).

A: категория, состоящая из объектов — элементарных типов данных, и морфизмов — функций, отображающих эти типы данных на другие (тоже элементарные).

Мне приходить на пересдачу или поставите зачёт? :)