Почему объектно-ориентированное программирование провалилось?

Luca · 11-10-10 11:25:03

по линку многабукаф, немного для Ъ:

факт остаётся фактом: сторона, представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp'еров была куда убедительней и последовательней, чем сторонников ООП.
Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: "Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле".
Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП "ускоряет разработку программ": "Как только ты сказал слово "объект", можешь сразу забыть о модульности".
Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла "тихая революция".

Linfan · 11-10-10 11:48:56

Этим холиварам уже лет и лет smile Напоминает свифтовские войны тупо- и остроконечников.

Гареев Станислав · 11-10-10 13:58:13

хм.. буду следить.

Mike22 · 11-10-10 16:51:13

Провалилось? А мужики-то не знают.

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

Tiphon · 11-10-10 17:44:45

Linfan пишет:

Этим холиварам уже лет и лет Напоминает свифтовские войны тупо- и остроконечников.

В койтом веке с тобой согласен... = )

Linfan · 11-10-10 19:51:51

Mike22 пишет:

Провалилось? А мужики-то не знают.
То, что ООП и быстродействие - несовместимы было понятно еще на заре ООП, ничего нового не открыто. Но разработка программ под ООП быстрее из-за предсказуемого поведения классов расширяющих базовые.

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

pavel2403 · 11-10-10 22:11:22

Linfan пишет:

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

Это выглядит конечно странно, но я плюсую.

Armanx64 · 11-10-10 22:24:44

Если Сутулый говорит, что ООП - плохо, значит, ООП - хорошо, а Сутулый - плохо.

pavel2403 · 11-10-10 22:44:52

Armanx64 пишет:

Если Сутулый говорит, что ООП - плохо, значит, ООП - хорошо, а Сутулый - плохо.

Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле".

Подпишусь хоть под каждым словом. Скажу по себе. ООП это здорово в плане удобства чтения кода, создания удобочитаемой иерархической последовательности действий, соотвественно использования уже готового кода, но в плане разработки мозк можно сломать, пока напишешь класс так как он должен выглядеть, просто и логично. сам с этим столкнулся, уже 4 раз структуру классов переделываю, зато на выходе получается просто конфетка., хотя может мне просто так кажется. roll

Отредактировано pavel2403 (11-10-10 23:15:25)

Armanx64 · 11-10-10 23:00:03

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

shell32 · 11-10-10 23:41:18

Luca пишет:

citforum.ru/gazeta/165/

имхо - хуита полная mad
конечно, для каких-то целей лучше подойдёт процедурный или функциональный подход (а то и сразу в бинарных кодах писать), но в целом - ООП рулитЪ!!! smile

Armanx64 пишет:

На мой взгляд, Делфи - это огроменный прорыв вперёд.

+100500!!!

ikkunan salvataja · 11-10-10 23:44:41

shell32 пишет:

(а то и сразу в бинарных кодах писать),

Это суровые виндейские програмисты пишут так:
copy con my_cool_prog.exe? Круто.

shell32 · 12-10-10 02:03:54

ikkunan salvataja пишет:

Это суровые виндейские програмисты пишут так:
copy con my_cool_prog.exe? Круто.

нет, это должно выглядеть, наверное, примерно так:

004520DC B8F0204500
004520E1 E87E52FDFF
004520E6 C3
004520E7 00FF
004520E9 FF

Mike22 · 12-10-10 10:10:02

shell32 пишет:

конечно, для каких-то целей лучше подойдёт процедурный или функциональный подход (а то и сразу в бинарных кодах писать), но в целом - ООП рулитЪ!!!

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

DonDublon3 · 12-10-10 13:32:28

Mike22 пишет:

и быстродействие - несовместимы было понятно еще на заре ООП

Лажа.
Как раз наоборот, хоть чуточку, да быстрее, чем голый код на if-ах.

В общем, конечно, интересно, вырастет ли из функционального подхода что-то применимое на практике. Я тут посмотрел F# - реально, заманчиво. Но с быстродействием ба-а-альшой вопрос.

Добавлено спустя 01 мин 22 с:

Armanx64 пишет:

На мой взгляд, Делфи - это огроменный прорыв вперёд.

Это ты какого года имеешь ввиду?

Mike22 · 12-10-10 14:05:10

DonDublon3 пишет:

Как раз наоборот, хоть чуточку, да быстрее, чем голый код на if-ах.

Создание объектов и операции с ними быстрее, чем "код на if-ах"? Лол.

DonDublon3 · 12-10-10 14:38:07

Mike22 пишет:

Создание объектов и операции с ними быстрее, чем "код на if-ах"? Лол.

Взаимно.

Гареев Станислав · 12-10-10 17:19:24

Armanx64 пишет:

а мой взгляд, Делфи - это огроменный прорыв вперёд.

Что там у вас прорвало? Советую вызвать сантехника:
1) Начертите в ванной мелом пентаграмму.
2) Расставьте свечи в её вершинах.
3) Зажгите свечи.
4) встаньте в центр пентаграммы и читайте:
"Именем повелителя вод и ничестот,
Сантехник прийди!
И не через год!
Кран почини.
Аминь."
В общем как то так smile

Еще офтоп в "Программировании" и ставлю предупреждение.
Tiphon

petrun · 12-10-10 17:21:22

DonDublon3 пишет:

Лажа.
Как раз наоборот, хоть чуточку, да быстрее, чем голый код на if-ах.

Это как так?Механизм процесса ускорения в студию!

shell32 · 12-10-10 18:17:53

Гареев Станислав,

Tiphon · 12-10-10 18:40:01

petrun пишет:

Это как так?Механизм процесса ускорения в студию!

Конечно, как правило голые ифы работают быстрее покуда транслируются напрямую в асм. Это не значит, все равно, что надо использовать спагетти го-то. Да и как работают голые ифы в питоне или пхп... Мы не будем об этом)))

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

Объекты же (классы) могут целиком попадать в кеш и работать. Теоретически... Но! Например в С++ используются виртуальные таблицы для реализации наследования, ссылки на стек (любая переменная - ссылка на область памяти) и на кучу... В результате классы оказываются достаточно фрагментированными и часто, таки, в кеш в не влезают. Есть специальные приемы "дефрагментации" классов, которые, однако, в основном сводятся к отказу от наследования в пользу использования членов класса, использование выделенных буферов памяти и т.д.

Но факт остается фактом, если у тебя есть "объект", то машине (говорю тут очень обобщенно о всей процедуре компилятции и выполнения) "легче оценить" (кавычки) набор используемых данных. И если у тебя хорошо скомпанованных класс (обычно результат грамотного менджмента памяти, либо, например, не сложной иерархии в С++), то его легко целиком засунуть в кеш и код может работать быстрее чем на голых ифах.

В реальности такое часто встречается, при использовании JIT, правда, нормальных JIT пока не много.

petrun · 12-10-10 19:01:06

Tiphon пишет:

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

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

Tiphon пишет:

Но факт остается фактом, если у тебя есть "объект", то машине (говорю тут очень обобщенно о всей процедуре компилятции и выполнения) "легче оценить" (кавычки) набор используемых данных. И если у тебя хорошо скомпанованных класс (обычно результат грамотного менджмента памяти, либо, например, не сложной иерархии в С++), то его легко целиком засунуть в кеш и код может работать быстрее чем на голых ифах.

Код не будет работать быстрее, он просто будет удобнее для современных алгоритмов оптимизация параллелизма(на уровне логических блоков cpu) и локальности.
Вот JIT это другое дело.Но, как показывает практика, в общем случае, они все-таки медленнее.

DonDublon3 · 12-10-10 19:03:26

petrun пишет:

Это как так?Механизм процесса ускорения в студию!

Елки-палки, тут Тифон так все умно расписал, я аж застеснялся smile

Ну в целом - очевидно, что всякий if будет выполняться дольше, чем без if-а, если напрямую взять указатель. Задача же объекта в том и состоит, чтобы запомнить внутри себя как можно больше указателей, что он и делает. То есть само количество выполняемых if-ов при программировании на объектах уменьшается.

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

Tiphon · 12-10-10 19:13:41

petrun пишет:

Ручная оптимизация локальности в ФЯ думается мне мало реальна, ведь даже порядок выполнения не определяется программистом.

Просто мало ли, я подумал. Чего только не бывает в жизни=) Тем более в С люди сильно изворачиваются, чтобы огрести по полной от того, как порядок написания их программы транслируется в асм.

petrun пишет:

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

Конечно, речь идет об оптимизации. Но мы же не говорим о написании прог на машинном коде? Тогда это значит, что "код" будет работать быстрее.

petrun пишет:

Вот JIT это другое дело.

Я тут сильно обобщаю. И JIT - это часть такого обощения. Ты говоришь, что JIT - медленнее? Но вспомни про фаерфокс с JIT оптимизацией))

petrun · 12-10-10 19:30:52

Tiphon пишет:

Просто мало ли, я подумал. Чего только не бывает в жизни=)

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

func a = do
  c <- func0 a
  b <- func1
    func3 c b

Tiphon пишет:

Я просто обощаю. И JIT - это часть такого обощения.

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

Tiphon пишет:

Но вспомни про фаерфокс с JIT оптимизацией))

Плохой пример.Там JIT-компилятор js, а до это был просто интерпретатор байт-кода.

Tiphon пишет:

Тогда это значит, что "код" будет работать быстрее.

При определенных условиях.На определенных компиляторах.Много но)
DonDublon3,
А вызов класса что, бесплатен?Что бы получить тот самый указатель.Не несите чушь.

Форум StopLinux

Объявление

#1 11-10-10 11:25:03

Почему объектно-ориентированное программирование провалилось?

#2 11-10-10 11:48:56

Re: Почему объектно-ориентированное программирование провалилось?

#3 11-10-10 13:58:13

Re: Почему объектно-ориентированное программирование провалилось?

#4 11-10-10 16:51:13

Re: Почему объектно-ориентированное программирование провалилось?

#5 11-10-10 17:44:45

Re: Почему объектно-ориентированное программирование провалилось?

#6 11-10-10 19:51:51

Re: Почему объектно-ориентированное программирование провалилось?

#7 11-10-10 22:11:22

Re: Почему объектно-ориентированное программирование провалилось?

#8 11-10-10 22:24:44

Re: Почему объектно-ориентированное программирование провалилось?

#9 11-10-10 22:44:52

Re: Почему объектно-ориентированное программирование провалилось?

#10 11-10-10 23:00:03

Re: Почему объектно-ориентированное программирование провалилось?

#11 11-10-10 23:41:18

Re: Почему объектно-ориентированное программирование провалилось?

#12 11-10-10 23:44:41

Re: Почему объектно-ориентированное программирование провалилось?

#13 12-10-10 02:03:54

Re: Почему объектно-ориентированное программирование провалилось?

#14 12-10-10 10:10:02

Re: Почему объектно-ориентированное программирование провалилось?

#15 12-10-10 13:32:28

Re: Почему объектно-ориентированное программирование провалилось?

#16 12-10-10 14:05:10

Re: Почему объектно-ориентированное программирование провалилось?

#17 12-10-10 14:38:07

Re: Почему объектно-ориентированное программирование провалилось?

#18 12-10-10 17:19:24

Re: Почему объектно-ориентированное программирование провалилось?

#19 12-10-10 17:21:22

Re: Почему объектно-ориентированное программирование провалилось?

#20 12-10-10 18:17:53

Re: Почему объектно-ориентированное программирование провалилось?

#21 12-10-10 18:40:01

Re: Почему объектно-ориентированное программирование провалилось?

#22 12-10-10 19:01:06

Re: Почему объектно-ориентированное программирование провалилось?

#23 12-10-10 19:03:26

Re: Почему объектно-ориентированное программирование провалилось?

#24 12-10-10 19:13:41

Re: Почему объектно-ориентированное программирование провалилось?

#25 12-10-10 19:30:52

Re: Почему объектно-ориентированное программирование провалилось?

Подвал форума