Добрый день, товарищи!

Игрался неделю со scala, до этого читал статьи всяких проповедников ФП(один договорился до того что патnерны проектирования уже не нужны поскольку ФП самая замечательная вещь на свете). В результате пребываю в довольно странном состоянии — "И ЭТО ВСЕ? И ЧЕМ ЭТО ОТЛИЧАЕТСЯ ОТ ИП?".

Начнем по порядку:

1) Функции высшего порядка (название то какое!) — принимают функции в качестве аргментов
и возвращают другме функции.
Вопрос: А чем это отличается от метода который принимает в качестве аргумента объект и возвращает другой, у которых есть не только свои методы и переменные члены, но и которые соответствуют определенной сущности предметной область.
2) Tuple (кортежи??) — еще одна замечательная вещь, ДИКО МОЩНАЯ!!!!, позволяет вернуть сразу несколько вещей (в общем случае как я понимаю — устанавливает однозначное соотношение между членами кортежа и пихает в одну упаковку?)
Вопрос: А что мне мешает вернуть объект и запихнуть туда что угодно?
И.т.д.

Я прекрасно понимаю что ФП в чистом виде мало применимо и есть такие языки как scala, сочетающие в себе оба подхода. Но вот после недели изучения скалы у меня сложилось такое впечатление что это обычный ИЯ с синтаксическим сахаром (анонимные параметризированные функции, матчинг) и несколько специфичным синтаксисом.

В процессе прочтения статей я видел кучу примеров (в основном всякие математические вычисления или сортировка). Но я нигде не видел РЕАЛЬНЫХ примеров (из тех областей для которых пишется большинство программ). Читал кусок сататью VladD2 (тот что лежит на сайте). Там описывается во введении описывается замечательный язык LISP, который является самым мощным, потому всю остальное сукс (во всяком случае посыл такой...), жду когда
появится полная версия статьи... Хотя лично я в реальной задачи скорее предпочту простой и понятный инструмент (возможно даже аскетичный) чем
супер хренорезку с функциями карьерного самосвала.

Вот мне, например, нужно написать универсальный траснпорт между подразделениями, по которму может ездить что угодно куда угодно а код менять не надо, сейчас играюся с диким гибридом Jetty+Axis2+Quarts+Xalan+JDBC (как я понимаю к ФЯ с натяжкой можно отнести только XSLT) и мнея абсолютно неважно кто, где и как считает факториал.

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

P.S, Я еще не растерял интуазизм и планирую еше посидеть на скалой.... а заодно попробую найти что-то конкретное.
P.P.S. Надеюсь на вменяемую дискуссию..

rsdn.ru, работает как то чудесато, войти так и не удалось(IE схлопывается)..., так что знайте первое сообщение написаль mini_root_2.

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

По поводу паттернов: http://norvig.com/design-patterns/

16 из 23 шаблонов из книги "Шаблоны проектирования" легче имплементировать в Лиспе или Дилане. Эти шаблоны проще или вообще незаметны (поддерживаются на уровне языка)

Здравствуйте, Аноним, Вы писали:

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

Ты считаешь, что есть единственный The Right Way?

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

К>Ты считаешь, что есть единственный The Right Way?

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

Здравствуйте, Аноним, Вы писали:

К>>Ты считаешь, что есть единственный The Right Way?

А>Разумеется нет, но в более или менее крупном проекте лучше предерживаться чего-нибудь
А>одного — меньше будет проблем...

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

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

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

Возможно, но как насчет приведенных примеров (пункты 1 и 2)... и так ли эта точка зрения
сильно отличается?

А>Возможно, но как насчет приведенных примеров (пункты 1 и 2)... и так ли эта точка зрения
А>сильно отличается?

Функции высшего порядка (или все же function as first-class values?) (на примере яваскрипта):

function fun(a, b)
{
    return a + b;
}


myvar = function(i) { return fun(2, i); }

//получаем значения

myvar(1);  // получим 3
myvar(5);  // получим 7
myvar(47);  // получим 49

или пример.

В библиотеке Ext есть так называемый mixedcollection. В котором есть функция filterBy. На вход она принимает функцию об одном/двух параметрах. Если передаваемая функция возвращает true, то элемент остается в возвращаемой коллекции. Если false, элемент игнорируется

// Предположим, у нас в коллекции есть 
// var numbers = [1, 2, 3, 4, 5, 6, 7]

var numbers;

// найдем все нечетные

var odds = numbers.filterBy(
    function(n) {
        return n % 2 == 0;
    }
)

// или даже так:

function isOdd(n) { return n % 2 == 0; }
function isEven(n) { return !isOdd(n); }

function conditional(cond) { 
    // в зависимости от переданного значения возвращаем одну функцию или другую
    return cond == 'odd' ? isOdd : isEven;
}

// находим четные

var evens = numbers.filterBy(
    conditional('even')
);

Что хорошо в function as first class values и языках, их поддерживающих (а это в основном функциональные) — это возможность создания функций на лету (anonymous/lambda functions) и замыкания (closures). Эти две вещи через объекты эмулируются кривовато

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Курилка, Вы писали:

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

А>Возможно, но как насчет приведенных примеров (пункты 1 и 2)... и так ли эта точка зрения
А>сильно отличается?

Вот тут как раз и очень отличается
Ты смотришь на всё как на объекты.
Как в поговорке про молоток.
А функция — она лишь только функция. И кортежи лишь только кортежи.
Наличие же классов может вылиться хотябы в отстутствии неизменяемости объектов. Никто же не мешает тебе в функтор (в плюсовой терминологии) добавить переменную (скажем, счётчик вызовов), только вот это уменьшает прозрачность, увеличивает число зависимостей и т.п.
Т.е. ты пытаешься функциональны подход "замапить" на ООПшный. Эт хорошо для понимания. Но для использования функционального подхода плохо.
Знаешь это напоминает изучение иностранного языка. В начале ты всё время переводишь иностранные слова на родной язык. Поэтому процесси идёт медленно. Потом в ходе практики получается что ты думать научиваешься на том языке, поэтому понимание идёт много проще. Хотя может у других это иначе, но вот с аглицким у меня так ситуация обстояла.

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

M>Функции высшего порядка (или все же function as first-class values?) (на примере яваскрипта):

Вообщето это все можо сделать и вто так:

 public interface MyInterface
  {
   public Integer function(Integer _a, Integer _b);
  }

 public interface MySecondInterface
  {
   public void setFristFunction(MyInterface _mi);   
   public Integer function(Integer _i);
  }

 ...
 MyInterface firstFunction=new MyInterface() 
  {
   public Integer function(Integer _a, Integer _b) {return _a+_b;}
  };

 MySecondInterface secondFunction=new MySecondInterface()
  {
   protected MyInterface mi=null;
   public void setFirstFunction(MyInterface _mi) {mi=_mi;}
   public Integer function(Integer _i) {return mi.function(2,_i);}
  }
 Integer myVar=secondFunction.function(1); //получим 3
 ...

Пишется несколько длиннее но результат тот же самый.
Или на scala:

def function(i:int):int = 
 {
  def internalFunction(_a:int, _b:int):int =
   {
    return _a+_b;
   }
  return internalFunction(2,_i);
 };

Одно и тоже, только во втором варианте сахара побольше (кроме того в случае с явой можно
было не определять первый интерфейс а захардкодить все внутрь анаонимного класса).
И никакой кривизны здесь нет! Вы удивитесь, но лично я выберу ПЕРВЫЙ вариант.
Я склоняюсь к мнению что рассматривать преимущества ФП "в малом" занятие бессмысленное,
единственное _возможное_ преимущество возможно только в одном случае если ФП позволит
как-то по-другому разбить проект и получившееся архитектура будет более понятной и простой...
Но вто этого я пока нигде и не увидел(и не уверен что оно вообще есть...): в основном сортировка или вышка...

Здравствуйте, Аноним, Вы писали:

А>Одно и тоже, только во втором варианте сахара побольше (кроме того в случае с явой можно
А>было не определять первый интерфейс а захардкодить все внутрь анаонимного класса).
А>И никакой кривизны здесь нет! Вы удивитесь, но лично я выберу ПЕРВЫЙ вариант.
Первый — с интерфейсами? Ну дак яж уже писал — ты тут смотришь на всё через призму ООП, тебе привычно, поэтому для тебя это логично
А>Я склоняюсь к мнению что рассматривать преимущества ФП "в малом" занятие бессмысленное,
А>единственное _возможное_ преимущество возможно только в одном случае если ФП позволит
А>как-то по-другому разбить проект и получившееся архитектура будет более понятной и простой...
А>Но вто этого я пока нигде и не увидел(и не уверен что оно вообще есть...): в основном сортировка или вышка...

А вышка — это что имеется в виду?

Здравствуйте, Аноним, Вы писали:

А>Вообщето это все можо сделать и вто так:

А>

А> Код поскипан...
А>

А>Пишется несколько длиннее но результат тот же самый.

Дык всё можно сэмулировать: языки-то Тьюринг-полные. У тебя здесь порядка 60 идентификаторов, а у Mamut'а меньше 15. А на Хаскелле та же мелодия угадывается с пяти нот:

fun = (+)
myvar = fun 2

Тестируем:

Hugs> myvar 1
3
Hugs> myvar 4
6
Hugs> myvar 47
49

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

Здравствуйте, <Аноним>, Вы писали:

А>один договорился до того что патnерны проектирования уже не нужны поскольку ФП самая замечательная вещь на свете

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

Касательно второго подхода — это не обязательно удел ФЯ. В том же С++ есть средства метапрораммирования. Просто в C++ эта фича реализована малость извртано. Вообще, метапрограммирование "дружит" с ФЯ, т.к. ФЯ содержит кучу сахара для облегчения написания макросов.

А>Начнем по порядку:

А>1) Функции высшего порядка (название то какое!) — принимают функции в качестве аргментов
А>и возвращают другме функции.
А>Вопрос: А чем это отличается от метода который принимает в качестве аргумента объект и возвращает другой, у которых есть не только свои методы и переменные члены, но и которые соответствуют определенной сущности предметной область.

Да, можно. Но написать функцию — быстрее и лаконичнее, чем каждый раз создавать объект. Ещё в ФЯ есть вложенные функции, лямбды и замыкания — неслабый такой сахар. Конечно, это всё эмулируется на классах. Но попробуй сам попиши с использованием перечисленных фич и без их использования (эмуляцией), и сам поймёшь в чём прелесть. Правда, стоит оговориться, что выбор того или иного подхода часто диктуется самой задачей. Иногда проще и понятнее добавить лишний класс. Но порой глаза начинает рябить от многочисленных XXXView, XXXHandle, XXXInfo, XXXDescriptor, которые имеют примитувную внутреннюю структуру и используются в двух-трёх случаях.

Кстати, применяя ФВП, мы можем немного по-другому думать о задаче. Иногда даже формулировка с использованием ФВП мало отличается от обычной математической формулировки.

А>2) Tuple (кортежи??) — еще одна замечательная вещь, ДИКО МОЩНАЯ!!!!, позволяет вернуть сразу несколько вещей (в общем случае как я понимаю — устанавливает однозначное соотношение между членами кортежа и пихает в одну упаковку?)
А>Вопрос: А что мне мешает вернуть объект и запихнуть туда что угодно?
А>И.т.д.

Опять же, вопрос удобства.

А>Я прекрасно понимаю что ФП в чистом виде мало применимо и есть такие языки как scala, сочетающие в себе оба подхода. Но вот после недели изучения скалы у меня сложилось такое впечатление что это обычный ИЯ с синтаксическим сахаром (анонимные параметризированные функции, матчинг) и несколько специфичным синтаксисом.

По сути, так оно есть. Большинство ФЯ (начиная с Лиспа) — это ИЯ с сахаром, в том числе поддерживающим и упрощающим функциональное программирование.


PS: продолжаю заниматься наглым самопиаром. А потому даю ссылочку сюда

Автор: konsoletyper
Дата: 13.04.07

, как пример использования ФЯ. Советую особенно посмотреть на вещи, связанные с генерацией ДКА и LALR-таблицы (src\Common\Bnf, src\Common\Finite, scr\Common\Grammar) и с распарсиванием BNF (src\BnfParser).

Аноним,

А>Игрался неделю со scala, до этого читал статьи всяких проповедников ФП(один договорился до того что патnерны проектирования уже не нужны поскольку ФП самая замечательная вещь на свете). В результате пребываю в довольно странном состоянии — "И ЭТО ВСЕ? И ЧЕМ ЭТО ОТЛИЧАЕТСЯ ОТ ИП?".

Отличия ФП от ИП очень много обсуждалось здесь (с переменным успехом)

А>1) Функции высшего порядка (название то какое!) — принимают функции в качестве аргментов
А>и возвращают другме функции.
А>Вопрос: А чем это отличается от метода который принимает в качестве аргумента объект и возвращает другой, у которых есть не только свои методы и переменные члены, но и которые соответствуют определенной сущности предметной область.
Если интерфейс соответствует сущности — отлично. Это должна быть крупная сущность, иначе мы упрёмся в создании миллиона интерфейсов на каждый писк, типа IFile, IFileArchived, IFileArchivedWithRAR, IFileArchivedWith7z и т.п. И созданием объектов типа

interface IFromIAndI {
   Integer call(Integer a, Integer b);
}

IFromIAndI add_two_integers = new IFromIAndI() {
   public Integer call(final Integer a, final Integer b) {
      return a + b;
   }
};

Намано?

Ещё пример. Дан регексп, нужно узнать, матчится ли он с текстом:

Pattern pattern = new Pattern(regexp);
Matcher matcher = pattern.matcher(text);
if (matcher.matches()) ...

Это и есть исполнение в Королевстве Существительных. Ты должен сначала создать нужных исполнителей, а потом сказать им: "Ду!" вместо непосредственного исполнения =matches regexp text=. Кроме замутнения самого Действия мы вдобавок получаем кучу побочных эффектов на пустом месте, там где можно было вполне обойтись без них.

К сожалению, крупные примеры в функциональном стиле будут вряд ли интересны читателю, поэтому и ограничиваются примерами типа =take k . quicksort=.


А>2) Tuple (кортежи??) — еще одна замечательная вещь, ДИКО МОЩНАЯ!!!!, позволяет вернуть сразу несколько вещей (в общем случае как я понимаю — устанавливает однозначное соотношение между членами кортежа и пихает в одну упаковку?)
А>Вопрос: А что мне мешает вернуть объект и запихнуть туда что угодно?
А>И.т.д.

Тебе нужно заводить тип (то есть плодить сущности без надобности), ты не можешь отождествлять объекты в соответствии со структурой, и ты не можешь делать паттерн-матчинг по содержимому объектов (обычно так, хотя в Scala есть unapply) и работа с объектами (обычно) более громоздка по сравнению с работой с кортежами.


А>Я прекрасно понимаю что ФП в чистом виде мало применимо


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

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

А>В процессе прочтения статей я видел кучу примеров (в основном всякие математические вычисления или сортировка). Но я нигде не видел РЕАЛЬНЫХ примеров (из тех областей для которых пишется большинство программ).

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

Реальное применение вообще ФП? Ну можно начать отсюда
http://rsdn.ru/Forum/Message.aspx?mid=2182617&amp;only=1

Автор: Didro
Дата: 26.10.06

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

В ФП паттерны часто являются просто ФВП. Ну вот fold — чем не паттерн? Или map-reduce? Или класс типов Monad?
Reusable — безусловно. General — тоже (в рамках применимости конечно ).

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

LCR>Это и есть исполнение в Королевстве Существительных.

Отличная фэнтези

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

MR2> Читал кусок сататью VladD2 (тот что лежит на сайте). Там описывается во введении описывается замечательный язык LISP, который является самым мощным, потому всю остальное сукс (во всяком случае посыл такой...),

Это когда же VladD2 успел разлюбить Nemerle и полюбить Лисп с жутким по его мнению синтаксисом? 8-о

Здравствуйте, <Аноним>, Вы писали:

А>Я прекрасно понимаю что ФП в чистом виде мало применимо и есть такие языки как scala, сочетающие в себе оба подхода. Но вот после недели изучения скалы у меня сложилось такое впечатление что это обычный ИЯ с синтаксическим сахаром (анонимные параметризированные функции, матчинг) и несколько специфичным синтаксисом.

Не парься. Не стоит рассматривать ФП как альтернатива ИП или ООП. ФП надо рассматривать как дополнение к ним, тогда всё будет очень хорошо

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

G>Это когда же VladD2 успел разлюбить Nemerle и полюбить Лисп с жутким по его мнению синтаксисом? 8-о

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

mini_root_2

Здравствуйте, Аноним, Вы писали:

А>1) Функции высшего порядка (название то какое!)

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

А>Вопрос: А чем это отличается от метода который

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

А>2) Tuple (кортежи??) — еще одна замечательная вещь, ДИКО МОЩНАЯ!!!!, позволяет вернуть сразу несколько вещей (в общем случае как я понимаю — устанавливает однозначное соотношение между членами кортежа и пихает в одну упаковку?)
А>Вопрос: А что мне мешает вернуть объект и запихнуть туда что угодно?

Мешает то, что для этих ваших объектов нет такой простой и понятной модели, как банальное декартово произведение множеств.

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

А> Читал кусок сататью VladD2 (тот что лежит на сайте). Там описывается во введении описывается замечательный язык LISP,

Lisp вообще никогда не был языком ФП. Лисп — это императивный язык, ориентированный преимущественно на метапрограммирование. Совсем другая область, гораздо более практичная и приземлённая.

А>Вот мне, например, нужно написать универсальный траснпорт между подразделениями, по которму может ездить что угодно куда угодно а код менять не надо, сейчас играюся с диким гибридом Jetty+Axis2+Quarts+Xalan+JDBC (как я понимаю к ФЯ с натяжкой можно отнести только XSLT) и мнея абсолютно неважно кто, где и как считает факториал.

А я бы с дикими гибридами из всяких разных уродцев не игрался, и построил бы тупейшую агентную модель, взяв за основу для протокола SXML и какую либо легковесную реализацию языка Scheme. Уложился бы строк в 100 кода и часа в два работы.

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

Шаблоны нужны там, где язык настолько убог, что заставляет одну и ту же абстракцию реализовывать многократно. Функциональщик же любую конструкцию, аналогичную встречающимся в GoF реализует ровно один раз, и забудет про неё навсегда. Кстати, самый часто употребимый функциональщиками pattern — "interpreter pattern". Но для постижения этого факта вам надо постичь дзен.

deniok,

D>Отличная фэнтези

Ага, ещё и с любопытным сатирическим оттенком.