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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Same.

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

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

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

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

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

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

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

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

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

Или нет. В геймдеве, например, принято мыслять в терминах данных и их преобразований (data-oriented design).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Продолжу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полиморфизмом?

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

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

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

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

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

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

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

:)

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

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

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

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