Сегодня мы представляем вашему вниманию продолжение перевода материала о вреде так называемого «функционального» программирования.
Давайте признаем то, что нам, программистам, платят за наше время. Точно так же как строителям, которые роют ямы неподалёку от моего дома вот уже два года (они, кстати, строят стену, то есть — дорогу).
Давайте поищем формулу продуктивности программиста. Каждый, кто работал в любой серьёзной большой корпорации, знает простую формулу успеха:
Человеческий мозг очень плохо приспособлен к работе с тем, что в программировании называют «состоянием приложения». Мы можем, в некий момент времени, хранить в нашей кратковременной памяти лишь примерно пять элементов. «Состояние» в программировании обычно представляет собой данные, хранящиеся в памяти. В ООП это, например, поля объектов или переменные. Работа с мутабельным состоянием очень похожа на жонглирование. Немногие мои знакомые могут жонглировать тремя шарами, не говоря уж о пяти.
ООП прекрасно использует эти слабости. В ООП практически всё может мутировать. Благодарю высшие силы за то, что создатели ООП со всей серьёзностью приняли во внимание то, от чего зависит продуктивность труда разработчиков! В ООП всё мутабельное состояние, кроме того, доступно для использования в разных местах программ по ссылке. Это означает, что программисту нужно не только думать о мутабельном состоянии объекта, с которым он в настоящий момент работает. Ему нужно помнить и о мутабельных состояниях ещё 10-50 объектов, с которыми этот объект взаимодействует! Это напоминает жонглирование сразу 50 шарами. У такого положения дел, кроме того, есть и дополнительная ценность. Это — прекрасное упражнение для мозга.
Ошибки? Да — в процессе жонглирования некоторые мячи падают. Программист, возможно, упустит какие-то мелочи, касающиеся взаимодействия 50 объектов. Но кого это, честно говоря, волнует? Об ошибках в продакшне должны сообщать пользователи. Именно так работают большие серьёзные организации. Затем сообщения об ошибках попадают в журнал JIRA (это, как вы понимаете, серьёзный программный продукт корпоративного уровня). Не пройдёт и нескольких лет, и ошибки будут исправлены. Проблема решена!
Господи, как же я люблю моё мобильное банковское приложение. Оно весьма функционально, банк ценит мой бизнес и заботится о моих персональных данных. Ошибки — это просто возможности (так мне сказали)!
Так называемые «функциональные» программисты непонятно зачем изолируют состояние и делают его иммутабельным. Это влечёт за собой печальные последствия уменьшения сложности программ и, следовательно, уменьшения количества ошибок. Если в кодовой базе будет меньше ошибок — это значит, что программистам придётся решать меньше проблем. Компании-разработчики не смогут брать плату со своих клиентов за исправление ошибок. Использующие функциональные методы программисты, работающие в любой большой серьёзной компании, будут плохо выглядеть в глазах своих менеджеров, и, в то же время, сильно навредят своим шансам на карьерный рост.
Программисту нужна возможность продемонстрировать менеджерам результаты своего труда, результаты продвижения к цели. Каков самый эффективный способ выражения результатов работы программиста? Это, конечно же, количество написанных им строк кода! Если мы все перешли бы на функциональное программирование, то мы сильно расстроили бы менеджеров и зародили бы в них серьёзные подозрения в эффективности нашей работы. «Декларативный» подход приводит к написанию более краткого кода. Его применение очень сильно сокращает число строк кода в программах. Полагаю, совершенно неприемлемо то, что при декларативном подходе для достижения той же самой цели необходимо до 3-5 раз меньше кода, чем при использовании ООП.
Другими словами, при переходе на функциональное программирование наша продуктивность в глазах серьёзных корпоративных менеджеров буквально рухнет. Это, в свою очередь, подвергнет риску наши рабочие места. Поэтому в наших лучших интересах — держаться подальше от «функционального» программирования.
Тот же совет применим и к подрядчикам, которые берут плату с клиентов, основываясь на отработанных часах. Вот простая формула успеха для них:
Эта формула успеха, конечно, кроме того, напрямую применима к серьёзным подрядчикам, которым платят за количество строк кода:
В отличие от функционального программирования, ООП предлагает нам последовательный подход к написанию спагетти-кода. Это чрезвычайно благотворно сказывается на продуктивности разработчика. Писать спагетти-код — значит тратить на написание кода больше оплачиваемых часов. Это — прямая выгода для любого серьёзного объектно-ориентированного программиста. Спагетти — это не только очень вкусно. Это ещё и чрезвычайно важная концепция для тех, кто пишет в стиле ООП.
ООП — это настоящий подарок для подрядчиков и сотрудников серьёзных компаний.
Вы не должны бояться использовать ООП. Повторюсь — назойливые ошибки — это мелочь, о которой не стоит беспокоиться. В любой серьёзной организации есть отдел по предотвращению ошибок (его ещё называют отделом поддержки пользователей), основной задачей которого является защита разработчиков компании от разгневанных клиентов. В конце концов — если клиент не может правильно использовать приложение — это лишь его вина.
Разработчиков не стоит донимать такими не относящимися к их делам вещами, как отчёты об ошибках. Это позволяет обеспечить такое положение дел, при котором ресурсы компаний не используются впустую. Разработчики же, в результате, получают возможность спокойно реализовывать новые возможности приложений и направлять всё своё внимание на создание объектно-ориентированных абстракций корпоративного класса и на применение сложных паттернов проектирования.
Этот тщательно продуманный и жёстко распланированный процесс обычно существует ради защиты человеческих ресурсов организаций. Как только пользователь обнаруживает ошибку, он обычно ищет номер телефона отдела поддержки пользователей. Затем пользователю предоставляют большое интерактивное телефонное меню, включающее в себя различные опции. Обычно на то, чтобы прослушать сведения о меню и выбрать нужную опцию, уходит около 2-5 минут. Этот шаг позволяет отсеять наименее настойчивых клиентов.
Затем клиенту обычно говорят о том, что компания столкнулась с «необычно большим объёмом звонков», и о том, что «среднее время ожидания составляет 56 минут». При этом перед клиентом обычно извиняются за неудобства и говорят о том, как ценят его и его бизнес. На этом шаге большинство клиентов решит не сообщать об ошибке. Для того чтобы развлечь тех, кто всё же решился ждать, им обычно проигрывают вдохновляющую музыку. Кроме того, им предлагают попробовать новое замечательное приложение. Это — то самое приложение, с которым у клиента возникла проблема.
После того, как 56-минутный период ожидания закончился, звонок перенаправляется в колл-центр, расположенный где-нибудь в Северной Америке. Сотрудники подобных колл-центров обычно проходят специальный тренинг, который позволяет им разговаривать с сильным индийским или болгарским акцентом. Сотрудник колл-центра отвечает, что приложение, о котором идёт речь, находится вне сферы его ответственности, но он с радостью переключит клиента на другой отдел.
После ещё одного периода ожидания, который теперь длится 42 минуты, ещё один сотрудник колл-центра с нотками счастья в голосе сообщает клиенту о том, что ошибка, с которой тот столкнулся, на самом деле является особенностью приложения. После этого клиенту рекомендуют обратиться к справочному разделу приложения. Если же клиент продолжает настаивать на том, что он имеет дело с ошибкой, то ему могут даже создать заявку в службу поддержки. Клиент даже может получить ответ — нечто в духе «Воспроизвести ошибку не удалось».
Надеюсь, теперь вы убедились в том, что ошибки — это не то, что должно заботить программиста. В организациях обычно принимают серьёзные меры для того чтобы оградить разработчиков от ненужной траты времени.
Если вы активно ищете работу — приложите некоторые усилия к тому, чтобы убрать из своего резюме всю «функциональную» ерунду. В противном случае никто не воспримет вас всерьёз. Никто в реальном корпоративном мире не тратит время на изучение детских игрушек наподобие «композиции функций», «чистоты», «монад» или «иммутабельности». Вам вряд ли хочется быть похожим на аутсайдера. Если вы начнёте говорить о подобных вещах — это заставит того, кто вас собеседует, неуютно себя почувствовать. А если представитель компании-потенциального работодателя ощутит, что вы умнее его — ваши шансы получить работу в этой компании будут стремиться к нулю.
Специалисты по кадрам, набирающие технический персонал в крупные компании, кроме того, проходят обязательный интенсивный тренинг. Это позволяет им уверенно различать серьёзные технологии — такие, как Java и JavaScript.
Постарайтесь, чтобы в вашем резюме встречались бы упоминания о том, что демонстрирует ваши обширные познания в сфере технологий, которые ценят крупные компании. Включите в резюме такие слова и словосочетания, как «класс», «наследование», «паттерны проектирования», «внедрение зависимостей», «SOLID», «абстрактная фабрика» и «синглтон».
Когда вам предложат решить на листке бумаги задачу FizzBuzz, которую часто предлагают на собеседованиях — вы добрым словом вспомните следующую рекомендацию, которая заключается в том, что вам нужно как следует приготовиться к решению этой задачи. Это — ваш шанс блеснуть своими глубокими знаниями в тех областях программирования, которые ценят в корпоративном мире. Вам стоит начать с исчерпывающего проекта решения, который предусматривает использование паттернов проектирования и других техник ООП. Хорошей отправной точкой в решении подобной задачи может стать FizzBuzzEnterpriseEdition. Многие соискатели допускают одну и ту же ошибку, характерную для новичков. Эта ошибка заключается в том, что они полагаются на ограниченные технологии наподобие функций. После этого нечего удивляться тому, что им, после собеседования, никто не звонит и не пишет.
Рассмотрев вышеприведённые аргументы, серьёзные и точные, любой теперь может чётко увидеть то, что от применения так называемого «функционального» программирования нельзя ждать ничего хорошего. Совершенно ясно то, что этого подхода к программированию нужно избегать любой ценой.
Вокруг «функционального» программирования в последние пару лет поднято немало шума. Но хорошо то, что это кратковременное увлечение сообщества программистов уже угасает! Большие игроки рынка наподобие Facebook и Microsoft уже давно осознали ограничения функционального программирования и безусловное превосходство над ним объектно-ориентированных подходов к организации кода. Они направляют свои силы на новое поколение объектно-ориентированных языков, в частности — на ReasonML и на BosqueOOP. Подобные языки выводят мутабельность состояния приложения на совершенно новый уровень, и, к счастью, в них нет поддержки бесполезных функциональных глупостей наподобие иммутабельных структур данных.
Тут у вас может появиться вопрос о том, какие альтернативы есть у так называемого «функционального» программирования. Это, конечно же, объектно-ориентированное программирование. ООП ниспослано нам самим истинным богом программирования. ООП — это сила, с которой необходимо считаться. Это — Инструмент с большой буквы, применение которого делает программистов продуктивными. Благодаря ООП вы и ваша команда всегда будете заняты делом (и не потеряете работу). Вот моя статья, в которой я подробно рассказываю об ООП.
Да пребудет с вами (объектно-ориентированная) сила. И ваш код. Я един с силой. Мира всем.
Как многие из вас уже, наверное, догадались, это — сатирический материал. Если вы — начинающий программист — не принимайте всё это слишком близко к сердцу.
Функциональное программирование — это замечательно. Потратьте некоторое время на изучение этой парадигмы программирования и вы окажетесь впереди многих товарищей по цеху.
Надеюсь, вам было так же интересно это читать, как мне — писать.
Уважаемые читатели! Что вам больше всего не нравится в ООП?
Успех — это путь, а не цель
Давайте признаем то, что нам, программистам, платят за наше время. Точно так же как строителям, которые роют ямы неподалёку от моего дома вот уже два года (они, кстати, строят стену, то есть — дорогу).
Давайте поищем формулу продуктивности программиста. Каждый, кто работал в любой серьёзной большой корпорации, знает простую формулу успеха:
продуктивность = количество_строк_кода x количество_исправленных_ошибок▍Количество исправленных ошибок
Человеческий мозг очень плохо приспособлен к работе с тем, что в программировании называют «состоянием приложения». Мы можем, в некий момент времени, хранить в нашей кратковременной памяти лишь примерно пять элементов. «Состояние» в программировании обычно представляет собой данные, хранящиеся в памяти. В ООП это, например, поля объектов или переменные. Работа с мутабельным состоянием очень похожа на жонглирование. Немногие мои знакомые могут жонглировать тремя шарами, не говоря уж о пяти.
ООП прекрасно использует эти слабости. В ООП практически всё может мутировать. Благодарю высшие силы за то, что создатели ООП со всей серьёзностью приняли во внимание то, от чего зависит продуктивность труда разработчиков! В ООП всё мутабельное состояние, кроме того, доступно для использования в разных местах программ по ссылке. Это означает, что программисту нужно не только думать о мутабельном состоянии объекта, с которым он в настоящий момент работает. Ему нужно помнить и о мутабельных состояниях ещё 10-50 объектов, с которыми этот объект взаимодействует! Это напоминает жонглирование сразу 50 шарами. У такого положения дел, кроме того, есть и дополнительная ценность. Это — прекрасное упражнение для мозга.
Ошибки? Да — в процессе жонглирования некоторые мячи падают. Программист, возможно, упустит какие-то мелочи, касающиеся взаимодействия 50 объектов. Но кого это, честно говоря, волнует? Об ошибках в продакшне должны сообщать пользователи. Именно так работают большие серьёзные организации. Затем сообщения об ошибках попадают в журнал JIRA (это, как вы понимаете, серьёзный программный продукт корпоративного уровня). Не пройдёт и нескольких лет, и ошибки будут исправлены. Проблема решена!
Господи, как же я люблю моё мобильное банковское приложение. Оно весьма функционально, банк ценит мой бизнес и заботится о моих персональных данных. Ошибки — это просто возможности (так мне сказали)!
Так называемые «функциональные» программисты непонятно зачем изолируют состояние и делают его иммутабельным. Это влечёт за собой печальные последствия уменьшения сложности программ и, следовательно, уменьшения количества ошибок. Если в кодовой базе будет меньше ошибок — это значит, что программистам придётся решать меньше проблем. Компании-разработчики не смогут брать плату со своих клиентов за исправление ошибок. Использующие функциональные методы программисты, работающие в любой большой серьёзной компании, будут плохо выглядеть в глазах своих менеджеров, и, в то же время, сильно навредят своим шансам на карьерный рост.
▍Количество строк кода
Программисту нужна возможность продемонстрировать менеджерам результаты своего труда, результаты продвижения к цели. Каков самый эффективный способ выражения результатов работы программиста? Это, конечно же, количество написанных им строк кода! Если мы все перешли бы на функциональное программирование, то мы сильно расстроили бы менеджеров и зародили бы в них серьёзные подозрения в эффективности нашей работы. «Декларативный» подход приводит к написанию более краткого кода. Его применение очень сильно сокращает число строк кода в программах. Полагаю, совершенно неприемлемо то, что при декларативном подходе для достижения той же самой цели необходимо до 3-5 раз меньше кода, чем при использовании ООП.
Другими словами, при переходе на функциональное программирование наша продуктивность в глазах серьёзных корпоративных менеджеров буквально рухнет. Это, в свою очередь, подвергнет риску наши рабочие места. Поэтому в наших лучших интересах — держаться подальше от «функционального» программирования.
Тот же совет применим и к подрядчикам, которые берут плату с клиентов, основываясь на отработанных часах. Вот простая формула успеха для них:
количество_строк_кода = время_необходимое_на_написание_кода = $$$деньги$$$Эта формула успеха, конечно, кроме того, напрямую применима к серьёзным подрядчикам, которым платят за количество строк кода:
if (1 == '1') {
doStuff();
} else {
// деньги
}▍Спагетти-код — это наш хлеб с маслом
В отличие от функционального программирования, ООП предлагает нам последовательный подход к написанию спагетти-кода. Это чрезвычайно благотворно сказывается на продуктивности разработчика. Писать спагетти-код — значит тратить на написание кода больше оплачиваемых часов. Это — прямая выгода для любого серьёзного объектно-ориентированного программиста. Спагетти — это не только очень вкусно. Это ещё и чрезвычайно важная концепция для тех, кто пишет в стиле ООП.
ООП — это настоящий подарок для подрядчиков и сотрудников серьёзных компаний.
Отдел предотвращения возникновения ошибок
Вы не должны бояться использовать ООП. Повторюсь — назойливые ошибки — это мелочь, о которой не стоит беспокоиться. В любой серьёзной организации есть отдел по предотвращению ошибок (его ещё называют отделом поддержки пользователей), основной задачей которого является защита разработчиков компании от разгневанных клиентов. В конце концов — если клиент не может правильно использовать приложение — это лишь его вина.
Разработчиков не стоит донимать такими не относящимися к их делам вещами, как отчёты об ошибках. Это позволяет обеспечить такое положение дел, при котором ресурсы компаний не используются впустую. Разработчики же, в результате, получают возможность спокойно реализовывать новые возможности приложений и направлять всё своё внимание на создание объектно-ориентированных абстракций корпоративного класса и на применение сложных паттернов проектирования.
▍Процесс работы с сообщениями об ошибках
Этот тщательно продуманный и жёстко распланированный процесс обычно существует ради защиты человеческих ресурсов организаций. Как только пользователь обнаруживает ошибку, он обычно ищет номер телефона отдела поддержки пользователей. Затем пользователю предоставляют большое интерактивное телефонное меню, включающее в себя различные опции. Обычно на то, чтобы прослушать сведения о меню и выбрать нужную опцию, уходит около 2-5 минут. Этот шаг позволяет отсеять наименее настойчивых клиентов.
Затем клиенту обычно говорят о том, что компания столкнулась с «необычно большим объёмом звонков», и о том, что «среднее время ожидания составляет 56 минут». При этом перед клиентом обычно извиняются за неудобства и говорят о том, как ценят его и его бизнес. На этом шаге большинство клиентов решит не сообщать об ошибке. Для того чтобы развлечь тех, кто всё же решился ждать, им обычно проигрывают вдохновляющую музыку. Кроме того, им предлагают попробовать новое замечательное приложение. Это — то самое приложение, с которым у клиента возникла проблема.
После того, как 56-минутный период ожидания закончился, звонок перенаправляется в колл-центр, расположенный где-нибудь в Северной Америке. Сотрудники подобных колл-центров обычно проходят специальный тренинг, который позволяет им разговаривать с сильным индийским или болгарским акцентом. Сотрудник колл-центра отвечает, что приложение, о котором идёт речь, находится вне сферы его ответственности, но он с радостью переключит клиента на другой отдел.
После ещё одного периода ожидания, который теперь длится 42 минуты, ещё один сотрудник колл-центра с нотками счастья в голосе сообщает клиенту о том, что ошибка, с которой тот столкнулся, на самом деле является особенностью приложения. После этого клиенту рекомендуют обратиться к справочному разделу приложения. Если же клиент продолжает настаивать на том, что он имеет дело с ошибкой, то ему могут даже создать заявку в службу поддержки. Клиент даже может получить ответ — нечто в духе «Воспроизвести ошибку не удалось».
Надеюсь, теперь вы убедились в том, что ошибки — это не то, что должно заботить программиста. В организациях обычно принимают серьёзные меры для того чтобы оградить разработчиков от ненужной траты времени.
Не допускайте на собеседованиях «ошибок новичков»
Если вы активно ищете работу — приложите некоторые усилия к тому, чтобы убрать из своего резюме всю «функциональную» ерунду. В противном случае никто не воспримет вас всерьёз. Никто в реальном корпоративном мире не тратит время на изучение детских игрушек наподобие «композиции функций», «чистоты», «монад» или «иммутабельности». Вам вряд ли хочется быть похожим на аутсайдера. Если вы начнёте говорить о подобных вещах — это заставит того, кто вас собеседует, неуютно себя почувствовать. А если представитель компании-потенциального работодателя ощутит, что вы умнее его — ваши шансы получить работу в этой компании будут стремиться к нулю.
Специалисты по кадрам, набирающие технический персонал в крупные компании, кроме того, проходят обязательный интенсивный тренинг. Это позволяет им уверенно различать серьёзные технологии — такие, как Java и JavaScript.
Постарайтесь, чтобы в вашем резюме встречались бы упоминания о том, что демонстрирует ваши обширные познания в сфере технологий, которые ценят крупные компании. Включите в резюме такие слова и словосочетания, как «класс», «наследование», «паттерны проектирования», «внедрение зависимостей», «SOLID», «абстрактная фабрика» и «синглтон».
Когда вам предложат решить на листке бумаги задачу FizzBuzz, которую часто предлагают на собеседованиях — вы добрым словом вспомните следующую рекомендацию, которая заключается в том, что вам нужно как следует приготовиться к решению этой задачи. Это — ваш шанс блеснуть своими глубокими знаниями в тех областях программирования, которые ценят в корпоративном мире. Вам стоит начать с исчерпывающего проекта решения, который предусматривает использование паттернов проектирования и других техник ООП. Хорошей отправной точкой в решении подобной задачи может стать FizzBuzzEnterpriseEdition. Многие соискатели допускают одну и ту же ошибку, характерную для новичков. Эта ошибка заключается в том, что они полагаются на ограниченные технологии наподобие функций. После этого нечего удивляться тому, что им, после собеседования, никто не звонит и не пишет.
Вероятно, функциональное программирование не может быть использовано для разработки серьёзных программных решений
Рассмотрев вышеприведённые аргументы, серьёзные и точные, любой теперь может чётко увидеть то, что от применения так называемого «функционального» программирования нельзя ждать ничего хорошего. Совершенно ясно то, что этого подхода к программированию нужно избегать любой ценой.
Вокруг «функционального» программирования в последние пару лет поднято немало шума. Но хорошо то, что это кратковременное увлечение сообщества программистов уже угасает! Большие игроки рынка наподобие Facebook и Microsoft уже давно осознали ограничения функционального программирования и безусловное превосходство над ним объектно-ориентированных подходов к организации кода. Они направляют свои силы на новое поколение объектно-ориентированных языков, в частности — на ReasonML и на BosqueOOP. Подобные языки выводят мутабельность состояния приложения на совершенно новый уровень, и, к счастью, в них нет поддержки бесполезных функциональных глупостей наподобие иммутабельных структур данных.
Итоги: дар богов
Тут у вас может появиться вопрос о том, какие альтернативы есть у так называемого «функционального» программирования. Это, конечно же, объектно-ориентированное программирование. ООП ниспослано нам самим истинным богом программирования. ООП — это сила, с которой необходимо считаться. Это — Инструмент с большой буквы, применение которого делает программистов продуктивными. Благодаря ООП вы и ваша команда всегда будете заняты делом (и не потеряете работу). Вот моя статья, в которой я подробно рассказываю об ООП.
Да пребудет с вами (объектно-ориентированная) сила. И ваш код. Я един с силой. Мира всем.
Как многие из вас уже, наверное, догадались, это — сатирический материал. Если вы — начинающий программист — не принимайте всё это слишком близко к сердцу.
Функциональное программирование — это замечательно. Потратьте некоторое время на изучение этой парадигмы программирования и вы окажетесь впереди многих товарищей по цеху.
Надеюсь, вам было так же интересно это читать, как мне — писать.
Уважаемые читатели! Что вам больше всего не нравится в ООП?
