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 развалилась благодаря неблагоприятному стечению обстоятельств и «эффективным» манагерам, но их наработки оказались никому не нужны что ли?
И опять-таки, когда нужное железо появилось почему выбор этих и других крупных компаний пал именно на эти языки?
Почему не на функциональные языки?
Потому что в то время функциональные языки в основном использовались сугубо в академической среде или как?
Или если перефразировать всё вышесказанное словами моего коллеги: «если всё так круто (про ФП), то почему оно ещё не захватило рынок?»


Ответ на: комментарий от abcq

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

olelookoe ★★★
()

Вот человек 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 больше лисп чем ООП.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

let a;
f1 { a = readString(file1) }
if (a)
    f2 { writeString(file2) }
применяет функциональная запись conditionalMonad(f1(), f2), где монадическая функция определена как-то вроде
conditionalMonad (prevResult, nextFunction) = {
    if (result1)
        nextFunction(result1)
    else
        nothing
}
а f1 переписана для возврата значения вместо изменения состояния:
 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

type ChildId = ChildId Int
В данном случае у нас ChildID - это не целое число, а целое число в контейнере ChildId. Да, у ChildId нет классов - это упрощение, с одной стороны, а с другой стороны, когда у тебя нет классов - это ограничивает возможности. Разраб обещал тайпклассы, но доселе их нету:
https://github.com/elm/compiler/issues/38

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://youtu.be/HG6c4Kwbv4I

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

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

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

Знаешь, у меня такое ощущение, что у него понта в лекции больше, чем самого содержимого лекции, и содержимое можно уложить в четыре абзаца, как ты и сделал. А то начинается вот эти «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. Я хочу подчеркнуть, что здесь речь идет о десятке циклов процессора, потерянных из-за неправильного ветвления. Это уже тонкая низкоуровневая оптимизация, которая актуальна не для каждой железяки.

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

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

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

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

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

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

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

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

  • Design around most common operations
  • Design data by access patterns
  • Avoid branches
  • Polymorphism by separation
fsb4000 ★★★★★
()
Ответ на: комментарий от byko3y

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

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

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

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

byko3y ★★★★
()

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

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

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

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

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

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

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

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

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