anonymous@RULINUX.NET~# | Last login: 2024-11-05 19:28:40 |
Регистрация Вход | Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск |
Форум - Talks | [RSS] |
Из одной почтовой рассылки. Очень любопытно. Дальше текст и комментарии не мои.
Из одного холивара:150+ кАмментов, вытащил пару вменяемых. Орфография цинично сохранена. http://blogerator.ru/page/oop_why-objects-have-failed
http://blogerator.ru/page/oop_why-objects-have-failed#comment-97
Clr
06.11.2010 в 06:45
Статья - эпик вин, тред комментариев успешно выведен в режим автотроллинга. По сути, изобретён новый уникальный вид холивара: Лисп против теории относительности - это реально круто.
Статистика очень интересная получается:
* На все 93 комментария только два адекватных - номера 58 и 59.
* Некоторые из представителей (как я понимаю) семейства ООП-кодеров-а-ля-освой-сишарп-за-31-день ничего другого, кроме процедурного и объектно-ориентированного подхода, не знают и искренне полагают, что на этом инженерная мысль благополучно и остановилась.
* Другие представители фауны путают методику с языком, а ООП с С++.
* Третьи берутся сравнивать Си (который, на минуточку, по своей сути является "высокоуровневым ассемблером") с ПХП. Напомню, что ПХП вообще начинал своё существование как шаблонизатор для подстановки переменных в HTML (и очень жаль, что там же и не закончил).
* НИ ОДИН не вспомнил о том, что ООП бывает классовое и прототипное, а это две большие разницы. Да и откуда такие слова-то знать, в самоучителе сишарпа об этом не пишут, а значит тру крутому пасану прогеру это и не надо.
* Ну и фееричное "спервадобейся" на тему отсутствия крупного софта, написанного на Сях. Ядро Линукс, ядро макоси, Апач, MySQL, интепретаторы большинства скриптовых языков, все Гномы, ну и вообще большая часть софта, существующего в рамках проекта GNU. Из другой "оперы": ядро винды, драйвера винды, графическая и десктопная обвязка винды - тоже Си. А Фряха так вообще ВСЯ написана на Сях, полноценная серверная операционка, да. Фактически, можно сказать, что наоборот, нет НИ ОДНОГО успешного случая применения статически типизированного ООП языка (С++, Ада, объектный паскаль, Оберон... ау?) в крупном, стабильном, развивающемся в течение десятилетий проекте, имеющем критическое значение для современной IT-индустрии. Подавляющаяя часть того, что крутится в наших компьютерах и стабильно работает годами, написано на Си.
Конечно, для тех, кому движок "Сталкера" кажется верхом технологичности, стабильности и качества - трудно представить, что есть программы, которые работают и не падают, натурально, годами: от включения сервера после установки в серверной и до его обесточивания через 5 лет.
Теперь что касается непригодности ООП. В том виде, в каком оно проталкивается уже 20 лет в массы, оно не пригодно для хоть сколько-нибудь сложных и ответственных проектов. Зато отлично подходит, чтобы посадить 20 индусов лабать код по заказу через аутсорсинг.
Конечно, есть годные ООП языки, такие как Руби, Питон... Реально хорошие и мощные языки, позволяющие прямо сказать машине, что нужно сделать, не ***хая мозг созданием нового класса на каждый чих. Но эти языки хороши не потому, что они ООП, а потому что это динамические рефлективные высокоуровневые языки. (Хых, для кого я это пишу... Из всех, кто тут писал комментарии, слово рефлективный поймёт 3 с половиной человека, не больше.)
Фактически, Руби и Питон - это Лисп с человеческим лицом. "Лисп для бедных." А все языки по своей внутренней сути, как известно, сводятся либо к ассемблеру, либо к Лиспу - третьего не дано. А если кто-то пытается усидеть на двух стульях сразу, в итоге получается получается С++, templates (тьюринг-полный язык в языке, адская жесть), бинарники HellowWorld на 4 мегабайта, и рефакторинг, рефакторинг, рефакторинг...
http://blogerator.ru/page/oop_why-objects-have-failed#comment-128
[Свернуть] Беларус 15.11.2010 в 04:32
К ООП тоже отношусь спокойно, отрицательно.
Так вот, написание кода - это мелочи. Это 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
anonymous(*) (2011-03-09 11:31:00)
Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
|
|
|
Скрыть
Re: [многа букафф] HolywarМужик, ооп, в его си++ - воплощении это удобно. и на плюсах написан почти весь коммерческий софт. тот же файнридер. с другой стороны, любую вещь можно довести до абсурда. вообще, классы должны описывать типы, а не содержать логику. lockywolf(*)(2011-03-10 10:44:16)
Opera/9.80 (J2ME/MIDP; Opera Mini/5.1.21214/23.405; U; en) Presto/2.5.25 Version/10.54 |
Скрыть
Re: [многа букафф] HolywarМужик, ооп, в его си++ - воплощении это удобно. и на плюсах написан почти весь коммерческий софт. тот же файнридер. с другой стороны, любую вещь можно довести до абсурда. вообще, классы должны описывать типы, а не содержать логику. lockywolf(*)(2011-03-10 10:44:48)
Opera/9.80 (J2ME/MIDP; Opera Mini/5.1.21214/23.405; U; en) Presto/2.5.25 Version/10.54 |
Скрыть
Re: [многа букафф] Holywar> классы должны описывать типы, а не содержать логику.
|
Скрыть
Re: [многа букафф] Holywar>вообще, классы должны описывать типы, а не содержать логику.
Хотя да, меру знать обязательно надо. |
|
|
|
Этот тред читают 2 пользователя: |
Анонимных: 2 Зарегистрированных: 0 |
Re: [многа букафф] Holywar
>Третьи берутся сравнивать Си (который, на минуточку, по своей сути является "высокоуровневым ассемблером") с ПХП. Напомню, что ПХП вообще начинал своё существование как шаблонизатор для подстановки переменных в HTML (и очень жаль, что там же и не закончил).
Недавно на опеннете это читал. :)
Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13