Неверно. Доказано python'ом. Говнокод на нём пишется в разы быстрее, чем на чём-либо ещё. Благодаря ООП.

Благодаря ООП.

Глупости.

Линус Торвальдс не согласен

Линус тупо троллил, а ты повелся.

А я разве сказал, что это единственный способ реализации? Один из, всего лишь.

Линус тупо троллил, а ты повелся.

То есть, по-твоему, Monotone работает лучше, чем Git? Или в чём он неправ (Git он написал на Си, ядро линукса тоже)?

inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app

Странные какие то понятия у этого вашего товальдса. Грамотно спроектированная ООП - система наоборот, какбы, избавляет от ада зависимостей.

written in C++

Да и пора бы ему уже усвоить, что ++, это, мягко говоря, не совсем ООП. Или совсем не ООП, хз. Непоказательный пример.

but now all your code depends on all the nice object models around it

интересно, его не смущает, что код, написанный для Linux, зависит от этого самого Linux?:)

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

То есть, по-твоему, Monotone работает лучше, чем Git?

То есть Monotone (с OpenCM) послужил прототипом всех современных DVCS. У него вообще интересная история.

Или в чём он неправ (Git он написал на Си, ядро линукса тоже)?

Вся мессага по ссылке - тупой троллинг.

Все эти наезды на ООП сводятся к одному простому факту: очень мало кто умеет в грамотную ОО декомпозицию, тут нужен особый талант и опыт. То есть ООП следует применять с огромной осторожностью и только там, где это абсолютно необходимо. Однако, индустрия пошла по пути массового внедрения и пропаганды ООП, и в этом главный фейл. Ключевой момент истории - это взлёт Си с классами, а не чего-то вроде Го. Теперь это осознали, пытаются переиграть, но поздно уже.

app

Это какой-то менеджер писал или вантуз.

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

Абсолютно согласен! Помню переход с Си на Си++ и рассказы про то, что «нельзя писать на Си++ как на Си с классами, надо писать в стиле Си++».

И только анонимус гордо писал на ассемблере и очень старался не изобрести ООП и там. Когда-нибудь. Когда-нибудь они все поймут, но будет поздно!

см. linux kernel, там и не такое решают средствами простого С и макросами. Да и я б не сказал что сильно спагетти выходит. Но если для ядра это полностью оправдано, за для БД это уж точно не катит.

зависит от этого самого Linux

Только glibc. А для всего остального интерфейс предоставляет glibc.

now all your code depends on all the nice object models around it

Он немножко про другое. В Си я просто пишу paint_triangle_to_screen, paint_triangle_to_ps, paint_circle_to_ps. В Си++ я должен решить, чей метод будет paint: screen.paint(triangle) или triangle.paint(screen). А может manager.paint(screen, triangle). А если я потом передумал, то переписывать придётся почти всё. И так с любыми функциями, которые работают с несколькими объектами.

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

Он немножко про другое.

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

А если я потом передумал, то переписывать придётся почти всё. И так с любыми функциями, которые работают с несколькими объектами.

Это заморочка уровня

В X я просто пишу foo.something(bar), а в си я вынужден писать foo_something(bar), и если я вдруг захочу наоборот bar_something(foo) придетсявсе переписывать.

Кстати, в *нормальном* ООП это можно решить простым свопом.

tmp = foo
foo = bar
bar = tmp

Ну, в простом случае, конечно. Можно всякие resend'ы. Вариантов тьма. Как раз си в этом смысле гораздо менее гибок.

Можно всякие resend'ы

Да уж, просто добавим ещё один уровень косвенности, делов то.

Классической ООП в стиле smalltalk — идеально (или близко к этому).

«In Smalltalk, everything happens somewhere else». Кстати, руби унаследовал от него ровно ту же проблему: обертки над обертками вокруг оберток... Кажется, это фундаментальный баг смолтокобразного ООП - удобные средства делегирования просто сносят крышу пограмистам, они уже не могут остановиться. Это даже хуже развесистых иерархий из жабьего мира.

Приведи мне пример не-говна. Единственный известный мне приличный пример написан в ООП-стиле и даже не на ООП языке.

ЧИТД сам не осилил еще и булькал в команде такихже

угу. Я из этой херни свалил и пишу драйвера на сишечке. Мне хорошо.

да вы еще и размножаетесь

Угу, орешками.

Если смотреть очень широко - то вообще всё есть ООП.

А так оно и есть:) Просто пейсатели иногда думают, что они пишут в другой парадигме, а на деле, их писанина — это все равно частный случай ООП:), просто они не осознают этого, как человек, не видящий за деревьями леса:)

anonimous - большой пузырь. Который лопнет.

унаследовал от него ровно ту же проблему

В чем проблема? Ты выступаешь против совместно используемого кода? Если маша и даша варят щи одинаково, то зачем каждой из них в поведении своя отдельная варка щей?

Доброго времени! По Вашему мнению, имеет ли смысл возня вокруг ООП?

По вашему мнению, имеет ли смысл возня вокруг заглавных букв (и вообще правил употребления слов)? Вы употребляете их как-то усложненно (наверное много слоев абстракции, виной чему непонимание смысла заглавных букв в местоимении «вы»): «Вашему» - это при личном официальнмо обращении к одному лицу (и монаршим особам). К неограниченному кругу лиц (быдлапростолюдинов) - «вашему». Не кажется ли вам, что какой-нибудь падонковский слэнг тащемта например дичайше более лудшы подходит для объяснения вам с колокольни давнего поборника изящной словесности, который от этого «Вашего» всего подустал. Хоть в спортлото пиши...

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

Приведи мне пример не-говна.

муха пишущая говнодрайвера просит пример не говна, поздно метаться

Маша кладёт сначала капусту потом картошку, Даша сначала кладёт картошку, а потом капусту, а Галя так вообще зажарку делает по-хохляцки на сале и кладёт сначала картошку. Но при этом все они варят борщ.

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

Засчитывай 8)

Собственно, индивидуальное поведение можно дернуть из общего.

Ну что за хурма. Вылез, начал срач и сразу в кусты. Аж неинтересно.

На моей памяти, попытки излишнего обобщения поведения и приводят к трэшу вида «фабрик конструкторов абстрактных классов».

В чем проблема?

Так в этом самом «everything happens somewhere else». Тыщи крошечных методов, делегирующие другим тыщам крошечных методов, реализованных где-то в дебрях модулей, подключаемых к каким-то классам. Чтобы разобраться, а что же делает вот этот маленький метод, нужно чуть не всю систему сразу мысленным взором охватить. При этом помним, что у нас динамическая типизация, и в рантайме могут происходить разные чудеса, что ещё меньше способствует ясности. Такой вот смолтоковский подход - это очень извращенное понимание модульности.

Как так, а удовольствие от осознания твоей правоты о Жертва Ооп?

Скорее разочарование. Только настроился поспорить, как оппонент слился. Неинтересно жи.

Никто не заставляет делегировать. Наследовать делегированием надо только там, где это уместно. Никто не запрещает иметь объектам собственную реализацию поведения. То есть недоооп — это частный случай того же Ъ, просто кастрированная версия.

И главное достоинство делегирования — а метаобъекты.

Есть мнение, что Линуса потихоньку накрывают возрастные изменения. Я бы не хотел к 5-му десятку заниматься прикладухой.

Чтобы спорить, милок, надо аргументы приводить, а не «ооп - говно». А иначе ты как сейчас - останешься единоличным победителем с кучей ооп.

А он разве не *архитектор*?

ой вэй, кисо обиделось.

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

Никто не заставляет делегировать.

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

я просто пишу foo.something(bar), а в си я вынужден писать foo_something(bar)

Не foo_something(bar), а foo_something(foo, bar); И. как я уже сказал, нет необходимости выяснять, кто владелец функции.

в *нормальном* ООП это можно решить простым свопом.

В смысле, безтиповом? Или как ты значения screen и triangle решил поменять? Или я не понял про что речь?

Да.

Вот видишь - ты уже все понял.

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

Не foo_something(bar), а foo_something(foo, bar); И. как я уже сказал, нет необходимости выяснять, кто владелец функции.

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

Или как ты значения screen и triangle решил поменять?

Не значения, а имена. что впрочем, в данном случае не важно.

Да, но это типа, шутка была:) В общем случае так не получиться конечно, это просто манипуляция именами

Ну... У архитекторов тут схожие проблемы.

ООП это инструмент. Но среди программистов распространено поверье, что инстумент важен сам по себе.

Язык формирует мышление. К естественным языкам это тоже, к слову, относится. Так вот ООП формирует мышление в категориях абстракций и делегирования по любому поводу. Причём это неустранимо, так как почти любой учебник по ООП начинается с: «Возьмём простую программу, перепишем её через классы, получилось на порядок больше кода. Зато, если, вдруг, нам когда-нибудь понадобится что-нибудь поменять, то это будет намного проще». Если программист эту идею не принял, то он забивает на ООП-подход и использует его по-минимуму, так как писать лишний код глупо, если можно не писать. Если же принял, то весь код пронизывается этой идеей «если, вдруг, нам когда-нибудь понадобится что-нибудь поменять»: все константы становятся параметрами конструкторов с значениями по-умолчанию, все алгоритмы дробятся на куски с параметризацией по всему, чему можно и т.д.

Особенно этому способствовало проникновение ООП в вэб, где у программистов осбый склад умабезумия.

Да конечно, все знают, что веб пишут только дауны. То ли дело формошлепство, вот там по-настоящему крутые парни.

к динамическому (в рантайме)

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

и поддержки кода

Кто ограничивает тебя в средствах абстракции в фп/процедурном программировании.

ой вэй, кисо обиделось.

КО из специалиста по говну никакой, пиши драйвера лучше 8)