Программисты на COBOL и RPG тоже одобряют.

«Стартап» — это как раз не просто ранняя фаза продуктовой компании. Очень часто стартап создают именно, чтобы выгодно продать, а вовсе не для развития его в продуктовую компанию.

Как-то так?
lh5.googleusercontent.com/...QA/EHQ1w0144o0/s0/sap.JPG

Я и в Киеве встречал. Причем, в аутсорсе. Дружная компания «дедушек» пилила что-то для IBM 360/370 на RPG (нет, RPG — это язык, а не то, что вы подумали)

Чем более небольшая, тем более ведущая и тем более «лидер рынка».

Год назад они показывали похожего атропоморфного робота, который вполне хорошо бегал по беговой дорожке и тоже удерживал равновесие при боковых ударах. Думаю, если у них в 2015 году получится «терминатор», они его показывать не будут :-)

Передовая разработка США — это всё-таки вот такое
www.youtube.com/...h?v=C8toQlSH8Xs
Особенно удержание равновесия на одной ноге впечатляет.

Мне пришло. Причем на старый ящик, причем, попало в спам. Ура, я программист.

Окей. Буду знать, чего ждать через 10 лет :-)

Мешает. Ключевое слово «сорокалетние». Это значит, что есть жена и орава детей, ремонты, ипотеки, бесконечные поездки по магазинам и аптекам, и основное желание — не изучить новый фреймворк, а спать, спать и еще раз спать!

Не наоборот, а вообще не зависит от. А зависит от свойств конкретных людей.

Совсем недавно обнаружилось дивное. Так что довод про частоту использования утилит (и кода) не всегда работает.
tjournal.ru/paper/bash-bug
Про каждый сам себе писец не понял, какое это имеет отношение к вопросу выбора между наследованием и композицией. Композицию наоборот проще тестировать.
Опять же соблюдение LSP — та еще задача.

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

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

Я так понимаю, речь о Java.
В .NET механизм перехода по таблице виртуальных методов по скорости почти не уступает вызову просто метода (единицы лишних команд процессора) и, насколько я помню, не зависит от глубины наследования.

Какая-то каша.
Во первых зависит от языка и фреймворка.
Начнем с простого. Например, в .NET наследование везде — любой тип унаследован от System.Object. А вот JavaScript хотя и объектно-ориентированный язык, но наследования там нет. Потому и появились всякие CoffeeScript.
В том же .NET обобщение — вообще ортогонально к наследованию. Обобщение реализовано через наследование.
Длинные цепочки — да, зло, но не абсолютное.
Я бы говорил, скорее, о композиции против наследования. Композиция очень мощный инструмент. Хотя заменить наследование полностью опять же не может.

Кто мешает заменять ноуты по мере необходимости? Сейчас имею дело с замечательным экземпляром HP: i7, 8 гиг, ссд, до 4 мониторов одновременно через докстанцию. С крышкой проблем нет. Из недостатков — условная мобильность в 3.5 кг и ценник.
Вы просто не умеете их готовить ©

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

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