Вот честно скажи - это ты написал?

PS.
Ответ на вопрос нашел, дочивши до конца
А ведь задал вопрос, дочитав только до середины.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

Да, я когда писал и перечитал, тоже создалось ощущение, что у меня припекло. Но это не так.

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

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

Что значит "вытянешь"? Может и так, не спорю. Но оно мне и не надо. Устраиваться в контору на чистое ООП я не собираюсь, мне эта работа не будет приносить радость. Разобраться и зарефакторить участками существующий код - не думаю что проблема. Я делал это не раз и даже не только на PHP.

Да и вообще, причем тут я. Я не открыл америки, я просто систематизировал то, что нарыл в сети и литературе за время этих холиваров. Это не лично мое мнение. Что касается

Так это не я назвал. Это Википедия, к ней претензии:

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

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

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

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

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

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

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

О том и речь. Что использовать ООП можно и должно. Но ограничиваться только им - ради чего? Ради того, чтобы очередной студент, кричащий "свободная касса!" мог не напрягать мозги при поддержке моего кода? Это его проблемы. Код должен красиво и оптимально работать. Не моя проблема, что кому то это кажется сложным. Голова на что?

А набивать ООП скилы можно и в мультипарадигме. Параллельно с процедурными. Кто запрещал?

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

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

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

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

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

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

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

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

А про рынок ООП программистов я там тоже написал.

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

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

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

Да ни кто не называет его говнокодом(тебя просто троллили), тебе же приводят доводы, что "мультипарадигма" не круто, потому что:

1. Смена стилей кодовой базы (читай как отсутствие унификации кодовой базы), бессмысленная фрагментация кода, что приводит к ужасной энтропии;
2. Довольно сложная поддержка и расширение такого кода;
3. Лишний повод дать программисту делать трудный и бессмысленный выбор как писать код;


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

А с кем? Fabien Potencier, например, активно юзает именно ООП. Я не знаю людей хоть сколько-нибудь искушенных, кто отрицал бы эту парадигму, тем более из принципа, как ТС.

Во-во! Сам хотел эту тему затронуть.

Я разве написал, что это плохо? Я написал, что не стоит этим ограничиваться, только и всего. В парижском ресторане Максим тоже могут приготовить гамбургер. И уверяю, он не будет хуже, чем в Макдональдс.

Почему? Мне очень часто приходят в голову нестандартные решения. И вообще на них прогресс держится.

Так сложилось. И высокоуровневые языки поголовно мультипарадигмальны. Закономернее задать встречный вопрос: Почему вы программируете не на Смолтолке?

Я имел ввиду опыт в ООП. У тебя еще эйфория не прошла. Ну не пройдет, я только рад за тебя буду.

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

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

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

Унификация, это главный антагонист прогресса. Если фрагментация действительно бессмыслена, то согласен. Но часто в ней гораздо больше смысла, чем в попытке все причесать одной гребенкой. Это как денормализация БД. Некрасивый термин, вроде как "сделать ненормальным". Но иногда очень полезная фишка.

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

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

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

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

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

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

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