Просмотров: 118713

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


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

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

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

объектно-ориентированное программирование ООП объекты провалилось схема диаграмма OOP objects методология программирования SOLID failed

Битва при рядовой конференции

Автор этой нашумевшей статьи, доктор компьютерных наук Стэнфорда, старший архитектор по разработке ПО сначала Sun, а потом и IBM, Ричард Гэбриел, никогда не скрывал своего скептического отношения к парадигме ООП. В 2002 году, по прошествии 2 лет после первоначальной публикации своей критической статьи, автора пригласили выступить, теперь уже живьем и перед большой аудиторией, — изложить свои критические взгляды на ежегодной конференции OOPSLA (центральная конференция IT-специалистов по объектно-ориентированным языкам и методологиям разработки ПО).

И, чтобы по старой доброй американской традиции, превратить это в горячее шоу, в качестве его оппонента одновременно пригласили Гая Стили, отца-разработчика языка Scheme, крупнейшего специалиста-теоретика по ООП, авторитет которого в американской академической среде непререкаем. Чтобы максимально отразить позиции выступающих, их решили усилить ещё двумя выступающими.

В качестве «анти-объектника» дополнительно пригласили Пола Грэма, крупнейшего специалиста по Lisp, автора многочисленных книг и стандартизаций Lisp, кстати, согласно Википедии в 1995 году создавшего вместе с Робертом Моррисом первое в мире web-приложение — Viaweb, которое затем выкупило у них Yahoo (как мы все знаем, Роберт Моррис, близкий друг и коллега Пола, этим историческим достижением не ограничился, до этого он уже успел написать пожалуй самый знаменитый сетевой червь в истории интернета, но это уже совсем другая история).

В стан объектников также пригласили Джеймса Ноубла, автора одних из первых книг и работ по теории ООП. Многие участники вспоминают, что конференция этого года надолго запомнилась им по тому уровню обсуждения, которое завязалось тогда в этой публичной «интеллектуальной дуэли» фактически диаметрально разных школ программирования.


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


ООП как... методология мифология разработки

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

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

Например, он говорит:

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

Хотя иногда объектно-ориентированный код действительно годится для повторного использования, таким его делает вовсе не объектно-ориентированность, а программирование в стиле „снизу вверх“. Возьмём, например, библиотеки: их можно подгружать и повторно использовать сколько угодно, потому что, по сути, они представляют собой отдельный язык. И при этом, совсем неважно, написаны ли они в объектно-ориентированном стиле или нет.»
объектно-ориентированное программирование ООП объекты провалилось схема диаграмма OOP objects методология программирования SOLID failed
Классик программирования Дейкстра, чрезвычайно остро не любит только две вещи: ООП и Калифорнию

Другой крупный критик ООП — это известный специалист по программированию — Александр Степанов, который работая в Bell Labs участвовал в создании C++ вместе c Бьерном Страуструпом, а впоследствии, уже по приглашению в HP Labs, написал Standard Template Library (STL).

Александр Александрович полностью разочаровался в парадигме ООП, в частности он пишет:

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

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

Ричард Столлман также известен своим критическим отношением к ООП, особенно он любит шутить насчет мифа объектников что ООП «ускоряет разработку программ»:


«Как только ты сказал слово „объект“, можешь сразу забыть о модульности»

«ООП ради самой ООП уже давно превратилось в замкнутый круг. Конечно, можно считать C# в .NET 3.5 с более чем 50,000 реализованных классов „венцом эволюции“. Добавить в следующей версии .NET ещё миллион классов — что может быть более правильным и более вожделенным, с точки зрения ООП-программиста? Говорите, это и есть то самое бегство от сложности?» (на этом месте интервью Ричард демонстративно делает паузу и выкашливается от приступа смеха).

Java/C# не являются ни развитием, ни «осознанием ошибок» C++. Они взяли наихудшую парадигму из языка и возвели ее в степень настоящей догмы. А именно — идею наследования.

Наследование — это самая большая провокация в индустрии. Ни в каком моделировании наследования не существует (и в реальной жизни его нет тоже) — ни в электронике, ни в бухгалтерии, ни в политике, ни где бы то ни было еще. Есть лишь одна область, где наследование теоретически встречается — генеалогия (эй, парни, лучше не путать это с гинекологией). Но это не имеет ни малейшего отношения к тому, что называется наследованием в программировании. Все эти многоэтажные иерархии классов только усложняют жизнь программиста, вместо того, чтобы упрощать по своему замыслу.

Томас Поток из MIT даже провел масштабное прикладное исследование, которое продемонстрировало, что нет никакой заметной разницы в производительности между программистами работающими в ООП и в обычном процедурном стиле программирования. «Это просто миф, который отлично работает вкупе с невежеством масс — если вы никогда не видели ничего кроме ООП, как же вообще вы можете в ней сомневаться?».

Никлаус Вирт, создатель языков Паскаль и Модула, один из создателей структурного программирования, утверждает, что ООП — не более чем тривиальная надстройка над структурным программированием, и преувеличение её значимости, выражающееся, в том числе, во включении в языки программирования всё новых модных «объектно-ориентированных» средств, безусловно, вредит качеству разрабатываемого программного обеспечения. Никлаус очень удивлен тем вниманием, которое уделяется ныне ООП.

объектно-ориентированное программирование ООП объекты провалилось схема диаграмма OOP objects методология программирования SOLID failed
Идеальная разработка с точки зрения ООП...

Ещё один ветеран программистского ремесла, Джоэл Спольски, рассказывает, что во время его работы в Microsoft его так достали тамошние адепты-инженеры ООП, что даже сейчас, по прошествии почти десяти лет, его передергивает от людей, «с головой погрязших» в этой парадигме. Джоел — автор популярного в англоязычной литературе шутливого термина Архитектурные Астронавты, который пошел гулять из его популярной статьи «Не дайте Астронавтам Архитектуры вас запугать», посвященной именно тем самым архитекторам-инженерам из Microsoft, которые так упорно преследовали Джоела со своими абстрактными ООП-концепциями и шаблонами.

О том самом выступлении...

Почти все пункты своего выступления и претензии к ООП как к парадигме, Ричард Гэбриел, позже, заново систематизировал, с учетом имевшего место широкого обсуждения и критики, после чего все было сведено в брошюру, которую Ричард выложил в свободный доступ вместе с поясняющими её слайдами (очень краткое содержание его выступления можно найти и в переводе на русский язык). После этого очень сильного выступления у него появилось очень много последователей, которые попытались систематизировать все мифы и дефекты ООП в своих многочисленных статьях и работах.

К сожалению, вероятно из-за того, что как я уже сказал выше, ответное выступление объектников «Почему ООП не провалилось» получилось несколько скомканным из-за интеллектуального натиска Lisp’еров, выступающие так и не оформили впоследствии свою позицию преимуществ ООП в развернутом виде. В интернете сохранилось лишь очень краткое содержание-конспект их выступления, которое также существует как в английской оригинальной версии, так и в русском переводе.

Сектантство в академической науке

Чтобы вскрыть корни подобного «культа отдельно-взятой технологии», Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла «тихая революция». Молодые сторонники теории относительности, массово пришедшие в номенклатуру университетов, тогда постепенно захватили власть в области преподавания физики, навязав свою малоизвестную, но столь любимую интеллектуалами того времени теорию относительности уже широким массам физиков.

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

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

«Ну и где мы теперь, с этой вашей красивой теорией относительности, кто-нибудь может мне назвать хоть какие-то реально-практические результаты её применения в вашей обыденной жизни после целого века её ковыряния и массового насаждения?» — как всегда язвительно вопрошает Гэбриел.

По мнению Ричарда, абсолютно с точностью тоже самое произошло и с ООП, которая в 80-ых годах была провозглашена «серебряной пулей» в «борьбе со сложностью программистского бытия», была искусственно и безальтернативно навязана в академической среде, причем мифы, которые кочуют из учебника в учебник по ООП — «часто забавны и высосаны буквально из пальца».

Вместо заключения

Только время покажет, кто в итоге окажется правым, а кто в этой горячей методологической дискуссии — искренне заблуждался. Но в любом случае, лично я за то, чтобы у нас всегда оставались возможности для альтернативных взглядов, пусть даже отличных от выбора большинства (как провокационно замечают американцы в таких случаях — «лемминги не могут ошибаться»).

объектно-ориентированное программирование ООП объекты провалилось схема диаграмма OOP objects методология программирования SOLID failed

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

~

Update: Продолжение темы — не менее известный текст Why OO Sucks, вот его русский перевод + дополнение.

Ещё подборка внешних текстов на эту тему в довесок: Я не понимаю ООП, также советую глянуть Manifesto for Not Only Object-Oriented Development. И, наконец — Microsoft: Object Oriented Programming is Dead и ООП-рабство программистов. Лично мне очень доставляет материал по вышеописанной теме, — «Кризис объектно-ориентированного программирования» — рекомендую.

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

твит прикол ооп объектно-ориентированное программирование объекты провалилось схема диаграмма OOP objects методология программирования SOLID failed
twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru ya.ru pikabu.ru blogger.com liveinternet.ru livejournal.ru google.com bobrdobr.ru yandex.ru del.icio.us

Подписка на обновления блога → через RSS, на e-mail, через Twitter

153 комментария

Следите за комментариями по RSS
  1. Дмитрий

    Ну что можно сказать - в принципе, ООП себя доказало. И вряд ли кто-то сейчас будет писать LoB приложение на Lisp, не так ли?

  2. Чуваки кроме "мифа ООП" разоблачили заодно "заговр энштейнологов". Какой пипец у людей в голове творится, только пальцем у виска покрутить остается.

  3. Немного не хватает завершенности в статье: можно ли увидеть ссылки на источники статей о «мифах и дефектах ООП»?

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

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

  5. Владимир

    Рекомендую посмотреть лекции Степанова в Яндексе

    http://video.yandex.ru/users/ya-events/tag/а.степанов/

  6. не познал lisp-а -- жизнь прожил зря?

  7. Статья конечно зачетная. Неудивительно, что судя по вышестоящим комментариям отечественные гении ООП повылазили из всех счелей, и с трудом сплетая слова, ярко демонстрируя кристальность и организованность своей мысли, попытались сформулировать путанные и туманные возражения, типа “а со-создатель С++ был-то на самом деле таким ебанатом…”. Да, большинство не хочет думать и выбирать – выбор им навязали и они его схавали непрожевывая даже.

    Конечно, ООП далеко не панацея и не серебряная пуля от всего… но всё же, у меня есть серьёзный вопрос к автору: поливая грязью, предложи альтернативу. Альтернативы ущербному ООП никакой в статье нет и даже не намекается … подумав немного на что же мне тут намекают – но в голову лезут только почему-то разные Васики и goto – вот уж где никаким ООП не пахнет и близко. По-твоему ЭТО идеал? И где же выход? В связи с этим, если напишешь вторую часть статья с этим конструктивным довеском – тогда цены тебе не будет.

  8. 2Ugine, типа ответ от автора:

    На самом деле, эта статья – чисто исторический обзор двух известных выступлений “Почему ООП провалилась“ и “Почему ООП не провалилась“ – здесь не даётся анализ самих парадигм и собственно программирования, и такая цель даже близко не ставилась. Просто забытая история… которую порой, по моему мнению, очень полезно напомнить современникам. Что касается самой сути дефектов ООП и альтернатив – в статье огромное количество ссылок на так называемую конкретику, и желающие (реально ЖЕЛАЮЩИЕ разобраться) найти альтернативу могут попытаться это сделать вмести с этими известными людьми, все эти работы написавшими.

    И, наконец, статья писалась для печатного издания (и она, думаю, выйдет в печать уже в октябре), поэтому был очень жесткий лимит по размеру – не более 8-9 тысячи знаков с пробелами. Поэтому пришлось вот так вот всё жестко втиснуть в эти пределы, пожертвовав глубиной погружения в суть программистского вопроса, в пользу просто исторического обзора события. Но опять же: желающему копнуть – ссылок умышленно насеяно немеряно :-)

  9. > Ну и где мы теперь, с этой вашей красивой теорией относительности,

    Зачет. Автор цитаты gps'ом не пользуется, видимо.

  10. >"Ну и где мы теперь, с этой вашей красивой теорией относительности, кто-нибудь может мне назвать хоть какие-то реально-практические результаты её применения в вашей обыденной жизни после целого века её ковыряния и массового насаждения?"- как всегда язвительно вопрошает Гэбриел.

    После такого заявления остаётся только заставить его выкинуть спутниковый навигатор и тихо убиться.

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

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

  12. > Объясните мне сирому и убогому - как позиционирование на местности связано с теорией относительности?!

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

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

    http://www.astronomy.ohio-state.edu/~pogge/Ast162/Unit5/gps.html

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

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

  15. Владимир

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

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

  16. фанатам доказательства СТО через GPS я очень люблю разсказывать историю об огромной практической точности астрономических вычислений по Птоломею. "Наши эпициклы дают практический результат значит они ВЕРНЫ." Ага?

  17. 2 Massy

    > Я физик по специальности,

    Вот и отлично. Тогда почитайте как работает GPS и почему без СТО он бы не работал.

  18. Иван Блинков

    http://www.insight-it.ru/programmirovanie/oop-ili-ne-oop/

  19. ТруАноним

    Проходил мимо... И в самом деле всё стало вдруг очень интересно: неужели этот затертый пример с GPS - это реально ВСЁ, что есть в приложении теории относительности на этой земле?! Я просто замер весь в ожидании - этот в сущности пустячный пример толдонят в сотый раз здесь, как будто это какой-то жопораздирающий прорыв и эпохальный бля рывок в развитии нашей цивилизации... неужели и в правду автор статьи прав - от теории относительности нет никакого практического проку, крому мегатонн книг по ней и заумных хитрых дядек из универов, якобы понимающих там что-то такое хитрое и жуутко глубокое, что такой смердь как ты никогда не поймешь даже (не пытайся даже!)?

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

    p.s. Приду завтра ответ смотреть, я на грани, учтите.

  20. Те кто достаточно глубоко понимают и разбираются в том, как работает GPS и ООП, и как вообще всё устроено, не спешат вставать ни под чей флаг.. и уж тем более не станут писать комментарии подобные "Ну что можно сказать - в принципе, ООП себя доказало." или "Зачет. Автор цитаты gps'ом не пользуется, видимо." или "... в спутниках GPS учитывается релятивистское замедление времени. То бишь, используются достижения СТО." хотя последний, по крайней мере, вежлив...

  21. Я надеюсь, никто не будет спорить, что Линукс всё же лучше, чем Windows? :-)

  22. 2 ТруАноним

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

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

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

  23. Мда... А кто-нибудь из сторонников "провала ООП" может привести пример крупного приложения уровня enterprise, написанного в процедурном стиле? Неужели есть такие извращенцы? Как иначе назвать людей, поддерживающих проект на 100-200 тысяч строк кода в процедурном стиле?

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

  24. я считаю что кому не нравится может не использовать ооп, мне же больше всего в нём нравится наличие конструкторов.....а так я очень редко его юзаю

  25. Гуманитарий

    Чисто мировозренченское наблюдение.

    Послушайте, я правильно понял, что объектников публично "наклонили" прямо на их главном съезде? Это как если бы я явился в главный муслимскую мечеть и жизнерадостно пернул бы там посредине толпы бородачей? Мне интересно, разве можно безнаказанно так унижать чужую религию, например ООП, да ещё на территории верующих, и при этом, это описывается в статье, как "открытая дискуссия с противниками (ООП) под смех зала".

    Уже только за это можно уважать западную демократию: публично доказать на сборище объектников, что они казлы и нихера не понимают в программировании, и за это они даже не выколят тебе глаза, а будут "одобрительно смеяться". Мама мия, как чуден мир и толерантность в частности!

  26. Тимофей

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

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

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

    Замедление времени в гравитационном поле -- это факт, который был заложен в основу ОТО (наблюдения за прецессией Меркурия показали это замедление времени до того как Эйнштейн придумал ОТО), это замедление времени есть аксиома, поверх которой можно построить ОТО. А можно отвергнуть ОТО и построить какую-нибудь Новую Всеобъемлющую Теорию Всего. И я подозреваю, что замедление времени при возрастании скорости -- это тоже факт, аксиома, заложенная в основу ОТО. Правда это я уже не возьмусь утверждать, ибо с ОТО знаком лишь в рамках школьного курса.

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

    ___________

    *) Я заявил, что Вы приписываете к заслугам ОТО факты, которые не являются её заслугам, и поступаете ровно как сторонники ООП. В связи с этим у меня возник вопрос: а вы сами поклонники ООП или нет? Может это такое свойство поклонников ООП -- путать причину со следствием, вначале объявляя их производными классами от одного базового типа, и попадая впоследствии в ситуацию, когда по указателю на базовый класс уже без спец.средств (100гр?) и не разберёшь -- кто из них кто.

  27. Гослинг

    В продолжении темы!

    http://rainman-rocks.livejournal.com/122876.html

  28. =) Сейчас уже истребители развивает скорость в три скорости звука, так как в природе все экспоненциально, то уже и до скорости света не далеко, поэтому СТО себя еще проявит.

    Я физик, ооп - не люблю, пишу на perl в процедурном стиле.

  29. Математик

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

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

  30. ЗАДОЛБАЛИ!

    Почитал комменты спешно, и меня просто взбесила-задела-завела примитивная порой логика и реплики объектников, типа "приведи примеры интерпрайз-приложений написанные не на ООП, тогда и поговорим" или там "Степанов - ебанат" и прочее... в связи с этим решил разразиться немного флэймом, надеюсь модератор этого блога не удалит это моё обострение и оно пойдёт даже всем на пользу (вероятно), итак:

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

    Во-вторых. Можно конечно сказать, что главный разработчик IBM и Sun - сосет, а со-разработчик С++ и создатель STL настолько наивен, как пишут в комментариях, что не знает просто элементарных вещей про аксиомы, -

    АХ, НО КОНЕЧНО ЖЕ ТОЛЬКО _ТЫ_, ВАСЯ ПУПКИН ИЗ МУХОСРАНСКА, ЗНАЕШЬ ИХ ВСЕ!!!

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

    У меня всё :)

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

  32. 2вася: А во-вторых что??

  33. старческий маразм

    1) аксиомы не нужно доказывать, они не доказуемые, и все доказательства строятся на них

    2) рефакторинг нужен и без ООП

  34. Любитель_механики

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

    http://www.popmech.ru/article/7872-sverhtochnyiy-eksperiment/

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

    Что меня действительно удивило в этом посте, дак это высказывание про теорию относительности.

    И меня теперь мучает вопрос: а как же атомные реакторы, как же атомная и водородная бомба, E=mc^2? Разве эти достижения современной техники не были созданы на основе теории относительности?

    Господа физики, пролейте пожалуйста свет на эти вопросы, научите бестолкового уму разуму.

  36. > А кто-нибудь из сторонников "провала ООП" может привести пример крупного приложения уровня enterprise, написанного в процедурном стиле?

    Ыммм... а ядра Linux и Windows, равно как и масса системных библиотек, разве не в нём самом написаны?

  37. "а как же атомные реакторы, как же атомная и водородная бомба, E=mc^2? Разве эти достижения современной техники не были созданы на основе теории относительности?"

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

  38. "Замедление времени в гравитационном поле -- это факт, который был заложен в основу ОТО (наблюдения за прецессией Меркурия показали это замедление времени до того как Эйнштейн придумал ОТО), это замедление времени есть аксиома, поверх которой можно построить ОТО."

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

    Касательно того, что квантовая физика и ОТО несовместимы, то есть же суперструнные теории, теория квантовой гравитации и т.п. теории всего, которые пытаются объединить вместе ОТО и квантовую. После того как пойдут результаты с БАК (скажем открытие суперсимметричных частиц), тогда можно будет двигать теории дальше.

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

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

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

    Вообще перед тем, чтобы говорить лучше почитайте хоть какие-то материальчики :D

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

  39. > Ыммм... а ядра Linux и Windows, равно как и масса системных библиотек, разве не в нём самом написаны?

    Вы еще BIOS упомяните, который вообще на ассемблере написан.

    Скажем проект уровня Adobe Photoshop или Microsoft Visual Studio

    Мне кажется они побольше ядра занимают

    Вдобавок, как я понимаю, ядро пишется так из-за скорости работы не ООП программ. Хотя тот же Symbian вроде как написан весь с использованием ООП

  40. > Господа физики, пролейте пожалуйста свет на эти вопросы, научите бестолкового уму разуму.

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

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

    Жесть а не фраза :) Скорость звука (чуть не написал 'вакууме') ~330м/сек, т.е. эффекты теории относительности будут ~0,0000000000006 от обычных и какой дурак будет их использовать?

  41. Респект, Василий. Статья и весь этот спор носят явно провокационный характер. Впрочем, статья содержит слово "шоу".

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

    Без понимания этих основ невозможно плодотворно работать и СОЗДАВАТЬ новое. Всем, кто повелся на этот клоунский замут скромно рекомендую крепко задуматься - что у вас всегда следует впереди: разум, или эмоции?

  42. Вася Пупкин из Мухосранска

    Большой адронный коллайдер придает протонам энергию 7 TeV и они летают со скоростью 0.999999991 c. У кого эфирный ветер в голове, пусть строит свой коллайдер.

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

    > "Наши эпициклы дают практический результат значит они ВЕРНЫ." Ага?

    Именно! Эпициклы Птолемея - абсолютно верная теория. Верная - по определению - означает соответствующая практике.

    А для Гэбриэла есть Flat Earth Society.

  43. 2Пыщ-пыщ

    Ядро Windows хз начем написано (кто исходники видел?).

    Linux, ядра OpenSolaris, Minix3, OpenBSD написаны на C в процедурном стиле, да.

  44. Ariel Feinerman

    Где Алан Кей, Бред Кокс, Годфри ван дер Линден и остальные? Ни слова о Smalltalk, Objective-C. От ооп были какие-то девственники теоретики. Степанов - без сомнений ебанат, если честно.

  45. Sw00p aka Jerom

    у ПОПэшников при вопросе чем лучше ООП, говорят - скорость

    а когда задаёшь вопрос, а что есть скорость ? вот тут и затыкаются

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

    скорость программ ? хрен - самая убогая программа на С будет быстрее работать любой ООП-шной программы на пэхэпэ (если нужна скорость и оптимизация - узайте асм - вот там вы и забедете про свои классы и объекты)

  46. Sw00p aka Jerom

    >>И меня теперь мучает вопрос: а как же атомные реакторы, как же атомная и водородная бомба, E=mc^2? Разве эти достижения современной техники не были созданы на основе теории относительности?

    когда Эйнштейн рассказал об относительности, то он поставил на колени всю физику Ньютона

    скоро будет время когда и относительность Эйнштейна поставят на колени

    пс: зарикаться не надо, тупо упираться не надо и действовать всегда надо от противного

  47. > Ядро Windows хз начем написано (кто исходники видел?).

    Читал в нескольких довольно авторитетных источниках, что на чистом С. Весь API, опять же, сишный, что кагбе намекает.

  48. ЛегионАнонимусов

    Бессмысленный срач какой-то, вопросы "что лучше?", всякие холивары и матановые доказательства утверждения, которое даже точно не сформулировано. На хрена тешить свое ЧСВ и выступать с мегаэпичными докладами по, в общем-то, бессмысленной теме(достаточно подумать о том, что изменилось после всех этих конференций - да ничего, посрались, мелькнули в новостях, да и всё)? И противоположные стороны очевидно чем руководствуются - (илитизм vs. попсовость) у всяких лисперов, (простота vs. матаны) у адептов ООП. Это в доме2 каком-нибудь прокатило, спорить в зомбоящике, какого цвета поклеить обои в сортире, а прохвессорам программных наук такое не пристало. Я сам ООП не особенно-то люблю по ряду причин, но так же и процедурные\декларативные\функциональные реализации имеют свои недостатки, которые при неуместном и неправильном применении увеличиваются на порядки.

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

    Сам много раз сталкивался с тем, что продумываешь модель, объект, вроде бы все, а потом через кучи написанного кода понимаешь, что объект-то не совсем подходит для выбранного алгоритма работы.

    PS.

    Не плодите тысячи классов!!! Это может и чем-то ускоряет разработку, но часто сильно усложняет понимание кода (например чтобы понять как рисуется в коде прямоугольник на экране, нужно разобрать половину объектов в программе)

  50. Константин

    Я не ходил по ссылкам и не хочу ходить. Мне чужда сама идея того "шоу", которое обсуждается в статье. Мое видение ООП таково, что это просто парадигма. А пользоваться этой парадигмой или нет зависит от программиста.

    Теперь немного о том, что я думаю о крупных проектах. Я знаю много примеров крупных проектов написанных на чистом C и на С++. Обычно коммерческие продукты пишутся на плюсах, а опенсорсные на чистом си. Но вот в чем парадокс. Многие крупные чисто сишные проекты используют парадигму ООП! Не верите? Посмотрите, например, сырцы dovecot или, что греха таить, сырцы ядра linux. Вот только ООП в таком коде настолько уродливо читается, что без стакана водки не разберешься. И самое главное, что такой проект титанически сложно сопровождать НЕ автору кода.

    Я не сторонник ООП, но и не противник. Для меня самое главное подобрать композитное решение. Там ООП, там STL, а тут можно и на процедурном си.

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

  51. Одинокий Админ

    Превращаем обсуждение в Холиварчик - ООП против СТО и ОТО?

    2Sw00p aka Jerom

    Никогда ещё не сравнивал собаку и верблюда. Уважаемый автор комментария сравнил компилятор выдающий исполняемый бинарный файл и интерпретатор по скорости выполнения. Я рад за него.

    Во вторых как измерять скорость, что сравнивать?

    for(i=1;i

  52. Бармаглот

    @Sw00p aka Jerom

    а объясните мне, милейший, с помощью каких концепций ПОПшник "по полочкам расписал на бумаге всю логику программы"? Или если на бумаге без слова class, то это уж не ООП ни разу?

  53. Дмитрий

    Очень хорошая статья. Из-за комментариев к ней...

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

    Значит можно посчитать процент "интеллигентов" (сидящих и не встревающих).

    Из кол-ва комментаторов можно посчитать процент "разумных буйных" и процент "буйных зомби". "Разумных буйных", как обычно, пренебрежительно мало. Как следствие -"лемминги не могут ошибаться" (зачетное выражение). Вторая его часть: " Есть еда - размножаемся. Нет еды - сваливаем"...

    А про ООП:

    - Степанову огромный респект и уважуха. Не просто вот так вот встать и сказать "А ведь все это лажа". И ведь это таки "да".

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

    - мальчиков-программистов нужно сечь ремнем за неправильное построение кода и слепое повиновение методикам. (Написал, а сам думаю: может это и к лучшему, что таких мальчиков - множество. Тупыми управлять проще (но скучно)).

  54. Владимир

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

    Что такое объект? Это структура, содержащая какие-то поля и указатели на функции их обработки. Эта структура средствами языка защищена от неправильного обращения и выкрашена блестящей краской.

    Вот и программисты на Plain C тоже пользуются ООП. Вместо

    class foo

    {

    int number;

    bool set_number(int n);

    };

    они напишут:

    struct foo

    {

    int number;

    bool (*set_number)(struct *foo, int n);

    };

    И вместо наследования и полиморфизма будут применять присвоение указателей на разные функции. Инкапсуляция на Plain C тоже в большинстве случаев получается лучше. Например, в h-файле можно объявить несколько функций, принимающих безтиповый указатель, а в c-файле этот безтиповый указатель внутри функции будет приводиться к указателю на структуру определённого типа. В результате из h-файла вообще будет невозможно узнать о том, что там есть внутри этой структуры. В то же время в C++ все потроха наверняка класса придётся объявлять в h-файле, что будет способствовать использованию программистом-пользователем класса его внутренних особенностей, что в корне подрывает саму идею инкапсуляции.

    Вопрос сводится к тому, что когда ты пишешь на Plain C, тебе не придёт в голову пользоваться объектами там, где без них можно обойтись. В результате программисты, предпочитающие процедурный стиль, часто склонны создавать библиотеки процедур, которыми потом по-настоящему можно пользоваться повторно в других проектах, а не выдирать один отдельный понадобившийся класс из сложной иерархии наследований и взаимных вызовов методов. Процедурщик не одержим ООП, он может воспользоваться и функциональным стилем программирования, может использовать в программах собственные встроенные специализированные мини-языки типа тех, которые используются в grep или printf, может использовать функции обратного вызова и т.п.

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

    Кстати, ООП в C++ - это скорее пример того, как можно хорошую идею испортить плохой реализацией. Даже в Object Pascal ООП лучше, поскольку позволяет достичь большего сокрытия внутренних деталей реализации объекта. Но и Object Pascal - не идеал, т.к. не поддерживает идею ОБМЕНА СООБЩЕНИЯМИ между объектами. Весь обмен сообщениями сводится к вызову методов, что подразумевает, например, невозможность отправки асинхронных сообщений средствами самого языка. Невозможно средствами языка адаптировать интерфейсы разных объектов друг к другу (банально - переставить аргументы между собой при выполнении вызова метода или передачи сообщения, ориентируясь на типы и имена этих аргументов) и т.п. То есть при ведении дискуссии "ООП против другой парадигмы" нужно учитывать ещё и то, какой конкретно ООП имеется в виду: ООП в стиле Object Pascal, в стиле C++, в стиле Smalltalk или Objective-C. Вердикт будет зависеть от типа ООП и задачи, которую требуется решить с его помощью.

  55. Адольф Нешаевич

    Замедление времени может объяснить некоторые эксперименты с короткоживущими частицами, если конечно, эти эксперименты имели место, а не понапридуманы релятивистами.

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

  56. Просто эпическая статья! Тот кто наплел всё это вместе, все эти сплетения из попеременных наездов на святые для многих ОТО и на ООП - просто гений. Поэтому от неожиданности даже и не знаю с чего и начать... с ООП или ОТО ;-) Короче, думаю что безусловно тут есть в такой критике зерно здравого смысла... только ведь не надо это всё превращать в такой холивар очередной... ведь за этим и теряется весь этот самый здравый смысл! Статья даёт возможность снять розовые очки и задуматься.

    Для некоторых программистов возможно это вообще будет ШАНС! задуматься ВПЕРВЫЕ! в своей карьере над тем, ПОЧЕМУ! они используют именно ЭТОТ! инструмент, под названием - ООП. В любом случае, рассмотрение и серьёзный анализ любой альтернативы ему (в том числе и в ВУЗах) пойдет профессионалу только на пользу, даже если этот человек всё-равно останется работать на ООП, разве нет? И это то - чего мы все в большинстве лишены, разве не об этом в том числе так ярко и толково говорит в статье выше докладчик Гэбриэль? Я только за за такой подход, как говоривали ещё десять лет назад:

    МЫ - ЗА ПЛЮРАЛИЗМ МНЕНИЙ, ТОВАРИЩИ!!!1

  57. Бедвар.

    И что касается ООП, и что касается ОТО.

    Юзаю Питон и ООП - потому как нравится, ну и из политических соображений. В ООП напрополую использую функционал.

    ОТО верна (но не всеобъемлюща), но эффекты видны на диких энергиях. Хотя по жизни, ни ООП ни ОТО леммингу не нужны.

    Тьфу, на вас.

  58. Дмитрий К

    Прочитал данную статью и комменты к ней...

    Нет смысла с пеной у рта доказывать что один из двух подходов (чисто процедурный или же ООП`шный стиль) продуктивнее или удобнее другого...

    Но позволю себе заметить (как программист `живущий' между с и с++, и пользующийся преимуществами обоих стилей):

    одним из важнейших плюсов в ООП `c++' (не буду называть другие ОО языки) является всё таки НАСЛЕДОВАНИЕ (я вообще удивился тому, что эта замечательная/отличительная особенность ООП не была упомянута здесь);

    что касательно того, что ООП`шников заткнули за пояс LISP`овцы: просто ООП`шники настолько абстрагировались мета-программированием (которое кстати мне пока неведомо - честно признаюсь), что не сообразили НАСЛЕДОВАНИЕ взять за основу круговой обороны, и использовать её как плацдарм для адекватно агрессивных выпадов в сторону своих аппонентов;

  59. Ну вы даете... Любой ускоритель частиц работает благодаря СТО.

  60. Кстати еще, именно в релятивистской теории у частиц возникает спин. Про магнетизм и спинтронику надо рассказывать?

  61. to Математик

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

    Очень интересно, правда. Не могли бы вы привести реальный пример, когда во время "придумывания"(!) какой-либо теории выводилась какая-либо аксиома или менялся набор аксиом или чего-то там (не понятно, почему вы отождествляете теорию с набором аксиом)?

    Хотя, мне кажется, вы запутались в терминологии. Вы путаете аксиому и постулат, теорию и гипотезу. По ссылке ниже эти термины объясняются на пальцах:

    http://www.scorcher.ru/art/science/theory/axioms.php

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

  63. Еще один математик

    >Очень интересно, правда. Не могли бы вы привести реальный пример, когда >во время "придумывания"(!) какой-либо теории выводилась какая-либо >аксиома или менялся набор аксиом или чего-то там (не понятно, почему вы >отождествляете теорию с набором аксиом)?

    Например, аксиомы теории гомологий в алгебраической топологии были придуманы Стинродом и Эйленбергом после тщательного изучения свойств групп гомологий. Пример попроще: аксиомы кольца, поля были придуманы в конце 19-начале 20-го века в результате исследования свойств различных числовых (и не только) систем.

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

  64. "satarsa

    Ну вы даете... Любой ускоритель частиц работает благодаря СТО."

    Ага, а вы тогда живете благодаря Химии. Не чувствуете бред высказывания ?

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

  65. Статья — эпик вин, тред комментариев успешно выведен в режим автотроллинга. По сути, изобретён новый уникальный вид холивара: Лисп против теории относительности — это реально круто.

    Статистика очень интересная получается:

    * На все 93 комментария только два адекватных - номера 58 и 59.

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

    * Другие представители фауны путают методику с языком, а ООП с С++.

    * Третьи берутся сравнивать Си (который, на минуточку, по своей сути является "высокоуровневым ассемблером") с ПХП. Напомню, что ПХП вообще начинал своё существование как шаблонизатор для подстановки переменных в HTML (и очень жаль, что там же и не закончил).

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

    * Ну и фееричное "спервадобейся" на тему отсутствия крупного софта, написанного на Сях. Ядро Линукс, ядро макоси, Апач, MySQL, интепретаторы большинства скриптовых языков, все Гномы, ну и вообще большая часть софта, существующего в рамках проекта GNU. Из другой "оперы": ядро винды, драйвера винды, графическая и десктопная обвязка винды - тоже Си. А Фряха так вообще ВСЯ написана на Сях, полноценная серверная операционка, да. Фактически, можно сказать, что наоборот, нет НИ ОДНОГО успешного случая применения статически типизированного ООП языка (С++, Ада, объектный паскаль, Оберон... ау?) в крупном, стабильном, развивающемся в течение десятилетий проекте, имеющем критическое значение для современной IT-индустрии. Подавляющаяя часть того, что крутится в наших компьютерах и стабильно работает годами, написано на Си.

    Конечно, для тех, кому движок "Сталкера" кажется верхом технологичности, стабильности и качества — трудно представить, что есть программы, которые работают и не падают, натурально, годами: от включения сервера после установки в серверной и до его обесточивания через 5 лет.

    Теперь что касается непригодности ООП. В том виде, в каком оно проталкивается уже 20 лет в массы, оно не пригодно для хоть сколько-нибудь сложных и ответственных проектов. Зато отлично подходит, чтобы посадить 20 индусов лабать код по заказу через аутсорсинг.

    Конечно, есть годные ООП языки, такие как Руби, Питон... Реально хорошие и мощные языки, позволяющие прямо сказать машине, что нужно сделать, не ***хая мозг созданием нового класса на каждый чих. Но эти языки хороши не потому, что они ООП, а потому что это динамические рефлективные высокоуровневые языки. (Хых, для кого я это пишу... Из всех, кто тут писал комментарии, слово рефлективный поймёт 3 с половиной человека, не больше.)

    Фактически, Руби и Питон - это Лисп с человеческим лицом. "Лисп для бедных." А все языки по своей внутренней сути, как известно, сводятся либо к ассемблеру, либо к Лиспу — третьего не дано. А если кто-то пытается усидеть на двух стульях сразу, в итоге получается получается С++, templates (тьюринг-полный язык в языке, адская жесть), бинарники HellowWorld на 4 мегабайта, и рефакторинг, рефакторинг, рефакторинг...

  66. И то, и другое имеет право на жизнь. Хотя я редко использую ООП, только в качестве написания интерфейса пользователя, который можно потом передать другим, менее квалифицированным программистам, для сопровождения и т.д.

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

    Но впечатление от статьи попортило влезание в научный мир - эффект обратный! Уже ко всему написанному начинаешь скептически относиться, уж слишком "круто" автор пишет, слишком безаппеляционно и категорично!

  67. Игорь, во-первых, спасибо за интересный материал!

    Почему-то в таких полемиках все забывают, что можно замечательно смешивать стили и парадигмы. Поэтому мне, например, нравится мультипарадигмальный Python (и, аналогично, -- не люблю Java, где есть только «один правильный» подход).

    И отдельное спасибо Clr :)

    Сергей.

    P.S. А почему нет OpenID для комментов? :(

  68. Андрей Булачев

    Господа, которые увидели в GPS использование ОТО, как физик, физикам, рассказываю:

    учитывая что спутник движется по орбите с 1ой космической скоростью: 7,9 км./сек., и учитывая формулу для вычисления задержки по времени ( http://ru.wikipedia.org/wiki/Релятивистское_замедление_времени ) получаем что погрешность получается 0,001% .

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

  69. Андрей Булачев

    Да! Статья интересная! Автору СПАСИБО!

  70. Беларус

    К ООП тоже отношусь спокойно, отрицательно.

    Так вот, написание кода - это мелочи. Это 5-10% времени и стоимости разработки. Сотни миллиарды долларов и миллионы человеко-лет (без преувеличения), как в трубу, вылетают на поддержание (тестирование, правку багов) софта. Вот это и есть настоящая проблема. Да еще программисты наповадились с места на место бегать каждые 2-4 года, -- только человек освоится и годик поработает продуктивно, -- глядишь, он уже опять куда-то намыливается... И вот тут возникает интересная проблема. В связи с высокой текучестью кадров и большой сложностью реальных проектов читаемость и модифицируемость кода приобретает первостепенное значение!

    Чтобы код был читаем и легко модифицируем, крайне желательно, чтобы он был локально понятен. Так, чтобы новый человек, посмотрев на процедуру, смог достаточно быстро понять, что она делает и как. И вот тут, в объектно-ориентированных языках типа Java, С# начинается веселье с конструкторами, деструкторами, виртуальными функциями, наследованием, монстроидальным шаблонным метапрограммированием, полиморфизмом, исключительными ситуациями... Увидев вызов простой функции, как правило сразу понятно что происходит, можно сходить и посмотреть, что она делает. В объектно ориентированных языках, где народ (в особенности вчерашние студенты) любят, ой как любят переоперделять функции, не поймешь, какой из 15 виртуальных методов будет вызван в данном контексте, и читать текст их всех дело утомительное. В результате починка бага занимает в 3-5 раз больше времени.

    Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, не сомневаясь, удаляет его. Программа перестает работать. Что случилось? Оказывается, конструктор этой переменной устанавливает связь с другим объектом. Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но что написано пером - не вырубишь топором. В результате программист (по-хорошему) вынужден прочитать описания всех конструкторов и деструкторов по всей цепочке наследования всех локальных cтруктурных переменных процедуры. Кому хочется шариться по 40 файлам, чтобы понять, что делается в процедуре? — да никому. Никто этого и не делает, в результате через 3 года в программе, лихо написанной на объектно ориентированном языке, не разберется никто. Посему, и надежность программ, размашисто написанных на таких языках, оставляет желать лучшего. Я уже не говорю про перекрытие операторов, конструкторов копирования и прочее. Творческое пользование темплейтами также сможет доставить потомкам немало приятных минут. А чего стоят исключительные события? Почему-то получается, что код, написанный на языке программирования без скрытого поведения, поддерживать и сопровождать гораздо легче. Просто уже потому, что вероятность наступить на грабли меньше. Описана переменная -- можно быть уверенным, что ничего больше это не означает. Вышли из блока -- значит, вышли, и нечего кроме. Что написано, то и происходит. Когда же приходится докапываться до третьего слоя истины -- это бардак. К сожалению, на объектно ориентированных языках наломать дров проще простого, что мы и наблюдаем изо дня в день.

    Как это ни удивительно, при промышленном программировании залогом хорошего здоровья является простота. Чем проще, тем лучше. Код должен быть понятен, иначе человек, который заменит Вас через 2-4 года, не справится. Хотите проинициализировать переменную? Вызовите процедуру. Надо вызвать функцию? Вызовите ее напрямую. Очевидно, что чем проще язык программирования, тем трудней сделать на нем семантическую ошибку. Если достаточно полное и предельно краткое описание языка занимает около 1000 страниц, можно ли ожидать, что рядовой программист будет знаком хотя бы с 50% особенностей языка? -- навряд ли. Тогда откуда может быть уверенность, что достаточно навороченная конструкция представляет собой именно то, что хотел сказать программист?

    Далее. Стандартные библиотеки. Опять же, с точки зрения промышленного программирования, — чем проще, тем лучше. Если в стандартной библиотеке (к тому же динамически подгружаемоей) есть баг, то это беда. Если программисты его не нашли -- значит, найдут пользователи. Если нашли и обошли, то проблемы начнутся после того, как пользователь обновит библиотеки и в новой версии баг будет починен. Наконец, необходимым требованием является 100% обратная совместимость библиотек. Ну скажите мне, хоть одна библиотека для Java удовлетворяет этому требованию? А есть ли там хоть одна процедура без какого-либо ляпа? Я уже не говорю о вопросах совместимости, инсталляции и прожорливости разных версий фреймворков под C# .NET и о том, что на изучение постоянно изменяющихся спецификаций различных новомодных библиотек может уйти полжизни, не говоря уже о проблемах стабильности их работы на практике.

    Смежная проблема. Возраст языка. Чем старше язык, тем лучше и глубже его знают программисты. Всем известно, что можно делать, чего нельзя, а что можно, но лучше не нужно. С новомодными языками дело обстоит сложней, и опыт, равно как устав караульной службы, пишется кровью программистов. Наконец, не следует забывать, что разработчики компиляторов тоже не боги и могут ошибаться, а чтобы найти баги в компиляторе с Java или, в особенности Сановском, напрягаться не нужно - баги Вас сами найдут.

    Вообще, за последние 20 лет вышла масса литературы на тему дизайна программного обеспечения. Авторы книг статей постарались на славу. Были выделены и формализованы основные конструкции в виде паттернов проектирования. Сформированы основные практики и рекомендации. Однако, у этой большой и красивой медали есть обратная сторона – очень редко говорится О РЕАЛЬНОЙ НЕОБХОДИМОСТИ ПРИМЕНЕНИЯ тех или иных методик, а также о трудозатратах при этом. Подавлющая масса молодых программистов из-за отсутсвия опыта воспринимает все подобные материалы совершенно неадекватно, стремясь де-факто реализовать в одном месте практически все то, о чем они когда-либо читали и слышали (а слышали они в силу возраста как раз все последние веяния). Им трудно дифференцировать рациональные зерна от бесполезных "бантиков" и программирование превращается не столько в создание требуемого функционала, сколько в продумывание деталей как это будет написано. Внешнее и второстепенное выдвигается на первое место. Значительную часть времени начинает занимать бесполезный рефакторинг программного текста и мысли о том как же организовать очередное хитрое зацепление классов, в то время как создание полезнго функционала уходит на задний план. Например, в игровой индустрии подобные повадки особенно вредны. Нужен функционал, не нужен лишний текст. 99% текста выполняют 100% работы.

    Например, когда-то одному разработчику был дан проект очень незатейливой игры. Предполагалось, что эта игра займет около месяца разработки. Но месяца не хватило. Спустя шесть недель выяснилась причина. Программист попался очень педантичный и вместо того чтобы взять чистый СИ и написать игру, он 80% времени занимался тусовкой классов в сложнейшей иерархии. Когда посчитали – оказалось порядка 210 классов. Движок получился, была написана чудовищная гора текста. В объекты было завернуто все, начиная от объектов межпоточной синхронизации и кончая экранными виджетами со своей собственной системой сообщений. Да только вот беда — сама игра была в совершенно зачаточном состоянии и не работала. Старые игры для GBA, C64, NES, SNES, Megadrive, ZX Spectrum, Atari, N64 всегда, с неизменным постоянством работали как часики. Можно конечно сейчас сказать "ну знаешь ли, не сравнивай сложность продуктов". А ничего подобного! Просто нужно знать как писались эти вещи и на чем писались. Раньше ведь даже не было IDE, и дебаггеров с одним тычком мыши. Не было самих мышей. Загружались с дискет (а еще раньше с кассет!). Иногда не было возможности отлаживаться или даже запускать код на самом устройстве. Так может уделять внимание эффективности, задачам которые пытаемся сделать?

    Информация к размышлению: http://www.softpanorama.org/SE/anti_oo.shtml

  71. 2 Беларус > ...Чем проще, тем лучше. Код должен быть понятен...

    Всё НЕВЕРНО изложено ибо неверно понято.

    ООП - это НЕ означает СЛОЖНО. - Это НЕ синоним слов "СЛОЖНОЕ ПРОГРАММИРОВАНИЕ". - нет!

    "Плоский С" - он же в тексте "простой (обычный) С" - не синоним слов "ПРОСТОЕ ПРОГРАММИРОВАНИЕ" - нет!

    На языках ООП можно писать как сложно, так и совершенно просто!

    И на "плоском С" можно писать как сложно, так и совершенно просто!

    Если писать на "плоском С" и имплементировать(осуществить), к примеру, все возможности языка ООП, то у вас получиться СЛОЖНАЯ программа (система)написанная на "плоском С", пользоваться которой будет очень сложно, по сравнению с написанием на языке ООП.

    Ещё раз - "простой язык (не ООП)" - не означает, что на нём нельзя написать сложные(!) программы, сложные в смысле сложности понимания - то есть сложно-понимаемые программы.

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

    Язык ООП - это фактически УПРОЩЕНИЕ(а не усложнение, как считает автор) - упрощение работы(!) по программированию, работы со всеми этими библиотеками, написанными на "простом("плоском") С" и осуществлявшими фактически парадигму ООП (хоть и закодированную в кодах "плоского С"). - По крайней мере так родился С++ (конечно не без влияние "чистых" языков ОПП, где ВСЁ есть объект).

    Но так как С++ всё же наследовал "рудименты" С, то эти рудименты приходилось учитывать при программировании, что приводило к правилам их учёта (а их несоблюдение к ошибкам, иногда трудно уловимым).

    Тогда родились почти "чистые" языки ООП, типа Java - где всё же НЕ ВСЁ есть объект! - там есть и примитивы.

    Ещё раз - "примитивный, простой, не ООП язык" не есть синоним слов "простая программа"! - Это заблуждение как ваше, так и миллионов программистов. имхо

    Вы можете взять язык, который состоит из десятка операторов (никаких конструкторов и прочего...) - "занесение в память", "чтение из памяти", "сдвиг" и прочее типа того и породить СЛОЖНЫЕ программы, когда на этом языке напишите к примеру алгоритмы умножения и деления.

    ООП не есть сложно, ООП есть УПРОЩЕНИЕ написания программ за счёт того, что контроль за правилами передали компилятору - то есть другой программе, а не голове человека, который ранее должен был всё это держать в этой голове и соблюдать эти правила, при написании сложнейших алгоритов на "простом языке"!

    P.S. - А можно ли на языке ООП писать просто? - Запросто, когда я спросил одного чела, почему он, используя технику "копи и пасте" дублирует один и тот же код по всем классам, он мне ответил, - Если надо будет потом исправить в этом коде что-то, то он текстовым редактором найдёт(!) все места, куда он вставил этот дублирующий код и везде(!) поправит. ;-)

    И не колышет его, что такой метод не не есть ООП. ;-)

    А почему он так делает? - А потому что сейчас IDE позводяет ему быстро найти в коде все(!) места где он для "простоты" продублировал какой-то кусок своего кода.

    Вот вам и "простое" программирование на языке ООП(!), - и это та простота, о которой можно сказать - "простота, которая хуже...". имхо

  72. Не буду комментировать статью, лучше прокомментирую комментаторов:

    Если ни один из вас не может хоть сколько-то времени оставаться "царем горы" затыкая оппонентов адекватными доводами, то стоит ли самим рот разевать?

  73. Константин

    1.

    По поводу СТО\ОТО (противникам теории)

    а) СТО+GPS -- СТО теория с минимальным количеством свободных патаметров, позволяющая добится от GPS практически необходимой точности.

    б) СТО+квантовая механика -- еще Энштейн искал "теорию всего", по причине того, что наличие 2-х известных взаимодействий (электро-магнитного и гравитационного) считал "перебором". Сегодня взаимодействий четыре. Одно из них (гравитационное) не совместимо с ОТО+квантовая механика. Это не говорит о том, что одна из теорий не верна -- просто более общая еще не разработана (сегодня на "теорию всего" претендует теория струн).

    Когда инженерам нужны временнЫе поправки -- они используют СТО\ОТО, когда квантово-механические при гравитационном взаимодействии -- планковскую теорию, а от СТО\ОТО отказываются.

    2. Про ООП vs !ООП.

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

    б) Если такое сравнение корректно, то выскажу утверждение: успешных проектов более 1млн. строк кода на Си больше, чем на С++.

    3. Про математику (доказательства и аксиомы)

    Имелись в виду формализации существующих теорий в математике -- тогда действительно встает вопрост о выделении [минимального] набора аксиом.

    П.С.

    Константин -- программист.

  74. Аноним Дима

    На случай, если кто-то дочитает.

    Аксиомы, на которых основана теория относительности:

    1. Законы физики одинаковы для всех систем

    2. Никакое воздействие не может передаваться со скоростью, быстрее скорости света.

    3. Инерционная масса равна гравитационной массе (это отличие СТО от ОТО).

    Все остальное (замедление времени, увеличение массы, сокращение размеров, "е равно мц в квадрате") - это СЛЕДСТВИЯ. Математически строго выведенные. Помните об этом.

  75. Ветеран

    Ребяты, об чём срач-то? ОТО, СТО...

    я таких слов типа "парадигма" не знаю, это работать не мешает.

  76. Аналитик

    Чёрт возьми, какая архитектура, какая методология, какие аксиомы, когда всё решают деньги? ООП позволяет производить код в промышленных масштабах, не особо напрягая мозг программиста(т.е. на коленке настрочил - и работает, а как оно там во всеобщей связи устроено - вопрос вторичный), позволяя таким образом экономить время, а следовательно - деньги. А небольшие проблемы типа нескольких десятков тысяч классов - не беда! Наймем несколько тысяч индусов - и они все под нашим руководством переделают. Работать, правда, будет плоховато, но кого это волнует? Главное - слить продукт пользователю с минимальными затратами и получить прибыль здесь и сейчас, а как оно там дальше пойдет - разберемся.

    Так что первый комментатор прав - ООП себя доказало. Вполне.

  77. В системе GPS никакие релятивистские эффекты не учитываются. Там часики на спутнике просто синхронизируются с часами на Земле с определенной периодичностью. Никто не парится с релятивистской математикой.

    Ну и товарищ выше про погрешность 0,001% уже написал.

  78. Ну уж если придираться, то 0,001% не такая уж маленькая величина,

    если речь идет о 10 часах например - 36 секунд однако!

    Вообще после прочтения статъи, ссылок и комментариев хочеться

    обратить внимане что данная, несколько провокационная, тема

    поднята скорее для того чтобы сбить ортодоксальность(костность)

    мышления, чем доказать что ООП и ОТО в корне неверны.

    Основная проблема высказанная не в этой статъе а в одной из

    ссылок - что увлечение ООП пошло не на пользу для общего развития

    языков вообще. Что увлечение промышленным ПО для бизнесса

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

    не ведущих к прибыли и не удовлетворяющих напрямую "большой

    бизнесс".

    И можно предположить куда примерно клонит автор - к возрождению

    некой свободной среды обмена идеями в сфере программного

    обеспечения, которое позволит предолеть тот застой, который

    сложился в результате увлечения коммерционализацией ПО и интересы

    которой не будуд так зависеть от потребности в порикладной сфере.

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

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

    Лично мне больше нравиться разнообразие и возможность пользоваться разными инструментами, изучать и знать их особенности, но это мои предпочтения. Если будет язык который позволит использовать ООП, структурное, процедурное, функциональное программирование и программирование в машинных кодах в одном флаконе - ради Бога - только не делайте этот язык обязательным для изучения в школе!

  79. Ну уж если придираться, то 0,001% не такая уж маленькая величина, если речь идет о 10 часах например - 36 секунд однако!

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

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

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

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

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

    Лично мне больше нравиться разнообразие и возможность пользоваться разными инструментами, изучать и знать их особенности, но это мои предпочтения. Если будет язык который позволит использовать ООП, структурное, процедурное, функциональное программирование и программирование в машинных кодах в одном флаконе - ради Бога - только не делайте этот язык обязательным для изучения в школе!

  80. Технарь мля

    ООП было вобщем то придумано в целях экономии времени при групповом разборе (вроде бы как). Предприятие хочет получить прибыль, создает продукт, среда разработки и двигатель (тут я как раз и имею ввиду парадигмы программирования) - есть станок который делает детали или изделия (ПО). Главный фактор - время, чем меньше затрачено, тем больше прибыль. Для некоторых ООП понятней, для некоторых процедурное. Сложные какие - либо продукты они естественно делаются по спец заказу и требуют, в первую очередь качества выполнения (аля "хендмейд = ассемблер). Настоящих программистов, готовых мыслить системно сразу в двух направлениях - это понимание уровня применения ПО, а так же определения места того самого ПО в экономике предприятия или его места на рынке.

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

    Про физику и программирование: та же самая вещь с рынком ( я про навязывание технологий). А теперь и про философию слегка :) Физика - имхо это формализованная философия ( а в философии првых нет). Все теории ПЫТАЮТСЯ описать мир, для использования ЕГО свойств в в собственных целях. Если взять программирование - это уже НАШ мир, законы придуманные в нем - мы в первую очередь сами и задаем (возможно это и имел, обхаяный многими математик-"ебанат"...).

    П.С. извиняйте за ошибки и сумбурную логику, но какнуть в каментах тоже ахота:)

  81. Мда. Судя по комментариям сторонников "провала ООП", никто из них концепции ООП не понимает вообще. Говорить же о "провале ООП", когда практически всё делопроизводственное программирование осуществляется на ОО языках (Java, Delphi, C# и, пока ещё, C++) - это просто смешно. Что касается принципов "Top-down design", который Степанов безосновательно сводит к совершенно некорректной аналогии с "аксиомами" и "доказательствами" в математике, то, как и любая парадигма разработки, для каких-то конкретных задач "Top-down design" работает лучше, для каких-то других - хуже, но, строго говоря, к ООП в целом это никакого отношения не имеет, "Top-down design" - вовсе не обязательное требование ООП.

  82. Скажу одно: возможно ООП самая наигалимейшая парадигма из всех - Бог с ним, даже соглашусь. Но провалилась???? Это как знаменитая фраза "загнивающий запад" :) Нам бы та погнить чуток, и дай бог функциональному программированию когда нибудь так провалится...

  83. А кому

    и что собственно известно о логическом устройстве интерфейса?

    и что изестно кому о эволюционном генезисе интерфейсов?

    и о типах взаимосвязи и управления классами?

    ВОПРОС: как создать класс?

    ВОПРОС: где кончается процедурное и начинается программирование объектное?

    Вы еще пишете коментарии к каждой строчке процедуры?

    А можете сделать так что бы коментарий к процедуре не были бы нужны?

    А могете ли вы отлаживать код который еще не написан?

    А можете ли вы математически( а не с головы-дурной "на авось") точно расчертить проект на 50 разработчиков?

  84. Plevat na vse etu chuj, vse ravno kak proggramirovat, lijbo platili normalno ! a ostalnoe propaganda

  85. Комментаттор 16

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

  86. Мой основной жизненный принцип - не говори о том, чего не знаешь.

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

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

    Давайте не будем делать из ООП "серебряную пулю". Есть разные типы задач, разные типы систем и, соответственно, разные списки требований к этим системам. Везде применим свой подход.

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

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

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

    Всего доброго!

  87. >Ну уж если придираться, то 0,001% не такая уж маленькая величина, если речь > идет о 10 часах например - 36 секунд однако!

    Если уж к Вам придираться, то не 36 сек. на 10 часах, а треть секунды, однако.

    > Почитайте Гради Буча

    Читал, не всю, чуть меньше половины книги прочел. И скажу - Буч очень

    часто передергивает. Расписывая принципы ООП пытается утвердить мысль, что "такое" возможно только в ООП, или благодаря ООП. Например, повторное использование кода. Это навскидку, но и в других местах (по тексту) тоже. Книга, к сожалению, очень тенденциозная и пропагандистская, и то что приходится эту муть фильтровать...

    Короче, именно по прочтении этой книги у меня стало создаваться впечатление,

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

    Вирта в статье упомянули, интересно, а как дедушка Д. Кнут отосится к ООП?

    Боюсь, что он тоже не фанат этого дела. Кстати, Вирт считает свое последнее детище Оберон в достаточной степени ОО.

  88. > Почитайте Гради Буча

    Читал. Не всю, чуть меньше половины книги прочел. И скажу - Буч очень

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

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

  89. Вот кстати из интервью D. Knuth журналу Byte (http://www.literateprogramming.com/byte1996.html)

    BYTE: In reviewing programming as it has evolved over the past 10 years, do you see anything that makes you disappointed, for example, in the object computing realm?

    Knuth: They haven't yet built a reliable way to reason about these programs, that is, we still lack the mathematical proofs to ensure a program will work. With object oriented programs, we have much less of an understanding of how we would ever prove that they don't have bugs. This is a huge gap. If people can understand OOP, they ought to be able to prove that the programs are correct.

    Если я правильно уловил суть, его точка зрения такая - в случае использования

    ООП не существует надежного способа оценить правильность написания программ

    и у нас гораздо меньше понимания, как можно доказать, что программы не содержат ошибок. "Это огромная брешь."

  90. aleksey.berezan@gmail

    Greetings!

    Прочитав статью так и не понял каковы причины провала ООП и что вообще стоит считать провалом. Не буду спорить с аргументами Кнута, Буча, Степановым, поскольку почти весь мой проф опыт(4 год) - 80% ООП, 19% SQL, 1% lisp/prolog/other, т.е. по своему опыту и академическим знаниям сравнивать я особо и не могу.

    Но что я могу сказать от себя.

    Как я вижу один из популярных вариантов ЖЦ парадигмы:

    - предистория: сначала парадигмы(ООП в нашем случае) нету, более-менее номарльно обходятся без нее;

    - зарождение: появляется парадигма(в научной статье, например, как концепция), первые експерименты, инструменты, компиляторы, первые успешные использования; Все видят, что это хорошо;

    - предмейнстрим: популярность парадигмы набирает обороты("ты что, ещё не пишешь на обьектах??!! "); Серебряная пуля?

    - мейнстрим: парадигма применяется почти повсеместно(иногда и не в совсем правильных случаях) как само собой разумеющееся;

    - и тут появляются люди, которые замечают недостатки парадигмы, пытаются их показать всем остальным; Иногда это у них почти получается(waterfall, например, применяется очень редко, RUP - тоже, даже в больших организациях, насколько мне известно, но все-равно применяются т.к. в некоторых случаях ничего лучше не придумано);

    С ООП сейчас то же самое. Оно стало мейнстримом, кто-то заметил недостатки, пытается их раскрыть/показать, может что-то и получится, но ИМХО, не в ближайшый десяток лет.

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

    И это - нормально.

    Вместо заключения.

    Что же все вышесказанное(включая и статью) для нас всех означает в практическом плане? Ничего

    Как по мне:

    ентерпрайзу - джаву с ООП; Для distributed, мат.вычислениям, исследователям - функциональщину; Студентам - паскаль и си-шарпы с джавой; Миру - мир;

    А вы живите, любите, учитесь и совершенствуйтесь, и тогда никакой провал нам не будет страшен :)

  91. Sw00p aka Jerom

    пацаны учите матчасть

  92. Я после обеда люблю почитать отвлеченные материалы на тему программирования, вот и сегодня наткнулся на доставляющую статейку. При чем особо она порадовала комментариями (шутка ли - до сих пор комментируют о_0)

    Считаю автора статьи толстым троллем. Правильнее всего высказался Вирт - о том, что ООП это всего лишь надстройка. Развивая его мысль: раз это надстройка - то использовать ее или нет это лишь желание автора.

    Я начинал с бейсика, ТП и асма в 90-е, много шкодил на С++, сейчас кормлюсь на РНР. И не вижу вообще никакой принципиальной разницы для РАЗРАБОТЧИКА - использовать ООП или нет. В том или ином случае выбор диктуется либо особенностями среды разработки, либо пожеланиями заказчика/работодателя, ну или на худой конец - привычками и вкусами автора. На С, пожалуй, с ООП у вас ничего не выгорит :))) А на Жаве - уже БЕЗ него не выгорит... А на Дельфи - можно и без ООП, но будет неэффективно, ибо большая часть готового кода реализована в виде классов. Так же и работодатели - некоторые маниакально требуют применения ООП в РНР, причем не думая о том, как криво эта концепция реализована в 5-й версии интерпретатора. А так же почему-то не задумываясь, что РНР - это таки интерпретатор, и некоторые фишки, которые легче реализовать как раз с ООП (например, событийная модель) в нем отсутствуют в принципе.

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

  93. ООП безусловно не решение всех проблем программистов. Но это весьма мощный паттерн на ряду с другими подходами. Мощный инструмент для определённого круга задач (подзадач). Объектно-ориентированные языки лишь позволяют меньшим количеством слов описать объекты (единицы представления структуры мира) и операции с ними, и на мой взгляд взгляд могут весьма адекватно инкапсулировать процедурные подходы. Естественные человеческие языки для меня лично очевидно являются ОО. Программист С++ со стажем > 10 лет

  94. Понравилось начало статьи, а потом автора захватил антинаучный бред.

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

    Никто никого не вытеснял из ВУЗов. Научные факты не исчезают просто потому, что _внезапно_ накатывают новые специалисты.

    Наконец, на результатах теории относительности держится почти вся современная физика. Взять те же спутники GPS, учитывающие релятивистские гравитационные эффекты при синхронизации по времени, — не применение ли это?

  95. Мимо проходивший

    Надо же, год статью комментируют. Комментарии полезней, чем сама статья.

    Я не хочу повторять уже тысячу раз написанное... С чем-то я согласен, с чем-то нет.

    ..Напишу своё. Обойдусь без умных слов, засыпаю уже...

    Я начинал программировать на программируемом калькуляторе. А кто-то на нём работал и получал за это деньги. Всех всё устраивало..

    Появились первые ПК... Стали какие-то подобия окошечек. Информация выводилась на экран. Калькуляторы уже не устраивали. Писали на ассемблере, да на бейсике. Паскаль, си, прочее...

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

    ...

    На рынке ПК всё-таки немало зависит от конечных потребителей. Им надо:

    - дёшево

    - красиво(!)

    - просто

    - функционально

    - удобно

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

    В той же Delphi делается это гораздо быстрей.

    Модули, как было сказано выше, неплохо справились бы с этой задачей.

    Но, надо учить кучу названий однотипных функций, которые делают одно и то же.

    .

    Реализация ООП в средствах разработки даёт преимущества. Не надо думать о деталях реализации. Наляпал и готово. Для большинства программистов ошибок в этом случае меньше будет, т.к. модули многократно проверены и совместимы с целевой ОС. К тому же ошибки - не самый важный критерий для нынешнего пользователя.

    .

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

    .

    К чему я это? К тому что нет заказа на программирование вручную в обыденности. Есть ширпотреб. концепция RAD подходит для этого лучше всего. А основана она, думается мне, на ООП. Сиди и знай свое место! Именно эта стратегия себя оправдывает. Требуется сосредоточится на сущности вопроса и даже не надо знать, как это всё целиком работает.

    .

    P.S. Концепция ООП дала программистам абстракцию и контейнер для процедур с данными. Были модули - контейнеры для процедур, но не для нескольких экземпляров данных, были классические структуры для хранения данных. Аналога этому я не встретил ни в комментариях, ни в статье... Конечно, это не панацея. Но не стоит втравливать в грязь этот метод.

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

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

  98. Братья и сестры, прошу минутку внимания! Всего лишь простого, человеческого внимания внемлю я!

    ------

    Системный обобщающий вброс для старта процесса быстрого мыслегенезиса читающего:

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

    Чтобы быть кратким, быстро проиллюстрирую это на cd-болванках. Сначала эта технология казалась очень дорогой, медленной (скорость 2x) и малодоступной, - короче непрактичной (юность), но постепенно она была доработана до приемлемого уровня, цены упали, скорости возрасли (30-40x) - CD-привод стал уже повсеместным (зрелость технологии).

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

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

    Это - общая схема развития любой технологии, в том числе той же эфиродинамики, о которой упомянули в статье, разве что её прибили политические конкуренты ещё в безобидном зародыше - в фазе ранней юности, - не дав показать на что она способна (а иначе, верю, мы жили бы сейчас в СОВСЕМ ДРУГОМ МИРЕ, а не хвалились, что где-то дескать блеать Великая Теория Относительности, развивавшаяся больше века лучшими умами человечества доросла уже до того, что ажно корректирует время на часиках в GPS!!!1 одын один).

    ТЕПЕРЬ ПО МАТЕРИАЛУ!

    ООП как технология - вступила в фазу СТАРЧЕСКОГО МАРАЗМА, и люди мыслящие независимо начинают понемногу замечать это. Переход от дисков к твердотельным устройствам хранения займет не один год, да, но старая привычная и признанная технология оптических дисков ОБРЕЧЕНА, эта очевидна, это вопрос просто времени, впрочем, в равной степени это касается и ООП. Бесполезно обсуждать хороша она или плоха - она не позволяет решать задачи колоссальной сложности стоящие перед нами уже в ближайшем будущем, и этого достаточно.

    Пока мне интересна разница лишь в восприятии: что кто-то видит на перед будущее, как это часто случается будучи гением, а кто-то (большинство) послушав радио и бессознательно рефлексирует бездумно ретранслируя то, что ему там сказали местячковые авторитеты вчерашнего дня. Тут аргумент НА САМОМ ДЕЛЕ ОДИН: нас много, а потому - лемминги не могут ошибаться. Ага. Большевики с броневичка - "вся власть советам!"

    Поэтому, извините за просто неизбежные космические обобщения, выходящие далеко за рамки этой приземленной статьи, но когда пенсионеры активно ратуют за коммунизм, даже после всего того голодомора и репрессий, которые над ними в свое время учинили коммуняки, а молодежь - за либеральные реформы после лихих и бандитских 90-ых, - мы наблюдаем противостояние не политических систем или технологий в нашем случае, а конфликт ПОКОЛЕНИЙ, который является не техническим феноменом и некоей конкуренцией объективных качеств различных систем/технологий, и которые бесполезно рассматривать в таком контексте (как это наивно пытаются делать выше), потому что это чисто ПСИХОЛОГИЧЕСКИЙ ФЕНОМЕН. Это же касается и демократий всяких, которые в 21 веке вдруг начинают работают как-то не так, это касается ещё в большей степени и технологий программирования.

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

    Корфаген должен быть разрушен.

  99. Dixi!

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

    поясните эти задачи.

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

  100. ТОЖЕСКАЖУ)

    Про ООП и не ООП, мне кажется и то и то верно.

    А про "GPS действительно является наиболее понятным примером для человека, не изучавшего физику." - ..ну тут единственное что понятно такому человеку, лично мне, как обывателю и не физику, то что (радио) волна может замедлять и/или увеличивать скорость прохождения сквозь/через что либо :) , пусть это будет эфирное масло ХЕ ХЕ )))

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

  102. Народ, ООП совсем не провалился. Вас разводят.

  103. Vse eto bred...JAVA RULIT !!!!!! JAVA 1.7/EJB3.1/Java Server Faces 2.0

  104. Меня удивили высказывания этой статьи, направленные против ООП. Во-первых, аксиомы в математике, как и в любой теоретической науке, не доказываются, а берутся как исходные истинные положения, из которых по правилам вывода доказываются теоремы. Во-вторых, теория относительности ни когда ни кому не навязывалась, фактически, ее ядро было создано еще до Эйнштейна Максвеллом, Лоренцом и Пуанкаре в рамках теории электромагнитизма, например, еще до Эйнштейна Лоренц сформулировал постулат о независимости скорости света от скорости его источника (http://ru.wikipedia.org/wiki/Уравнения_Максвелла). Также теория относительности хорошо подтверждалась в многочисленных опытах, например, в опыте Майкейльсона.

    Поэтому из приведенных в статье аналогий никак не следуют недостатки и провалы ООП. Что касается обсуждаемой эффективности ООП, то я сам использую ООП и могу сказать, что при правильном подходе оно сильно упрощает процесс разработки. Хотя мне известны также и неудачные примеры использования ООП. Что я хотел особенно отметить, это то, что ООП - это не просто стиль программирования, навязываемый языками программирования, а это некоторая идеология, которой можно придерживаться, ведя разработку на любом языке, например, даже на C и LISP. Кстати в CLISP ООП и реализована как аккуратная надстройка над лексическими конструкциями LISP. На языке C тоже можно использовать ООП-дизайн, например, на языке C можно делать изящные реализации COM/ActiveX интерфейсов так, что эти реализации и представляют собой полноценные объекты в самом строгом понимании.

    Главная же особенная черта ООП, на мой взгляд, позволяющая увеличивать эффективность разработки, а также сопровождения программ, заключается в том, что ООП позволяет создавать лексически компактные сущности (объекты), несущие большую смысловую нагрузку, благодаря чему уменьшается писанина. То есть участки кода, использующие объект, значительно уменьшаются за счет того, что в них указывается последовательность коротких манипуляций с ним вместо прописывания детальных действий, которые реализованы в методах объекта. К тому же, если к этому добавить большое множество вариантов использования объекта, то короткие вызовы методов еще существенно сокращают объем кода и улучшают его структуру. И это еще не все, если учесть, что одни и те же участки кода могут совершенно однотипно обращаться к разным объектам (полиморфизм), реализующим разную функциональность, то сокращение кода и структурированность программы еще увеличиваются. Если еще принять в рассмотрение динамические языки программирования, где объекты полностью могут замещать друг друга без наследования общему интерфейсу, то можно вообще создавать максимально компактные и понятные программы.

  105. Истина как всегда по середине.

  106. ООП не решает всех проблем, но это не значит, что ООП провалилось.

    Многие идеи, реализованные в ООП, действительно хорошие - например, объединение данных и кода.

    Существующий Windows API можно рассматривать как аргумент в пользу

    ООП: функция GetCurrentProcess возвращает некий HANDLE, который нельзя использовать к примеру с функцией ReadFile. Для окон и графических контекстов сделали разделение, на HWND и HDC – ну а что это такое ? Фактически тот же HANDLE, а что такое HANDLE ? просто некоторый адрес в памяти, число.

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

    Не любите классы, потому что они заставляют вас создавать объекты, хотя это не всегда требуется? Используйте статические методы, как это сделано например в .NET для класса Math.

  107. В cpu нет инструкций поддерживающие ООП в каком бы то не было виде :)

    Нужна скорость ? - юзай assembler.

    Вся прелесть в ООП - это простота передачи проекта следующему разработчику.

  108. Подходы в программировании развиваются эволюционным путём — приспосабливаясь к потребностям текущего времени, сохраняя полезные свойства и отбрасывая ненужное. Разумеется, ООП появилось не на пустом месте. Его методики стали популярными потому, что сумели вобрать в себя тот удивительный набор полезных приёмов из разных областей, который позволил занять данному подходу лидирующие позиции в умах программистов, их программах и на рынке.

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

  109. Добрый Аноним

    Теория относительности Эйнштейна? Что за чушь?

    Ещё в начале века было понятно, что это всё "белыми нитками шито". Сейчас даже пузатые профессора отпираться от это го не смогут:

    Произошло это еще два года назад в ходе эксперимента на детекторе OPERA (Oscillation Project with Emulsion-tRacking Apparatus), который находится на глубине 1400 метров под итальянскими Апеннинами в подземной лаборатории Гран-Сассо. Именно сюда сквозь толщу земли прилетают пучки тау-нейтрино, создаваемые на протонном суперсинхротроне SPS в подземной лаборатории CERN, расположенной в 732 километрах. Поскольку тау-нейтрино свободно пролетают сквозь любую материю (к примеру, подсчитано, что сквозь наше тело ежедневно пролетает до 10 в 14-й степени нейтрино, порожденных Солнцем), ученые подсчитали, что этот путь они должны преодолеть примерно за 3 миллисекунды — как обычный фотон света. Но случилось непредвиденное: измерив время попадания нейтрино в мишень, исследователи вдруг обнаружили, что нейтрино прибыли раньше расчетного времени примерно на 60 наносекунд. Естественно, ученые сначала просто не поверили своим глазам: ведь еще со школьной скамьи всем нам прекрасно известно, что скорость света в вакууме, достигающая 299 792 458 метров в секунду, согласно специальной теории относительности Эйнштейна, является универсальной физической константой, то есть ничто и никогда не способно двигаться быстрее. Это предельная скорость движения частиц и распространения взаимодействий.

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

    И вот 23 сентября 2011 года в конференц-зале CERN профессор Дарио Аутьеро от лица международной команды исследователей прочитал специальный доклад, в котором он не только официально подтвердил результаты этого сенсационного эксперимента, но и поставил под сомнение сам фундамент современной науки — теорию Эйнштейна. (Интересная деталь: доклад Аутьеро подписали 174 ученых, тогда как в эксперименте участвовали 216 человек, вероятно, далеко не все ученые согласились подписаться под документом, который фактически выносит приговор одному из постулатов физики элементарных частиц.) Зато свое одобрение коллегам высказал лауреат Нобелевской премии 1976 года Самуэль Тинг, заведующий лабораторией физики высоких энергий Массачусетского технологического института.

    Подробнее: http://www.kommersant.ru/doc/1783137

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

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

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

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

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

    Так что всем есть куда совершенствовать свои навыки. Главное - это осознавать проблемы, и вырабатывать новые подходы к устраеннию причин.

    Учимся, анализируем, делаем выводы, обобщаем, больше не наступаем на грабли. Иначе - будешь вссю жизнь бороться с последствиями...

  111. 2Roman M

    Абсолютно согласен!!!!

  112. По своему опыта работы могу сказать так:

    Плохой код можно писать как следую принципам ООП, так и принципам "макаронного" кода.

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

    Но! Если же он будет использовать ООП, то программа станет модульнее, доступнее, и проще будет поддаваться доработки и развитию, и, что я считаю основным преимуществом, даже при смене команды разработчиков они смогут разобраться в несметном количестве строк и функций (А их, как вы сами знаете, бывает намного больше)

  113. Здравствуйте !

    Мой пост адресован всем тем, кто АБСОЛЮТНО не понял высказывания математика Александра Степанова:

    "Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств."

    Это очень точное высказывание.

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

    Их утлый умишко из потолка достал фразу "аксиомы - нуждаются в доказательстве" - хотя такого бессмысленного утверждения Степанов не высказывал !

    Высказывание Степанова - правильно и понятно, но только тем, кто умеет хотя бы складывать и умножать числа (хотя бы от 1 до 9 и желательно без калькулятора).

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

  114. Просто ОБАЛДЕННАЯ статья! Спасибо вам, на некоторые вещи открыли глаза!

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

  116. Александр

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

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

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

  117. Хорошая тема, конечно, для холивара.

    Если нужно сделать "2+2" - пиши процедурно, и нечего тыкать ООП.

    Если нужно запрограммировать "сложное логарифмическое уравнение" - тогда юзай ООП.

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

    И если кто-то понял мои намеки "про картошку", буду признателен ))) Ибо хоть я и держу нейтралитет - но поддерживаю тех, кто говорит, что ООП - всего лишь МОДА и не более ТОГО

    P.S. Сам я программист, долгое время писал на Java и не знал ничего другого, сейчас пишу на Perl, наверное "прозрел" )))

  118. Сейчас смотрю индекс популярности ЯП - и как это всегда бывает, время все расставляет на свои места.

    Java - которая исключительно ООП, за последние 10 лет потеряла около 10%, а за последние 3 года ее популярность всего лишь раз была зафиксирована выше 20%, и видно что объективно продолжает падать. Если сравнить с графиком С, то он как колебался в пределах 15 - 20%, так и колеблется в этом промежутке. С++, с которым так же чаще всего связывают ООП - то же продолжает падать. Популярность PHP - тоже в ауте, и насколько я знаю, мода писать веб на ООП - тоже не самым лучшим образом сказалась на этом языке.

    http://habrahabr.ru/post/137833/

    Выводы о том провалилась ООП или нет - делайте сами. Только не нужно отрицать очевидных фактов )))

  119. Прочитал по указанным ссылкам перевод выступлений Стила и Гэбриэла. Так, по-моему, как раз наоборот: статья сторонника ООП более адекватная. Кстати там в очередной раз нашел подтверждение и опять именно со стороны ООП-шников (аналогично Бертрану Мейеру в его книге об ООП), что С++ не есть гуд.

  120. эрлангер

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

    И да, я видел ОГРОМНЫЙ проект, написаный в функциональном стиле, и думаю, что на жаве такое сделать было бы, ммм... затратно по времени. Где-то на порядок, если не на два -- из-за необходимости использования параллельных вычислений.

  121. эрлангер

    luckycat:

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

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

  122. Откуда столько горя - друзья!!!

  123. Мне бы ваши проблемы... А вам бы мои... У меня 8 килобайт памяти в микроконтроллере, даташит на китайском и специфический асм. Такты на бумажке никогда не считали? Ассемблер без nopов никогда не видели? Хочется ПЛИС тыщи на две вентилей или NVidia Tegra 3 с QNXом на борту, а есть только дешёвый PIC. И на нём будет TCP-IP, веб-сервер с поддержкой динамической генерации страниц и эффекторы, чёрт возьми. Это я к чему: каждой задаче свой инструмент. Есть у тебя время и желание - сиди рефакторь на до-диезе. Нет времени - VCL в руки (Delphi, Lasarus, Kylix, чё там ещё...). Нет желания - VB в правую руку вместо того, что там у таких людей обычно, хе-хе... Нужна железка, которая в 100 астрономических едницах от земли с отказом основной антенны при старте и одном проценте мощности РИТЭГа будет работать - милости просим: фортран на земле, ассемблер на железке.

  124. Давид Мзареулян

    Перл про теорию относительности обесценивает всю статью разом. «А как дышал, как дышал…»

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

    А теперь скажите, в чём разница между процедурным програмированием,использующим конкретные функции, принцип непрерывности и точки разрыва(условные и безусловные переходы), и объектно-ориентированным программированием, активно использующим математическую теорию множеств? Глупый спор ни о чём.

  126. Статья справедливо. То что ООП провалился, для меня вполне очевидно.

    Вижу самый основной недостаток ООП - неоправданное умножение сущностей. А это вступает в прямое противоречие с KISS принципом -

    основополагающим принципом программирования.

    Что касается большой системы написанной процедурно. Ну это например SAP R/3 - он весь написан процедурно на ABAP еще до появления в нем объектной надстройки. И работает прекрасно!

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

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

  127. Да черта с два ООП провалилось. Автор нуб и опозорился. Если С++ сдулся, то C# только набирает обороты вместе с Java. Достойных альтернатив пока нет и рыпаться не стоит. Процедурное программирование ущербно. А по поводу сущностей правильно сказали, если руки растут из одного места, то и на другом языке человек будет писать говнокод.

  128. Денис

    17.01.2012 в 03:21

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

    Конечно возможно - возьмите любую обычную функцию или процедуру с параметрами.

    Набор параметров (ее называют сигнатура) это и есть интерфейс.

    Интерфейс можете оставить прежним, а алгоритм в теле функции можете менять или оптимизировать как хотите.

  129. В общем ООП-петушки как всегда соснули.

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

    Нет времени учить теорию категорий, теорию графов, монады и прочее, к чему весь этот матан, Erlang, Haskell, да что ты, прошлый век, для прыщавых задротов ко-ко-ко, у меня есть C#, Java и плюсы, сейчас я буду создавать классы и наследовать, какой я крутой программист, работаю в современной, модной и молодёжной парадигме, в динамично развивающейся компании, ко-ко-ко.

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

    Неудивительно, что рынок перенасыщен, но 85% его состоит из быдлокодеров, один копия другого просто, при такой лёгкой заменяемости, я вообще удивлён, как средняя з/п плюсплюсника не упала ниже 2к$. Хотя можно немного подождать.

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

  130. А я за эфир. ОТО и квантовая теория, противоречат друг другу. А ТС, ТСС и М-теория - просто позор для теоретической физики, для существования своей теории они допустили 10-11 дополнительных измерений, подобных выходов в астрал я давно не видел в науке.

  131. Маленький тест парадигм на примере бейсика и jav'ы:

    ***Длина кода

    retro BASIC: ?"hello world"

    J2ME: (около 1 кб кода)

    ***Управление возможностями архитектуры

    retro BASIC интерпретатор: допускает выполнение программ на бейсике на родном ассемблере архитектуры

    J2ме: Управление архитектурными возможностями не доступны: все говорят что это плюс, но на самом деле это очевидный минус

    Хотелось бы узнать: почему разработчики java написали для различных платформ JVM, но для тех же платформ им было впадлу написать компилятор

  132. Слаффка

    Бред собачий.

    ООП показало свою жизнеспособность.

    Альтернативы не показано, примеры (чем же все-таки ООП плохо) не приведены.

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

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

  133. Класс! первый коммент - сентябрь 2010 - интересно, сколько ещё будут обсуждать? Журналисты помрут от зависти. Спасибо за статью! Как на семинаре по ООП побывала, ей-богу (проходили в прошлом веке такие семинары в Минске)и тут так же смешно и бестолково. Поднимает настроение.

  134. Хорошая статья. Согласен с создателем STL.

    Нашел еще "продолжение" по названием "Комментарии к статье про ООП. Карфаген должен быть разрушен". Вам бы ссылку на эту статью здесь указать.

  135. Теперь Вам понятно, презервативотусовщики, пардон, энтитимусолы, чем Вы занимаетесь? Один мой знакомый пожарников тусовал, нследование юзал в 10-15 уровней на убогом MVVM (с интерфейсом а-ля WinForms). (Совсем отупели, как в моде... Один пидор сказал - круто, и хор КРУУТТТААА). Я говорю ему, давай напишем 2-3 класса пожарников-тушителей, пожарников-водителей и еще там кого-то и ...забудем. Не, говорит, так не круто... Человек с высшим образованием в IT.

    Помню, доводом против отличного инструмента VB6 было такое де изречение: но он то не язык, потому как интерпетируемый, а не компилируемый... Вот смеху то... А подход то - та же основа JVM и NET. А сейчас языки в ж..пу засунули...

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

  136. Цитирую: "Подходы в программировании развиваются эволюционным путём — приспосабливаясь к потребностям текущего времени, сохраняя полезные свойства и отбрасывая ненужное."

    Ага, я тоже так думал, пока не окунулся в мир индустрии IT. Полное ООП мракобесие. С огромным опытом преподавания, со степенью, я не смог объяснить адептам ООП, что практика наследования больше двух глубоко порочна и противоречит гармонии. (скорее транссексуалов напоминает, ООП чувствуете? Из мужика в бабу, обратно, BaseEntity то один). А дело вот в чем! Эта - самая консервативная среда, подверженная моде... Один чухонец ляпнул, другой слюной захлебнулся, все в интернете и пошло...

  137. Возникает ощущение, что у огромного числа людей рак мозга. Вы хоть понимаете, как расшифровывается ООП? Мир состоит из объектов, прикиньте. И из их взаимодействий. А любой анонимус является потомком амеб, которые, в свою очередь потомки молекул. ООП - это описание сути мироздания(по крайней мере в том виде, в котором мир воспринимает адекватный человек, и не важно, к какой области относится это описания - программирование или что-то еще). Ничего логичнее ООП еще не придумано.

  138. О чем спор? Концепция ООП стала массовой в программировании не тек давно - последние лет 10 - 15. До того существовали ERP системы, такие как MANMAN\x, MK Entrprise, R3, система управления инфраструктурой Unicenter, огромное количество САПровских систем, AutoCAD, например, СУБД такие, как Oracle, ADABAS, Ingress, и много - много других систем и продуктов, многие из которых работают и поддерживаются до сих пор. Спор о том, на какой парадигме остановиться при разработке - из области болтовни ни о чем. Как правило, быстрее разрабатывать на том, что лучше знаешь. Я в свое время программировал на assembler и благодаря опыту и наработанным собственным заготовкам и приемам на спор мог заткнуть за пояс коллег, которые использовали языки высокого уровня. При этом тестовая прога у меня работала намного быстрее и занимала намного меньше процессорного времени. Сейчас ресурсы компа никому не приходит в голову экономить, поэтому использование assembler'ов довольно редко. Но это касается только ширпотреба.

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

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

  140. Почитал коменты - ещо больше убедился, что ОПП это модно. (если бы хотел сказать лудше - так бы и написал).

    поехали.

    Дмитрий пишет - ооп доказало себя - где когда и как???

    никто не будет писать на лиспе - я вообщето думал что язык мёртвый, но начал видеть вакансии на этот язык. точно никто не будет??? а то такое ощущение что не то что будут, а уже пишут!

    Макс - нащот безграмотности Степанова в математике. ну учитывая что человек написал матом комент, я не думаю что он как степанов доктор наук. Собственно Макс, а сам то как думаешь? - кто из вас не понимает математику??? :) ты просто поспешил.

    Да, аксиомы, это то что берёться без доказательств, а доказываються теоремы. Но ты не понял мысли...

    В математике, что либо верно лиш когда доказано. Тоесть если мы имеем факты, которые наводят нас на мысль, мы пытаемся это доказать. И лишь если долгое время не получаеться доказать, но жизнь раз за разом утверждает - что оно таки так, только тогда мы опускаем рукава и констатируем - похоже это аксиома, её нельзя доказать, но оно так есть. вот о чом шла речь. Что прежде чем чтото постулировать, нужно набраться фактов, и убедиться что оно не доказуемо... ну а в плане ооп - не точно степанов сравнил. Но идея похожая. Описывая родителя, мы ещо не посмотрев на конкретику, сразу постулируем чтото, а жизнь то она такая. Куча "отцов" ООП НА КАЖДОМ проекте творят божественный код, который впредь на все случаи жизни будет применим для какойто проблемы, и на другом проекте будут делать новый божественный код, так как опыт предыдущего указал на недостатки. вот о чом шла речь.

    Ugine

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

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

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

    Лично моё мнение, чтоаналогия с сто очень хорошая. сегодня растёт количество добра, которое заставляет начинать сомневаться в СТО, так и в ООП - я про все антипатерны и прочее.

    Мне кажеться лично, что ООП, как идея, это да, хорошая идея, но это точно не серебряная пуля.Я для себя сделал вывод такой.

    1)на собеседовании не надо говорить что ООП это зло, даже если так думаешь.

    2)создавая код, для других програмистов по всему миру, нода очень продумано использовать ооп.

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

  141. Быдлокодер

    С ума можно сойти от такого обсуждения - в нём абсолютно нем ничего осмысленного, даже если исключить оффтоп про математиков и физиков и СТО и пр. Давайте отбросим интерпретируемые языки и будем рассматривать только компилируемые. Чем машинный код, который сгенерит код на ЯП в ООП стиле, будет отличаться от сгенерённого кода от-и-до использующего только процедурный стиль? Несомненно, будет большое число различий, зависящих от использованных техник, того, насколько адекватно код обычный был переписан кем-то в ООП-стиль, короче говоря. Смысл, ИМХО, в том, что чем сложнее абстракция, тем максимально проще необходимо её использовать, а особенно - предельно грамотно подбирать необходимую (привет Design Patterns!, которые на первых взгляд кажутся законченными и детерменированными). Я всё это вёл к тому, что если ведутся такие разговоры объектники vs процедурщики - то это только говорит о том, что спорщики обеих сторон толком не разбираются в парадигмах ООП. В итоге срач скатывается к фаллометрии в виде скорости выполнения... Да и только.

  142. Евгений

    Мужики, наверно выскажу страшно крамольную мысль, за что буду тут заклеймлен позором и ненормативной лексикой, однако факт. Единственный в моей жизни случай, когда я САМ и ДОБРОВОЛЬНО юзал ООП, это когда требовалось портануть алгоритм БПФ Кули-Тюки на конвейерную архитектуру (в FPGA короче на верилоге). Вот там да, это оказалось удобным. С одной стороны насоздавал кучу линий задержки, ключей, фазовращателей и прочей хреноты, которую соединял между собой портами. С другой - мог как угодно издеваться над исходным алгоритмом, прописывая туда вместо класса комплексных чисел любую хрень, которая умела не только складываться и умножаться, а в добавок еще вела подробные логи происходящего. Фактически просто строила граф преобразования. Короче конвейерная версия на С++ была сделана за пару выходных. На верилог это было переписано за день. Во всех остальных случаях обычного чистого С мне хватало с избытком. Ну кроме конечно случаев, когда надо было окошки с менюшками рисовать. Там просто библиотеки этого требовали. Вобщем очень во многом согласен с аффтаром. ООП это и правда скорее раскрученный бренд, чем серебрянная пуля. Да, иногда бывает удобно. Но не более того.

  143. Евгений

    >Наверное, имелось в виду, что в спутниках GPS учитывается релятивистское замедление времени. То бишь, используются достижения СТО.

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

  144. Кстати, только что забавная мысль в голову пришла. Ведь тот единственный в жизни раз, когда я по своей инициативе использовал ООП, я фактически решал ту же самую задачу, под которую С++ и создавался ! Если кто забыл, создавался он именно для задач МОДЕЛИРОВАНИЯ вместо тормозной Симулы-67. Ну так и я использовал его именно для моделирования. Не телефонной сети правда, а конвейерного алгоритма, но какая разница... Не удивительно что в тот раз поимел от С++ кучу положительных эмоций ибо просто употребил инструмент по назначению. Но когда некто утверждает, что этот инструмент хорош вообще на все случаи жизни, это не меньший маразм, чем имея молоток (да очень классный молоток !), утверждать что этот инструмент универсален и пытаться пилить им дрова.

  145. Евгений

    Уффф... Асилил наконец все камменты ! Поражает в первую очередь удивительная адекватность многих из выступивших. Я думал будет куда больше тупого срача, флейма и холивара. Поэтому респект и автору и большинству комментаторов. Резюмируя можно сказать, программирование наука сложная. Да и является ли оно наукой, еще очень большой вопрос. Ибо как любая инженерная деятельность, включает в себя немало от искусства. А потому братцы, не ищите серебрянных пуль. Их нет и быть не может, что бы ни говорили вам препы в универе или авторы популярных книжек. ООП это не более чем МЕТОД. Иногда он работает просто на ура. Иногда нет. А потому не надо заморачиваться. Ваша цель решить задачу, а не написать диссертацию, о том как Вы ее решали (хотя безусловно есть множество задач, достойных не только диссертации, но и нобелевки).

    Ну и наконец о чем бы я сам хотел поговорить. А хотел бы я обсудить типизацию. Динамическая vs статическая. Стаж у меня больше 20 лет. Первую программу набивал еще на перфораторе. Всю жизнь интересовался в основном низким уровнем. Отсюда и языки. Разного рода ассемблеры, С/С++, ява и т.п. Сейчас впервые в жизни взялся написать что-то для веб. Сервер на питоне, потому что задача всей этой хрени будет обработка текстов на естественном русском языке, а на питоне многое для этого есть. Клиент на яваскрипте. Я хотел писать на флеше, но заказчик настоял на яваскрипте из-за совместимости с планшетами.

    Ну так вот... Как итог, когда объем кода на яваскрипте у меня достиг где-то 2К строк, я понял, что с проектом происходит что-то не то. Слава богу на форуме javascript.ru мне хоть и с руганью, но подсказали решение - использовать typescript. Сейчас объем кода на клиенте перевалил за 10К строк и я нормально продолжаю проект. Объем серверного кода сейчас приблизился к тем самым волшебным 2К строк и я всё чаще и чаще задумываюсь, а не уйти ли мне под jetty или что-то вроде этого, на первых порах запустив уже написанных код на питоне через jython.

    И в это же самое время в сети полно любителей яваскрипта и питона ! С удовольствием пишут на этих языках достаточно серьезные проекты. Ну да, в мире нет ничего невозможного, так что наличием таких гуру я не удивлен. Удивляет другое. Что НИКТО ИЗ НИХ так и не смог привести мне примера кода на своем любимом языке, где динамическая типизация имела бы явное и неоспоримое преимущество над статической. Ну а то что она создает (как бы это помягче сказать) определенные проблемы, когда объем кода начинает измеряться в тысячах строк, по-моему согласны абсолютно все. Сторонники динамических языков правда утверждают, что компенсируют это тестами. Вот мне и очень хотелось бы обсудить этот вопрос. В чем все-таки сила динамической типизации и чем так хороши языки питон и яваскрипт ? Пока никто на этот вопрос мне так и не смог убедительно ответить.

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

    Другими словами ОТО математически верна, но не для Евклидова пространства, в котором мы живем.

    Фактически ОТО это "частный случай", математическая абстракция, ничего не имеющая общего с реальным пространством.

  147. GOOGLE

    [url=https://google.ru/]GOOGLE[/url]

  148. Бред же:

    "Нам не нужна химия, биология, сопромат, элетротехника и т.д. Ведь это всё можно объяснить физикой!!! Нахуй столько отдельных дисциплин? сегодня их 100, а завтра 1000 и с каждым днём всё больше, это всё только усложняет!!" примерно такая вот такая х@йня изложена противниками ООП. Так и ни один из быдлокодеров кроме пизд@жа не привёл примеров реального софта без ООП.

    Теория относительности вполне неплохо объясняет мироздание, д@лб@ёбы не увидевшие развитие прогресса за 100 лет, как я уже сказал д@лб@ёбы)) ибо фундаментальная часть физики она кабы фундаментальна, и без неё ты живёшь безграмотным быдлом, которое в свою очередь не может внести свою частицу в научный прогресс, такие вот дела.

    ПыСы: Кругом блядь заговор и эфирный ветер, а повторить положительные результаты по эфиру через 100 лет и застримить это всё мы бл@дь не можем, но пизд@нуть что такой опыт был, проще простого

  149. Да, видимо кризис не в ООП, математике и физике, а в программистах, математиках и физиках. Математик утверждает, что аксиомы доказываются теоремами. Уважаемому математику нужно все-таки позаниматься математикой. И уяснить причинно-следственные связи. А раз уж затронули Лобачевского, то причина его теории - не трудность ОТО (вспомните, когда был Лобачевский, а когда Эйнштейн). Все было наоборот, уважаемый математик. Лобачевский, если хотите, прикольнулся и изменил всего-то одну аксиому. И развил тему (читай - доказал основные теоремы). Все остальное (и все неевклидовые геометрии позднее) появились модификацией базиса - блока аксиом. Учите матчасть. А уважаемому физику следует вспомнить школьный курс физики, где черным по белому написано, что любая теория имеет ограничения. И не надо путать Ньютона с Эйнштейном. А мухи с котлетами. Вот когда Ваше ведро с болтами (для описания его движения достаточно лорда Ньютона) полетит с релятивитской скоростью, тогда Вы на практике (или, как Вы говорите, в быту) и увидите то, чего просите от других. И с удивлением обнаружите, что конторский клерк Эйнштейн был прав. А теперь, уважаемый физик, если хотите, тест на профпригодность. Скажите, пожалуйста, почему у Ньютона 3 _закона_ механики, а у Эйнштейна всего лишь 2 _теории_ (которые почему-то не законы до сих пор)? По поводу противоречий с квантовой механикой. Да, есть нестыковки. На этом Стивен Хокинг делает свою теорию не очень черных дыр. Кстати, если верить Хокингу, то в быту Вы сталкиваетесь с ОТО ежедневно, подвергаясь гравитационному воздействию Земли. Ну и теперь коллеге программисту-антиООПшнику. Я, наверное, открою секрет для Вас, но ООП используется не для отражения физических сущностей (это duck-style, хотя есть и такие умельцы). Его не используют в качестве элементов ИИ с помошью "фрейма" Мински (как в свое время нам парили об этом некоторые вузовские преподаватели, которые никогда не делали мало мальски крупного проекта). И только ушлые акулы софтверного бизнеса оценили эффективность объектного подхода для организации работы крупных команд разработчиков, их координации и дальнейшей поддержки проекта (чтобы в нем не заблудиться, как тем полякам, которых завел в болота герой войны старик Сусанин). Рефакторинг же - лишь прием, облегчающий работу по поддержке и оптимизации проекта и никакого отношения именно к ООП не имеет. Это лишь способность Вашей IDE, которая, кстати не всеми IDE поддерживается. Ну и напоследок о стате (включая английские источники). Прессе нужна сенсация. Клоуны ее им дали. Принимать это в качестве явления в мире программирования несерьезно ибо сенсация эта высосана из пальца.

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

  151. Владимир

    То, что ООП вместо упрощения привело к усложнению - это факт. Но зато до сих пор такие масштабные проекты, как, например, ядро Linux, GTK+, OpenGL и проч., пишутся на Си, даже не на C++, то есть в процедурном стиле. А сколько процентов кода в процедурном стиле написано в проектах, написанных на C++! ООП - это не основа, это надстройка над процедурным программированием, и его не должно быть много, ИМХО.

  152. php писатель

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

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

  153. Человек с еврейской фамилией

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

Оставьте комментарий!

Не регистрировать/аноним

Используйте нормальные имена. Ваш комментарий будет опубликован после проверки.

Зарегистрировать/комментатор

Для регистрации укажите свой действующий email и пароль. Связка email-пароль позволяет вам комментировать и редактировать данные в вашем персональном аккаунте, такие как адрес сайта, ник и т.п. (Письмо с активацией придет в ящик, указанный при регистрации)

(обязательно)


⇑ Наверх
⇓ Вниз