ООП vs ФП

← →
Kerk © (2013-02-04 19:20) [0]

Интересное мнение по-моему, давайте пофлеймим немного:

Вот смотри, люди начали писать программы. Оказалось, что есть некий набор принципов, которые позволяют упростить написание программ. И люди начали использовать эти принципы. Их никто не называл и не называет ООП. Внезапно оказалось, что эти принципы наиболее легко и естественно используются в рамках определенной парадигмы - эту парадигму назвали «функциональное программирование» (по сути это и есть программирование в соответствии с указанными принципами, программирование заточенное под них). Никакого ООП, опять же, и близко еще не было. К сожалению, рантайм реального процессора был очень далек от рантайма таких языков и потому они ТОРМОЗИЛИ. Надо было писать на чем-то более низкоуровневом. Люди пытались и там использовать все те же принципы - но изза низкоуровневости языка это уже не было легко, изящно и просто. Это было криво и костыльно. Тогда пришла идея - ввести в язык ряд встроенных средств, которые бы упрощали использование этих принципов (то есть сделать эдакий набор стандартизованных универсальных костылей). Сказано - сделано. Вот этот набор стандартизованных костылей и назвали ООП. Но те самые принципы, использование которых ООП должно упрощать в низкоуровневых язычках, как и раньше, наиболее легко, полно и удобно выражаются именно в рамках ФП. Потому что именно ФП - программирование в соовтетствие с этими принципами. А ООП - это просто костыль. Исторически сложившийся казус.

← →
icelex © (2013-02-04 19:27) [1]

прикольно: написано много, а не сказано ничего

← →
Rouse_ © (2013-02-04 19:45) [2]

А мне кажется чушь. Во вторых про какой такой низкоуровневый язык идет речь, в который ввели ООП?

← →
брат Птибурдукова (2013-02-04 19:50) [3]

> Rouse_ © (04.02.13 19:45) [2]
С точки зрения ФП ВСЯ эта ваша процедурщина — низкоуровневые языки...

← →
Rouse_ © (2013-02-04 19:52) [4]

> брат Птибурдукова (04.02.13 19:50) [3]
> С точки зрения ФП ВСЯ эта ваша процедурщина — низкоуровневые языки...

Ну может быть тогда я не верно понимаю сам принцип ФП :)

← →
брат Птибурдукова (2013-02-04 19:58) [5]

> Ну может быть тогда я не верно понимаю сам принцип ФП
Так шо ж непонятного? «некий набор принципов, которые позволяют упростить написание программ» ≡ «функциональное программирование»

← →
Пит (2013-02-04 19:58) [6]

Удалено модератором

← →
Inovet © (2013-02-04 20:06) [7]

> [0] Kerk © (04.02.13 19:20)
> в низкоуровневых язычках

Из маленьких язычков разгорится большой флейм.

← →
TUser © (2013-02-04 20:38) [8]

Ерунда какая-то. ООП - императивная штуковина, при чем тут функциональщина? Это вообще мало имеющие отношение друг к другу вещи. Имхо.

← →
Pavia © (2013-02-04 20:47) [9]

> Kerk © (04.02.13 19:20)

У вас всё шиворот на выворот.

← →
имя (2013-02-04 21:12) [10]

Удалено модератором

← →
KilkennyCat © (2013-02-04 21:14) [11]

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

← →
имя (2013-02-04 21:17) [12]

Удалено модератором

← →
Inovet © (2013-02-04 21:25) [13]

Удалено модератором

← →
Kerk © (2013-02-04 21:27) [14]

Переведу для тех, кто не читатель, а писатель. Ничего личного :)

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

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

← →
Игорь Шевченко © (2013-02-04 21:28) [15]

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

Буч старается

← →
alexdn © (2013-02-04 21:39) [16]

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

← →
Игорь Шевченко © (2013-02-04 21:40) [17]

я процитирую, с позволения:

"Объектно-ориентированное программирование - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования.
...
ООП использует в качестве базовых элементов объекты, а не алгоритмы.
...
Для объектно-ориентированного стиля концептуальная база - это объектная модель. Она имеет четыре главных элемента:
- абстрагирование
- инкапсуляция
- модульность
- иерархия
Эти элементы являются главными в том смысле, что без любого из них модель не будет объектно-ориентированной. Кроме главных, имеются еще три дополнительных элемента:
- типизация
- параллелизм
- сохраняемость
Эти элементы полезны в объектной модели, но не обязательны.
"
Г. Буч, "Объекно-ориентированный анализ и проектирование"

← →
Игорь Шевченко © (2013-02-04 21:41) [18]

alexdn © (04.02.13 21:39) [16]

В цитатник! Автор, пиши еще!

← →
Игорь Шевченко © (2013-02-04 21:42) [19]

И еще одна цитата:

"ОО-языки упрощают абстракцию, возможно, даже слишком ее упрощают. Они поддерживают
создание структур с большим количеством связующего кода и сложными уровнями.
Это может оказаться полезным в случае, если предметная область является
действительно сложной и требует множества абстракций, и вместе с тем такой
подход может обернуться неприятностями, если программисты реализуют простые
вещи сложными способами, просто потому что им известны эти способы и они умеют
ими пользоваться.
Все ОО-языки несколько сколнны "втягивать" программистов в ловушку избыточной
иерархии. Чрезмерное количество уровней разрушает прозрачность: крайне
затрудняется их просмотр и анализ ментальной модели, которую по существу
реализует код. Всецело нарушаются правила простоты, ясности и прозрачности,
а в результате код наполняется скрытыми ошибкми и создает постоянные проблемы
при сопровождении.
Данная тенденция, вероятно, усугубляется тем, что множество курсов по
программированию преподают громоздкую иерархию как способ удовлетворения
правила представления. С этой точки зрения множество классов приравнивается
к внедрению знаний в данные. Проблема данного подхода заключается в том, что
слишком часто "развитые данные" в связующих уровнях фактически не относятся
у какому-либо естественному объекту в области действия программы -
они предназначены только для связующего уровня.
Одной из причин того, что ОО-языки преуспели в большинстве характерных для них
предметных областей (GUI-интерфейсы, моделирование, графические средства),
возможно, является то, что в этих областях относительно трудно неправильно
определить онтологию типов. Например, в GUI-интерфейсах и графических средствах
присутствует довольно естественное соотвествие между манипулируемыми
визуальными объектами и классами. Если выясняется, что создается большое
количество классов, которые не имеют очевидного соответствия с тем, что
происходит на экране, то, соотвественно, легко заметить, что связующий уровень
стал слишком большим."

Эрик Реймонд, "Искусство программирования для UNIX"

← →
Inovet © (2013-02-04 21:42) [20]

> [16] alexdn © (04.02.13 21:39)
> костыль, причём для виндовс..

Расшифруй постулат.

← →
Игорь Шевченко © (2013-02-04 21:43) [21]

Inovet © (04.02.13 21:42) [20]

Просим! Просим!

← →
alexdn © (2013-02-04 21:45) [22]

> Inovet © (04.02.13 21:42) [20]
> > [16] alexdn © (04.02.13 21:39)
> > костыль, причём для виндовс..
>
> Расшифруй постулат.
а что тут расшифровывать ооп: наследование, инкапсуляция, полиморфизм, а обьекты, это как правило что то относящееся к vcl

← →
antonn © (2013-02-04 21:47) [23]

> а что тут расшифровывать ооп: наследование, инкапсуляция,
> полиморфизм, а обьекты, это как правило что то относящееся
> к vcl

=)

← →
Inovet © (2013-02-04 21:48) [24]

> [22] alexdn © (04.02.13 21:45)
> а обьекты, это как правило что то относящееся к vcl

Т.е. ООП было придумано для создания VCL?

← →
alexdn © (2013-02-04 21:51) [25]

> Inovet © (04.02.13 21:48) [24]
нет конечно, но оно появилось примерно в конце турбопоскаля, как раз когда усложнилась работа с графикой, меню и всё прочее.

← →
alexdn © (2013-02-04 21:51) [26]

паскаля)

← →
Kerk © (2013-02-04 21:59) [27]

> Игорь Шевченко © (04.02.13 21:40) [17]
>
> Для объектно-ориентированного стиля концептуальная база
> - это объектная модель. Она имеет четыре главных элемента:
>
> - абстрагирование
> - инкапсуляция
> - модульность
> - иерархия
> Эти элементы являются главными в том смысле, что без любого
> из них модель не будет объектно-ориентированной. Кроме главных,
> имеются еще три дополнительных элемента:
> - типизация
> - параллелизм
> - сохраняемость
> Эти элементы полезны в объектной модели, но не обязательны.

А что из первых четырех не ФП? Разве что иерархия. Т.е. наследование. Мы знаем два вида наследования - наследование интерфейса и наследование реализации. Через наследование интерфейса в ООП реализуют полиморфизм, который в ФП цветет пышным цветом, а наследование реализации нам легко заменит аггрегрегация.

Я не совсем понял, что он имеет ввиду под параллелизмом и сохраняемостью.

В целом, объект в ООП - это типичный абстрактный тип данных, которые в ФП существуют испокон веков. Тем более что системы типов в ФП традиционно куда более мощные.

← →
Inovet © (2013-02-04 22:01) [28]

> [26] alexdn © (04.02.13 21:51)
> паскаля)

А Си++ тоже придумали, чтобы для Виндоус менюшки рисовать? Да и объектный турбопаскаль под ДОСом работал.

← →
Kerk © (2013-02-04 22:01) [29]

У alexdn тоже интересная версия, конечно.

← →
KilkennyCat © (2013-02-04 22:03) [30]

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

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

← →
KilkennyCat © (2013-02-04 22:05) [31]

> Inovet © (04.02.13 22:01) [28]
</I
С придумали из-за хеадеров в общем, и для меня в частности, чтобы мучался.

← →
antonn © (2013-02-04 22:06) [32]

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

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

← →
alexdn © (2013-02-04 22:14) [33]

> Игорь Шевченко © (04.02.13 21:42) [19]
> Одной из причин того, что ОО-языки преуспели в большинстве
> характерных для них
> предметных областей (GUI-интерфейсы, моделирование, графические
> средства),
вот примерно про это ж я и говорил.

← →
alexdn © (2013-02-04 22:17) [34]

Вообще Гейтс большим путаником был, его "Окна" грандиозная афера 20-го века..)

← →
брат Птибурдукова (2013-02-04 22:27) [35]

> alexdn © (04.02.13 21:45) [22]
тема взаимоотношения GD, GDI и VCL не раскрыта...

← →
Игорь Шевченко © (2013-02-04 22:30) [36]

Kerk © (04.02.13 21:59) [27]

Я ничего не знаю про ФП ;) Расскажи ?

← →
Inovet © (2013-02-04 22:34) [37]

> [35] брат Птибурдукова (04.02.13 22:27)
> тема взаимоотношения GD, GDI и VCL не раскрыта...

Это, видимо, вторая часть постулата, где про костыль.

← →
Игорь Шевченко © (2013-02-04 22:59) [38]

alexdn © (04.02.13 22:14) [33]

> вот примерно про это ж я и говорил.

То есть, один раз ты эту цитату уже видел ? :)

← →
знайка (2013-02-04 23:16) [39]

> Вообще Гейтс большим путаником был
уж был так был

← →
KilkennyCat © (2013-02-04 23:50) [40]

а копи-пасте некоторых кусков ассемблерного кода с последующими небольшими изменениями, это ООП?

← →
Плохиш © (2013-02-05 00:01) [41]

Прикольная ветка.

← →
Inovet © (2013-02-05 00:03) [42]

> [40] KilkennyCat © (04.02.13 23:50)

Это кусочно-адаптивное Пэ.

← →
Kerk © (2013-02-05 00:18) [43]

> Игорь Шевченко © (04.02.13 22:30) [36]
>
> Kerk © (04.02.13 21:59) [27]
>
> Я ничего не знаю про ФП ;) Расскажи ?

Ну это слишком общО как-то :)

Вот под рукой хороший пример на ML.
Объявляем полиморфный тип данных - дерево.

datatype ("a,"b) tree = Node of "a * ("a,"b) tree * ("a,"b) tree | Leaf of "b

Это дерево содержит в узлах значение типа "a, в "листьях" значение типа "b

Допустим, мы хотим объявить конкретное дерево с значением int в узлах и string в "листьях". Этот тип выглядит так:

(int, string) tree

Просто, да? Сколько строк займет подобное на ОО-языке? :)

А теперь, я допустим захочу вместо int хранить там record вот такой

datatype student_info = {name : string, surname : string, age : int}

Много ли для этого понадобится? Нет, тот же самый полиморфный тип:

(student_info, string) tree

А теперь у нас вдруг оказывается, что иногда вместо student_info нам удобнее хранить некий ID, но этот ID есть не у всех, так что у кого-то останутся строковые данные.

Что делаем? Пишем:

datatype student = StudentID of int | StudentStr of student_info

Символ "|" здесь можно условно воспринимать как "или", т.к. этот тип может содержать один из вариантов.

Ну и дерево соответственно начинает выглядеть так: (student, string) tree

Сколько строк понадобится на любом ОО-языке для подобного полиморфизма?

Как с такими типами работать? Очень просто. Тут нам на помощь приходит вся мощь паттерн-матчинга. Например:
fun someop (stud : student) = case stud of StudentID x => (* здесь x - это соответствующий ID *) | StudentStr x => (* а здесь - x = student_info *)
Ну вот как-то так, в двух словах.

← →
картман © (2013-02-05 00:52) [44]

> Просто, да? Сколько строк займет подобное на ОО-языке? :
> )

другой синтаксис, дженерики... а суть отличий в чем?

← →
Kerk © (2013-02-05 00:56) [45]

> картман © (05.02.13 00:52) [44]
> другой синтаксис, дженерики...

Ну во-первых, во многих ОО-языках дженериков тупо нету. До сих пор :)
А в большинстве они появились только недавно, в последние годы.

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

> а суть отличий в чем?

В том же, о чем в топике речь. Все суперизобретения ООП в ФП есть уже лет 50 :)

← →
картман © (2013-02-05 01:02) [46]

> Все суперизобретения ООП в ФП есть уже лет 50 :)

полностью согласен.
Да и большинство "новых"-технологий/методов и т.д. тоже оттуда.

Мне вообще непонятно, в чем отличие функционального программирования от объектного - кроме, разве что, в ОО данные и действия в одном месте. Других - принципиальных - найти не могу.

← →
Kerk © (2013-02-05 01:13) [47]

> кроме, разве что, в ОО данные и действия в одном месте.

Причем в ФП и это можно организовать с помощью замыканий.
Т.е. технических препятствий никаких, скорее вопрос в традиции.

← →
KSergey © (2013-02-05 09:09) [48]

> Kerk © (05.02.13 00:18) [43]

Т.е. приведенный кусок - это ФП?
Ну тогда отличий и в самом деле нет.

← →
Игорь Шевченко © (2013-02-05 10:32) [49]

Kerk © (05.02.13 00:18) [43]

Насколько я читаю определение:

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

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

← →
Anatoly Podgoretsky © (2013-02-05 10:38) [50]

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

Индусы и китайцы основа ООП

← →
jack128 © (2013-02-05 10:49) [51]

> "Объектно-ориентированное программирование - это методология
> программирования, основанная на представлении программы
> в виде совокупности объектов, каждый из которых является
> экземпляром определенного класса, а классы образуют иерархию
> наследования.

то есть языки со структурной и динамической типизацией не могут быть ОО-языками?

← →
Игорь Шевченко © (2013-02-05 10:53) [52]

jack128 © (05.02.13 10:49) [51]

че ?

← →
Kerk © (2013-02-05 11:18) [53]

> Игорь Шевченко © (05.02.13 10:32) [49]

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

Ну да. Иммутабельность данных, отсутствие побочных эффектов. Правда, точнее - стремление к этому.

Но я напомню о чем ветка. Автор утверждает, что на заре было ФП и была императивщина. И ООП придумали, чтоб приблизить императивщину к ФП по выразительным средствам. И действительно - убери из ООП то, что позаимствовано из ФП, непонятно что в итоге останется :)

← →
Kerk © (2013-02-05 11:24) [54]

Я тут на досуге соорудил некое подобие объекта на ФП. Тип данных, который содержит в себе и данные и методы их обработки. Инкапсуляция во весь рост, к внутренним данным ни у кого доступа нет.

datatype set = Set of { add : int -> set, exists : int -> bool, count : unit -> int } fun empty_set () : set = let fun prepare init = let val xs = init fun f_add x = prepare (x::xs) fun f_exists x = List.exists (fn (a) => a=x) xs fun f_count () = List.length xs in Set {add = f_add, exists = f_exists, count = f_count} end in prepare [] end fun e (s : set) = case s of Set x => x

Тип set содержащий в себе числа и имеющий три метода: add, count и exists.

Применять примерно так:

- val a1 = empty_set(); val a1 = Set {add=fn,count=fn,exists=fn} : set - (#count (e a1))(); val it = 0 : int - val a1 = (#add (e a1))(13); val a1 = Set {add=fn,count=fn,exists=fn} : set - (#count (e a1))(); val it = 1 : int - val a1 = (#add (e a1))(42); val a1 = Set {add=fn,count=fn,exists=fn} : set - (#exists (e a1))(13); val it = true : bool

Жирным мой код, за ним ответ интерпретатора.
Ну и прошу делать скидку на мою криворукость, кто-то может быть элегантнее бы смог :)

← →
Ega23 © (2013-02-05 11:24) [55]

> чтоб приблизить императивщину к ФП по выразительным средствам

Спорный вопрос. Биение на абстракции (а ООП, по сути, это и есть) оно хорошо само по себе, вне зависимости от своей реализации "в кишках".

← →
Kerk © (2013-02-05 11:27) [56]

Форум съел табы :)
Вот тут нормальная версия http://yankovsky.me/sets.txt

← →
Kerk © (2013-02-05 11:28) [57]

> Ega23 © (05.02.13 11:24) [55]
>
> > чтоб приблизить императивщину к ФП по выразительным средствам
>
> Спорный вопрос. Биение на абстракции (а ООП, по сути, это
> и есть)

Биение на абстракции было и до ООП и после него будет.

← →
Игорь Шевченко © (2013-02-05 11:37) [58]

Kerk © (05.02.13 11:18) [53]

> Но я напомню о чем ветка. Автор утверждает, что на заре
> было ФП и была императивщина. И ООП придумали, чтоб приблизить
> императивщину к ФП по выразительным средствам. И действительно
> - убери из ООП то, что позаимствовано из ФП, непонятно что
> в итоге останется :)

Мне кажется, автор преувеличивает относительно заимствования.

← →
Ega23 © (2013-02-05 11:50) [59]

> Биение на абстракции было и до ООП и после него будет.

Там оно как-то нагляднее, что ли? ИМХО.

← →
Компромисс1 (2013-02-05 14:13) [60]

Насколько я помню Lisp, ФП предполагает работу на очень высоком уровне, когда нас интересует только результат и не особо интересует реализация, то есть как именно этот результат был достигнут. Уровень черного ящика.
Мы вызываем какой-нибудь CDR с параметрами и нам наплевать, как эти параметры представлены внутри List машины и как эта CDR их собственно обрабатывает.
Это близко к какому-нибудь SQL с его SELECT, которому тоже наплевать, как хранятся таблицы, строки и колонки, как происходят JOIN и пр. Тоже черный ящик.
Конечно, было невозможно использовать чисто процедурные императивные языки на таком высоком уровне, программисты вынуждены были работать на уровне переменных типа int и char[]. Библиотечные функции типа calculateAverage(int[]) явно недостаточны, потому что кто-то все равно должен был инициализировать/передавать параметры, то есть у нас множество серых ящиков вместо одного черного. Поэтому придумали ООП, которое позволяет легко создавать черные ящики любого уровня сложности.

← →
clickmaker © (2013-02-05 14:55) [61]

> А ООП - это просто костыль

А почему костыль-то? Ну, обертка - это еще куда ни шло... Но костыль - это нечто (иногда сколоченное на скорую руку), что не позволяет слишком распухшей и трудной для обозрения одним взглядом конструкции не упасть в самый кульминационный момент... Причем тут ООП вообще?..

← →
Медвежонок Пятачок © (2013-02-05 15:28) [62]

если ооп это костыль, то что же тогда есть процедурный подход?

а вообще тема ветки - для задротов.

← →
sniknik © (2013-02-05 16:07) [63]

> Но костыль - это нечто ...
что при должном развитии становится протезом. :)

← →
Kerk © (2013-02-05 16:13) [64]

> Компромисс1 (05.02.13 14:13) [60]

Ну вот как-то так, да. Если эмоции отбросить. По сути эволюция императивных языков - это попытка наверстать первоначальный отказ от высокоуровневости.

← →
Компромисс1 (2013-02-05 16:56) [65]

Kerk © (05.02.13 16:13) [64]

Насколько я знаю, сперва появились низкоуровневые языки: машкоды, затем ассемблер. Только потом появились функциональные языки, а также императивные языки более высокого уровня, чем ассемблер, но более низкого, чем какой-нибудь C#. Так что не было никакого отказа от высокоуровневости. Просто функциональные языки сперва обогнали императивные, а теперь императивные их догоняют. Функциональные вообще обогнали время, появившись слишком рано, - как можно не заботиться о способе реализации, если памяти 16кб и процессор соответствующий (даже не помню, можно ли говорить тут о сотнях тысяч операций в секунду)...

← →
Kerk © (2013-02-05 17:01) [66]

> Компромисс1 (05.02.13 16:56) [65]

Это понятно что сначала машкоды появились. Но вообще почва под ФП закладывалась еще до появления компьютера. Лямбда-исчисление Чёрч еще в 30х придумал.

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

> Функциональные вообще обогнали время, появившись слишком рано

В точку.

← →
KilkennyCat © (2013-02-05 17:09) [67]

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

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

4-я страница идет, какие-нибудь предложения к действиям уже есть? а то у меня есть тушь, перья и большой кусок картона.

← →
Игорь Шевченко © (2013-02-05 18:14) [68]

Kerk © (05.02.13 17:01) [66]

> любой функциональный язык "выше", чем С с Паскалем

Не совсем понял, в чем высота меряется ? В количестве строк кода для выражения алгоритма ? Тогда не уверен

> не говоря уже о фортранах и алголах.

Ты один от другого-то отличаешь ? :)

← →
Kerk © (2013-02-05 18:23) [69]

> Игорь Шевченко © (05.02.13 18:14) [68]

> Не совсем понял, в чем высота меряется ? В количестве строк
> кода для выражения алгоритма ? Тогда не уверен

Ну вот Algol 68, Fortran, виртовский Паскаль и ML появились в рамках одной пятилетки. Угадай, в каком из этих языков полиморфная система типов? :)

LISP так вообще динозавр. Не уверен, что вообще были какие-то другие языки высокого уровня в 1958 году.

> Ты один от другого-то отличаешь ? :)

Я на них не писал, врать не буду. Но примеры кода видел, так что наверно отличу :)

← →
Павиа (2013-02-05 18:28) [70]

Вначале появился язык математики. Он был функциональным потом появилась польская натация после первый калькулятор. После машкоды и ассемблер. затем фортран. Фортран был императивным. После уже появляется ООП.

Да в ООП в качестве входных данных выступает объект без конкретизации его части. Что облегчает труд программиста. Но делает программу слабо предсказуемой. (Похо сформулировал)

← →
Kerk © (2013-02-05 18:36) [71]

> Ну вот Algol 68, Fortran, виртовский Паскаль и ML появились
> в рамках одной пятилетки. Угадай, в каком из этих языков
> полиморфная система типов? :)

Ах, да... и сборщик мусора, конечно же.

← →
Kerk © (2013-02-05 18:38) [72]

> Не уверен, что вообще были какие-то другие языки высокого
> уровня в 1958 году.

А, Фортран таки был, чОрт. Ошибся с его датировкой. Его честнее с LISP сравнивать. Но это мало что меняет.

← →
Игорь Шевченко © (2013-02-05 18:42) [73]

Kerk © (05.02.13 18:23) [69]

> Ну вот Algol 68, Fortran, виртовский Паскаль и ML появились
> в рамках одной пятилетки. Угадай, в каком из этих языков
> полиморфная система типов? :)

Угадай, в каких задачах в то время она была востребована ? Правильно :)

Фортран и Алгол появились слегка раньше, если что...

← →
Игорь Шевченко © (2013-02-05 18:46) [74]

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

Кстати, в Фортране сборщика мусора не было, потому что там не было мусора :)

← →
Kerk © (2013-02-05 18:59) [75]

> Игорь Шевченко © (05.02.13 18:42) [73]

> Угадай, в каких задачах в то время она была востребована ? Правильно :)

Ну да. Именно поэтому все то же самое начали прибивать гвоздями к наследникам Алгола и Фортрана через 40 лет. Зелен виноград :)

> Фортран и Алгол появились слегка раньше, если что...

По Фортрану я уже исправился, но насколько я понимаю, он на фоне LISP не сильно лучше смотрится, чем на фоне ML. А Алгол вроде как раз попадает в рамки одной пятилетки, как я и сказал. Это очень маленькая разница. В Делфи юникод дольше внедряли :)

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

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

← →
Игорь Шевченко © (2013-02-05 19:04) [76]

Kerk © (05.02.13 18:59) [75]

> Алгол вроде как раз попадает в рамки одной пятилетки, как
> я и сказал

Алгол разработан в 1958 году

> Именно поэтому все то же самое начали прибивать гвоздями
> к наследникам Алгола и Фортрана через 40 лет. Зелен виноград
> :)

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

Тебя не удивляет тот факт, что функциональные языки стали на слуху сравнительно недавно ? (За исключением LISP, разумеется)

Наверное это ж-ж-ж неспроста.

← →
Kerk © (2013-02-05 19:13) [77]

> Игорь Шевченко © (05.02.13 19:04) [76]

> Тебя не удивляет тот факт, что функциональные языки стали
> на слуху сравнительно недавно ? (За исключением LISP, разумеется)

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

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

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

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

← →
alexdn © (2013-02-05 19:14) [78]

> Игорь Шевченко © (05.02.13 19:04) [76]
> Наверное это ж-ж-ж неспроста.
наверное ооп исчерпалось?

← →
Игорь Шевченко © (2013-02-05 19:19) [79]

Kerk © (05.02.13 19:13) [77]

> Так вот давайте поймем что же такое ООП и чем оно радикально
> отличается от других парадигм?

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

Этим на мой взгляд они и отличаются.

← →
alexdn © (2013-02-05 19:19) [80]

> Kerk © (05.02.13 19:13) [77]
У меня как то дебильная идея родилась.. а что если б языки были не обьектно ориентированные, а событийно ориентированные? Хотя это тоже всё танцы с бубном вокруг ФП и ооп. Т.е. чтобы событие не привязывалось к обьекту. Эдакий язык из хуков..

← →
Kerk © (2013-02-05 19:21) [81]

> alexdn © (05.02.13 19:19) [80]

http://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D0%B9%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

← →
Игорь Шевченко © (2013-02-05 19:22) [82]

alexdn © (05.02.13 19:14) [78]

Пиши еще, ждем с нетерпением!

← →
alexdn © (2013-02-05 19:26) [83]

> Kerk © (05.02.13 19:21) [81]
Разные языки программирования поддерживают СОП в разной степени. Наиболее полной поддержкой событий обладают следующие языки (неполный список):
Это оттуда, но хотелось бы как то в более чистом виде..

> Игорь Шевченко © (05.02.13 19:22) [82]
> Пиши еще, ждем с нетерпением!
вот, пишу...

← →
alexdn © (2013-02-05 19:28) [84]

> Kerk © (05.02.13 19:21) [81]
Что то мне кажется что ява ближе всего к этому..

← →
alexdn © (2013-02-05 19:43) [85]

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

← →
Kerk © (2013-02-05 19:45) [86]

> Игорь Шевченко © (05.02.13 19:19) [79]
>
> > Kerk © (05.02.13 19:13) [77]
>
> Тем, что программа представляется в виде совокупности взаимодействующих
> друг с другом объектов, а не в виде последовательности действий
> над состояниями, как в процедурном программировании. Так
> же, как в ФП программа рассматривается как вычисление результатов
> функций от результатов функций от результатов функций от
> исходных данных.
>
> Этим на мой взгляд они и отличаются.

Т.е. они отличаются подходами к проектированию?

← →
alexdn © (2013-02-05 19:50) [87]

Эврика! я жду событие tEvent на равне с tObject..!

← →
Anatoly Podgoretsky © (2013-02-05 20:01) [88]

> Kerk (05.02.2013 19:13:17) [77]

За что и получил ледорубом по башке

← →
Kerk © (2013-02-05 20:14) [89]

Позволю себе высказать такую мысль: ООП - это химера. Нет ООП, есть OOD (design) и есть языки помогающие выразить эти идеи декларативно.

← →
Игорь Шевченко © (2013-02-05 20:38) [90]

Kerk © (05.02.13 20:14) [89]

> Нет ООП, есть OOD (design) и есть языки помогающие выразить
> эти идеи декларативно

ООП существует наряду с ООД и ООА.

> Т.е. они отличаются подходами к проектированию?

Они отличаются парадигмами.

← →
alexdn © (2013-02-05 20:45) [91]

> Kerk © (05.02.13 20:14) [89]
Нет, наверно ООП таки есть, а вот то, что ООП стало ассоциироваться с VCL вот это уже плохо.. Хотя конечно вышеуказанных рассуждений о ФП это не отменяет...

← →
Kerk © (2013-02-05 21:04) [92]

> Игорь Шевченко © (05.02.13 20:38) [90]

А что делать с неимперативными ОО-языками. Вот возьмем Erlang. Там объекты взаимодействуют через сообщения прямо как в этом вашем SmallTalk-е, но при этом иммутабельность, даже оператора присваивания нет. В Delphi же, например, не только оператор присваивания есть, так еще и объекты общаются не через сообщения.

Почему-то если ОО-языки в кучку собрать, то дикий зоопарк получится, который непонятно что объединяет. Слышал даже, что в более-менее свежих инкарнациях LISP объекты есть.

Объект - это просто такое семантическое понятие. Мы же не будем вокруг того, что некоторые языки поддерживают дженерики строить новую парадигму программирования.

А вот на [91] мне даже возразить нечего.

← →
Игорь Шевченко © (2013-02-05 21:15) [93]

Kerk © (05.02.13 21:04) [92]

> В Delphi же, например, не только оператор присваивания есть,
> так еще и объекты общаются не через сообщения.

В Delphi, С++, Java, C# роль сообщений выполняют вызовы методов. Сообщения - это термин. Можно назвать контрактом, протоколом, горшком, от этого суть взаимодействия объектов между собой не изменится.

> Объект - это просто такое семантическое понятие

Функция в ФП не менее семантическое понятие, не так ли ?

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

> А вот на [91] мне даже возразить нечего.

[91] надо просто читать. С благоговением :)

← →
Игорь Шевченко © (2013-02-05 21:16) [94]

Кстати:

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

http://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%B8%D0%B3%D0%BC%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F

← →
Ega23 © (2013-02-05 22:12) [95]

> Эврика! я жду событие tEvent на равне с tObject..!

TNotifyEvent + F1

← →
Ega23 © (2013-02-05 22:14) [96]

> Позволю себе высказать такую мысль: ООП - это химера. Нет
> ООП, есть OOD (design) и есть языки помогающие выразить
> эти идеи декларативно.

Есть в этой идее какое-то благородное безумие. Можно даже согласиться.

← →
Kerk © (2013-02-05 22:33) [97]

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

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

Но в целом, это действительно близко к правде. Речь ведь вроде как раз об этом. ООП пришлось придумывать, чтобы приблизить выразительные средства императивных языки к функциональным. А выразительные средства ФП функциями не ограничиваются. Даже если взять отдельно функции, то в ФП они - "first-class citizen". С ними можно работать как с другими данными, передавать в качестве параметров, объявлять лямбда-функции и т.п. - это все (некоторые) императивные языки обретали с течением времени, намного позже.

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

Есть такое. В тупик зашли по-моему.

← →
Игорь Шевченко © (2013-02-05 22:46) [98]

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

Со всем, кроме этой фразы, согласен.

← →
oxffff © (2013-02-05 22:53) [99]

:)

http://newstar.rinet.ru/~goga/tapl/tapl023.html
http://newstar.rinet.ru/~goga/tapl/

http://agp.hx0.ru/oop/TvsC.pdf

← →
oxffff © (2013-02-05 22:56) [100]

Насколько помню объектное исчисление можно смоделировать в рамках лямбда и наоборот.

← →
oxffff © (2013-02-05 23:02) [101]

Всю ветку не читал, но скорее всего ответы в главе 18 tapl.

← →
Kerk © (2013-02-05 23:09) [102]

> oxffff © (05.02.13 22:56) [100]
>
> Насколько помню объектное исчисление можно смоделировать
> в рамках лямбда и наоборот.

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

← →
Компромисс1 (2013-02-06 10:45) [103]

> Позволю себе высказать такую мысль: ООП - это химера. Нет
> ООП, есть OOD (design) и есть языки помогающие выразить
> эти идеи декларативно.
>

ООП - это парадигма программирования, в которой основными концепциями являются понятия объектов и классов (http://ru.wikipedia.org/wiki/Объектно-ориентированное_программирование).
Парадигма прогррамирования - это это система идей и понятий, определяющих стиль написания компьютерных программ (http://ru.wikipedia.org/wiki/Парадигма_программирования).
Так существует ли ООП, если ООП - это система идей и понятий, определяющих стиль написания компьютерных программ, причем в этой системе основными концепциями являются понятия объектов и классов?
Конечно, существует.

← →
Компромисс1 (2013-02-06 10:49) [104]

Можно и в Java писать как на Фортране, кстати, все в одном классе и все методы static.
Используемый язык не всегда определяет используемый тип программирования, даже в императивных языках.

← →
xayam © (2013-02-06 12:57) [105]

> картман © (05.02.13 01:02) [46]
> в чем отличие функционального программирования от объектного

чем отличается движение от того, что движется ?

← →
Kerk © (2013-02-08 19:11) [106]

Я тут вот что нашел :)

Статья "Обобщенное программирование" русская википедия:
Возможности обобщённого программирования впервые появились в 1970-х годах в языках Клу и Ада

Английская википедия "Generic programming":
This approach, pioneered by ML in 1973

Хаха, не императивщина - значит не было :)

P.S. Ссылки не даю, они тут уродливо выглядят.

← →
Mystic © (2013-02-08 20:03) [107]

А ты пробовал что-то писать на ФП? Отсутствие изменяемых переменных, как для меня, жестковатое ограничение...

Далее, многие операции над списками можно представить при помощи задания пяти функций. Это хинт. А теперь помедитируй на этот код (Haskell):

module Templates (lstLength, lstSumm, lstProduct, lstReverse, lstMap) where lstTemplate :: ([a] -> b) -> (c -> d -> b) -> (e -> c) -> (b -> d) -> ([e] -> [e]) -> [e] -> b lstTemplate f1 _ _ _ _ [] = f1 [] lstTemplate f1 f2 f3 f4 f5 (x:xs) = f2 (f3 x) (f4 (lstTemplate f1 f2 f3 f4 f5 (f5 xs))) lstConstant :: a -> b -> a lstConstant n _ = n lstId :: a -> a lstId any = any lstSwap :: (a -> b -> c) -> b -> a -> c lstSwap op x y = op y x lstList :: a -> [a] lstList x = [x] lstLength :: [a] -> Integer lstLength = lstTemplate (lstConstant 0) (+) (lstConstant 1) lstId lstId lstSumm :: [Integer] -> Integer lstSumm = lstTemplate (lstConstant 0) (+) lstId lstId lstId lstProduct :: [Integer] -> Integer lstProduct = lstTemplate (lstConstant 1) (*) lstId lstId lstId lstReverse :: [a] -> [a] lstReverse = lstTemplate lstId (lstSwap (++)) lstList lstId lstId lstMap :: (a -> b) -> [a] -> [b] lstMap f = lstTemplate lstId (:) f lstId lstId

Да, я разобрался, как это работает. Но это не просто и понятно.

← →
Kerk © (2013-02-08 20:31) [108]

Писал на ФП, но не много.

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

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

Как бы не хотелось обратного, в ФП все-равно приходится иметь дело с изменяемым состоянием. Приходят в итоге к жесткому разделению изменяемых и неизменяемых данных. Приходят по-разному. В ML есть возможность объявить тип изменяемым, в хаскелле придумали монады.

В целом, по-моему, дело привычки.

← →
Kerk © (2013-02-08 20:49) [109]

Я могу то же самое переписать намного понятнее без всяких f1 f2 f3 f4 f5. Правда на ML, мне так проще.

← →
tesseract © (2013-02-08 20:53) [110]

> Да, я разобрался, как это работает. Но это не просто и понятно.

Товарищи теоретики - а вы пробовали ентот код сопровождать?

← →
Kerk © (2013-02-08 21:00) [111]

> tesseract © (08.02.13 20:53) [110]
>
> > Да, я разобрался, как это работает. Но это не просто и понятно.
>
> Товарищи теоретики - а вы пробовали ентот код сопровождать?

Есть у меня ощущение, что этот код писался исключительно для демонстрации идеи "операции над списками можно представить при помощи задания пяти функций".

И, кстати, ты думаешь нельзя накопипастить сюда плохо читаемого кода на делфи? :)

> И, кстати, ты думаешь нельзя накопипастить сюда плохо читаемого
> кода на делфи? :)

Ромыч я производством занимаюсь. И у нас расчетчик себестоимости с Харькова - я блин такого ТЗ и кода начитался, что знаю методов казни больше Торквемады :-)

Ну вот я даже не поленился переписать те же самые функции (сделаем вид, что в стандартной библиотеке ни одной из них нет :)

Записал в одну строку, т.к. все равно форум форматирование съест, да и короткие они.

fun lstLength xs = case xs of [] => 0 | x::xs" => 1 + lstLength xs"; fun lstSum xs = case xs of [] => 0 | x::xs" => x + lstSum xs"; fun lstProduct xs = case xs of [] => 1| x::xs" => x * lstProduct xs"; fun lstReverse xs = case xs of [] => [] | x::xs" => lstReverse(xs") @ [x]; fun lstMap f xs = case xs of [] => [] | x::xs => (f x) :: (lstMap f xs);

> Игорь Шевченко © (08.02.13 23:12) [114]

Дело привычки :)
Да, и я боюсь, Паскаль о функцию lstMap споткнется. Дженерики понадобятся :)

Kerk © (08.02.13 23:16) [115]

> Дело привычки :)

APL тоже дело привычки. Ну и клавиатуры специальной. Я к чему - может, потому языки не получили такого распространения, как императивные, что много неестественных сочетаний символов запоминать надо ? :)

> Компромисс1 (06.02.13 10:45) [103]
> ООП - это парадигма программирования, в которой основными
> концепциями являются понятия объектов и классов (http://ru.
> wikipedia.org/wiki/Объектно-ориентированное_программирование).
>
> Парадигма прогррамирования - это это система идей и понятий,
> определяющих стиль написания компьютерных программ (http:
> //ru.wikipedia.org/wiki/Парадигма_программирования).
> Так существует ли ООП, если ООП - это система идей и понятий,
> определяющих стиль написания компьютерных программ, причем
> в этой системе основными концепциями являются понятия объектов
> и классов?
> Конечно, существует.

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

"Вы, сударь, ерунду говорите. И хуже всего то, что говорите безапеляционно и уверенно"

> Игорь Шевченко © (08.02.13 23:19) [116]

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

Да, забыл добавить ИМХО, каюсь :)

Kerk © (08.02.13 23:33) [119]

Жалко, у меня Пратт ушел в страну вечной охоты - я бы его процитировал.
(Пока искал, смотрю, у книги уже 4-ое издание, надо бы купить, там даже про ML есть:
http://www.ozon.ru/context/detail/id/1158230/ )

Вот она, какая у меня была
http://www.umup.narod.ru/1021_1.html

про Снобол сейчас кто-нибудь помнит, интересно ?

Да, списочек языков там реально тру-олдскул :)

Среди языков открытием последних дней для меня стал Datalog. Очень интересно выглядит.

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

Удалено модератором

> Jeer © (09.02.13 00:04) [124]
> Ну да.. я однажды, давно уж, о Питоне услышал, вогнал себя
> туда - после Perl это было более чем занятно. И понял, что
> садомазохизм, известный мне по очень старым книжкам, меркнет
> перед этим Явлением.

Однако ж достаточно большое количество современных онлайн игр написано на питоне. EVE-Online как пример этому (кстати самая известная космическая одиссея, можно сказать) :)

Вот претензии к Питону неплохо бы обосновать, да :)

Удалено модератором
Примечание: Выражения выбираем

> Вот претензии к Питону неплохо бы обосновать, да :)

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

Вообще интересно. Чем больше читаю по ФП, тем больше кажется, что в ближайшее время они станут мейнстримом. Через вещи вроде linq и лямбда-функций они становятся не такими уж чужими для среднего программера.
F# вообще хоть сейчас можно использовать в реальной жизни. Сейчас выбираем javascript библиотеку и я случайно наткнулся на http://websharper.com. Заговорил о нем с коллегами и выяснилось, что один как раз проходит курс по функциональным языкам на Coursera.

> Чем больше читаю по ФП, тем больше кажется, что в ближайшее
> время они станут мейнстримом

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

> F# вообще хоть сейчас можно использовать в реальной жизни

LISP с 1958 года можно использовать в реальной жизни. Более того, он используется. Но мэйнстримом не стал.

> Игорь Шевченко © (11.02.13 00:11) [131]
>
>
> > Чем больше читаю по ФП, тем больше кажется, что в ближайшее
> > время они станут мейнстримом
>
>
> Как раньше в ближайшее время не стало, так и сейчас не станет.
> Мне кажется. Каждая парадигма имеет свою нишу.

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

> LISP с 1958 года можно использовать в реальной жизни. Более
> того, он используется. Но мэйнстримом не стал.

Я к тому, что F# можно легко использовать с MS продуктами, а это все же сильно снижает порог вхождения. Т.е. я могу его прямо сейчас начать использовать в текущем проекте, который под .Net. Все же это намного проще, чем ставить новую среду, изучать новые библиотеки, привыкать к новой экосистеме.

> Игорь Шевченко © (08.02.13 23:48) [122]
> Вот она, какая у меня былаhttp://www.umup.narod.ru/1021_1.
> html

И у меня эта книга встретилась в самом начале и оказала немаленькое влияние на формирование соответствующих взглядов.
Кто-то у меня её свиснул :(

По поводу удобности забавное мнение :)

Хватит уже спорить о юзабильности или не юзабильности языков. Тот факт, что javascript является одним из самых используемых языков программирования, как бы намекает нам на то, что не юзабельных языков не бывает, бывает мало карго-культа и недостаточно хипстеров. Я серьезно, возьмите haskell, ocaml, lisp, любую бесовщину возьмите. Взяв, монополизируйте бесовщину в отдельно взятом секторе, киньте туда хипстеров, стартаперов и добавьте модных словечек {scalability, big data, high load, lean startup} по вкусу.

http://juick.com/dk/2217232

← →
знайка (2013-02-11 17:25) [135]

javascript-у альтернативы нет, по большому счету, как бы тоже намекает. :)

> Ну вот я даже не поленился переписать те же самые функции
> (сделаем вид, что в стандартной библиотеке ни одной из них
> нет :)

Как бы не в духе ФП. Не видно никакой разницы с обычными языками. Демонстрация встроенных средств работы со списками, на более. Ну чуть меньше писанины, но это не такой уж и большой плюс.

Второй аспект в том, что если это возможно, то кто-то это будет использовать. А значит разбираться с этим придется.

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

А идея ФП состоит в том, что...

lstLength :: [a] -> Integer lstLength [] = 0 lstLength x:xs = 1 + lstLength xs lstSumm :: [Integer] -> Integer lstSumm [] = 0 lstSumm x:xs = x + lstSumm xs lstProd :: [Integer] -> Integer lstProd [] = 1 lstProd x:xs = x * lstProd xs

Мы видим, что эти три функции имеют общую структуру. По сути, нам надо три функции:

lstGeneric [] = f1 -- Результат обработки пустого списка
lstGenetic x:xs = f3 f2 x xs

И теперь для lstLength у нас f1=0, f2=1, f3=сложение. Для lstProd у нас f1=1, f2=x, f3=произведение.

Но чем дальше по этому пути продвигаться, тем больше болит голова.

> Mystic © (12.02.13 15:50) [136]
> Как бы не в духе ФП.

С чего бы?

> А идея ФП состоит в том, что...

Это не идея ФП, это твоя идея. Нечто подобное можно и в Delphi соорудить.

> Второй аспект в том, что если это возможно, то кто-то это
> будет использовать. А значит разбираться с этим придется.

В этом коде нет ничего, что было бы недоступно в современных мейнстримных языках. Разве что синтаксис непривычный.

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

Если уж говорить про дух ФП, то функция "посчитать произведение элементов" в реальной жизни выглядела бы примерно так:

fun xs = List.foldl (fn (x, acc) => x+acc) 1 xs

Тут и функция высшего порядка и анонимная функция и в целом достаточно общЕ.

Имя функции забыл, но не суть

fun lstProd xs = List.foldl (fn (x, acc) => x+acc) 1 xs

Или даже так, выкинем параметр. Сделаем partial application, чтоб еще больше ФП :)

val lstProd = List.foldl (fn (x, acc) => x+acc) 1;

Да елки-палки. Там не +, а * конечно же. Умножаем же.
Сорри за такое количество сообщений подряд.

если мы говорим про ФП, то операторы там должны быть обычными функциями, так что нуно так писать

val product = List.fold (*) 1

← →
Вариант (2013-02-13 09:50) [143]

> Mystic © (12.02.13 15:50) [136]

> Как бы не в духе ФП. Не видно никакой разницы с обычными
> языками

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

Все вполне в духе. Функция определяет себя через себя саму же.
Могу привести исходники этих функций на эрланге из модуля lists , весьма похоже на функции Керка, с той разницей, что в эрланге сделано с хвостовой рекурсией ну и да, там принято выносить работу с пустым списком в отдельное определение, что не является на мой взгляд принципиальным. А так написано весьма понятно для читающего код, то есть требуется более низкий уровень вхождения, чем для вашего примера. Если писать проще и понятней, то голова болеть не будет:-) Конечно ко всему сказанному добавлю ИМХО.....

> jack128 © (13.02.13 09:11) [142]

Точно, так еще проще, как-то я сходу не сообразил :)

В синтаксисе SML это будет выглядеть так:
val product = List.foldl op* 1;

> val product = List.foldl op* 1;

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

Еще для затравки: что тут делается понятно из названия. Вроде и код понятен. А вот повторить его в похожей задаче уже напряг.

randomQsort :: (Ord a) => [a] -> IO [a] randomQsort [] = return ([]) randomQsort xs = do pos <- getStdRandom (randomR (0, -1 + length xs)) let op = xs !! pos left <- randomQsort (filter (< op) xs) right <- randomQsort (filter (> op) xs) return (left ++ (filter (== op) xs) ++ right)

Т.е. твоя критика заключается в том, что это не то, к чему ты привык?

← →
Вариант (2013-02-13 15:09) [147]

> Mystic © (13.02.13 14:29) [145]

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

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

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

sort([Pivot|T]) ->
sort([ X || X <- T, X < Pivot]) ++
[Pivot] ++
sort([ X || X <- T, X >= Pivot]);
sort([]) -> [].

← →
Вариант (2013-02-13 15:24) [148]

> Mystic © (13.02.13 14:29) [145]

Кстати таки и сам неправильно написал, ибо синтаксис не знаю,

> правда без случайного деления на части списка

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

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

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

Аналогичный пример все-таки имеет сложность O(N^2) для случая отсортированных (или почти отсортированных) списков.

И мы ничего не говорили про расход памяти. А это тоже важный момент, попробуй при помощи своего sort отсортировать массив целых чисел от 1_000_000 до 1? Засемь время и сравнить с Ц++? Решение без дополнительного выделения памяти на Haskell, конечно, возможно. Можно наслаждаться оптимизированных чистым Haskell-кодом:

import Control.Monad import Data.Array.IO import Data.IORef qsort :: IOUArray Int Int -> Int -> Int -> IO () qsort a lo hi = do let z :: IO (IORef Int) z = newIORef 0 (.=) = writeIORef ref .=. action = do v <- action; ref .= v (!) = readArray (.!) a ref = readArray a =<< get ref get = readIORef (.<) = liftM2 (<) (.>) = liftM2 (>) (.<=) = liftM2 (<=) (.>=) = liftM2 (>=) (.&&) = liftM2 (&&) (h,l,p,t) <- liftM4 (,,,) z z z z when (lo < hi) $ do l .= lo h .= hi p .=. (a!hi) doWhile (get l .< get h) $ do while ((get l .< get h) .&& ((a.!l) .<= get p)) $ do modifyIORef l succ while ((get h .> get l) .&& ((a.!h) .>= get p)) $ do modifyIORef h pred b <- get l .< get h when b $ do t .=. (a.!l) lVal <- get l hVal <- get h writeArray a lVal =<< a!hVal writeArray a hVal =<< get t lVal <- get l writeArray a hi =<< a!lVal writeArray a lVal =<< get p hi" <- fmap pred (get l) qsort a lo hi" lo" <- fmap succ (get l) qsort a lo" hi where doWhile cond foo = do foo b <- cond when b $ doWhile cond foo while cond foo = do b <- cond when b $ foo >> while cond foo main = do a <- (newListArray (0,9) [10,9..1]) :: IO (IOUArray Int Int) printArr a putStrLn "Sorting..." qsort a 0 9 putStrLn "Sorted." printArr a where printArr a = mapM_ (\x -> print =<< readArray a x) [0..9]

(отсюда)
http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort

← →
Вариант (2013-02-14 07:07) [150]

> Mystic © (13.02.13 22:20) [149]

Сравнивать с Ц++ не буду, ибо плюс эрланга не могучем быстродействии. Тут он заведомо проиграет. И да, для меня расход памяти НЕ важный момент, ибо пишу не для PIC или ATMEL, да и нет дико большого расхода памяти в моих задачах. SQL Server больше у нас жрет и все равно память только на 1/4 задействована. Слышал что хаскель и F# могут примерно поспорить по скорости с Ц++, но считаю, что плюс функциональных языков не в скорости выполнения вычислений, а в другом. Выразительности, краткости и т.п. Если они экономят память и скорость у них приличная- ради бога, если нет, главное что бы все было в разумных рамках.
Естественно считаю, что краткость не должна быть в ущерб читаемости кода. У ФП свои фишки. Тут весь вопрос стоит в том - а нужны ли тебе эти фишки, а нужна ли тебе скорость и небольшая память, можно ли найти баланс между всеми твоими хотелками. Мне например просто удобно работать не думая о памяти, мне очень нравится паттерн матчинг, мне нравится и list comprehension, хотя вот им почти не пользуюсь в коде, только в скриптах и многое другое, чего нет в дельфи или сделано там по другому. Скорость выполнения кода и расход памяти для моих задач вполне приемлем.

Но когда надо сделать задачу с ГУИ, я даже не думаю и иду к дельфи или C#. А вот в прочих случая уже выбираю чаще ФП в последнее время, но не всегда. Кстати некоторые ФЯ имеют порты к библиотеками написанным на других языках... Это уж если очень хочется и сладкого и кислогоLOL

И да -про монады не знаю, вернее читал это слово, но не проникся, как и всем хаскелем. Не потому , что не нравится, просто все объять - нет времени:-)

Хорошо бы не думать о памяти, но на сервере ее всего 64 гига, да на видеокарточке еще шесть :"-(

Самое ресурсоемкое приложение у нас отъедало порядка тридцати гиг, но это Ц++. Что было бы с ФП грустно представить.

Ну а на хаскеле можно соперничать с Ц++, но в большой ущерб читаемости.

Ну в общем пришли к тому, с чего начали. ФП начинает выигрышно смотреться там, где ресурсы не поджимают :)

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

> Всякие паралельные вычисления без ФП вообще не представить.

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

Имхо, ФП просто "не взлетело"

> Mystic © (14.02.13 14:37) [153]

Т.е. OpenCL - это не специфичная ниша, а всякие mapreduce - специфичная? Ну понятно :)

> Иксик © (11.02.13 00:09) [130]
>
> Вообще интересно. Чем больше читаю по ФП, тем больше кажется,
> что в ближайшее время они станут мейнстримом.

Поправка: не обязательно сами ФП языки, но ФП фичи скорее всего. Т.е. возможно они просто вольются в языки типа с#.

> Иксик © (14.02.13 15:59) [155]

Этим фичам уже много лет, больше десятка. Пока что они не спешат вливаться в мейнстрим. Есть отдельно Scala, в C# понемногу добавляют функциональные фичи.

Жаль, что понемногу. Но если в C# 2.0, спустя 40 лет, появились дженерики, а в C# 1.0 так вообще круть - сборщик мусора, то вполне можно надеятся, что в C# 29.0 программистам предложат прогрессивную новую технологию - сопоставление с образцом. Задержка в 40-50 лет вполне приемлима.

Троллю, да. Не сдержался :)

← →
знайка (2013-02-15 14:37) [158]

> что в C# 29.0 программистам предложат прогрессивную новую
> технологию
а до тех пор в дотнете есть f#. $)

> Mystic © (15.02.13 13:33) [156]
>
>
> > Иксик © (14.02.13 15:59) [155]
>
>
> Этим фичам уже много лет, больше десятка. Пока что они не
> спешат вливаться в мейнстрим. Есть отдельно Scala, в C#
> понемногу добавляют функциональные фичи.
> <Цитата>
>
> Kerk © (15.02.13 14:07) [157]
>
> Жаль, что понемногу. Но если в C# 2.0, спустя 40 лет, появились
> дженерики, а в C# 1.0 так вообще круть - сборщик мусора,
> то вполне можно надеятся, что в C# 29.0 программистам предложат
> прогрессивную новую технологию - сопоставление с образцом.
> Задержка в 40-50 лет вполне приемлима.
>
> Троллю, да. Не сдержался :)

Я как раз про C#, на нем в последние годы. Я мало смыслю в ФП, но кроме дженериков вроде LINQ со всякими там лямбда экспрешеннами, анонимные функции, новые асинхронные методы - может я неправ, но имхо от этого пахнет ФП.

ООП vs ФП Найти похожие ветки