Здравствуйте, Mikl Kurkov, Вы писали:

MK>Вот хорошая статья про монаду IO в Haskell. Собственно идея та же — в функциях, взаимодействующих с внешним миром, добавляется еще один парметр RealWorld, также возвращаемое значение дополняется тем же значением RealWorld. Эти значения нужны только для компилятора,- чтобы обеспечить правильный порядок вызовов и не дать ему соптимизировать вызовы одной функции с одинаковыми парметрами. В статье показано как это можно сделать без всяких монад, монады же просто скрывают от программиста этот механизм и упрощают его использование.

Спасибо, про монады я читал Хотел узнать, чем решение в Clean отличается.


Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Если мы будем добавлять в файл символ и возвращать тот же файл, то функция append_char перестаёт быть собственно функцией и результат main зависит от того, левый или правый элемент тупла вычисляется первым. Это можно победить, если возвращать копию файла. Тогда main будет гарантированно всегда возвращать тот же самый результат. Создание новых файлов — это конечно слишком неэффективно и разумеется отметается как вариант. Но что тогда?

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

Т.е. я правильно понял, что один из append_char изменит текущий file, а другой сделает копию?

VoidEx,

VE>Т.е. я правильно понял, что один из append_char изменит текущий file, а другой сделает копию?

Скорее всего да. 'Скорее всего' — потому что здесь легко можно вывести уникальность одного из аргументов (первого или второго, но ессно не обоих сразу) самим компилятором. Но сейчас компилятора под рукой нет, проверить не могу.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Просто и эффективно, не так ли?

Не то слово! А каой оргазм испытывает мозг при пропускании этой простоты через него!!!

deniok wrote:
> Спасибо всем (отдельно Кодту за обычную содержательность). Был неправ.
> Хотел поставить себе минус, но не обнаружил такой возможности.
>
> Разаработчикам: поддержите возможность самокритики
Поднимайте старую ветку в обсуждении сайта.. Может, в этот раз..

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, Mikl Kurkov, Вы писали:

MK>>Вот хорошая статья про монаду IO в Haskell. Собственно идея та же — в функциях, взаимодействующих с внешним миром, добавляется еще один парметр RealWorld, также возвращаемое значение дополняется тем же значением RealWorld. Эти значения нужны только для компилятора,- чтобы обеспечить правильный порядок вызовов и не дать ему соптимизировать вызовы одной функции с одинаковыми парметрами. В статье показано как это можно сделать без всяких монад, монады же просто скрывают от программиста этот механизм и упрощают его использование.

VE>Спасибо, про монады я читал Хотел узнать, чем решение в Clean отличается.

меня мозговой штурм на эту тему привёл к следующему выводу: есть различные варианты реализации императвиности в lazy языке. один — использовать уникальные типы (оно как раз описано в этой статье, а также используется в Clean, Mercury), второе — использование continuations (использовалось в hbc и возможно других хаскел-компиляторах; фактичсеки это тоже способ сделать нечто уникальным, только на этот раз уникальным является цепочка последующих исполняемых прцедур, передаваемая в качсетве continuation)

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


VE>Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>>Если мы будем добавлять в файл символ и возвращать тот же файл, то функция append_char перестаёт быть собственно функцией и результат main зависит от того, левый или правый элемент тупла вычисляется первым. Это можно победить, если возвращать копию файла. Тогда main будет гарантированно всегда возвращать тот же самый результат. Создание новых файлов — это конечно слишком неэффективно и разумеется отметается как вариант. Но что тогда?

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

VE>Т.е. я правильно понял, что один из append_char изменит текущий file, а другой сделает копию?

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

Прочитал вот статью и содержимое обсуждения, но так и не нашёл ответов на мучающие меня вопросы. Возможно, кто-нибудь сможет откомментировать мои мысли?

1. Однако. Теоретически всё хорошо, на маленьких примерах всё отлично, но при обращении к большим примерам (а на Haskell их немало), то я вижу такие вещи.

1.1. Конечно, возможно, это отлично, что каждый может определить свои примитивы для control flow. Вроде монад, скобок, стрелки. Но оказывается (?) этих примитивов не хватает. Они не универсальны, и в большом проекте возникает куча собственных промежуточных абстракций, которые реализуют собственный control flow через манипулирование функциями. Можно сказать, что это отлично, что так и должно быть, ведь, это — true fp.

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

Хороший пример этого неудобства — книга Пейтона Джонса о разработке компилятора и виртуальной машины для функционального языка. Где для каждой мелкого с точки зрения функциональности дополнения приходится переписывать ВСЕ функции. Конечно, эти изменения внести можно быстро благодаря структуре языка. Но их нужно внести МНОГО.

И это черта не только примеров в этой книге. Я попробовал немножко похакать вокруг исходников Frag — приходится делать то же самое. Что я делаю не так?

1.1.1. Возможно, это поведение связано с тем, что конструируется main — 'высокоматематичный' объект. Функция. А, как известно, математические объекты никакой динамикой не обладают. И чтобы эти объекты менять, их нужно менять целиком, на всех уровнях.

1.2. Сначала в Haskell мы упорно уходим от side effects, уходим от переменных, а потом очень много кода пишем при помощи монад. Но монады — это не очень гибкий инструмент, потому что связывание функций возможно только единственным способом. Конечно, можно иметь несколько bind'ов, но это вряд ли приведёт к улучшению понимания кода. Да и как может быть заранее известно, какой именно bind понадобится, и как они должны взаимодействовать. Поэтому, для организации dataflow:

1.2.1. Нужно делать world-состояние большим, включая в него большое количество значений. Но это сводит на нет все утверждения об автоматическом распараллеливание. Вычисление в монаде строго последовательные. А монады сплошь и рядом. Непонятно в этом случае, а зачем уходить от переменных и от описания dataflow при помощи них? Да, они требуют более мощных алгоритмов автоматического распараллеливания, но эти алгоритмы дают и больше возможностей. А насчёт того, насколько это возможно, так посмотрите компиляторы Fortran и С от Intel и Sun.

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

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

2. Возможно, всё хорошо, пока дело не доходит до вызова main. Вызов — же это действие — 'примени main к такому-то значению', а не описание применения. Что-то у меня в голове не сходится: мы долго бежим от того, чтобы использовать действия, и в итоге, оно оказывается чуть ли ни самой фажной частью системы. Зачем писать программы, которые никто не запускает? Как насчёт концептуальной целостности?

В чём я не прав? Надеюсь, тут есть гуру, которые смогут открыть мне глаза.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Я с удовольствием послушаю, как вы реализуете на функторах функцию iterate:
LCR>

LCR>let compose f g x = f(g x) ;;
LCR>let rec iterate n f =
LCR>    if n = 0 then (function x -> x)
LCR>    else compose f (iterate (n-1) f) ;;

LCR>(* использовать можно так *)
LCR>let rec power i n =
LCR>    let i_times = ( * ) i in  (* "i_times n" равно функции "умножить на i" n раз *)
LCR>        iterate n i_times 1 ;;

LCR>power 2 8 ;; (* выдаст 256 *)

LCR>

LCR>(ocaml)
LCR>Больше чем уверен, что вы вернёте разве что функтор-интерпретатор, который будет инкапсулировать АСТ.

Вообще идея приводить человеку вообще не понимающему что такое ФП примеры на ОКамле или его аналоге — это все равно, что глумиться над старушкой заставляя читать ее учебник по высшей математике.

Здравствуйте, VladD2, Вы писали:

LCR>>Больше чем уверен, что вы вернёте разве что функтор-интерпретатор, который будет инкапсулировать АСТ.
VD>Вообще идея приводить человеку вообще не понимающему что такое ФП примеры на ОКамле или его аналоге — это все равно, что глумиться над старушкой заставляя читать ее учебник по высшей математике.
Можно утешиться тем, что примеры не на K или Haskell'е

Здравствуйте, mike.b, Вы писали:

MB>1.1. Конечно, возможно, это отлично, что каждый может определить свои примитивы для control flow. Вроде монад, скобок, стрелки. Но оказывается (?) этих примитивов не хватает. Они не универсальны, и в большом проекте возникает куча собственных промежуточных абстракций, которые реализуют собственный control flow через манипулирование функциями. Можно сказать, что это отлично, что так и должно быть, ведь, это — true fp.

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

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

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

MB>Хороший пример этого неудобства — книга Пейтона Джонса о разработке компилятора и виртуальной машины для функционального языка. Где для каждой мелкого с точки зрения функциональности дополнения приходится переписывать ВСЕ функции. Конечно, эти изменения внести можно быстро благодаря структуре языка. Но их нужно внести МНОГО.

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

MB>И это черта не только примеров в этой книге. Я попробовал немножко похакать вокруг исходников Frag — приходится делать то же самое. Что я делаю не так?

я пробовал изучать C по другой книге, посящённой созданию 3d-шутеров, и тоже ни чаго не понял. что я делаю не так?

MB>1.2. Сначала в Haskell мы упорно уходим от side effects, уходим от переменных, а потом очень много кода пишем при помощи монад. Но монады — это не очень гибкий инструмент, потому что связывание функций возможно только единственным способом.

к тому же фнукции — негибкий инструмент потомушта для них предусмотрен всего один способ вызова. вот если бы f() ознаало одно, а f[] — другое, это было бы реальное преимущество перед бейсиком

MB>Конечно, можно иметь несколько bind'ов, но это вряд ли приведёт к улучшению понимания кода. Да и как может быть заранее известно, какой именно bind понадобится, и как они должны взаимодействовать. Поэтому, для организации dataflow:

вот ещё одна проблема с фукциями — как их можно писать, если заранее неизвестно какие понадобятся. ну просто ума не приложу!

MB>1.2.1. Нужно делать world-состояние большим, включая в него большое количество значений. Но это сводит на нет все утверждения об автоматическом распараллеливание.

и ещё у С недостаток — на моём денди не работает. а сосед говорил, что будет. ну не мог же мой сосед наврать!

>Вычисление в монаде строго последовательные. А монады сплошь и рядом. Непонятно в этом случае, а зачем уходить от переменных и от описания dataflow при помощи них? Да, они требуют более мощных алгоритмов автоматического распараллеливания, но эти алгоритмы дают и больше возможностей. А насчёт того, насколько это возможно, так посмотрите компиляторы Fortran и С от Intel и Sun.

а для бейсика емсть калькуятор МK-85, значит бейсик лучше!

MB>1.2.2. Можно попробовать разбить все вычисления на вычисления в небольших монадках, но это увеличивает количество аргументов у функций, заставляет придумывать функции для склейки значений. Снова усложнение. Зачем, если с переменными проще?

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

MB>1.2.3. Стрелка спасает, но не очень эффективно: опять же требует много дополнительного кода для манипуляции над значениями.

а ещё говорят там есть классы — это уж вовсе недецкий изврат

MB>2. Возможно, всё хорошо, пока дело не доходит до вызова main. Вызов — же это действие — 'примени main к такому-то значению', а не описание применения. Что-то у меня в голове не сходится: мы долго бежим от того, чтобы использовать действия, и в итоге, оно оказывается чуть ли ни самой фажной частью системы. Зачем писать программы, которые никто не запускает? Как насчёт концептуальной целостности?

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

MB>В чём я не прав? Надеюсь, тут есть гуру, которые смогут открыть мне глаза.

на деревню дедушке Мазаю от пионерской организации. передать в сосбвтенные руки

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Quintanar, Вы писали:

Q>>Вы плохо понимаете, что такое побочные эффекты. Если вы меняете поле в структуре, которую вам передали по указателю, то вы меняете состояние внешнего объекта — это побочный эффект. А программ на С, где такого нет, я не знаю.

VD>Это зависит исключительно от того кто и как пишет.

Все таки я тоже не припомню случая, чтобы на С вместо модификации данных, ссылка на которые приплыла на стеке, создавали измененную копию. Лишний malloc, от мысли об этом любой с-программист выпадет в осадок. Зато компиляторы ФП могут оптимизировать этот процесс и клонировать только определенные части данных.

struct A
{
int a;
}

struct B
{
int b;
}

struct S
{
A* a;
B* b;
}

S* foo(S* s)
{
struct A* newA = {s.a.a++};
struct B* newB = {s.b.b};
struct S* newS={newA, newB};
return S;
}

В фп например компилятор увидев, что newB является копией b, может сделать так:

newS = {newA, S.b}

Чтобы на С получить эту оптимизацию, надо самому следить за неизменямостью ссылки b и здесь, и в будущем (за пределами функции foo). Это и есть "автоматическое управление identity", которым так гордятся функциональщики.

Здравствуйте, mike.b, Вы писали:

MB>Прочитал вот статью и содержимое обсуждения, но так и не нашёл ответов на мучающие меня вопросы. Возможно, кто-нибудь сможет откомментировать мои мысли?

MB>1. Однако. Теоретически всё хорошо, на маленьких примерах всё отлично, но при обращении к большим примерам (а на Haskell их немало), то я вижу такие вещи.

MB>Хороший пример этого неудобства — книга Пейтона Джонса о разработке компилятора и виртуальной машины для функционального языка. Где для каждой мелкого с точки зрения функциональности дополнения приходится переписывать ВСЕ функции. Конечно, эти изменения внести можно быстро благодаря структуре языка. Но их нужно внести МНОГО.

Цена внесения изменений не зависит от парадигмы а зависит от соблюдений/не соблюдений общепринятых норм проектирования ПО, которые и для ООП и для ФП совершенно одинаковы. Кратко их можно сформулировать так: программы должны строиться из модулей, которые могут взаймодействовать друг с другом только по строго определенным абстрактным интерфейсам.

LP>Цена внесения изменений не зависит от парадигмы а зависит от соблюдений/не соблюдений общепринятых норм проектирования ПО, которые и для ООП и для ФП совершенно одинаковы. Кратко их можно сформулировать так: программы должны строиться из модулей, которые могут взаймодействовать друг с другом только по строго определенным абстрактным интерфейсам.

Угу. Когда программа написана, то все её модули 'взаимодействуют друг с другом только по строго определённым абстрактным интерфейсам'. А как часто у Вас получалось сразу же придумать лучший абстрактный интерфейс для новых модулей в новой программе? А цена изменения интерфейса в процессе проектирования для ФП (кстати, ООП тут ничем не лучше ФП, да и вообще этот подход ничем не лучше, кроме толщины книг ему посвящённых) очень высока. Добавили одну переменную в состояние -> правим все функции, потому что аргументы надо протаскивать по всему графу вызовов, ну и прочие прелести. По крайней мере, мой опыт таков. И вы не думайте, что модули у меня выходили в итоге монструазные и не абстрактны, нет, я всегда стремлюсь к минимальным интерфейсам — 20 функций для меня уже слишком много.

Но на Си к итоговым хорошим интерфейсам подобраться получается гораздо быстрее, чем на Haskell, например. Понимаю, что опыта у меня не много, но опять же, небольшое изменение в уже готовую программу на Си я вношу быстро, а в программу на Haskell — долго и упорно. Хотя, кажется, что текста пишется при этом меньше. Но локальное (казалось бы) изменение расползается на код всего модуля. Я, конечно, могу быть и не правым. Но мистер Джонс патриарх же, насколько я знаю. И у него в книге всё точно так же, как и в моих попытках постичь ФП. Может быть, я чего-то воспринимаю неправильно?

Здравствуйте, m.o.b., Вы писали:

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

Хм... а если использовать монаду State?

Здравствуйте, m.o.b., Вы писали:

LP>>Цена внесения изменений не зависит от парадигмы а зависит от соблюдений/не соблюдений общепринятых норм проектирования ПО, которые и для ООП и для ФП совершенно одинаковы. Кратко их можно сформулировать так: программы должны строиться из модулей, которые могут взаймодействовать друг с другом только по строго определенным абстрактным интерфейсам.

MOB>Угу. Когда программа написана, то все её модули 'взаимодействуют друг с другом только по строго определённым абстрактным интерфейсам'. А как часто у Вас получалось сразу же придумать лучший абстрактный интерфейс для новых модулей в новой программе?

Редко. Рефакторить всегда приходится много.

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

Я не знаток хаскеля, но много раз читал, что как раз для этой цели хорошо пригодны монады.

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

MOB>Но на Си к итоговым хорошим интерфейсам подобраться получается гораздо быстрее, чем на Haskell, например. Понимаю, что опыта у меня не много, но опять же, небольшое изменение в уже готовую программу на Си я вношу быстро, а в программу на Haskell — долго и упорно. Хотя, кажется, что текста пишется при этом меньше. Но локальное (казалось бы) изменение расползается на код всего модуля. Я, конечно, могу быть и не правым. Но мистер Джонс патриарх же, насколько я знаю. И у него в книге всё точно так же, как и в моих попытках постичь ФП. Может быть, я чего-то воспринимаю неправильно?

Опять же, не будучи особым знатоком фп, выскажу кое-какие соображения по этому поводу. Классы типов + параметический полиморфизм обеспечивают приблизительно тот же уровень полиморфизма, что и интерфейсы + элементы обобщ. программирования в обычных ООП-языках. Чудес не бывает, и при изменении интерфейса и там и там приходится перепахать код с его использованием. Возможности изменения реализации, не затрагивая интерфейса и там, и там одинаковы. Поэтому я не могу понять, почему стоимость внесения изменений может быть где-то выше. Протаскивание же состояния на стеке никак не может увеличить цену внесения изменений, какая разница, к чему обращается функция/метод — к глобальному состоянию или переданному на стеке. Какая разница, чем является переменная, тип которой меняется — локальной или членом класса.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, VoidEx, Вы писали:
VE>>Можно сказать так, отличительной чертой ФЯ является то, что некоторые из них имеют отсутствие побочных эффектов.

VD>Не может быть отилчительной чертой вида черта встречающаяся не у всех представителей класса.
Отличительной чертой птиц (среди других позвоночных) является способность летать.
Что будем делать со страусами/пингвинами, с одной стороны; и с птеродактилями/летучими мышами — с другой?

Здравствуйте, Dusty, Вы писали:

Тут термин неверно мной подобран. Точнее его двояко в жизни используют. Ибо формально способность летать — не отличительная черта птиц. С другой стороны, если кого-то спросить "что за животные такие — птицы", самым простым ответом будет, что они летают. Хотя можно сказать "двулапые с перьями"

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, Dusty, Вы писали:

VE>Тут термин неверно мной подобран.
Неверно, но правильно В смысле — именно наналогия с птицами позволяет понять, что же такое ФЯ в отличие от ИЯ.

VE>Ибо формально способность летать — не отличительная черта птиц.
Да, верно.
Но с другой стороны, у биологов есть список из формальных признаков птиц — т.н. "синдром"; семь штук, кажется (или это у млеков 7, а у птиц 6? не помню).
И если посмотреть на этот список, то большинство признаков являются либо обеспечением возможности полета (маховое перо — пуховое перо появилось еще у предшественников птиц); либо оптимизацией под полет (теплокровность — повышенная энергетика; килевая кость — прикрепление мускулов для движения крыльев и т.д.) У страусов и пингвинов — хоть они и не летают — все эти формальные признаки сохранились (из-за чего их и считают птицами); но уже не служат для полета.

С ФЯ почти то же самое. Существует целый спектр оптимизаций в дизайне языков, упрощающих написанием на нем функциональных программ. Если в языке представлено достаточно большое количество таких оптимизаций, то он "поддерживает функциональную парадигму". Если, он не поддерживает кроме функциональной парадигмы других — то это ФЯ (иначе — это "гибридный" язык; вещь, в животном мире не встречающаяся).

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

Здравствуйте, LaPerouse, Вы писали:

LP>Цена внесения изменений не зависит от парадигмы

зависит, как и стоимость самого программирования. языки развивиаются как раз в направлении увеличения компонентности программирования, ООП например исключительно в этом и состоит

Здравствуйте, Линкер Николай (перевод), Вы писали:

ЛНП>Статья:
ЛНП>Вячеслав Ахмечет. Функциональное программирование для всех

Автор(ы): Вячеслав Ахмечет
Дата: 16.09.2006
Данная статья достаточно кратко и вполне доступно, используя примеры на Java (!), знакомит читателя с базовыми понятиями функционального программирования.

ЛНП>Авторы:
ЛНП> Линкер Николай (перевод)

ЛНП>Аннотация:
ЛНП>Данная статья достаточно кратко и вполне доступно, используя примеры на Java (!), знакомит читателя с базовыми понятиями функционального программирования.

После прочтения статьи вообще потерял интерес к ООП. Хочу программировать на ФЯ!
ООП — old stuff . ФЯ — rocks!