ООП vs ФП

← →
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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kerk © (05.02.13 18:23) [69]

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

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

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

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

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

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

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

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

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

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

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

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

Kerk © (05.02.13 18:59) [75]

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

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

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

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

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

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

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

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

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

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

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

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

Kerk © (05.02.13 19:13) [77]

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

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

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

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

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