LINUX.ORG.RU

Почему ООП стало более популярным и соответствующие языки и технологии программирования чем то же ФП?

 ,


2

4

Заранее прошу прощения за то, что не в Talks, а сюда. Так получается, что теперь в Talks просто так постить нельзя, нужна некая карма и я должен «страдать» (Почему я не могу писать в раздел Talks? (комментарий)). Я в упор не помню данные своего старого аккаунта. Зарабатывать карму здесь и сейчас у меня нет ни времени, ни возможности, ни необходимости. Почему сюда, а не на другие форумы? Потому что считаю, что здесь обитают люди, которые смогут ответить на вопросы ниже и, возможно, даже, которые застали те самые времена (если конечно те самые люди ещё здесь).

Всем доброго времени суток! Не срача ради, а понимания для. Хочется понять историчность и почему так произошло. Понятно, что сейчас уже стали внедрять функциональные фичи много куда (в те же Java, C++, C# и т.д.). Стало появляться много функциональных языков (в том числе совсем новых). Но почему спустя столько времени? Почему спрашиваю:
- Functional programming has its origins in lambda calculus, a formal system developed in the 1930s (!!!) to investigate computability, the Entscheidungsproblem, function definition, function application, and recursion. Many functional programming languages can be viewed as elaborations on the lambda calculus (отсюда: https://en.m.wikipedia.org/wiki/Functional_programming);
- Lisp появился ажно в 1958 году;
- после лиспа ещё была целая куча функциональных языков (APL, IPL, ML, Miranda, Erlang, etc.);
- C++ в 1985;
- Haskell в 1990;
- Java в 1995;

Сама идея ООП (и то я так понял весьма размытая, каждый понимал (и, кстати, по-моему до сих пор понимает) по-своему) вроде как витала со времени создания самого лиспа, но до конкретных реализаций она добралась ближе к концу 80-х - начала 90-х годов.
(поправьте меня, если не прав)
И это ещё при всём при том, что ФП имеет под собой весьма конкретный математический базис (чего я, пожалуй, не могу сказать про ООП).
Я так понял, что благодаря таким крупным компаниям как Microsoft, Oracle...
Но почему они так сильно повлияли на развитие этих технологий и как именно они это сделали я, честно говоря, не совсем понимаю.
Ок, ладно, тогда железо было не такое как сейчас, памяти было маловато для нормального существования функциональных языков на x86 платформе.
Но ведь была же та же, например, Symbolics, которая вроде бы весьма активно продавала лисп-машины?
Ок, Symbolics развалилась благодаря неблагоприятному стечению обстоятельств и «эффективным» манагерам, но их наработки оказались никому не нужны что ли?
И опять-таки, когда нужное железо появилось почему выбор этих и других крупных компаний пал именно на эти языки?
Почему не на функциональные языки?
Потому что в то время функциональные языки в основном использовались сугубо в академической среде или как?
Или если перефразировать всё вышесказанное словами моего коллеги: «если всё так круто (про ФП), то почему оно ещё не захватило рынок?»

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

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

Eddy_Em ☆☆☆☆☆
()

Я, наоборот, вижу, что ООП, как культ, сдувается. Сейчас пишут на мешаниние ФП И ООП. Хардкорный ООП, наверное, остался только в странах, куда легаси проекты сбагривают.

mv ★★★★★
()

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

quantum-troll ★★★★★
()
Ответ на: комментарий от mv

От ФП в основном берут стилистические мелочи типа map вместо цикла. Проектирование остается объектное. И это естественно, живем-то в мире из объектов и с состоянием.

anonymous
()
Ответ на: комментарий от anonymous

Проектирование остается объектное.

Нет, не остаётся. Без наследования, ООП в принципе не отличается от не-ООП. И наследование считается анти-паттерном (composition over interitence).

quantum-troll ★★★★★
()
Ответ на: комментарий от quantum-troll

Без наследования, ООП в принципе не отличается от не-ООП

Сильное заявление. Ну, будет композиция, не будет наследования. Будут объекты и полиморфизм. Все равно на ООП тянет, на ФП - нет.

anonymous
()
Ответ на: комментарий от anonymous

От ФП в основном берут стилистические мелочи типа map вместо цикла.

Не только. Замыкания, лямбды (не тот смех, что в C++) и т.п.

Проектирование остается объектное. И это естественно, живем-то в мире из объектов и с состоянием.

А, может, в мире с замыканиями и лямбдами? :)

Причём, я ООП и ФП не взаимоисключаю.

mv ★★★★★
()
Ответ на: комментарий от mv

Я, наоборот, вижу, что ООП, как культ, сдувается.

Same.

Deleted
()
Ответ на: комментарий от mv

А, может, в мире с замыканиями и лямбдами?

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

anonymous
()
Ответ на: комментарий от quantum-troll

Чем объекты без наследования принципиально отличаются от структуры и функций в модуле?

Ничем, пожалуй. Но мыслим-то при этом по-прежнему в терминах объектов, состояния и поведения.

anonymous
()
Ответ на: комментарий от anonymous

Проектирование остается объектное. И это естественно, живем-то в мире из объектов и с состоянием.

Вот. Аргумент, выдвигаемый адептами ФП: все объекты вычисления, включая сами числа (натуральные), можно представить на языке лямбда выражений (или проч. SKI комбинаторов). Не понятно только, чем эти языки кошернее и теоретичнее языка МТ, если они эквивалентны?

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

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

seiken ★★★★★
()
Последнее исправление: seiken (всего исправлений: 1)
Ответ на: комментарий от anonymous

Но мыслим-то при этом по-прежнему в терминах объектов, состояния и поведения.

Вопрос: современное ООП мыслит «в терминах объектов, состояния и поведения»? Или подменили деталями реализации в виде «инкапсуляция, наследование и полиморфизм»?

anonymous
()
Ответ на: комментарий от quantum-troll

Хм. От жанра зависит, наверно? Геймдев - это же хрестоматийный пример ООП, со всеми его npc, юнитами и их взаимодействием.

А так да, где обработка данных - там вроде и водятся хаскель да F#.

anonymous
()
Ответ на: комментарий от anonymous

современное ООП мыслит «в терминах объектов, состояния и поведения»?

Грамотные архитекторы мыслят так, насколько я видел. Кто уровнем пониже - уже нет, конечно.

anonymous
()

Хочется понять историчность и почему так произошло. Понятно, что сейчас уже стали внедрять функциональные фичи много куда (в те же Java, C++, C# и т.д.). Стало появляться много функциональных языков (в том числе совсем новых). Но почему спустя столько времени?

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

ООП стало популярным исключительно благодаря Си++. Несмотря на то, что это уже не такое ООП как в Smalltalk, именно оно стало новой модой.

Эффективное ФП невозможно без сборщика мусора и достаточно умного компилятора. Сборщик мусора стал моден только после появления Java. До этого были лиспы, но умерли после AI Winter.

Но ведь была же та же, например, Symbolics, которая вроде бы весьма активно продавала лисп-машины?

Ок, Symbolics развалилась благодаря неблагоприятному стечению обстоятельств и «эффективным» манагерам, но их наработки оказались никому не нужны что ли? И опять-таки, когда нужное железо появилось почему выбор этих и других крупных компаний пал именно на эти языки?

Symbolics была обречена именно потому, что при равной стоимости их машины работали намного медленней. А когда нужное железо появилось, то новые языки должны были быть совместимы со старыми по библиотекам и программистам. Для того же Haskell до сих пор нет нормального валидирующего парсера XML, а интеграция с Xerces или libXML выглядит как кошмар.

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

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

monk ★★★★★
()
Ответ на: комментарий от anonymous

современное ООП мыслит «в терминах объектов, состояния и поведения»?

Грамотные архитекторы мыслят так, насколько я видел.

«Грамотные архитекторы» наверно еще рисуют uml-диаграммы (какие еще там диаграммы есть?), по которым автоматически генерится скелет будущего проекта на миллионы строк кода. :)

anonymous
()
Ответ на: комментарий от anonymous

Продолжу.

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

anonymous
()
Ответ на: комментарий от anonymous

А так да, где обработка данных - там вроде и водятся хаскель да F#.

В машинном обучении дофига данных. Где там Haskell с F#?

seiken ★★★★★
()
Ответ на: комментарий от seiken

В машинном обучении дофига данных. Где там Haskell с F#?

Машинное обучение в частности и AI в принципе разве ещё официально не скатилось в банальное распознавание паттернов?

mv ★★★★★
()

если всё так круто

Потому что не все так круто, и зачем чистое ФП нужно ваще? Берешь ООП язычек и добавляешь туда штуки из ФП, что же еще нужно для счастья...

Deleted
()
Ответ на: комментарий от mv

Машинное обучение в частности и AI в принципе разве ещё официально не скатилось в банальное распознавание паттернов?

Гипотеза анонима была не о эволюции области машинного обучения, а о обработке данных и Haskell с F#. В MO большие массивы данных как использовались, так и есть, и с каждым годом их все больше и больше. А резкого захвата этой области функциональщиной как-то не наблюдается. Все С++, да Python.

seiken ★★★★★
()
Ответ на: комментарий от seiken

Про резкий захват аноним ничего не писал. А то что ФЯ встречаются в финансовом секторе и в науке - то не гипотеза.

anonymous
()
Ответ на: комментарий от seiken

А резкого захвата этой области функциональщиной как-то не наблюдается. Все С++, да Python.

Ну так в машинном обучении сейчас экстенсивный рост - тупой комбинаторный взрыв «старой математики» за счет резко увеличившихся объемов данных и вычислительной мощности. А «старая математика» и на фортране быстро работает. Раньше просто не было столько данных и мощностей. Хорошо что есть хоть какой-то полезный выхлоп этого взрыва, в том числе качественный.

anonymous
()
Ответ на: комментарий от seiken

На практике «правильный» ФП иногда сливает даже самому убогому фортрано-подобному ЯП из 60-х, с более современными костылями. Вот пример со stackoverflow: императивный, костыль-на-костыле Matlab заслужил более 80тыс. вопросов, а более ФП'шная Wolfram Mathematica и 8тыс. не набрала.

seiken ★★★★★
()
Ответ на: комментарий от quantum-troll

Кстати про геймдев. Кармак же рассказывал, как здорово пишутся игры с ФП. Haskell хвалил. Но никаких подвижек у id и прочих я не заметил.

Но я и не следил. Может, есть что-то про поворот геймдева к ФП? Raincat не предлагать)

anonymous
()
Ответ на: комментарий от anonymous

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

KyoujurouRengoku
()

Потому что callback hell - тоже ФП. Но не идеальное, а в условиях дедлайна.

Shadow ★★★★★
()

памяти было маловато для нормального существования функциональных языков

функциональный ассоциативный массив со сложностью вставки и поиска o(1) никто не придумал, с другими структурами данных видимо такие же проблемы. Памятью эту проблему не решить

Leron ★★
()
Ответ на: комментарий от KyoujurouRengoku

Современный ООП про инкапсуляцию, наследование и полиморфизм

Это механизмы низкого уровня. Проектируют поверх них, уже в терминах ближе к реальному миру.

anonymous
()

Давным давно не видел ООП кода, уже не очень представляю что-то

oxo
()

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

Сейчас все всё переделывают под ФП, чуть чуть обрезая ООП, что во фронтенде, что в современных ЯП. Например в языках сделанных за последние 10 лет наследования обычно нету. Мутабельность тоже по дефолту часто отключена

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от mv

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

Shadow ★★★★★
()
Ответ на: комментарий от mv

Ну, допустим, предобработка данных даже в питоне лучше работает с помощью векторных функций над таблицами numpy...

Shadow ★★★★★
()

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

dave ★★★★★
()
Ответ на: комментарий от dave

Сейчас есть запрос на ФП, потому что почти достигнут потолок в производительности одного процессорного узла (ядра).

Даешь cuda и opencl на хаскель! Структурное программирование - это г... мамонта. А ООП - это всего лишь нагромождение сомнительных абстракций над структурным программированием, то есть еще большее ...

anonymous
()

ООП для работы, ФП для почёсывания своего ЧСВ.

ox55ff ★★★★★
()
Ответ на: комментарий от dave

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

Так для этого же микросервисы придумали. Вроде работает.

monk ★★★★★
()

Потому что индустрии не нужна горстка джедаев-одиночкек, владеющих крутой заумной хренью, которых всех целуют в попы, потому что они априори всех потребностей не перекроют. Индустрии нужна армия клонов, более-менее справляющихся с использованием простых и тупых инструментов. Поэтому популяризируется то, что можно запихать в большее количество усредненных мозгов. Чем проще говнякать, тем лучше. JS/PHP/C++ — OK, а Haskell/CL — no way.

Virtuos86 ★★★★★
()

В С++ многое для функциональщины было уже готово с незапамятных времен (например, переопределение operator()).

Указатели на функции использовались в С еще до того, как многие посетители этого форума пошли в первый класс.

Просто раньше спокойно все это использовали по мере необходимости без лишнего хайпа. Использовали и все.

А теперь: «ПОСОНЫ, смотрити, я совсем как функциональщину к нам в проджект завёс!».

trex6 ★★★★★
()
Ответ на: комментарий от quantum-troll

Наследование интерфейсов с инкапсуляцией готового поведения вместо наследования реализации — совсем не отменяет существование наследования как такового. Просто способ наследования изменился.

trex6 ★★★★★
()
Ответ на: комментарий от mv

лямбды (не тот смех, что в C++)

Что именно плохо в реализации С++-лямбд? В каком языке можно посмотреть на правильную реализацию?

P.S. Не срача ради, мне правда интересно.

trex6 ★★★★★
()
Ответ на: комментарий от KyoujurouRengoku

Ты мыслишь в обратную сторону, не раскладывая объекты на составляющие, а обобщая их в группы по паттернам поведения.

trex6 ★★★★★
()
Ответ на: комментарий от monk

И сообщения еще неизменяемые, как на зло, между этими микросервисами. А где же теперь DCOM и Корба?! Вот, уж где ООП надо искать!

dave ★★★★★
()
Ответ на: комментарий от anonymous

Извини, додумывать за тебя не хочу! Ничего не понял из твоего потока мыслей.

И еще, если нет таблички большими буквами ФП, то это не значит, что не используется идей ФП. Вообще, многое переплетено гораздо сильнее, чем некоторым кажется. Нет такого жесткого водораздела, чтобы сказать, вот здесь 100%-й ФП, и 0% ООП, а вот там - наоборот. Так не бывает! Говоря строго, ФП и ООП взаимно не исключают друг друга.

dave ★★★★★
()
Ответ на: комментарий от Virtuos86

Всё конечно так, только разделение на простое/сложное почти не коррелирует с разделением на ООП/ФП. Настоящее (c) ООП заумно, практичное ФП просто.

anonymous
()
Ответ на: комментарий от anonymous

Я хотел упомянуть, что самые практичные ништяки из ФП уже повытягивали, из тех, что просто натянуть на глобус императивного погромирования. А потом подумал: «Ладно, и так сойдёт!»

Virtuos86 ★★★★★
()
Ответ на: комментарий от dave

Вообще, многое переплетено гораздо сильнее

:)

Тьюринг напару с Чёрчем, заплели всё своим извращенным умом. Теперь хрен поймешь, где начинается и заканчивается ФП и ООП.

«Функция - объект первого класса». Что за смешение терминов из разных парадигм: функция, объект, класс?

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

Но это не важно. Даешь нейросетки на cuda, который на хаскель (ну хотя бы на лисп). А то какие-то диалекты си c фортранами, что за прошлый век? «Сейчас есть запрос на ФП».

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.