ООП vs ФП

← →
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 есть возможность объявить тип изменяемым, в хаскелле придумали монады.

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

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

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

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

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

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

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

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