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

Mike22 · 13-10-10 16:49:04

shell32 пишет:

можешь показать кейген в 5 килобайт умеющий то же самое?

Речь шла о быстродействии и неэффективном использовании ресурсов вообще. Можешь показать форму на дельфи, которая использует 100% реализованного?

Tiphon пишет:

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

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

Не только ООП виновато в этом. Геттеры/сеттеры, хоть и крайне удобны программисту, но гробят быстродействие в разы. Всплывающие события - туда же.

Tiphon · 13-10-10 18:29:04

Mike22 пишет:

Отложенная инициализация и jit - никак не меняют количества процессорного времени требуемого на инициализацию.

Меняют, тк.к. некоторые переменные могут быть не инициализированы вообще - это ответ на твой claim.

Mike22 пишет:

Не только ООП виновато в этом. Геттеры/сеттеры, хоть и крайне удобны программисту, но гробят быстродействие в разы. Всплывающие события - туда же.

Ты опять из прошлого века общаешься. С каких это пор геттеры/сеттеры не идут автоматом в инлайн?

И еще, если так все гладко с функциональными языками, а весь мир заблуждается, то почему тут на первом месте не функциональные языки?
shootout.alioth.debian.org/u32/which-la … =calculate

два:
shootout.alioth.debian.org/u32/benchmar … l&lang=all

Linfan · 13-10-10 19:08:02

pavel2403 пишет:

Mike22 пишет:
Я не понял, это что, утверждение, что в винде настолько хреновый менеджер процессов, что он даже не способен очистить память после окончания работы приложения и приложение само обязано заботиться о том, чтобы завершиться "чисто"?
Кто говорил об окончании??? Один и тот же обьект может инциализироваться в приложении сколько угодно раз. )
Linfan пишет:
Пашок, че-то ты откровенную херню спорол. После завершения процесса, аллокированная память освобождается. Или может в венде это новое веяние моды?
Если бы ты был нормальным программистом а не горлопаном, то ты бы знал, что данная процедура не мгновенна, и память освобождается не сразу после удаления обьекта.

Пашок, ты заявил, что "после 20 запусков вашей поделки из-за утечки памяти система может действительно начать еле ползать или зависнуть намертво и вам придется делать ребут" Данное утверждение четко заявляет о мемориликах в венде при завершении процессов. Если ты плохо владеешь русским языком и не можешь выразить точно свою мысль - иди на курсы русского big_smile

pavel2403 пишет:

Linfan пишет:
Пашок, отсутствие GC у VB - это признак убогости реализации языка, а не особенность смешанной парадигмы. У Питона и ООП и процедурное программирование и элементы функционального. Но при этом GC отлично работает.
Ну может припомним когда появился VB6 и питон, в том виде о котором ты сейчас заявляешь???

Ну давай вспоминать, раз ты старый мразматик lol

май 1991 — выпущен Visual Basic 1.0
...
В середине 1998 — вышла Visual Basic 6.0
ru.wikipedia.org/wiki/Visual_Basic

Разработка языка Python была начата в конце 1980-х годов
...
В феврале 1991 года Гвидо опубликовал исходный текст в ньюсгруппе alt.sources
ru.wikipedia.org/wiki/Python

Как мы видим, Пашок, развитие шло параллельно во времени. Посему заявлять, что VB старше/моложе - это тупо. На ГивиВасик и КуВасик можешь не ссылаться - у них вообще совершенно другая структура.

Отредактировано Linfan (13-10-10 19:14:31)

pavel2403 · 13-10-10 19:46:25

Linfan пишет:

Как мы видим, Пашок, развитие шло параллельно во времени. Посему заявлять, что VB старше/моложе - это тупо. На ГивиВасик и КуВасик можешь не ссылаться - у них вообще совершенно другая структура.

Ты идиот и не лечишся

Python — активно развивающийся язык программирования, новые версии (с добавлением/изменением языковых свойств) выходят примерно раз в два с половиной года. Вследствие этого и некоторых других причин на Python отсутствуют ANSI, ISO или другие официальные стандарты

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

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

Linfan пишет:

после 20 запусков вашей поделки из-за утечки памяти система может действительно начать еле ползать или зависнуть намертво и вам придется делать ребут" Данное утверждение четко заявляет о мемориликах в венде при завершении процессов. Если ты плохо владеешь русским языком и не можешь выразить точно свою мысль - иди на курсы русского

Ты сначала читать по-русски научись клоун, и понимать написанное. Речь шла про классы, и дальше в том же контексте, причем здесь какое-то завершение процессов, а клоун??? Опять читаем что бох-Питух на душу положит??? Приложение еще работает, понимаешь, и хавает память, врубился, жопенсурсдевелопер?
Теперь я понимаю, почему нет твоей поделки для винды! С такими познаниями ты её врядли до конца своей жизни соберешь. lol

Mike22 · 13-10-10 20:09:21

Tiphon пишет:

С каких это пор геттеры/сеттеры не идут автоматом в инлайн?

Какая разница, идет геттер/сеттер в инлайн или не идет, это вызов функции вместо изменения переменной. В случае перла, например, разница в скорости примерно в пять раз. И это в простейшем случае.

Tiphon пишет:

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

Повторю - выше скорость разработки. Эффективность приносится в жертву скорости. В вебе вообще перешли с компиляторов на интерпретаторы, с простых решений по хранению данных - на СУБД. И не важно, что скорость работы на отдельных участках просаживается в десятки раз, зато просто в разработке и надежно.

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

petrun · 13-10-10 20:20:25

Mike22 пишет:

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

Вы вообще в курсе, что такое инлайн?Это и есть "изменение переменной".

Linfan · 13-10-10 20:22:58

pavel2403 пишет:

Ты сначала читать по-русски научись клоун, и понимать написанное. Речь шла про классы, и дальше в том же контексте, причем здесь какое-то завершение процессов, а клоун??? Опять читаем что бох-Питух на душу положит??? Приложение еще работает, понимаешь, и хавает память, врубился, жопенсурсдевелопер?
Теперь я понимаю, почему нет твоей поделки для винды! С такими познаниями ты её врядли до конца своей жизни соберешь. lol

Таки да, Пашок... С русским у тебя напряги. Пока не поздно - запишись на курсы lol А то так и помрешь "жопорукой макакой" (с) Пашок

pavel2403 пишет:

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

Доооооооооо.... Ибо так сказал Пашок, известный выньдовс иксперт (в переводе на русский - васик-быдлокодер) lol

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

pavel2403 пишет:

после 20 запусков вашей поделки из-за утечки памяти система может действительно начать еле ползать

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

Гареев Станислав · 14-10-10 00:06:47

Linfan пишет:

могут зохавать всю оперативку?

В c++ как бы могут, если будут запрашивать куски памяти небезизвестной функцией.
В VB есть ограничения на размеры массивов (32000 элементов), хотя если взять массив статических переменных объектного типа и каждый из них будет содержать в себе растр (stdpicture) то можно добиться очень неплохих результатов.
ИМХО, потому что я этого не делал.

Добавлено спустя 01 мин 36 с:
Это типа, я сделаю просмоторщик изображений...

bALMER · 14-10-10 00:31:47

Гареев Станислав пишет:

В c++ как бы могут, если будут запрашивать куски памяти небезизвестной функцией.

это + или -, я не могу понять hmm

Mike22 · 14-10-10 04:47:59

petrun пишет:

Вы вообще в курсе, что такое инлайн?Это и есть "изменение переменной".

В курсе. Но это не совсем "изменение переменной". Безусловно, будет некоторый выигрыш от отсутствия стековых операций. Но беда не приходит одна, если есть геттер/сеттер, то программист обязательно засунет в него часть программной логики, даже если это не было необходимостью. Просто, потому, что так удобнее.

Tiphon · 14-10-10 06:40:19

Mike22 пишет:

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

Ну что за бред ты несешь.
А в функциональных языках програмисты не будут ничего никуда пихать?
У меня есть предложение. Оно по адекватности сравнимо с твоим высказыванием. Давайте тогда запретим программистам писать программы, чтобы они не пихали ничего в геттеры и сеттеры.

З.Ы. И даже если пихают код, ты почитай, как сейчас (в 2010 году, а не в 1988) компиляторы обращаются с инлайнами.

pavel2403 · 14-10-10 13:00:44

Mike22 пишет:

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

Безусловно, а зачем тогда они вобще нужны??? Если мне нужно просто свойство-переменная, то я не буду отдельно для каждого писАть Property Get и Property Set, а обявлю в разделе дклараций нужную переменную как Private. Я честно говоря, уже потерялся, о чем вы конкретно спорите??? Не нравиться ООП не используй, но, блин, то, что это удобно и логично, нельзя отрицать.

Отредактировано pavel2403 (14-10-10 13:35:18)

Mike22 · 14-10-10 17:21:33

Tiphon пишет:

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

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

pavel2403 пишет:

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

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

Отредактировано Mike22 (14-10-10 17:24:41)

pavel2403 · 14-10-10 17:34:06

Mike22 пишет:

Однако, Tiphon верит в какое-то идеальное ООП, позволяющее и на елку влезть, и не оцарапаться. Фанатизм, такие дела...

Ну зачем же так сразу, фанатизм? Ну нравиться человеку считать, что ООП это лучшее, на сегодняшний момент, что придумано в программировании, ну и пусть себе считает. Опять таки, все зависит от области использования. Где-то удобна процедурная(императивная) концепция, а где то ООП. roll

Tiphon · 14-10-10 18:12:06

Mike22 пишет:

Проверка в сеттере работает при каждом присвоении переменной значения, даже там, где это совершенно не нужно, даже там, где программист на 100% уверен, что значения корректны.

Ну опять ты начинаешь толкать о плохой архитектуре. И не только в ООП есть свои удобства и ты платишь за них свою цену. Бенчмарки посмотри - С и С++ первое место. Удобств нет в ассемблере, а совсем - в чистом машинном коде. Да.

Mike22 пишет:

Однако, Tiphon верит в какое-то идеальное ООП, позволяющее и на елку влезть, и не оцарапаться. Фанатизм, такие дела...

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

Tiphon пишет:

Дальше пойдем. Функциональные языки, на самом деле, имеют ряд приемуществ и ряд недостатков. лучше всего было бы их совмещать. Но совместить это в одном языке... ну до сих пор это всегда получалось криво. Поэтому было бы здорово чтобы часть модулей была написана на ООП языке, но некоторые алгоритмы могли бы быть написаны на функциональных языках.
Вопрос, как этого добиться? .so .dll библиотеки? - отвратительно! Однако в .NET можно использовать и F#, и C# в одном флаконе запросто. Туда можно намного проще запихать C/C++ (чем юзать через длл/со), который (правда под виндой, вот беда), обладая и прямым управлением памятью, и менеджером памяти с JIT, по тестам рвет анменеджед (обычный) С/С++. Ну и питон с руби тоже в кллекции. Ответной технологии в полном весе в линуксе сейчас нет.

Но в фанатизме сразу надо обвинить, да.

З.Ы. Сиди прогарммируй лучше на функциональных языках под 16 процессоров, чем спорить только ради спора.

DonDublon3 · 14-10-10 18:18:40

petrun пишет:

А вызов класса что, бесплатен?Что бы получить тот самый указатель.Не несите чушь.

Вызов класса - один один указатель плюс одно смещение при вызове извне.
Внутри же и того меньше.

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

Mike22 пишет:

1. Создание и разрушение объектов - не мгновенная операция.

Согласен. Объекты - не стероиды, надо использовать с умом, как и любой инструмент.

Mike22 пишет:

Расширение стандартных классов приводит к наследованию массы неиспользуемого функционала и переменных, что не оптимально.

Ну кагбэ ничего страшного. "Масса неиспользуемого кода" лежит себе, кушать не просит. памяти бульше тратится, это да, но я и не утверждал, что на объектах экономится память smile

Mike22 пишет:

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

Чесгря, не совсем понял, что имелось ввиду, поэтому совесм строго отвечать не буду, чтобы не попасть в просак. Но кое-какие замечания сделать таки можно.
Процедурное программирование - так процедуры ж работают с переменными, а объекты это частный случай переменных. Если что-то противопоставлять объектам (ну, более простое, ФП не рассматриваем), то это только код с голыми переменными-примитивами. Это ж разве проще? Это сложнее стократ в таком разобраться. Кто пытался рабобраться в коде на чистом С, меня поймет. Я пытался, это ваще финиш, при том что сам код в рамках "как можно было написать" был вполне ничего.

Mike22 пишет:

А теперь обоснуйте, как объекты НЕ замедляют программу.

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

Mike22 · 14-10-10 19:03:21

Tiphon пишет:

Сиди прогарммируй лучше на функциональных языках под 16 процессоров

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

DonDublon3 пишет:

"Масса неиспользуемого кода" лежит себе, кушать не просит.

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

DonDublon3 пишет:

Чесгря, не совсем понял, что имелось ввиду, поэтому совесм строго отвечать не буду

Речь о ситуациях, когда класс А использует объекты класса B и C, которым зачем-то нужно взаимодействовать друг с другом, причем опираясь на данные класса L, который напрямую не имеет отношения к классу A. И начинается бардак и чехарда со ссылками. Я сталкивался с таким много раз. Конструкция вида parent.parent.function(parent.object.somedata) - не очень понятна.

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

DonDublon3 пишет:

Это сложнее стократ в таком разобраться

Сложнее, хоть и не стократ. Если ООП подразумевает изучение отдельных объектов как цельных сущностей (я могу не знать, как устроен класс, мне достаточно знать, что он поддерживает пару-тройку нужных мне методов), то процедурное программирование подразумевает изучение как отдельной библиотеки общих функций, так и форматов данных, чтобы точно знать, что SaveUser работает только со ссылками от массива users_data, но ему не подходят элементы массива users_info, и т.д. Куда проще вызвать users_data[..].save()

DonDublon3 пишет:

Написал выше. уменьшается количество условных уператоров

Если честно, я вообще не понял откуда взялось сравнение ООП и множества if. Это, как сравнивать метр и секунду. И в ООП может быть множество if, и в процедурном программировании все может быть аккуратно и четко.

Tiphon · 14-10-10 19:27:01

Mike22 пишет:

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

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

Mike22 пишет:

И начинается бардак и чехарда со ссылками.

Поэтому умные люди рекомендуют не злоупотреблять наследованиями. Опять ты лезешь с плохой архитектурой. Да, говно архитектура бывает. Она бывает на любом языке. И вообще, что за чехарда со ссылками? Ты берешь С++ и размазываешь его на все ООП языки.
Возьми C# и покажи мне там чехорду со ссылками.

petrun · 14-10-10 22:41:05

Mike22 пишет:

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

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

DonDublon3 пишет:

Вызов класса - один один указатель плюс одно смещение при вызове извне.
Внутри же и того меньше.

Нет, а вызов нужного метода в нужном классе у вас не по уловию производится?

Отредактировано petrun (14-10-10 22:41:23)

Майор Очевидность · 14-10-10 23:11:14

Tiphon пишет:

потом оказываешься не прав

как у Вас лихо получается кругом декларировать свою правоту.

Tiphon · 14-10-10 23:50:41

Майор Очевидность пишет:

как у Вас лихо получается кругом декларировать свою правоту.

Как лихо у Тебя получается не читать, не врубаться, но лезть.

Читай 63 и 65 сообщения. (ключевое слово "читай") Если "не веришь в цитату" лезь на вторую страницу.

дохтур · 19-10-10 11:01:02

Mike22 пишет:

Речь шла о быстродействии и неэффективном использовании ресурсов вообще. Можешь показать форму на дельфи, которая использует 100% реализованного?

Можешь показать helloworld.c, использующий 100% реализованного в crt/libc? smile Насчёт ресурсов - советую смотреть в диспетчер задач, насчёт быстродействия - в книжки по программированию

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

Кстати, гонял альт у друга на 4м пне... (просил установить после демонстрации).
Хоть и всё лётает, но пока не видел загрузки процессора 100%. Хотя не исключаю что она наверное была.

Tiphon · 19-10-10 17:53:50

Гареев Станислав пишет:

Хоть и всё лётает, но пока не видел загрузки процессора 100%. Хотя не исключаю что она наверное была.

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

Гареев Станислав · 19-10-10 20:59:44

Не хотелось новую тему создавать, а спросить о том почему такое может быть интересно.

Форум StopLinux

Объявление

#51 13-10-10 16:49:04

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

#52 13-10-10 18:29:04

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

#53 13-10-10 19:08:02

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

#54 13-10-10 19:46:25

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

#55 13-10-10 20:09:21

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

#56 13-10-10 20:20:25

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

#57 13-10-10 20:22:58

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

#58 14-10-10 00:06:47

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

#59 14-10-10 00:31:47

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

#60 14-10-10 04:47:59

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

#61 14-10-10 06:40:19

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

#62 14-10-10 13:00:44

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

#63 14-10-10 17:21:33

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

#64 14-10-10 17:34:06

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

#65 14-10-10 18:12:06

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

#66 14-10-10 18:18:40

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

#67 14-10-10 19:03:21

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

#68 14-10-10 19:27:01

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

#69 14-10-10 22:41:05

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

#70 14-10-10 23:11:14

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

#71 14-10-10 23:50:41

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

#72 19-10-10 11:01:02

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

#73 19-10-10 12:05:02

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

#74 19-10-10 17:53:50

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

#75 19-10-10 20:59:44

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

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