https://citforum.ru/gazeta/165/
по линку многабукаф, немного для Ъ:
факт остаётся фактом: сторона, представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp'еров была куда убедительней и последовательней, чем сторонников ООП.
Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: "Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле".
Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП "ускоряет разработку программ": "Как только ты сказал слово "объект", можешь сразу забыть о модульности".
Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла "тихая революция".
Неактивен
Этим холиварам уже лет и лет Напоминает свифтовские войны тупо- и остроконечников.
"но в отличие от вас не стремлюсь здесь перед всеми показаться умнее всех"
"Ну здесь много мосек, что ж поделаешь."
"народ после общения со мной умнеет что ли, становится более бдительным в сети"
(с) Великий Человек
Неактивен
хм.. буду следить.
Не ламерствуй лукаво.
"А петь мне нельзя - постановление суда" (с) Бендер
Неактивен
Этим холиварам уже лет и лет Напоминает свифтовские войны тупо- и остроконечников.
В койтом веке с тобой согласен... = )
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Провалилось? А мужики-то не знают.
То, что ООП и быстродействие - несовместимы было понятно еще на заре ООП, ничего нового не открыто. Но разработка программ под ООП быстрее из-за предсказуемого поведения классов расширяющих базовые.
Ну я бы сказал - программная логика, которую можно расчленить на объекты, отлично имплементится на ООП и такой код гораздо читабельнее и проще в саппорте, чем процедурный или функциональный.
"но в отличие от вас не стремлюсь здесь перед всеми показаться умнее всех"
"Ну здесь много мосек, что ж поделаешь."
"народ после общения со мной умнеет что ли, становится более бдительным в сети"
(с) Великий Человек
Неактивен
имхо - хуита полная
конечно, для каких-то целей лучше подойдёт процедурный или функциональный подход (а то и сразу в бинарных кодах писать), но в целом - ООП рулитЪ!!!
На мой взгляд, Делфи - это огроменный прорыв вперёд.
+100500!!!
Windows == УМВР
Неактивен
(а то и сразу в бинарных кодах писать),
Это суровые виндейские програмисты пишут так:
copy con my_cool_prog.exe? Круто.
Yesterday it worked.
Today it is not working.
Windows is like that.
Неактивен
Это суровые виндейские програмисты пишут так:
copy con my_cool_prog.exe? Круто.
нет, это должно выглядеть, наверное, примерно так:
004520DC B8F0204500
004520E1 E87E52FDFF
004520E6 C3
004520E7 00FF
004520E9 FF
Windows == УМВР
Неактивен
и быстродействие - несовместимы было понятно еще на заре ООП
Лажа.
Как раз наоборот, хоть чуточку, да быстрее, чем голый код на if-ах.
В общем, конечно, интересно, вырастет ли из функционального подхода что-то применимое на практике. Я тут посмотрел F# - реально, заманчиво. Но с быстродействием ба-а-альшой вопрос.
Добавлено спустя 01 мин 22 с:
На мой взгляд, Делфи - это огроменный прорыв вперёд.
Это ты какого года имеешь ввиду?
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
Создание объектов и операции с ними быстрее, чем "код на if-ах"? Лол.
Взаимно.
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
а мой взгляд, Делфи - это огроменный прорыв вперёд.
Что там у вас прорвало? Советую вызвать сантехника:
1) Начертите в ванной мелом пентаграмму.
2) Расставьте свечи в её вершинах.
3) Зажгите свечи.
4) встаньте в центр пентаграммы и читайте:
"Именем повелителя вод и ничестот,
Сантехник прийди!
И не через год!
Кран почини.
Аминь."
В общем как то так
Еще офтоп в "Программировании" и ставлю предупреждение.
Tiphon
Не ламерствуй лукаво.
"А петь мне нельзя - постановление суда" (с) Бендер
Неактивен
Неактивен
Это как так?Механизм процесса ускорения в студию!
Конечно, как правило голые ифы работают быстрее покуда транслируются напрямую в асм. Это не значит, все равно, что надо использовать спагетти го-то. Да и как работают голые ифы в питоне или пхп... Мы не будем об этом)))
Один из возможных вариантов, когда код с классами может работать быстрее связан с использованием кеша. Борьба обычно идет за то, чтобы используемые переменные попали в регистры, потом за то, чтобы блок используемых данных весь был в кеше. Вопрос - как определить этот блок? (Т.е. очевидно дать понять бездушной машине) В функциональных языках, которые используются сейчас - никак (если где-то есть, то не слышал, было бы интересно узнать). Точнее это может решать компилятор при оптимизации, но, в функциональных языках это сильно не очевидно. В Си, например, одно из правил расставлять в коде переменные, которые используются часто вместе - рядом (да-да), дабы они, вероятно, попадали в одну страницу памяти. Т.е. борьба идет за следующий уровень - одна страница памяти, но не кеш.
Объекты же (классы) могут целиком попадать в кеш и работать. Теоретически... Но! Например в С++ используются виртуальные таблицы для реализации наследования, ссылки на стек (любая переменная - ссылка на область памяти) и на кучу... В результате классы оказываются достаточно фрагментированными и часто, таки, в кеш в не влезают. Есть специальные приемы "дефрагментации" классов, которые, однако, в основном сводятся к отказу от наследования в пользу использования членов класса, использование выделенных буферов памяти и т.д.
Но факт остается фактом, если у тебя есть "объект", то машине (говорю тут очень обобщенно о всей процедуре компилятции и выполнения) "легче оценить" (кавычки) набор используемых данных. И если у тебя хорошо скомпанованных класс (обычно результат грамотного менджмента памяти, либо, например, не сложной иерархии в С++), то его легко целиком засунуть в кеш и код может работать быстрее чем на голых ифах.
В реальности такое часто встречается, при использовании JIT, правда, нормальных JIT пока не много.
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Это как так?Механизм процесса ускорения в студию!
Елки-палки, тут Тифон так все умно расписал, я аж застеснялся
Ну в целом - очевидно, что всякий if будет выполняться дольше, чем без if-а, если напрямую взять указатель. Задача же объекта в том и состоит, чтобы запомнить внутри себя как можно больше указателей, что он и делает. То есть само количество выполняемых if-ов при программировании на объектах уменьшается.
А вообще - тут Майк22 первый начал, что объекты, якобы, замедлают программу, так что пусть он и обосновывает.
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
Ручная оптимизация локальности в ФЯ думается мне мало реальна, ведь даже порядок выполнения не определяется программистом.
Просто мало ли, я подумал. Чего только не бывает в жизни=) Тем более в С люди сильно изворачиваются, чтобы огрести по полной от того, как порядок написания их программы транслируется в асм.
Код не будет работать быстрее, он просто будет удобнее для современных алгоритмов оптимизация параллелизма
Конечно, речь идет об оптимизации. Но мы же не говорим о написании прог на машинном коде? Тогда это значит, что "код" будет работать быстрее.
Вот JIT это другое дело.
Я тут сильно обобщаю. И JIT - это часть такого обощения. Ты говоришь, что JIT - медленнее? Но вспомни про фаерфокс с JIT оптимизацией))
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен