Всем привет, меня зовут Серёжа, я технический лидер iOS-разработки в Альфа-Банке. Сегодня я хочу поговорить о многогранности мира программирования, а именно о количестве языков и причинах, по которым они нам нужны, и о том, зачем одному программисту несколько языков.
Поскольку тема довольно неоднозначна, хочу зафиксировать два момента:
Всё нижеизложенное – моё личное и субъективное мнение, основанное на моём опыте.
Если с каких-то рассуждений прямо сильно подгорит, приходи в комментарии, будет классно пообщаться!
Из основных причин, зачем учить языки (как языки программирования, так и языки в принципе), выделю: непредсказуемое будущее (никогда заранее не знаешь, какой язык тебе пригодится), огромное количество зарубежных материалов и базирование многих вещей на английском (например, название сущностей в том же Swift). В целом с языками программирования так же, как и со знаниями: лишними точно не будут.
Как я знакомился с языками
Сколько себя помню, с тех пор, как начал интересоваться ИТ, меня всегда поражало разнообразие языков программирования. В школе мы изучали Pascal, Delphi и позднее C. Я вообще не понимал принципиальную разницу между ними, зачем их так много и для чего мне учить новый язык, если я уже знаю какой-то (справедливости ради, для школьных задач все языки примерно одинаковые).
Уже позже, в университете, я узнал, чем же всё-таки отличаются языки, зачем придумывают новые, и как с этим жить. Тогда же у меня и сформировалась чёткая метафора о параллели языков программирования с инструментами.
Языки программирования, как инструменты в ящике рабочего. Да, можно взять только молоток, особенно если рабочий — специалист по забиванию гвоздей. Молотком можно забить саморез в стену при большом желании, но, согласитесь, если бы у вас была отвёртка или шуруповёрт, с саморезами вам было бы гораздо проще (да и саморез сел бы надёжнее).
Так и с языками, нет единого, который применим вообще ко всему и на отличном уровне (привет, JavaScript). Каждый язык хорош для какой-то одной или даже нескольких задач, но использовать его везде не имеет большого смысла, так как постоянно придётся мириться с ограничениями.
Главный вопрос: какие языки учить?
Так какие же языки нужно учить программисту? Вопрос довольно сложный и многогранный. Да и слово «нужно» неуместно, так как особо горящей потребности в этом, как правило, нет.
Я, как мобильной разработчик, могу говорить с высоты своего опыта только о фронт-разработке (простите за тавтологию), но, думаю, что и у ребят с бэкенда или системной разработки (или любых других мест, разработка живёт не одними программами) идеи будут те же самые.
Конечно, тем, кто пишет на более-менее современных языках (JavaScript, Kotlin, Swift) сложно понять, что существуют другие языки зачем нужны другие языки программирования. Все они мультипарадигмальные, и на них можно писать почти что угодно, причём с удобством для себя. В чём же тогда проблема — разберёмся далее.
Плагины, скрипты и на чём их пишут
Возьмём утилиты, которые помогают нам в работе (я сейчас не про IDE): плагины, скрипты, автоматизаторы. На чём их пишут? Ну, наверное, можно написать на тяжёлом Swift или Kotlin, можно использовать npm и тащить с собой всю телегу с модулями различные библиотеки для JS, и это даже будет работать, но насколько это всё удобно? И что делать, если на рынке уже есть утилита, которая требует другого языка?
В таком случае вам пригодятся lightweight-языки для написания простеньких скриптов, особенно те, которые позволяют развернуть нужное окружение на любой рабочей машине и жить в одном окружении всей команде. Так, например, очень удобно писать скрипты на Ruby или Python, потому что они встроены в большинство Unix-систем, а также дают возможность настроить весь workaround очень просто (например, с помощью Bundler). Можно ещё писать скрипты прям для bash (zsh и т.д.), это почти максимальный lightweight, но ты платишь за это удобством, да и не все хорошо владеют Shell сегодня.
Многие из нас пишут удобные скрипты для работы, но вот в чём проблема: чтобы запустить скрипты, их нужно скачивать и разворачивать у себя, поддерживать в актуальном состоянии и т.д. Если скрипт маленький — ничего, а вот если большой, для него нужны сторонние ресурсы, которые неизвестно где находятся, а если вам ещё и нужен доступ к базам данных…
Мы делаем для такого микросервисы — лайтовые внутренние «ручки», которые можно дёрнуть из внутренней сети и воспроизвести функции, например, добавить ревьюеров в репозиторий разом во все в проекты.
Так исторически сложилось, что эти микросервисы мы пишем на Go. По нынешним меркам довольно молодой язык, который уже успел заслужить одобрение со стороны многих крутых компаний, и они начали применять его в продакшене. Подробно про Go можно почитать тут. Добавлю, что это системный язык программирования, который работает очень быстро.
Прикольно, занимая должность iOS-разработчика, параллельно приобретать новый востребованный навык. Понятно, что Go — неспецифический язык для iOS, в отличие от Swift, но для меня это и стало мотивацией поизучать его. На Swift тоже можно писать микросервисы, и ребята в Альфе даже пробовали. Но чаще пишем на Go, как раз чтобы попробовать что-то интересное. Были даже случаи, когда ребята из iOS уходили в бэкенд, просто потому что понравилось.
Примеры с CocoaPods и Fastlane и хаосом в линтере
В iOS-разработке есть самый популярный и удобный менеджер пакетов под названием CocoaPods, который написан на Ruby (и да, я знаю про Carthage и SPM, но пока они не отняли весь рынок у CocoaPods). Знание Ruby у нас явно будет не лишним.
Также есть безумно популярный и удобный автоматизатор сборки под названием Fastlane, и он тоже на Ruby. Здесь резонный вопрос: ну и что, что они на Ruby, я же их только использую? Да, всё так, но часто компании дорабатывают эти утилиты или пишут свои функции, чтобы расширить возможности. Согласитесь, в таком случае неплохо бы знать Ruby?
Необязательно знать все фреймворки, вышедшие для Ruby, или все ультрасложные конструкции языка, но неплохо понимать базовые штуки. Расскажу пример из жизни: у нас в Альфе как-то раз на сборках PR начал происходить просто хаос, код менялся сам собой, причём непонятно на что (это было ещё даже до появления ChatGPT).
Мы не могли понять, что происходит со сборками и начали раскапывать историю коммитов, чтобы найти виновника. Виновником оказалась функция на Ruby, которая изменяла приходящие в неё данные через параметры. В Swift для этого нужно указывать специальное слово inout, чтобы приходящие параметры можно было менять, а в Ruby это по умолчанию(сейчас профессионалы Ruby могут меня съесть, потому что это не совсем так, но в данном контексте этого достаточно). iOS-разработчик о таком, естественно, не знал.
В общем и целом, забавная вышла история, мы смогли быстро найти проблему и откатить изменения. Ничего страшного не случилось, но могло что-то сломаться при сборке релиза.
Теперь о CI/CD
Кроме скриптов и автоматизаторов, на большинстве мало-мальских серьёзных проектов используется CI/CD. Одна из самых популярных и известных таких систем (а также open source) — это Jenkins. Так вот, если вы хотите писать джобы на Jenkins, то придётся немного подучить Groovy.
Если кто не знает, Groovy — это язык, построенный на базе JVM и имеющий обратную совместимость с Java, что хорошо для людей, знакомых с Java, и не очень для тех, кто регулярно пишет на других языках. Да, можно переехать на другую систему CI/CD с другим языком, но менять инструменты только из-за языка как минимум странно и непрактично.
В любом случае большинство, если не все системы CI/CD так или иначе привязаны к какому-то языку разработки. Даже если вы напишите свою систему для данной цели, всё равно все джобы и скрипты нужно будет писать на каком-то одном языке. Команда чаще всего мультиплатформенная, и кому-то всё равно придётся осваивать новый язык для поддержки и доработки CI/CD.
Иногда, конечно, за CI/CD отвечает отдельный человек или команда, но такое бывает только на крупных проектах. И да, умение развернуть и поддерживать CI/CD никогда лишним не будет.
Pet-проекты и микросервисы для себя
Pet-проекты ребята пишут в свободное время, чтобы сделать что-то по кайфу. Если тебе нравится программировать, логично, что в свободное время ты не против этим заняться, особенно если хочешь сделать что-то конкретное. Я как-то написал за пару вечеров пульт для телевизора, потому что меня выбесили все приложения из стора: во-первых, они дорогие и рекламы очень много, во-вторых, я могу не хуже.
У нас в команде кто-то писал fullstack-проекты с фронтом, кто-то — чисто на бэкенде. Кто-то писал софт для тренировок, кто-то — приложение для изучения английского и даже получал деньги за рекламу.
Это покрывало затраты на аккаунт, плюс прилетало ещё 100$ в год сверху. Кто-то пишет проект, чтобы изучать новую технологию — это самая частая история. Компания Apple в своё время представила виджеты или Swift UI, и все побежали их пробовать. Мало прочитать гайдлайны и статьи про новые фишки, нужно пописать самому, чтобы всё понять. Для этого можно сделать калькулятор или To do лист. Главное не приложение, а как и с помощью чего ты его написал.
Pet-проекты требуют нестандартных подходов и мотивируют изучать новые технологии, чтобы добавить какую-то функциональность. Когда у тебя в багаже умение пользоваться разными языками, ты можешь запросто без изучения чего-то с нуля выполнить новую работу. У тебя расширяется инструментарий.
Обычно полноценные проекты разрабатываются большой командой, и до начала самой разработки подготавливаются различные артефакты, изучается рынок, планируется продукт, а также выбираются технологии для реализации. У pet-проекта нет стадии предпродакшена, разработка запускается, и необходимость в новой (и потенциально неизученной) технологии возникает сразу.
Если ты когда-то писал сервер на условном Python или Ruby, то можешь пойти и развернуть бэкенд для своего приложения. Если ты этого никогда не делал, потребуется больше времени, и нужно будет изучить новый фреймворк или новый язык и новый фреймворк для него. Те, кто пишут у нас микросервисы, намного охотнее разворачивают какие-то системы, чем те, кто занимается чистым фронтом.
Извечный холивар про единый язык и мультиязыки
Все мы знаем про замечательный JavaScript. Есть огромное количество людей, которые пишут на нём бэкенд, фронтенд, мелкие скрипты, микросервисы и даже мобильные приложения. При всём уважении, это прекрасный язык для своих вещей, я не хейтер JS, но и не сторонник такого мнения. Это быстро, удобно, ты не изучаешь новые технологии. Если вам нравится — спорить не буду, вам это приносит доход и (возможно) удовольствие.
Я считаю, что языки разрабатываются под конкретные нужды. У нас есть системные языки, языки для фронта, языки для мобильной разработки. Kotlin и Swift подходят много для чего, кроме того, под что они создавались, за счёт универсальности и продуманности, но имхо, скоуп этих задач ограничен. Если мы выходим за этот скоуп, могут возникнуть проблемы.
Одна из проблем — отсутствие большого комьюнити. Если ты пишешь бэкенд на языке, предназначенном для фронта, тебе будет трудно встретить таких же энтузиастов. Это приводит к тому, что некому развивать и двигать технологию, находить ответы на вопросы. Даже на Stack Overflow про Vapor в разы меньше ответов. Возможно, в будущем что-то изменится, но я не Нострадамус, я не знаю. Пока, выбирая фреймворк и язык для написания бэкенда в продакшен, вряд ли большинство компаний выберет Vapor, хотя фреймворк достойный, и его можно использовать.
Вернусь к сравнению языков программирования с набором инструментов. Давайте откладывать шуруповёрт, если нужно распилить дерево, и возьмём пилу, не будем заниматься ерундой. Я считаю, что проще писать на том языке, который больше подходит для нашей системы, а не пытаться натянуть его на всё. Если у вас другое мнение, а такое точно будет, буду рад услышать его в комментариях. Даже внутри нашей команды у нас расходятся точки зрения примерно 50/50.
Плюсы и минусы изучения нескольких языков
Что хорошего мы получаем:
Уменьшение выгорания на основном проекте за счёт изучения чего-то нового.
Дополнительные навыки, которые могут пригодиться в будущем.
Как следствие — изучение новых инфраструктур, архитектур и прочего.
Возможность быстрее и проще решать повседневные задачи и настраивать автоматизации.
Общение с новым комьюнити, рост вширь.
Потенциальный рост в Full-Stack разработчика, или в DevOps, или в техлида, ну и так далее.
А какие минусы могут быть:
Повышение порога входа на проект с большим количеством используемых языков (для скриптов, CI и т.д.).
Потенциальная каша из языков, если каждый будет использовать свой (привет, скрипты на Python с подключением JS и запуском через Ruby).
Синдром самозванца в новой для себя области.
Что ещё можно поизучать разработчику
Итак, вернёмся к обсуждению, какой язык учить. Это сильно зависит от вашего рода деятельности и того, чем вы хотите заниматься. Кому-то достаточно JS + React, его не в чем винить, но и осваивать новые языки и фреймворки всё же полезно.
Если говорить про мою специальность, я бы посоветовал iOS-разработчику изучать, кроме Swift, опционально Objective-C (iOS легаси все-таки) и Ruby (CocoaPods, Fastlane). Это несколько каверзный язык, у нас неоднократно были с ним проблемы (выше есть даже история об одной из таких проблем). Там много неочевидных вещей, особенно для неподготовленного зрителя. Если ты не изучишь их по книжечке, они могут всплыть рано или поздно.
Ещё iOS-разработчику можно изучить Kotlin, если очень хочется, он напрямую связан с Java — популярнейшим языком в мире. На Kotlin сегодня часто пишут бэкенд, поэтому его знание для столь важной части современной разработки точно не будут лишними. Kotlin — основной язык Android, огромной мобильной платформы. Круто понимать, как разрабатывают твои коллеги, особенно в большой компании. Если у тебя есть хотя бы минимальная экспертиза, ты сможешь что-то подсказать.
Разрабатывая какую-то технологию, некоторые совсем не учитывают ограничения альтернативной платформы. Тебе будет нужен оппонент, и да, ты не станешь экспертом в обеих платформах, но у тебя точно будут пререквизиты.
У JetBrains есть фреймворк Kotlin Native, чтобы разрабатывать сразу для двух платформ. Пока он сыроват, его мало кто использует в проде, но в перспективе он сможет в будущем сэкономить время разработки вдвое. Несколько человек будут делать системный код, а остальные вёрстку. Уже сейчас можно смотреть в будущее и изучать новые языки.
Ещё рекомендую изучить Groovy — язык над Java. Многие ребята, которые пишут на Java и Kotlin, с ним знакомы, как и ребята с Android (что логично). Для чего он айосеру? Напомню, о чём говорил выше: одна из самых популярных систем для CI/CD — это Jenkins.
Ну, и чисто моя личная рекомендация — Go. Мне он понравился благодаря ультралёгкому пониманию написанного кода, а также простому вливанию в комьюнити. Язык достаточно простой, чтобы его можно было быстро изучить действующему программисту, зато он предоставляет большие возможности и быструю скорость сборки (что подкупает после Enterprise iOS-проектов). На нём легко писать небольшие скрипты и собирать данные. Я его много для чего использую, не скажу, что он незаменим, но мне Go зашёл.
Как дальше жить после прочтения статьи
Если вы прочитали статью, и вам она показалась полной чушью, значит у вас есть своё альтернативное мнение, это круто!
Если статья вам не только показалась чушью, но и вы полностью не согласны с ней, отлично, жду ваших комментариев, буду рад услышать ваше мнение, это всегда интересно.
Если статья вам понравилась, но вы считаете её неполной, было бы здорово, чтобы вы написали свои мысли, запилим upd.
Если у вас остались вопросы, тоже пишите, отвечу, исходя из своего опыта.
Программист мыслит языками программирования, фреймворками, алгоритмами и т.д., поэтому чем шире его база знаний, тем круче будет полёт его мысли. Учите языки, наш мир развивается очень быстро, особенно ИТ-сфера, классно, когда вы на острие. Языки — непосредственный инструмент для создания продукта.
Возможно, именно вы придумаете универсальный язык, и нам больше не понадобится куча инструментов. А пока подрезюмируем: в программиста сможет влезть сколько угодно языков, вопрос в том, надо ли оно именно ему.
Комментарии (52)
c3gdlk
12.12.2023 15:41Где вариант ответа - зачем учить все языки, если можно выучить их принципы?
Каждый язык это сборная солянка. В Основе стиль - процедурный, ооп, функциональщина и декларативщина или их смесь в каком-то виде. И дальше каждый яызк выбирает подход к решению задач - как организовать типы, управление памятью, параллелилизм, управление исключениями, что делать с NULL и какие возможности предоставить в метапрограммировании. Может забыл чего, но этот список все равно конечный.
kopytovs Автор
12.12.2023 15:41Тоже отличный вариант, но чаще всего принципы учат как раз через языки, которые на них базируются, потому что учить принципы в отрыве от реальности - это как писать в резюме, что ты сеньор после прочтения всей доступной документации по твоей вакансии. Теория - это хорошо, но без практики не имеет много смысла (если ты, конечно, не занимаешься научными исследованиями).
А так, вполне себе, почему нет :) Нет варианта, потому что статья больше про языки, чем про подходы к разработке, но спасибо за мнение ????
c3gdlk
12.12.2023 15:41Не совсем соглашусь про теорию. Я вот книгу по хаскелю прочитал, и даже не попробовал что-то написать. Это в итоге изменило мой руби код и помогло выучить очень бысро эликсир, когда мне попался проект. А так коненчо согласен, что попрактиковаться в языке коненчо намного полезнее. Я хотел добавить, что выбирая язык для практики нужно учитывать каким общим подходам можно будет научиться, не считая изучения самого языка.
kopytovs Автор
12.12.2023 15:41Конечно, согласен, парадигмы и подходы - это важно, спасибо за дополнение)
xfides
12.12.2023 15:41Здравствуйте.. Полююбопытствую. А какую книгу по хаскелю вы читали, и за какое время? Просто сам читаю\ем книгу "хаскель с первых принципов" - и судя по той сорости с которой идем, её прохождение займет год (уже осилили 35%).
Интересен ваш опыт, практики, советы по чтению подоюных книг, где впервые встречаешься с новой парадигмой.
c3gdlk
12.12.2023 15:41Я читал "изучай хаскель во имя добра". На Хабре кто-то посоветовал, так и написал "прочитать, даже если использовать не будешь". Для меня книга была полностью понятна и дружелюбна. Не помню сколько времени потратил, но я просто неспешно читал.
MountainGoat
12.12.2023 15:41Теперь ещё Inform7 посмотрите, так, дзэном проникнуться.
Валидный код на Inform7
Section 2 - Smells A thing has some text called scent. The scent of a thing is usually "nothing". The report smelling rule is not listed in any rulebook. Carry out smelling something: say "From [the noun] you smell [scent of the noun]." Instead of smelling a room: if a scented thing can be touched by the player, say "You smell [the list of scented things which can be touched by the player]."; otherwise say "The place is blissfully odorless." Definition: a thing is scented if the scent of it is not "nothing". Before printing the name of something scented while smelling a room: say "[scent] from the " Section 3 - Sounds A thing has some text called sound. The sound of a thing is usually "silence". The report listening rule is not listed in any rulebook. Carry out listening to something: if in darkness, say "The [sound of the noun] sounds like [a noun]."; otherwise say "From [the noun] you hear [the sound of the noun]." Definition: a thing is audible if the sound of it is not "silence". Echolocating is an activity. Before printing the name of something audible (called target) while echolocating: if the target is not the player, say "[sound] from [if the target is not the player]the [end if]" Rule for printing the name of the player while echolocating: if the player is not audible, say "yourself"; otherwise say "your own [sound of the player]" Rule for printing the name of something (called target) which is not visible while echolocating: say "[roman type]"; if the target is the player: say "yourself"; rule succeeds; let place be the holder of the target; let way be the best route from the location to the place; if way is a direction, say "[way]"; otherwise say "[if the target is in location]immediate vicinity[otherwise]middle distance[end if]".
garfish
12.12.2023 15:41такими образом изучают только Паскаль на информатике, а потом осваивают языки количественно не формируя качественной стороны вопроса, так как границы представлений ограничены Паскалем. Надо изучать фундаментальную сторону вопроса что такое ячейка памяти, переменная, машинные команда, Ассемблер и уже потом нагружать это понимание объектами языковой грамматики - детерминированными конечными автоматами, транслятором языка, терминальным символом, польской записью и т.д.
KiberneticWorm
12.12.2023 15:41Согласен, все основано на базовых знаниях, это как построить новый дом, сначала делается качественный и прочный фундамент, а потом уже ставятся стены
kopytovs Автор
12.12.2023 15:41Мне кажется, все зависит от цели. На сегодняшний день возможности в программировании ушли далеко вперед, по сравнению с концом 90-х и началом 00-х, есть очень простые и умные языки с крутыми фреймворками (тот же Python), есть системные языки с синтаксисом на уровне высокуровневых интерпретируемых языков, есть тот же ChatGPT, в конце концов (не панацея, но отличный помощник). Фронт разработчику, который 20 лет занимается фронт разработкой и его все устраивает, нет большого смысла (кроме внутреннего интереса) изучать подробно структуру языка, машинные команды и тд. Ровно как и нет большого смысла системному разработчику изучать возможности блюра во вьюхе. Это просто дополнительные знания, это не плохо, но никак их не ограничивает и не обязывает.
Да, конечно, очень полезно знать фундамент и базисные основы, особенно в той сфере, где ты работаешь, но, как показывает практика, сегодня, это не обязательные знания. Множество людей делают сложные и крутые штуки, быстро выполняют задачи в срок, при этом, не имея представления о структуре битов в их коде.
Karl_Benz
12.12.2023 15:41Идеальное сочетание C++ & Java & JavaScript = 90% всех задач можно решить.
Kazikus
12.12.2023 15:41Плюсы меняем на rust, жабу на го, js на ts и огонь :-)
D7ILeucoH
12.12.2023 15:41Java & JavaScript можем спокойно заменить на Kotlin, ведь он умеет компилиться и в JVM, и в JS... Да, без быкенда, но и быкенд можно было бы на Котлине, что супер удобно в плане единения инфомоделей.
Придумал свой способ шейринга (одного источника) констант на JS+JS проекте, в плане совместимости языков это прикольно и в целом радует что такое возможно почти из коробки...
Статья интересная, но я как мобильщик влезал в быкенд энтерпрайза лишь тем, что редактировал документации из их репозиториев, и опасался того что они меня на ревью как угрозу воспримут за такие действия...
kopytovs Автор
12.12.2023 15:41Ну, в целом, могу тоже самое сказать и про Swift. С фронт разработкой всё понятно (под iOS и Mac можно из коробки писать, пот Linux и Win уже сложнее, но тоже можно), бэкенд можно с помощью Vapor развернуть, это даже удобно будет, а для веба сгодится WebAssembly (https://webassembly.org). Проблема будет только в комьюнити, таких энтузиастов не много, а значит, почти любые проблемы ты будешь решать в гордом одиночестве(
Ну тут чисто синдром самозванца начинает работать, при Т-шейпе так всегда, от этого никуда не деться) В любом случае, рост вширь - это круто, как по мне, с синдромом самозванца можно и нужно бороться ????
a-tk
12.12.2023 15:41Смотря что считать языком.
Нормальное знание языка - это не только синтаксис, но и стандартная библиотека, и концепции и подходы, и набитые злосчастные 10 000 часов на живых проектах.
За 15-20 лет легко можно набить и 20, и 30 языков, если языком считать хотя бы знание синтаксиса и понимание концепций, но при этом держать в активном использовании на экспертном можно, скажем, до 5 языков, но это уже со скрипом.
Минутка сарказма
Со всеми остальными можно иметь достаточное знакомство, чтобы в холиварах указывать на недостатки этих языков :)
И да, полезно иметь предоставление и разных языках, построенных на разных концепциях: чтобы и десяток императивных было, и пяток декларативных, и парочка функциональных, и с логическими поиграться. Чтобы впитать разные подходы, и иметь свободу мышления при выборе подходов.
a-tk
12.12.2023 15:41Да, кстати
КуМир, Pascal, VBA, Delphi, Assembler x86, C++Builder а затем и нормальный С++, Assembler PIC16x, (HTML/CSS, PHP, SQL, JS), XSLT, Java, Ruby, Prolog, Lua, Assembler IBM PowerPC, C#, Squirrel, XAML, Python, F#.
Наверняка что-то забыл, а значит не сильно важно. И, разумеется, половина забыта полностью, как половина оставшегося давно не используется, но руки вспомнят достаточно быстро. Остальное - более-менее активное хотя бы эпизодически.
Nialpe
12.12.2023 15:41полностью согласен, синтаксис и основные концепции выучить можно быстро, но этим язык не ограничивается. не единожды встречал ситуацию, когда вместо того, чтобы задуматься (хотя бы задуматься! поискать, взвесить за-против и т.п.) о наличии готового решения в стандартных (или общеизвестных, или проектных) библиотеках, еще раз подчеркиваю именно задуматься (а не сразу тащить в проект почем зря), разработчик с гордостью принимает решение творить свой велосипед с покрытием тестами и прочими плясками лучших практик (включая получение новых проблем из-за внедрения данного велосипеда), потому что знания синтаксиса ему (на его взгляд) более чем достаточно для решения проблемы, которая вполне вероятно (опять же почеркиваю допущение) уже решена. в этой ситуации невольно вспоминаю Косого из "Джентельменов удачи", который считал, что переводчиком уже может вполне себе работать.
kopytovs Автор
12.12.2023 15:41Да, конечно, тут я, наверное, не очень корректно написал, под изучением языка я как раз и понимал глубокое изучение, с подходами, фишками и всем остальным. Про экспертное знание согласен, но чаще всего, тебе не нужно быть экспертом в Ruby, чтобы написать себе небольшой кодогенератор или что-то в этом духе, поэтому можно не обязательно изучать все языки в эксперта, особенно, если язык не твой профильный)
a-tk
12.12.2023 15:41Тут можно было бы зацепиться за слово "профильный" и развить длинную дискуссию, но мы друг друга поняли и я не стану это делать.
kopytovs Автор
12.12.2023 15:41В любом случае, всегда полезно изучать различные подходы к разработке, архитектуры, способы шарить данные и тд, никогда заранее не знаешь, когда и где может пригодится :)
Взять тот же Rx, который затащили уже, кажется, во все платформы, но изначально популярность пришла именно с Java же (RxJava), если бы никто из iOS, например, никогда бы это не изучал, то никакого RxSwift и Combine и не было бы ????
ioncorpse
12.12.2023 15:41Плюсы: потенциальный рост в Full-stack.
Минусы: потенциальный рост в Full-stack. ^_^Когда несколько лет назад искал работу - удивился, что Full-stack на рынке дешевле Back.
А в целом да, хорошо иметь опыт в 8-15 языках и 2-3 основных.a-tk
12.12.2023 15:41Забавно: почему Full-stack прилипло именно к вебу?..
Чем не fullstack - разработать PCI-плату, прошивку ПЛИС, драйвер, клиентскую библиотеку доступа? :)
kopytovs Автор
12.12.2023 15:41Мне кажется, просто привычно уже, любого из ИТ (почти) спроси кто такой FullStack, тебе скажут, что это это тот, кто пишет сайт с бэкендом сам. По крайней мере, на моем опыте, именно так)
Правда сегодня под фронтом уже можно не только Веб понимать, все-таки смартфоны всегда под рукой и приложений там куча.
Frevv
12.12.2023 15:41Господи, вот людям не на что жизнь тратить. Много языков =мало свободного времени. Жизнь интереснее работы, и как я на своём опыте узнал, что есть и профессии лучше чем пахать в ИТ
a-tk
12.12.2023 15:41Кто ж спорит, что кому-то проработать всю жизнь официантом вполне подходящий вариант.
taravkovmv
12.12.2023 15:41Соглашусь. Когда больше других занятий нет, можно углубляться в одной предметной области, при этом мимо тебя могут пройти не менее интересные вещи, о которых ты задумаешься в конце жизни, и, вероятно, будешь сожалеть об этом.
Andreu_s
12.12.2023 15:41Swift + Ruby + Groovy + Go = IOS разработчик в Альфе :)
kopytovs Автор
12.12.2023 15:41Никогда не знаешь, что пригодится завтра, будь готов ко всему ????
a-tk
12.12.2023 15:41Когда у тебя десяток языков за плечами, то достаточно просто методички и пары недель, чтобы пойти
сдавать китайскийписать на чём угодно, что похоже на что-то из твоего багажа.kopytovs Автор
12.12.2023 15:41В целом, да, так и получается. И это, ведь, очень удобно, что ты можешь решать разные задачи, используя свой набор инструментов, а не подбирать инструменты дольше, чем решение задачи))
ssmaslov
12.12.2023 15:41Это неправда. Ну писать г.нокод наверное да. Писать что то промышленное наверное нет (возможно я уже старый и медленнее) так то десяток разных языков на которых профессионально писал в багаже есть, собеседование с листа наверное по парочке пройду... Но за две недели на новом писать вряд ли
Ronii
12.12.2023 15:41Посыл и техническая часть статьи понятны и разумны. В статье промелькнуло слово выгорание. Хотел бы дать альтернативную трактовку изучению нескольких языков в контексте выгорания.
То, что изучение нового языка поможет уменьшить выгорание -- спорно. Скорее ускорит выгорание. Я бы переформулировал: "уменьшение выгорания на основном проекте за счёт выгорания на другом проекте".
В борьбе с выгоранием поможет work-like balance, и изучение нового, но не связанного с программированием/it.
Почему вам НЕ надо учить новый язык
Если вы не знаете, зачем вам это надо. Вдруг пригодится
Если делаете это через силу, потому что "это круто" знать несколько языков
Если вы чувствуете, что выгорание уже рядом
Если вы хотите отсрочить решение жизненных проблем, создав видимость занятости
"Буду круче как специалист, работодатель оценит". Это ложь. Было актуально в 2000 году, в компании из 5 человек, где вы и жнец и кузнец. Но вы можете найти такую
Если это не поможет работе/карьере, но отнимет время от вашей "новой рукописи", семьи и тд.
Почему вас стоит ОЗНАКОМИТЬСЯ с новым языком
Если позволит вам оптимизировать свою работу; написать нужный вам скрипт и "меньше работать". Необязательно учить, достаточно чтобы работало. Можно сделать за день и получить результат. А можно писать идеальный проект месяцами, который не поможет вам в моменты, но вы будет тратить энергию в "красивый код"
Это связано с вашим других хобби. Например, робототехника, ии и тд. Но это спорный момент. Не надо писать инструмент годы, если его можно купить за 10$
Это поможет починить принтер
Почему вам стоит основательно УЧИТЬ новый язык
Текущий направление работы умирает, никому не нужно, плохие условия и тд
Текущий язык был плохим выбором, но тогда вы этого не знали
Хотите сменить работу, область деятельности
Вы уверены, что это объективное решение! А не желание сбежать по причине выгорания. Смена контекста работы может помочь, а может на оборот, толкнуть вас в "спираль неудачи", когда вы будете постоянно менять работу, одно хуже другого, и вы рассыпетесь раз специалист
Вы 3Ц-Ботрогс программист
Теперь посмотрим со стороны вашей загрузки и личной жизни
(?) Вы работаете по 12 часов, часто по выходным. Вы не можете сказать "нет", и часто овертаймите за свой счет. И так учите язык Jopling, ведь вам "сложно" отдать это работу в другой отдел, специалисту данного направления. Или такого отдела нет.
(!) Вам не нужно учить новый язык, стоит серьезно заняться work-like balance, подумать о личной жизни, и своих интересах.(?) Вы работаете 8 часов в день, все ок.
(!) Можете поизучать то, что поможет вам делать вашу работу лучше, оптимизировать процессы.Подойдет даже php. У многих сервисов есть api, можете сделать удобный вам интерфейс, например, для bitbucket.(?) Вы 4 часа пинаете груши на работе
(!) Можно смело учить новый язык. Или помочь коллеге улучшить его рабочие процессы.Со стороны вашего возраста и жизненных целей
Вам 18-24 лет. Вы можете учить 10 языков за раз, пробовать все, познавать мир. Ваш позвоночник, руки, ноги и прочее еще в полном порядке
Вам 24-28 лет. Вы уже вложились в свою специальность. Если это не то, что вам надо... стоит обдумать, "кем вы видите себя через 5-10 лет". Этот вопрос не просто так задают на собеседованиях. Важность этого вопроса вы поймете, но позже.
Вам 30+ лет. Вряд ли вам нужны советы, нужно ли учить новый язык и зачем. Вы уже понимаете, это самые ценные ресурсы: время, нервы, здоровье. Вы на себе ощутили, как летит время, ускоряет свой шаг. Вы уже умеете (или учитесь), отделять личную жизнь и работу. И точно знаете, когда нужно учить новый язык и для чего.
Сначала цель, потом язык!
kopytovs Автор
12.12.2023 15:41Спасибо за такой развернутый фидбек!
В целом, согласен, но не очень понял про то, что новый язык - это какая-то сложная работа, к которой надо быть готовым и четко понимать зачем это. Мне, например, просто нравится изучать новые языки, новые подходы, архитектуры, парадигмы и тд. Это просто интересно и не занимает жизненных ресурсов.
Проведу параллель: спорт занимает твои жизненные ресурсы, расходует твою энергию, забирает много времени, но тебе это все равно нравится и ты раз за разом возвращаешься на тренировку. Вот ты занимаешься, например, большим теннисом, наступает зима и ты начинаешь, параллельно, ездить кататься на сноуборде/лыжах. Это занимает у тебя сильно больше времени и ресурсов, но ты же получаешь от этого удовольствие! Большинство профессиональных спортсменов так же занимаются другими видами спорта (если по контракту не запрещено), вот и мы, как профессиональные разработчики, параллельно занимаемся другими языками. Не потому, что это срочно должно принести новый доход, не потому, что мы не знаем чем заняться и ищем себя, не потому, что текущий проект (спорт) разваливается, а просто потому, что нам это нравится.
Мне кажется, что многие ребята, которые сегодня занимаются ИТ, пришли в эту специальность не только за приличными доходами, но и за тем, чтобы заниматься любимым делом. Многие с начальной школы мечтали придти в ИТ и сегодня успешно занимаются этим делом, поэтому изучение новых технологий, скорее, вызывает ощущение челленджа и новых высот, чем очередной сложной задачи, которую не очень хочется делать. Но, это чисто мое личное мнение ????
FussuChalice
12.12.2023 15:41Спасибо за статью. Сам использую Python и Bash скрипты для автоматизации либо написания быстрых скриптов, там скачать библиотеки, пропарсить данные сайта и т.д.
Насчёт языков программирования я согласен, что каждый из них создан для определенных целей.
Мне понравилось, что в статье используются мемы, по ним в некоторых случаях легче понять какой смысл закладывал автор.
deadraidfd
Я за 20 лет собрал 10. Начинал с C++ и Delphi.
Основной стек у меня бекенд.
После перешел на скриптовые Perl и PHP.
Чуть позже Python.
Дальше меня затащило в JVM )). Java, Scala.
Spring Framework до сих пор в кошмарах снится.
После ушел в Ruby отдохнуть у белых людей без переработок с Rails.
Сейчас активные(на которых я в любой момент готов пройти собес) JS(Typescript), Go и Rust. Иногда в Python забредаю на волне хайпа в AI.
Это всего хватает не думать о том что на одном языке нет вакансии.
Просто ищу на другом. Если чуть подзабыл хватает пару недель снова зайти обратно.
Есть еще несколько языков без коммерческого опыта просто для души.
Nim, Crystal и недавно стал ковырять Zig. Но этоу же совсем другая история ))
kopytovs Автор
Очень крутой опыт ????
garfish
Нет смысла учить языки и присущие им парадигмы программирования, есть более фундаментальные понятия на основе которых разрабатываются лингвистическое обеспечение. Понимая принципы организации языков, как формируется лексическая свёртка, как происходит генерация кода, какие существуют лингвистические конструкции, то понимание будет иное. Изучение языка сведется к анализу реализованных в нем дискриптивных лингвистических концепций и поиску способов реализации известных вам алгоритмических единиц.
kopytovs Автор
Согласен) Но мне кажется, что через языки это понять проще, так как у тебя будет конкретный референс и некоторая практика, которая позволит тебе не только понять что-то, но и ощутить в действии.
arheops
Теория, конечно, прекрасно.
Но непонятно как вам это поможет написать код с использованием numpy, к примеру.
90%+ знания языка это его библиотеки. Ну как минимум в современном мире.
kopytovs Автор
Да, согласен, помимо языков нужно изучать фреймворки и библиотеки, без них языки пустоваты, конечно. У меня как раз посыл в том, чтобы не останавливаться на одном, даже, если в моменте это не требуется.
Ну тут сильно зависит от языка и от цели, как мне кажется) Но под изучением языка, я, конечно, имел в виду не голое зазубривание синтаксиса, а, именно, умением им пользоваться, а значит и пользоваться библиотеками ????
garfish
Надо разделять понятия языка и прикладных инструментов. Это вопрос спецификации фреймворка и прикладной задачи на которую он рассчитан. Если он предоставляет, например, инструменты анализа механики сплошной среды, а я не знаю принципов механики, то это проблема незнания прикладной задачи, а не вопрос непонимания языка или возможностей фреймворка. И восстановить обратным инжинирингом фундаментальные положения механики из возможностей фреймворка будет некорректной задачей и освоить таким образом фреймворк это тупиковая идея.
kopytovs Автор
Само собой) Язык - это инструмент для решения задачи, если не знаешь, какую задачу решать и как, примерно, ее можно решить, то язык тебе мало чем поможет. Это как взять в руки навороченный лобзик и пытаться им забить гвоздь, прежде, чем браться за инструмент, нужно обязательно ознакомиться с задачей и с ее способами решения.
В контексте статьи, пишу только о своем опыте, а он, в основном, связан с мобильной разработкой, поэтому даже и не думал про математические языки и решения физических задач, замечание хорошее)