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

бессмысленный холивар в котором каждый прав по своему, хотя ваша позиция она более приземленная к реалиям что ли

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

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

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

У любого языка есть набор объективных плюсов и минусов, но то как тут расписывали минусы сишки - это хейтерство и некомпетентность.

Не потому что их нет, а потому что они не там.

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

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

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

Я не хочу строить из себя супер-специалиста. Я уже писал, что не писал код на сишке. Я оспаривал твои аргументы про сишку. Также я попал под влияние царя про фундаментальность сишки. Я писал немного прикладухи на С++, но это даже не уровень мидла. Я хочу изучить раст (вопреки рассказами царя, но его тезисы с тэгом «методичка» меня затронули) и углубить знания в С/С++. Но это не день и не месяц, так что пока я пишу логику на скриптухе (js, python).

Фундаментально ЛОР для меня нужен для того, чтобы «указали на ошибки и показали как надо». Лучше производить впечатление на противоположный пол, чем на анонимусов с форума.

Изучать язык - это значит писать на нем.

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

Желательно посвятить этому некоторое время, для того, чтобы почувствовать вкус языка. Что нравится, что не нравится. Где он многословный, где неудобный, где в зубах навяз. Преимущества станут заметны в сравнении с другими языками. то есть пока не попишешь на языке номер два, что хорошего в языке номер один вряд ли сможешь осознать.

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

И вот тогда появится необходимая компетенция для сравнения.

Ту же джаву или тот же раст создали не просто так, а в надежде решить целые классы проблем. Хороший вопрос - а какие именно проблемы решали создатели языка? Можно ли было решить эти проблемы не изобретая новый язык, стоит ли овчинка выделки - на эти вопросы ответ можно получить только путем практического сравнения, на своей шкуре.

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

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

https://www.youtube.com/watch?v=QyJZzq0v7Z4

Много хорошего материала, я немного не согласен с выводами.

Я например не считаю что ООП - стало мейнстримом. Там разные его огрызки, но мейнстримом стали нестрогие языки.

Топ-10 языков позволяют писать что попало, баг на баге, главное чтобы программист был счастлив что все скомпилировалось.

TIOBE 10

1	1		Java	16.884%	-0.92%
2	2		C	16.180%	+0.80%
3	4	change	Python	9.089%	+1.93%
4	3	change	C++	6.229%	-1.36%
5	6	change	C#	3.860%	+0.37%
6	5	change	Visual Basic .NET	3.745%	-2.14%
7	8	change	JavaScript	2.076%	-0.20%
8	9	change	SQL	1.935%	-0.10%
9	7	change	PHP	1.909%	-0.89%
10	15	change	Objective-C	1.501%	+0.30%

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

SQL, JavaScript, C и, на деле, PHP - не то чтобы сильно языки поощряющие ООП стиль. JS больше лисп чем ООП.

Так что дело не в ФП или ООП, а втом чтобы **як-**як и в продакшн.

https://www.youtube.com/watch?v=QyJZzq0v7Z4

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

Правда, я таки не знал, что в 2003 году Sun вложил 500 млн долларов в маркетинг Java (13:50 на видео). Не, я понимал, что для создания рукотворного хайпа по куску дерьма, вроде жавы, нужно очень много денег, но цифр конкретных не встречал.

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

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

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

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

Если язык с нуля сделан чтобы работать только в рамках Redux паттерна, то одновременно не нужны сайд-эффекты и монады

А это что? :

type Maybe a = Just a | Nothing
andThen : (a -> M b) -> M a -> M b

[[1,2,3]] |> List.head |> Maybe.andThen List.head

Просто функции. Хочешь видеть монаду - дерзай. Разница в том что в хаскелле нужно главу о монадах расписать, потому что они там могут быть любыми. А в Elm просто консистентно написали пару функций в стандартных типах и сказали monkey see, monkey do

Монада - это композитор функций. То есть, вместо императивного последовательного выполнения

let a;
f1 { a = readString(file1) }
if (a)
    f2 { writeString(file2) }

conditionalMonad (prevResult, nextFunction) = {
    if (result1)
        nextFunction(result1)
    else
        nothing
}

 f1 () = { return readString(file1) }

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

А теперь смотри на реализацию andThen:

andThen : (a -> Maybe b) -> Maybe a -> Maybe b
andThen callback maybe =
    case maybe of
        Just value ->
            callback value

        Nothing ->
            Nothing

Нету ленивости, нету тайпклассов

Ленивости нет, действительно. Тайпклассы, а.к.а. контейнеры, есть.

Если язык с нуля сделан чтобы работать только в рамках Redux паттерна, то одновременно не нужны сайд-эффекты и монады

Насколько мне известно Redux, vuex, flux сделан по модели изменения данных Elm. Вот только в JS можно сделать это и еще многое другое, а в Elm сделать простое изменяемое хранилище - это пытка.

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

Если вот в Java есть Optional, то что, это язык известным своими монадами? Или С++?

Тайпклассы, а.к.а. контейнеры, есть

Нельзя определить свой тайпкласс. Значить не надо знать что это такое, не нужно разбираться в развесистой иерархии стандартной библиотеки как в Scala. Потому что для фронтенда не нужно

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

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

Если вот в Java есть Optional, то что, это язык известным своими монадами? Или С++?

Как бы они не пытались закосить под монады - у них не особо получилось:
https://www.sitepoint.com/how-optional-breaks-the-monad-laws-and-why-it-matters/
В итоге индустрия откатывается к тому же async/await для разворачивания вложенных вызовов функций в линейную последовательность команд.

Нельзя определить свой тайпкласс. Значить не надо знать что это такое, не нужно разбираться в развесистой иерархии стандартной библиотеки как в Scala. Потому что для фронтенда не нужно

Хорошо, нет классов и их иерархий. Однако же, контейнерные типы есть:

type ChildId = ChildId Int

Ну в елм вообще мало что есть, это такой себе Go от фронтенда, где ограниченость и отсутсвие фич - фича.

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

Недавно в ютубе наткнулся на лекцию с таким же заголовком. Там парниша норм, живо рассказывает:

https://www.youtube.com/watch?v=QyJZzq0v7Z4

И получили штуку, на которой сайт написать проще чем на реакте.

Естественно если ты ее слепой хейтер всего что отдаленно связано с фп, как ты.

Elm - язык, который очень быстро изучить, как и Go. Причем ты даже может не будешь знать слова Flux/Redux и загибать ФП в бараний рог чтобы получить чистую функцию Model->View

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

а я вот не знал что Sun целых 500 лямов баксов потратил на рекламу Java. (и это вроде за один какой-то год)

И получили штуку, на которой сайт написать проще чем на реакте.

Я пишу сайты на Vue.js, и это очень просто. Никакого Elm. Хронология развития была примерно такая: XHP, Elm, React, Flux, Vue.js, Redux

Естественно если ты ее слепой хейтер всего что отдаленно связано с фп, как ты

А откуда, по-твоему, я умею писать на хаскеле?

Elm - язык, который очень быстро изучить, как и Go.

Это очень поверхностное свойство - потому я и возмутился. Так-то Go и Elm вообще никак близко не стоят.

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

Можешь считать, что я ему завидую. Он умеет впаривать, а я - нет.

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

Эх, раз опоздал я с тем роликом, дам другой, который сегодня вечерком посмотрю перед футболом: https://youtu.be/rHIkrotSwcc

Вроде по отзывам должен быть ничё ролик...

Зопейсал. Люблю доклады CppConf

а я вот не знал что Sun целых 500 лямов баксов потратил на рекламу Java. (и это вроде за один какой-то год)

А ты что, думал, что Жава так популярна потому, что божественная объектно-ориентированная модель притягивает к себе программистов, а заказчики кончают от сочетания надежности системы в сочетании с высокой скорости работы и разработки? Конечно же нет, просто туда ввалены миллиарды долларов.

Но Жава оказалась настолько ужасна, что в итоге разорила Sun. Они хотели получить средство, которое одинаково бы работала на всех устройствах и во всех сферах разработки, но выяснилось, что оно одинаково плохо подходит для всех сфер, кроме серверов с требованиями по высокой производительности и надежности. Причем, далеко не всегда на фоне требований к производительности применение жавы оправдано - потому YouTube использует питон.

А дело в том, что Java - это среднеуровневый язык (по нынешним меркам), который при этом имеет сборщик мусора, характерный для высокоуровневых языков, но Java катастрофически не способна подниматься вверх по абстракциям, поскольку топит кодера в хитросплетении классов/интерфейсов (нужное подчеркнуть). По этой причине развелось такое кол-во новых языков для JVM, которые растут на трупе этого многомиллиардного хайпа.

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

Я вполне конкретно указал - задроты, не идиоты. Это примерно как люди, которые 50 часов подряд гриндят в WoW/Lineage/Allods/etc. Им просто по приколу этим заниматься.

А книжки я не читаю вообще - только отдельные статьи или куски из этих книжек. Да, хаскель без руководства освоить нереально.

Исследовали уже, early adoptors vs mainstream majority.

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

Другие больше веса придают текущим минусам, и потенциал для них слишком эфемерный

Причем в разных ситуациях люди находятся по разную сторону этих понятий. Технологически я почти всегда early adoptor, в играх и развлечении я наоборот выжидаю по 3 года и потом играю на дешевом железе в только лучшее. Потому что я не разработчик игр и в новых играя я лично не создаю инновацию. Но так как разработка моя профессия, то я там я ценю инновацию

Исследовали уже, early adoptors vs mainstream majority.
Одни обращают внимание больше на плюсы и потенциал идеи, и ради них готовы терпеть минусы.

Вообще не в той плоскости рассматриваешь проблему. Сам же и замечаешь, что одни и те же люди оказываются и тем, и другим - в чем тогда смысл деления? Типа «бывают люди с двумя руками, а бывают люди с двумя ногами».

Ну в том что у тебя например экстремальная позиция что Elm посполезен, хобби штангистов. Хотя это не хаскель, а его одна десятая сделаная специально чтобы нормально соответствовать когнитивной нагрузке других фреймворков. С другой стороны настолько безопасный рефакторинг - очень сильная фича, которой практически невозможно добиться в Vue

Ну в том что у тебя например экстремальная позиция что Elm посполезен, хобби штангистов

Я вполне конкретно описал позицию в самом начале, и касалось она не того, что Elm бесполезен, а того, что Elm не обретет славу жаваскрипта/php, и что автор, на самом деле, впаривает нам свой продукт, точнее - ищет инвесторов, подавая это под соусом «почему ФП не мейнстрим», хоть сам он на этот вопрос и не отвечает - вообще вся его презентация весьма поверхностная в этом плане. У него такой характер, и он вполне грамотно его реализовывает.

Вот ещё один тип который думает, что ООП мертв

https://youtu.be/yy8jQgmhbAU

А можно в тексте? Или ссылки на время с ключевымы тезисами. Как бы ,сейчас ООП не пинает только ленивый - и вполне оправдано. Удивляет разве что то, что кто-то умудряется до сих пор ООП хвалить, будто проспал 20-30 лет в криокамере.

Конечно, вот текст https://github.com/CppCon/CppCon2018/blob/master/Presentations/oop_is_dead_lo...

Конечно, вот текст https://github.com/CppCon/CppCon2018/blob/master/Presentations/oop_is_dead_lo...

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

Тогда возникает вопрос: в чем же фишка DoD?

Писать как на паскале функциями и структурами, причем не запаиваться инкапсуляцией.

Абстракции делать compile-time, например через композицию шаблонами. Никаких виртуальных методов.

Избегать ветвления в hot path. Как пример приводится «if (x.isActive)», это у них как-то сожрало 1 мс, потому что процессор не угадал. Вместо этого active и не active предлагается просто перемещать между списками. Итерируешь по одному - знаешь что всегда active. По другому - всегда не active

Фишка не понятно в чем, просто куча примеров как не делать медленные вещи в С++

Тогда возникает вопрос: в чем же фишка DoD?

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

А в DOD мы находим функцию которая будет выполняться большинство времени, и пишем её так чтобы не было ветвлений, минимум аллокаций. В общем так быстро как можем, и создаём классы лишь по мере надобности. То есть решаем задачу снизу вверх.

Там в конце выступления ему один зритель сказал что он не понимает, что такое ООП и Dod тот же самый ООП.

Вот ещё немного про Dod, ООП и функциональный стиль:

https://youtu.be/HG6c4Kwbv4I

https://github.com/CppCon/CppCon2019/blob/master/Presentations/path_tracing_t...

Писать как на паскале функциями и структурами, причем не запаиваться инкапсуляцией.

Знаешь, у меня такое ощущение, что у него понта в лекции больше, чем самого содержимого лекции, и содержимое можно уложить в четыре абзаца, как ты и сделал. А то начинается вот эти «Data-driven development», «Inversion of control», и прочий словестный мусор, за которым толком ничего не стоит, но зато звучит красиво и дорого.

Абстракции делать compile-time, например через композицию шаблонами. Никаких виртуальных методов.

Если брать современный x86 с L1 32+32, то вполне праводоподобная ситуация, когда стэк в L1, таблица виртуальных методов с указателем на функцию в L1, сама структура из L1 никуда не уходила. В самом пессимистичном и маловероятном случае мы получаем вместо инлайна вызов виртуальной функции - сколько циклов мы потеряли? Возьмем грубо время обращения к L1 в 3 цикла. Разыменовывание указателя объекта, разыменовывание указателя таблицы функций, засунуть ссылку на объект в регистр, вызвать функцию (запись в стэк из L1), плюс вернуться из функции. Ну 15 циклов - вот так потеря, да? Более того, на RISC процах стэк не используется, и цифра окажется еще меньше.

Что я хотел сказать-то. Там, где есть вопрос «использовать виртуальные методы или нет», обычно нет смысла вообще париться этими вопросами оптимизации, а намного важнее оказывается вопрос «как нам не словить UD?» и «как это говно потом дописывать и поддерживать?». А там, где оптимизацией парятся, уже разговор ведется на уровне элементарных операций, и этот уровень ниже вопросов иерарахий классов и виртуальности методов.

Избегать ветвления в hot path. Как пример приводится «if (x.isActive)», это у них как-то сожрало 1 мс, потому что процессор не угадал.

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuilti...
Причем, оно есть не только в GCC. Я хочу подчеркнуть, что здесь речь идет о десятке циклов процессора, потерянных из-за неправильного ветвления. Это уже тонкая низкоуровневая оптимизация, которая актуальна не для каждой железяки.

Фишка не понятно в чем, просто куча примеров как не делать медленные вещи в С++

Фишка в том, что лектор читает интернет, и рассказал нам то, что мы и без него могли бы узнать. И как бы вообще не понятно, каким тут боком архитектура приложения.

А в DOD мы находим функцию которая будет выполняться большинство времени, и пишем её так чтобы не было ветвлений, минимум аллокаций

Это самое обычное, ничем не примечательное, и выполняемое многие десятиления действо, именуемое «профилирование» и «оптимизация». Можно назвать это «Jedi-oriented architecture», но смысл действия от этого не поменяется. У меня такое ощущение складываются, что лекторы соревнуются в том, кто завернет самую банальную и общеизвестную вещь в самую необычную обертку.

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

Вот ещё в одном слайде было краткое объяснение что такое DATA-ORIENTED DESIGN

• Design around most common operations
• Design data by access patterns
• Avoid branches
• Polymorphism by separation

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

Design around most common operations
Design data by access patterns
Avoid branches
Polymorphism by separation

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

где можно поподробнее про это почитать? гайды, best practices, etc.?

https://sites.google.com/site/anisimovkhv/learning/pris/lecture/tema6

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

Правда, в статье слишком очевидное «сам придумал, сам опроверг». Сначала пишет про «жемчужину информатики», потом успешно доказывает, что это не так. А кто бы спорил.

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

https://tproger.ru/translations/oop-the-trillion-dollar-disaster/

Это компиляция-пересказ материалов из интернетов. Некоторые представляют собой довольно очевидный плагиат про «падение четырех столпов ООП» - была такая статья на хабре.

Спасибо, у меня тоже возникло такое ощущение, что я это уже читал, причём не по одному разу.