Ты слышал про парня, который попрощался с OOП?

О нет. Ещё один? Что же он сказал?

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

Ох. Да, я слышал всё это раньше...

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

Двигаться дальше к чему?

Ты чего? К следующему технологическому прорыву, конечно!

А, к этому… И что там у нас на очереди?

Не знаю, меня очень привлекает идея микро-сервисов; и я очень заинтересован в Elixr; и я слышал React по-настоящему крут; и ...

Да. Да. Маслобойка. Ты попался в Маслобойку.

Чего? Что ты хочешь этим сказать? Сейчас захватывающее время.

Как по мне, скорее удручающее.

Почему? Новые технологии возникают каждую неделю! Мы взбираемся на всё более высокие высоты.

Тю! Всё, что мы действительно делаем, заново изобретаем колесо, снова и снова. И мы напрасно тратим время и огромные усилия на это.

Ой, да ладно! Мы создаём ПРОГРЕСС.

Прогресс. В самом деле? Это не то, что я вижу.

Ну, и что же ты видишь?

Я вижу расточительство. Массовые, неисчислимые потери времени и средств. Расточительство помноженное на расточительство и помноженное на ещё большее расточительство.

Как ты можешь такое говорить?

Ну, рассмотрим хотя бы этот вопрос с OOП. OOП не умерло. OOП никогда не было живым. OOП является техникой, хорошей техникой. Утверждать, что оно мёртво, это как утверждать, что хорошая отвёртка мертва. Прощаться с OOП, это как прощаться с хорошей отвёрткой. Это пустая трата!

Но функциональное программирование лучше!

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

Это не то, что я слышал. Я слышал, что они взаимоисключающи.

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

И как же это работает по-твоему?

Прогресс в области программного обеспечения следует логарифмической кривой роста. В первые годы прогресс был резким и драматичным. В последующие годы прогресс стал гораздо более постепенным. В настоящее время прогресс практически отсутствует.
Смотри: ассемблер был гораздо лучше, чем машинный код. Fortran был намного лучше, чем ассемблер. C был существенно лучше, чем Fortran. C++ вероятно лучше, чем C. Java был улучшением по сравнению C++. Ruby вероятно немного лучше, чем Java.
Каскадная модель (водопад) была намного лучше, чем ничего. Agile была лучше, чем водопад. Lean был немного лучше, чем Agile. Kanban возможно был чем-то типа улучшения.
Каждый год, хотя мы прикладываем огромные усилия, мы делаем меньший прогресс, чем годом ранее. Потому что каждый год мы становимся всё ближе и ближе к асимптоте.

Асимптота?! Думаешь, есть верхний предел технологий разработки программного обеспечения?

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

Что? Это звучит нелепо! И удручает!

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

Но если мы не будем подстёгивать будущее — мы никогда не создадим его!

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

Так к какому же будущему мы должны стремиться?

К продуктивному. К будущему, которое не подчинено расточительной маслобойке.

Что значит "расточительный" в данном контексте?

Ты когда-нибудь использовал IntelliJ или Eclipse для программирования на Java?

Конечно.

Это невероятно мощные инструменты. Опытный специалист может быть в высшей степени продуктивным с этими инструментами. Рефакторинг! Представления! Удобства! Боже мой, эти инструменты впечатляют!
Тем не менее, каждый раз, когда возникает новый язык, мы отказываемся от мощных инструментов, чтобы перейти к СЛЕДУЮЩЕЙ НОВОЙ ШТУКЕ. И инструменты для нового языка программирования выглядят как уровень жизни в странах третьего мира. Боже, зачастую там нет даже банального "rename" рефакторинга!
На создание приличного набора инструментов уходит время. Если мы будем продолжать переключаться с одного языка на другой, мы никогда не обеспечим их надёжным инструментарием.

Но новые языки лучше.

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

Новые блестящие вещи? Звучит как-то обидно, не так ли?

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

Непрофессиональным?

Да! Это непрофессионально. Нам нужно осознать, что мы упёрлись в асимптоту. Пора остановить расточительное вспенивание языков и фреймворков, а также парадигм и процессов.
Пришло время, чтобы начать просто работать.
Нам нужно выбрать язык, или два, или три. Небольшой набор простых фреймворков. А затем выстроить наши инструменты. Кристаллизовать наши процессы. И стать настоящими профессионалами.

Автор: Source

Источник ^[1]