Бинарный салют, друзья! На связи Инженер Спок.
Сегодня мы поговорим об одном расхожем мифе, который как бы миф, а как бы и не миф. Я говорю о следующем тезисе:
"Язык программирования – это инструмент, а значит, надо выбирать язык, исходя из той задачи, которую вы решаете. Ведь для решения определенных задач подходят определённые языки".
Ну, звучит логично, и для новичков может показаться, что лишь глупец будет оспаривать то, что язык программирования – это лишь инструмент, который выбирают, исходя из решаемых задач. Что ж, давайте в этой статье попробуем разобраться, так ли это, и существуют ли какие-то важные нюансы. Поехали!
Лайкосы / Подписки / Курсы
Язык программирования лишь инструмент?
Итак, в этих ваших интернетах довольно распространено мнение, что язык программирования – это инструмент. Раз это инструмент, то желательно знать побольше языков и применять тот или иной язык, в зависимости от решаемой задачи. Дать некоторую формулировку, которая закрыла бы рассматриваемый вопрос, довольно проблематично, и, как мне кажется, будет проще обсудить какие-то примеры из жизни. Язык программирования – это действительно инструмент, и иногда он выбирается, действительно, исходя из поставленной задачи. Если вы хотите разработать игру уровня Triple-A, то, скорее всего, вне зависимости от ваших желаний, придётся использовать С++.
Более того, в выборе движков вы тоже будете сильно ограничены. Вы не можете взять Python для разработки каких-либо вменяемых игр. Можно вдаваться в причины этого, но это затянет статью, так что давайте примем это как факт. Этот пример хорошо иллюстрирует тот факт, что если задача стоит нишевая или специфическая, то выбирать зачастую будет практически не из чего. Для программирования микроконтроллера, который надо воткнуть в миллион девайсов, придётся, скорее всего, использовать, опять же, С++ или вообще чистый C, потому что бизнесу надо удешевлять производство девайсов, и туда просто так совать Arduino или вообще полноценный комп в виде Raspberry Pi никто не будет.
Итак, если речь о нише или специфике, то, пожалуй, к изначальному тезису придраться трудно, ибо всё так и есть. Ну, специфика специфике, правда, рознь, ибо в разных нишах разная широта выбора доступных инструментов. Но не будем углубляться, допустим, что в большинстве нишевых случаев вышеозначенный тезис справедлив. Однако давайте разберёмся с задачами более общего порядка. Неспроста самые популярные языки программирования, такие как C# или Java, являются языками общего назначения, то есть на них можно решать почти что любые задачи. Какие-то легче, какие-то сложнее.
Но возьмем, к примеру, C#. Используя C#- платформу .NET, можно писать под Windows, Linux, MacOS, можно десктопное приложение, можно мобильные, можно игры на Unity, можно machine learning заниматься, можно под микроконтроллеры писать с ограничениями...
У C# очень высокий уровень интероперабельности с низкоуровневым кодом, написанным на С++. Примерно то же самое можно сказать и о Java. Да, что касается игр, микроконтроллеров, machine learning и Data Science, – в зависимости, опять же, от задачи, при выборе языка и платформы, возможно, придётся отказаться от C# в пользу иного технологического стека. Это правда. Однако как это происходит в реальности? Так ли это просто?
На самом деле, в реальной жизни не всегда, но зачастую даже в крупных компаниях используется какой-то один язык общего назначения, которым забивают абсолютно все доступные гвозди. Казалось бы, это тот самый знаменитый антипаттерн, когда человеку с молотком в руках всё вокруг кажется гвоздями. И точно таким же образом, когда в конторе используют какой-то один язык и платформу, ими стараются закрыть абсолютно все проблемы, даже те, для которых существуют более подходящие инструменты. Бизнес будет до последнего стремиться применить ту платформу, которая у него в ходу. И, лишь полностью осознав необходимость смены технологического стека или добавления нового технологического стека, пойдёт на это. А почему же так происходит?
Да всё очень просто. Начнём с рассмотрения утверждения о том, что программистам необходимо знать несколько языков программирования.
Трудно не согласиться с тем, что знание нескольких языков программирования делает программиста лучше. Такой специалист понимает программирование глубже, знает больше концепций. А с учетом мультипарадигмальности множества современных языков, это весьма полезно.
Однако не стоит путать хорошее знакомство с языком программирования с профессиональной разработкой на этом языке. Это совершенно разные вещи, и они тем больше поляризуются, чем сложнее инженерный продукт, для разработки которого планируется применять язык программирования.
Проблемы с применением множества языков программирования
Для действительно глубокого погружения в язык и соответствующую платформу уходит минимум пара лет даже у профессиональных программистов. Получается, что в реальном мире количество программистов, знающих более одного языка программирования на действительно хорошем уровне, достаточном для корпоративной разработки, минимально. И это мягко сказано. Большинство же осваивает хорошо лишь какой-то один язык и всю жизнь на нём работает. Это совершенно не предосудительно. То есть получается, что в большинстве IT-контор складывается ситуация, при которой есть некий довлеющий технологический стек, и при найме сотрудников нанимаются те, кто понимает в этом самом стеке. А если нанимаются те, кто понимает в конкретном технологическом стеке, это автоматически означает, что в других технологических стеках эти специалисты ничего не понимают. В большинстве случаев. Когда у конторы возникнет задача, для которой основной технологический стек подходит не лучшим образом, но всё же подходит, бизнес даже не задумается о том, чтобы выбрать более подходящий инструмент. Ему это на фиг не надо. Программисты уже наняты и способны решить задачу. Вот пусть её и решают. Никому никакого дела нет до того, что на другом языке программирования код, видите ли, получился бы более чистым. Прошу заметить, это ещё автоматически не означает, что программистам придётся писать говнокод.
А представьте, что контора, вся такая белая и пушистая, и решила забивать гвозди молотком, а закручивать шурупы отвёрткой. Аналогия звучит прекрасно, однако на практике всё может быть не так радужно.
Представим, что в конторе основным языком программирования является С#, и вдруг возникла задача реализовать крупную библиотеку для внутреннего использования, в которой будет очень много так называемой чистой логики, близкой к математике, возможно. Вполне вероятно, что этой конторе в идеале стоило бы выбрать для реализации такой библиотеки в качестве языка программирования F#. Это функциональный язык программирования, который, казалось бы, идеально подходит для решения подобных задач.
Кроме того, в данном случае даже технологический стек поменять не пришлось, ведь F# – это брат С#, который работает на платформе .NET. Казалось бы, вообще кайф. Ну о чём тут можно думать? Надо, конечно же, выбрать отвёртку в виде F# для закручивания шурупов в виде чистой логики. Контора решает так и поступить. Однако каково будет удивление начальства, когда оно узнает, что среди С#-разработчиков никто или, в лучшем случае, полтора инвалида из пула в 20 человек знакомы с С# на вменяемом уровне. А если контора решит порвать рубаху на груди и нанять F#-разрабов с рынка, то их, опять же, ждёт разочарование: вереница из кандидатов у порога не выстроится. Допустим, что нашли N человек, которые займутся разработкой той самой библиотеки.
Ну что ж, прекрасно, конечно. Но, с высокой долей вероятности, вместо спокойствия контора обзавелась бомбой замедленного действия. F#-разработчиков на рынке вряд ли станет больше, а ротация кадров – штука, с которой, так или иначе, придётся столкнуться. То есть теперь контора обречена искать редкие кадры. А когда никто из F#-разрабов недоступен (ну, например, часть в отпуске, а часть при смерти), то с внезапно найденными багами разбираться придётся С-шарперам. А это долго, муторно и чревато неприятностями.
Именно по этой причине, когда в подобной конторе возникает способный программист с тягой к изучению нового, который, возможно, из благих намерений предлагает тимлиду или техническому директору разработать большой кусок кода на языке, не основном для данной конторы, то, собственно, такой программист чаще всего адекватным тимлидом или техдиром бывает послан далеко лесом. Его руководство понимает, что огребёт массу геморроя, если позволит оттачивать свои технические скилы этому хорошему программисту, ибо в сухом остатке выяснится, что свои технические скилы этот программист будет оттачивать за счёт бизнеса. А зачем это бизнесу надо? Правильно, на фиг не надо.
Итоги
Вот, собственно, вот это всё я и хотел сегодня прояснить для многих людей, даже для тех, кто уже давно не является джуном, но всё ещё не понимает, отчего же так происходит. Таким образом, изначальный тезис о том, что язык программирования – это инструмент, в принципе, в общем и целом, верный. Однако есть нюансы. И если искать аналогию, то я, пожалуй, сравнил бы такой язык общего назначения, как С# или Java, не с молотком или отвёрткой, то есть с конкретным инструментом, которым можно эффективно делать что-то одно, а, скажем, со швейцарским ножом, который представляет собой кучу инструментов в одном. Им можно и что-нибудь порезать, или прикрутить и открутить и так далее. Местами он будет не так удобен, как какой-то конкретный инструмент, поскольку, когда вы будете откручивать что-то, остальные инструменты будут у вас находиться в руке и мешаться, создавать дискомфорт. Вот, пожалуй, такая аналогия более близка к реальности.
Означает ли это, что надо отказаться от изучения дополнительных языков программирования? Отнюдь. Даже поверхностное изучение языков, основная парадигма которых отличается от основной парадигмы вашего основного языка – дело полезное. Необязательно погружаться с головой. Если получилось погрузиться глубоко – прекрасно. Если только поверхностно – хорошо. Однако если программист железно знает какой-то один язык программирования, особенно мультипарадигмальный, типа С#, то вполне себе проживёт неплохую жизнь, совсем не трогая другие языки.
Да, вот в таком вот мы неидеальном мире живём. А вы, мои дорогие подписчики, не повторяйте заезженные штампы, распространяемые людьми, которые сами не понимают, о чём говорят. Вместо этого загляните в описание к статье и воспользуйтесь ссылками на мои видеокурсы. В конце концов, как известно, статьи я пишу только для того, чтобы на вас заработать. Надеюсь, статья была полезна и станет некоей пищей для размышлений. Возможно, даже вызовет дискуссии в комментах, ведь я оставил за бортом множество управленческих проблем, которые можно было бы обсудить. До новых встреч.
