ООП - большой пузырь?

А с нуля на Си что-то разрабатывать...

А на sh и с нуля? А у меня еще библиотеки есть. Я на sh встречал программы (успешные) в тысячи строк.

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

Я с ООП знаком более 20 лет. И без ООП программировал лет 10. Свой Web-фреймворк первые лет 5 (с конца 1990-х) развивал чисто процедурным (исторически сложилось — он пережил длинную цепочку переходов Basic/Forth/Perl/PHP). Но как только перевёл фреймворк на объектные рельсы, скорость разработки увеличилась раз в 5. А объём прикладного кода уменьшился раз в 10. Это один практический пример в рамках одной задачи.

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

ООП - большой пузырь?

с языка снял

Пузыри так долго не живут. Это не пузырь уже, это сфера из бронестекла :)

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

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

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

Притча о слоне и 7 мудрецах.

то что называют мудрецы на курсахООП и то что мудрецы в промышленности разные слоны.

АТД использовались когда было чисто_процедурно?

ООП как таковой применим не очень часто.

Не хотел бы я работать с кодом, который пишут такие, как ты.

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

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

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

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

оставлю это здесь http://eax.me/adt-and-traits/

Слабенько, на 3 с плюсом.

В перечисленных там языках есть ADT?! Не говоря уже о средствах работы с ними.

Go - помесь Сишки, паскаля и javascript (как мне кажется) Go - это такая Си, только проще Если начинать программировать, то лучше с Го Го и Си - лучшие языки компилируемые

если есть использовался ли их синтаксис?

если нет было ло соблюдения «патернов» абстрактный_тип_данных?

Пузырь, который давно лопнул, но адепты еть адепты.

В том виде, в котором оно описано у того же Бертрана Мейера, ООП вполне пригодно. Другое дело, что действительно ОО-проекты часто переусложнены.

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

Не кажется ли вам, что просто Си или какой нибудь Го, проще для разработки реального кода в краткие сроки

Оно может и проще. Но чревато багами, проблемами в случае ухода специалистов, дороже в поддержке, дороже в модификации и т.п.

Напиши парочку систем по ляму строк кода

люди столько неживут. средний вброс в нормальном соотношении кол-во качество, всегда меньше 100строчек в день.