Комментарии 67
Я за 20 лет собрал 10. Начинал с C++ и Delphi.
Основной стек у меня бекенд.
После перешел на скриптовые Perl и PHP.
Чуть позже Python.
Дальше меня затащило в JVM )). Java, Scala.
Spring Framework до сих пор в кошмарах снится.
После ушел в Ruby отдохнуть у белых людей без переработок с Rails.
Сейчас активные(на которых я в любой момент готов пройти собес) JS(Typescript), Go и Rust. Иногда в Python забредаю на волне хайпа в AI.
Это всего хватает не думать о том что на одном языке нет вакансии.
Просто ищу на другом. Если чуть подзабыл хватает пару недель снова зайти обратно.
Есть еще несколько языков без коммерческого опыта просто для души.
Nim, Crystal и недавно стал ковырять Zig. Но этоу же совсем другая история ))
Очень крутой опыт 🔥
Нет смысла учить языки и присущие им парадигмы программирования, есть более фундаментальные понятия на основе которых разрабатываются лингвистическое обеспечение. Понимая принципы организации языков, как формируется лексическая свёртка, как происходит генерация кода, какие существуют лингвистические конструкции, то понимание будет иное. Изучение языка сведется к анализу реализованных в нем дискриптивных лингвистических концепций и поиску способов реализации известных вам алгоритмических единиц.
Согласен) Но мне кажется, что через языки это понять проще, так как у тебя будет конкретный референс и некоторая практика, которая позволит тебе не только понять что-то, но и ощутить в действии.
Теория, конечно, прекрасно.
Но непонятно как вам это поможет написать код с использованием numpy, к примеру.
90%+ знания языка это его библиотеки. Ну как минимум в современном мире.
Да, согласен, помимо языков нужно изучать фреймворки и библиотеки, без них языки пустоваты, конечно. У меня как раз посыл в том, чтобы не останавливаться на одном, даже, если в моменте это не требуется.
90%+ знания языка это его библиотеки. Ну как минимум в современном мире.
Ну тут сильно зависит от языка и от цели, как мне кажется) Но под изучением языка, я, конечно, имел в виду не голое зазубривание синтаксиса, а, именно, умением им пользоваться, а значит и пользоваться библиотеками 🙂
Надо разделять понятия языка и прикладных инструментов. Это вопрос спецификации фреймворка и прикладной задачи на которую он рассчитан. Если он предоставляет, например, инструменты анализа механики сплошной среды, а я не знаю принципов механики, то это проблема незнания прикладной задачи, а не вопрос непонимания языка или возможностей фреймворка. И восстановить обратным инжинирингом фундаментальные положения механики из возможностей фреймворка будет некорректной задачей и освоить таким образом фреймворк это тупиковая идея.
Само собой) Язык - это инструмент для решения задачи, если не знаешь, какую задачу решать и как, примерно, ее можно решить, то язык тебе мало чем поможет. Это как взять в руки навороченный лобзик и пытаться им забить гвоздь, прежде, чем браться за инструмент, нужно обязательно ознакомиться с задачей и с ее способами решения.
В контексте статьи, пишу только о своем опыте, а он, в основном, связан с мобильной разработкой, поэтому даже и не думал про математические языки и решения физических задач, замечание хорошее)
За 30 лет я:
начинал с васиков (QBasic, GWBasic), встроенных к "шкафы".
В универе (прошлый век) прыгали на трубо поскакале (из пасквилей Дельфин тоже ага), и насильничали на голом Си, на плюсах и конечно же на Борланд - нещадно глушили лунатиков (один лунатик у нас препода, любителя сипипи прям на лекции "загасил" - так в лоб ему и сказал куда ему (им обоим) идти с сипипи, при наличии Дельфина.)
Оу. БД. Парадокс! ) и фокс про ) может помнит ещё кто их ))
Был ASM, был даже машинный код (да!, прям напрямую машкодами кодили)!
С нулевых MSSQL + Delphi (самое начало 0х) , потом .Net (VB и шарпы)
По итогу C#.Net в полный рост и под любые задачи (нет задач которые нельзя решить на шарпах), свои ORM под базы. SQL "не знаю", т.к. более 20 лет назад благополучно забыл его, создав одну из первых собственных ORMок. Потом были ещё ORMки разного уровня сложности и функциональности.
/ Между делом бы у меня и опыт на Яве - до сих пор кошмары от неё, Солнце закатилось. Там кстати тоже свою ORM удалось засунуть в проекты. /
Скриптовые языки я не признаю и не перевариваю. Они и медлительные, и ...
В общем лично мой выбор - шарпы (и серверсайд лоджик). И я убеждён что нет смысла учить китайский, латинский, древнегреческий, и язык инопланетян с планеты Нибиру, т.к. в реальности они даром не сдались. Все задачи можно решить имеющимся бэкграундом, уже хорошо известным языком, и на хорошо изученных "технологиях", к которым давно уже есть 2-3 слоя абстракций и не один десяток собственных модулей, давно уже решающих всё то, что сейчас наизобретали для всяких там LINQ, EF, NHibernate и т.п.
ПыС есть у меня и свой WorkFlow (а не жира), полно своих ORMок, есть и свой логгер, кстати 100 лет как многопоточный (и асинхронный) и умеющий следить за памятью и временем исполнения кода.
Мультилингвальность не для меня. Да и "рост" в фулстэка сомнителен. Многие тут позиционируют фулстэков как джунов.
Очень крутой опыт 👍
На мой взгляд, нельзя однозначно утверждать, что пригодится, а что нет, чтобы быть на 100% уверенным. Насчет китайского: его сейчас очень активно многие изучают и на нем создаются работы, да, сейчас это ничтожно мало, но утверждать на будущее сложно. Столетие назад все учили французский и английский был даром никому не нужен (равносильно языку инопланетян с планеты Нибиру), а сейчас все ровно наоборот (утрирую, конечно, но смысл понятен, я думаю).
Про скриптовые языки есть очень много обсуждений, использовать их для системного программирования - это такое себе, полностью согласен, но кто мешает их использовать для небольших скриптов?) Это же, тупо, удобно, ты быстро пишешь, смотришь в интерпретаторе и сохраняешь, развернуть элементарно, запустить так же, хранить просто и всю историю видишь. Можно использовать компилируемые языки и собирать себе бинари, но: 1) бинари в гите не сможешь хранить; 2) после каждого изменения нужно пересобирать; 3) чтобы разобраться - нужно искать исходники. Как по мне, скриптовые языки тут гораздо удобнее.
А что с фуллстеками не так? Понятно, что есть новички, которые могут одновременно на всем писать на довольно слабом уровне, но кто их фуллстеками называет, кроме их самих?) Мне кажется, если человек может писать код и в фронт и в бэк - это крутой специалист, который может закрыть полторы позиции, что особенно актуально для небольших команд, аутсорсов или случаев, когда в команде не хватает специалиста, но нужно быстро что-то развернуть. К тому же, такой эксперт всегда пригодится при планировании задачи и поможет спроектировать наиболее удобное API для всех платформ. Никто не говорит, что расти в фуллстека обязательно и этого не избежать, это просто один из вариантов роста при изучении разных языков, фреймворков, плафторм и подходов. 🙂
Ну, уверенным в наше время вообще быть невозможно.
Скриптовые удобно? Вы думаете я никогда не писал скрипты, отлаживая их алертами??
А что там нужно пересобирать то прям? Дебаг зато есть, да и мелочь сейчас можно корректировать без пересборки.
С фулстеками что не так? Ой сейчас рискую на холивар нарваться.
Кстати мнение о их неопытности не совсем моё, где-то тут на хабре его и увидел.
Лично как по мне, что такое "фуллстек" ? Это JS + ASP.Net Core + T-SQL (угу).
Вот скажите мне (и моим коллегам, которые были со мной хоть на одном моём проекте), зачем мне нужен T-SQL если мои ORM покрывают 99% необходимых запросов? Зачем писать запросы, если их 20 лет уже полностью автоматически генерируют ORMки?
И примерно тоже самое с "мордой". Ну скрипты скриптами. Весело видеть да, как у тебя по форме что-то пляшет. Забавно ага. Когда ты маленький. Но со вренем все эти свистопер... а ой... "бантики и рюшечки", отнимающие уйму времени, так сильно надоедают, ппц просто. Ладно просто надоели бы твои же "детёныши", которых ты сделал собственноручно. Мало того они устаревают, их необходимо перепиливать и выбрасывать. И в эти моменты становится особенно грустно смотреть на "смерть" того что ты создал лично сам.
Другое дело генерация (фронта в т.ч.) . Тут ты прекрасно понимаешь что сам ты фронт не делал, не собирал. Генератор твой априори не может ошибаться , ему даже тестов не надо. Он с гарантией 100% соберёт всё ровно также как секунду назад. Тестов не требуется, повторюсь. Ой не то. Самое смешное что нет эмоциональной привязанности и тяжести - не надо тратить время на сборку фейса, и совершенно наплевать когда какой-то кусок фронта "улетает в корзину". Точнее даже не улетает ведь, он просто не генерируется генератором в определённый момент времени и всё (за не надобностью). Ты об этом можешь даже и не знать. Да и пофиг. Главное что генератор не только жив, но и здравствует. И даже, возможно, развивается.
Фичи. Любые фичи во фронт внедряются массово, через генератор. И только так. Это касается и ОРМа. Там ровно такой же подход - захотел чёт нового на уровне хранения. Да не вопрос - запилить к примеру адаптер под Постгре - дело работы 1 дня (личный опыт). Перегнать в него базу - ещё день (с отладкой). 2 дня и у тебя новое хранилище, со "старыми" данными и старой бизнес-логикой. Ура!
Захотел распределённое хранилище, да не вопрос. Определись только что где будет храниться, и вперёд, ORMку научил этому, она сама разделит всё по распределённым хранилищам, сама и соберёт обратно, если нужно. Может даже на гетерогенных базах данные хранить, если нужно.
Поо итогу вся работа сводится только на том чтобы : 1) отладить генераторы (если их перенастраивали), 2) сосредоточится на бизнес-логике. Ни фронт, ни базы после отладки генераторов больше не беспокоят (их даже тестировать нет смысла!). Свободно себе твори - реализуй требования бизнеса (бизнес-логику), а если нужны рюшечки - засунь их сразу в генератор, и они появятся на всём текущем проекте сразу, да даже на всех проектах текущих. Да и на всех последующих (SOLID и DRY). Главное не забывай строго отделять морду, логику, ядро и хранилище друг от друга через необходимые уровни абстракций.
Ну и по итогу. Когда пытаешься "вернуться на землю", т.е снова начать писать фронты или запросы руками, то это всё сильно начинает ломать. Ну нет желания писать их ручками, когда генераторы давно это умели и умеют делать за тебя. И главное делают.
Тут хоть сколько может быть "детской" радости от "мгновенной" работы мелкого скрипта без компиляции, но эта детская радость никогда не заменит опыта, и тех сотен часов мучений отладки, притом без дебага, алертами блин.
Но вернёмся к JS+ASP + Core + T-SQL. У меня полно коллег, которые в т.ч. сейчас и микросервисы фулстэчат. Думаете оно им нравится? Ну платят за это да и это работа. Но к сожалению очень нелюбимая. Творчества там ноль!
Итоги работы тех "коллективов" какие? Пока было интересно созидать - что-то лепили (тяп ляп чаще всего). Даже микросервисы налепили и много. После первой версии даже вторую налепили где микросервисов стало ещё больше. И всё руками! А архитектура какая? А нет её от слова совсем.
Все микросервисы сами лезут в базу (T-SQL) сами пихают данные на фронт (JS). И отладить их практически невозможно, ибо их сотни, если не тысячи. Что где сломалось сам чёрт не разберёт.
И как себя чувствуют в этом всём программисты, со стажем по 20+ лет? Вы думаете им приятно работать в проектах, которые каждый день всё хуже и хуже поддерживаются, притом даже ими самими, теми кто их "создавал"? Они фактически сами видят гибель собственных "детей" (проектов), которые они по-сути вообще вынуждены самостоятельно "убивать", которые умирают под собственным весом. Да и в проектах этих они "одни", т.к. "команда" давно сбежала, ещё на этапе "а нам уже не интересно, в другом месте за эту же фигню могут заплатить чуть больше". И бегают туда-сюда эти "бракоделы".
Мои же коллеги, с которым разрабатывали совместно несколько ядер, впадают в этакую творческую депрессию (и не только они). Во-первых они решали уже сотни тех же задач, которые "решают" сейчас заново. Притом их опыт бесполезен, т.к. им приходится на новом проекте делать ровно тоже самое, но руками и не один раз. Хотя раньше ядро решало эти же проблемы за нас всех, ну а мы вынуждены были (это чуть сложнее ага) учить именно ядро массово исполнять те или иные фичи. И оно исполняло. И исполняет в принципе. Но им приходится писать тоже самое именно руками. Ядра то у них нет. Архитектура такая.
И имея подобный опыт, снова повторяюсь, когда ядро за тебя делало 90% того что ты сейчас вынужден делать руками, и ты сам видишь как это разваливается и умирает, как молодые просто сбегают от проблем на другие проекты (иногда выучив новый язык или освоив новую версию старого), становится морально очень тяжело (даже похоже на некую "измену"). А с учётом роста кода, роста кол-ва (неотлаживаемых) сервисов, ростом проекта вширь... всё это становится всё сложнее и сложнее. Тяжелее и тяжелее. В том числе морально. Каждая новая итерация развития проекта всё больше и дольше и сложнее. Ядра то нет. По итогу это всё тот же "комок" в результате. Т.е. результат всё тот же м.г. "неидеальный", и даже близко не похожий на идеал. А время потрачено. И по-сути впустую. Особенно когда знаешь (имеешь опыт) реализации "идеала", ну точнее близкого к идеалу, и работающего, и расширяемого практически только в одну сторону (слой БЛ).
Кто-то конечно привык к этому и смирился, тянет эту тяжёлую ношу (без творчества), но многие просто ломаются и бросают это (не сбегают уж как школьники, но всё равно не выдерживают - "выгорают"). А потому даже смена проекта, без смена к подходу программированию, снова приводит к тем же плачевным результатам и тому же предсказуемому выгоранию. И уже точно не возникает никаких "вау" эффектов, когда ты в 10й а то и 100й раз решаешь одну и ту же проблему, которую решил уже лет 100 назад. Где тут SOLID ? Где тут DRY ?
Ну и резюмируя... Одно дело когда вы понимаете паттерны проектирования, SOLID, KISS, DRY , MVC и строите один проект круче другого. Растёте профессионально. Каждое новое ядро у вас лучше, каждое новое ORM у вас умеет вдвое больше предыдущей. Когда вы решаете всё более сложные задачи (сами ага - головой, а не как многие сейчас через поиск готовых решений). Это приятно, это то самое творчество, решение сложных задач.
И совсем другое когда с проекта на проект вы всё также вручную кодите кодите кодите примерно одно и то же почти одинаковыми инструментами "от завода". А потом ещё и переписываете всё тоже самое на новые те же самые заводские инструменты но новой версии. Переписываете переписываете. А рост тут где? А сложные амбициозные задачи?
Вспомнились чёт тут "шуточки" из саги "Если бы программисты строили дома". Ну а многие снова сбегут с проекта пока он не развалился. Вот такая вот мораль.
Ну и всё-таки. Тут либо вы знаете сотни языков (полиглот прям) но не глубоко (это гарантировано) и сложные задачи не решали и не решаете, либо знаете один но на столько глубоко, что вам даже его обновления уже давно не нужны, ибо вы давно ещё до "завода" смогли решить/обойти все проблемы стандартными средствами. И снова, вы либо каждый раз делаете одно и тоже но разными языками или инструментами, либо владеете в совершенстве одним "языком" так, что можете решить любую проблему, практически ничего не кодируя, т.к. давно уже (SOLID, DRY, KISS) имеете чуть ли ни сразу готовое решение под "всё". А потому вам интересны только более сложные задачи чем раньше. Мозг требует более новых и сложных задач.
И самое интересное в том, что вам по плечу практически любая задача любой глубины и сложности, ибо 90% этих задач вы уже решали, и под них есть готовый или почти готовый код, который можно использовать повторно, а не писать заново всё тоже самое, что давно уже по-сути написано (вами).
Вот как-то так. Не знаю смог ли донести суть. Но букв чёт очень много.
Заголовок провокационный:)
Где вариант ответа - зачем учить все языки, если можно выучить их принципы?
Каждый язык это сборная солянка. В Основе стиль - процедурный, ооп, функциональщина и декларативщина или их смесь в каком-то виде. И дальше каждый яызк выбирает подход к решению задач - как организовать типы, управление памятью, параллелилизм, управление исключениями, что делать с NULL и какие возможности предоставить в метапрограммировании. Может забыл чего, но этот список все равно конечный.
Тоже отличный вариант, но чаще всего принципы учат как раз через языки, которые на них базируются, потому что учить принципы в отрыве от реальности - это как писать в резюме, что ты сеньор после прочтения всей доступной документации по твоей вакансии. Теория - это хорошо, но без практики не имеет много смысла (если ты, конечно, не занимаешься научными исследованиями).
А так, вполне себе, почему нет :) Нет варианта, потому что статья больше про языки, чем про подходы к разработке, но спасибо за мнение 👍
Не совсем соглашусь про теорию. Я вот книгу по хаскелю прочитал, и даже не попробовал что-то написать. Это в итоге изменило мой руби код и помогло выучить очень бысро эликсир, когда мне попался проект. А так коненчо согласен, что попрактиковаться в языке коненчо намного полезнее. Я хотел добавить, что выбирая язык для практики нужно учитывать каким общим подходам можно будет научиться, не считая изучения самого языка.
Конечно, согласен, парадигмы и подходы - это важно, спасибо за дополнение)
Здравствуйте.. Полююбопытствую. А какую книгу по хаскелю вы читали, и за какое время? Просто сам читаю\ем книгу "хаскель с первых принципов" - и судя по той сорости с которой идем, её прохождение займет год (уже осилили 35%).
Интересен ваш опыт, практики, советы по чтению подоюных книг, где впервые встречаешься с новой парадигмой.
Теперь ещё 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]".
такими образом изучают только Паскаль на информатике, а потом осваивают языки количественно не формируя качественной стороны вопроса, так как границы представлений ограничены Паскалем. Надо изучать фундаментальную сторону вопроса что такое ячейка памяти, переменная, машинные команда, Ассемблер и уже потом нагружать это понимание объектами языковой грамматики - детерминированными конечными автоматами, транслятором языка, терминальным символом, польской записью и т.д.
Согласен, все основано на базовых знаниях, это как построить новый дом, сначала делается качественный и прочный фундамент, а потом уже ставятся стены
Мне кажется, все зависит от цели. На сегодняшний день возможности в программировании ушли далеко вперед, по сравнению с концом 90-х и началом 00-х, есть очень простые и умные языки с крутыми фреймворками (тот же Python), есть системные языки с синтаксисом на уровне высокуровневых интерпретируемых языков, есть тот же ChatGPT, в конце концов (не панацея, но отличный помощник). Фронт разработчику, который 20 лет занимается фронт разработкой и его все устраивает, нет большого смысла (кроме внутреннего интереса) изучать подробно структуру языка, машинные команды и тд. Ровно как и нет большого смысла системному разработчику изучать возможности блюра во вьюхе. Это просто дополнительные знания, это не плохо, но никак их не ограничивает и не обязывает.
Да, конечно, очень полезно знать фундамент и базисные основы, особенно в той сфере, где ты работаешь, но, как показывает практика, сегодня, это не обязательные знания. Множество людей делают сложные и крутые штуки, быстро выполняют задачи в срок, при этом, не имея представления о структуре битов в их коде.
Орнул с мема на превью)
Идеальное сочетание C++ & Java & JavaScript = 90% всех задач можно решить.
Плюсы меняем на rust, жабу на го, js на ts и огонь :-)
Java & JavaScript можем спокойно заменить на Kotlin, ведь он умеет компилиться и в JVM, и в JS... Да, без быкенда, но и быкенд можно было бы на Котлине, что супер удобно в плане единения инфомоделей.
Придумал свой способ шейринга (одного источника) констант на JS+JS проекте, в плане совместимости языков это прикольно и в целом радует что такое возможно почти из коробки...
Статья интересная, но я как мобильщик влезал в быкенд энтерпрайза лишь тем, что редактировал документации из их репозиториев, и опасался того что они меня на ревью как угрозу воспримут за такие действия...
Ну, в целом, могу тоже самое сказать и про Swift. С фронт разработкой всё понятно (под iOS и Mac можно из коробки писать, пот Linux и Win уже сложнее, но тоже можно), бэкенд можно с помощью Vapor развернуть, это даже удобно будет, а для веба сгодится WebAssembly (https://webassembly.org). Проблема будет только в комьюнити, таких энтузиастов не много, а значит, почти любые проблемы ты будешь решать в гордом одиночестве(
Ну тут чисто синдром самозванца начинает работать, при Т-шейпе так всегда, от этого никуда не деться) В любом случае, рост вширь - это круто, как по мне, с синдромом самозванца можно и нужно бороться 🙂
ох, зачем же вы начали этот холивар
Смотря что считать языком.
Нормальное знание языка - это не только синтаксис, но и стандартная библиотека, и концепции и подходы, и набитые злосчастные 10 000 часов на живых проектах.
За 15-20 лет легко можно набить и 20, и 30 языков, если языком считать хотя бы знание синтаксиса и понимание концепций, но при этом держать в активном использовании на экспертном можно, скажем, до 5 языков, но это уже со скрипом.
Минутка сарказма
Со всеми остальными можно иметь достаточное знакомство, чтобы в холиварах указывать на недостатки этих языков :)
И да, полезно иметь предоставление и разных языках, построенных на разных концепциях: чтобы и десяток императивных было, и пяток декларативных, и парочка функциональных, и с логическими поиграться. Чтобы впитать разные подходы, и иметь свободу мышления при выборе подходов.
Да, кстати
КуМир, 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#.
Наверняка что-то забыл, а значит не сильно важно. И, разумеется, половина забыта полностью, как половина оставшегося давно не используется, но руки вспомнят достаточно быстро. Остальное - более-менее активное хотя бы эпизодически.
полностью согласен, синтаксис и основные концепции выучить можно быстро, но этим язык не ограничивается. не единожды встречал ситуацию, когда вместо того, чтобы задуматься (хотя бы задуматься! поискать, взвесить за-против и т.п.) о наличии готового решения в стандартных (или общеизвестных, или проектных) библиотеках, еще раз подчеркиваю именно задуматься (а не сразу тащить в проект почем зря), разработчик с гордостью принимает решение творить свой велосипед с покрытием тестами и прочими плясками лучших практик (включая получение новых проблем из-за внедрения данного велосипеда), потому что знания синтаксиса ему (на его взгляд) более чем достаточно для решения проблемы, которая вполне вероятно (опять же почеркиваю допущение) уже решена. в этой ситуации невольно вспоминаю Косого из "Джентельменов удачи", который считал, что переводчиком уже может вполне себе работать.
Да, конечно, тут я, наверное, не очень корректно написал, под изучением языка я как раз и понимал глубокое изучение, с подходами, фишками и всем остальным. Про экспертное знание согласен, но чаще всего, тебе не нужно быть экспертом в Ruby, чтобы написать себе небольшой кодогенератор или что-то в этом духе, поэтому можно не обязательно изучать все языки в эксперта, особенно, если язык не твой профильный)
В любом случае, всегда полезно изучать различные подходы к разработке, архитектуры, способы шарить данные и тд, никогда заранее не знаешь, когда и где может пригодится :)
Взять тот же Rx, который затащили уже, кажется, во все платформы, но изначально популярность пришла именно с Java же (RxJava), если бы никто из iOS, например, никогда бы это не изучал, то никакого RxSwift и Combine и не было бы 😁
Плюсы: потенциальный рост в Full-stack.
Минусы: потенциальный рост в Full-stack. ^_^
Когда несколько лет назад искал работу - удивился, что Full-stack на рынке дешевле Back.
А в целом да, хорошо иметь опыт в 8-15 языках и 2-3 основных.
Забавно: почему Full-stack прилипло именно к вебу?..
Чем не fullstack - разработать PCI-плату, прошивку ПЛИС, драйвер, клиентскую библиотеку доступа? :)
Мне кажется, просто привычно уже, любого из ИТ (почти) спроси кто такой FullStack, тебе скажут, что это это тот, кто пишет сайт с бэкендом сам. По крайней мере, на моем опыте, именно так)
Правда сегодня под фронтом уже можно не только Веб понимать, все-таки смартфоны всегда под рукой и приложений там куча.
Господи, вот людям не на что жизнь тратить. Много языков =мало свободного времени. Жизнь интереснее работы, и как я на своём опыте узнал, что есть и профессии лучше чем пахать в ИТ
Кто ж спорит, что кому-то проработать всю жизнь официантом вполне подходящий вариант.
Круто, что вы в познании очень преисполнились и не стали пахать в ИТ! А мне вот ИТ, пока, нравится, вот и пишу на эту тематику :)
Визуализация
Соглашусь. Когда больше других занятий нет, можно углубляться в одной предметной области, при этом мимо тебя могут пройти не менее интересные вещи, о которых ты задумаешься в конце жизни, и, вероятно, будешь сожалеть об этом.
Swift + Ruby + Groovy + Go = IOS разработчик в Альфе :)
Никогда не знаешь, что пригодится завтра, будь готов ко всему 😁
Когда у тебя десяток языков за плечами, то достаточно просто методички и пары недель, чтобы пойти сдавать китайский писать на чём угодно, что похоже на что-то из твоего багажа.
В целом, да, так и получается. И это, ведь, очень удобно, что ты можешь решать разные задачи, используя свой набор инструментов, а не подбирать инструменты дольше, чем решение задачи))
Это неправда. Ну писать г.нокод наверное да. Писать что то промышленное наверное нет (возможно я уже старый и медленнее) так то десяток разных языков на которых профессионально писал в багаже есть, собеседование с листа наверное по парочке пройду... Но за две недели на новом писать вряд ли
Посыл и техническая часть статьи понятны и разумны. В статье промелькнуло слово выгорание. Хотел бы дать альтернативную трактовку изучению нескольких языков в контексте выгорания.
То, что изучение нового языка поможет уменьшить выгорание -- спорно. Скорее ускорит выгорание. Я бы переформулировал: "уменьшение выгорания на основном проекте за счёт выгорания на другом проекте".
В борьбе с выгоранием поможет 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+ лет. Вряд ли вам нужны советы, нужно ли учить новый язык и зачем. Вы уже понимаете, это самые ценные ресурсы: время, нервы, здоровье. Вы на себе ощутили, как летит время, ускоряет свой шаг. Вы уже умеете (или учитесь), отделять личную жизнь и работу. И точно знаете, когда нужно учить новый язык и для чего.
Сначала цель, потом язык!
Спасибо за такой развернутый фидбек!
В целом, согласен, но не очень понял про то, что новый язык - это какая-то сложная работа, к которой надо быть готовым и четко понимать зачем это. Мне, например, просто нравится изучать новые языки, новые подходы, архитектуры, парадигмы и тд. Это просто интересно и не занимает жизненных ресурсов.
Проведу параллель: спорт занимает твои жизненные ресурсы, расходует твою энергию, забирает много времени, но тебе это все равно нравится и ты раз за разом возвращаешься на тренировку. Вот ты занимаешься, например, большим теннисом, наступает зима и ты начинаешь, параллельно, ездить кататься на сноуборде/лыжах. Это занимает у тебя сильно больше времени и ресурсов, но ты же получаешь от этого удовольствие! Большинство профессиональных спортсменов так же занимаются другими видами спорта (если по контракту не запрещено), вот и мы, как профессиональные разработчики, параллельно занимаемся другими языками. Не потому, что это срочно должно принести новый доход, не потому, что мы не знаем чем заняться и ищем себя, не потому, что текущий проект (спорт) разваливается, а просто потому, что нам это нравится.
Мне кажется, что многие ребята, которые сегодня занимаются ИТ, пришли в эту специальность не только за приличными доходами, но и за тем, чтобы заниматься любимым делом. Многие с начальной школы мечтали придти в ИТ и сегодня успешно занимаются этим делом, поэтому изучение новых технологий, скорее, вызывает ощущение челленджа и новых высот, чем очередной сложной задачи, которую не очень хочется делать. Но, это чисто мое личное мнение 🙃
Вот это действительно стоящий комментарий! С удовольствием прочитал)
Спасибо за статью. Сам использую Python и Bash скрипты для автоматизации либо написания быстрых скриптов, там скачать библиотеки, пропарсить данные сайта и т.д.
Насчёт языков программирования я согласен, что каждый из них создан для определенных целей.
Мне понравилось, что в статье используются мемы, по ним в некоторых случаях легче понять какой смысл закладывал автор.
На мой взгляд, разработчику iOS было бы полезнее изучать Dart вместо Kotlin.
А почему именно Dart? Только из-за Flutter? Не хочется начинать холивар, но чем Flutter лучше Kotlin Native?)
Что-то у меня на языке последнее время вертится аналогия между программистом на языке N и сантехником гаечным ключом. Тогда программист на языке M будет аналогичен сантехнику вантузом. И так далее.
Любой специалист должен уметь пользоваться набором инструментов, пускай и специализироваться на ограниченном подмножестве.
Как по мне то знать несколько языков это очень полезно, расширяет возможности по проектированию по видимости парадигмы и т.п... но это я сужу по себе потому что я улетаю в лидство менеджмент и там широта познаний только в плюс (прям сейчас я единственный в команде кто может писать на С# например доставшийся как легаси сервис)
А вот с теми кто утверждает что языки учить не обязательно важно понимать как, тут не совсем так... я то вот питон "выучил" за три недели опираясь на имеющиеся знания VB/C#/PHP/Java ... и еще года два продолжал писать питонячие проекты в java-стиле...и только сейчас познал дзен и вкатился полностью.. а это не совсем хорошо...писать надо так как принято в этом языке, а не то как ты привык в другом
==
ну и я не люблю Go, от упоминаний его ультралегкости и вменяемости у меня очень сильно начинает болеть голова, на одном из проектов, ковыряние в одном сервисе где ультрапростой код Go не работал завел меня в дебри ядра линукса и только так я понял почему... но яж типа сеньор яж должен разобраться, а что будет делать миддл клюнувший на ультрапростой язык и забивший на правила работы с многопоточностью и т.п.?... нет не люблю я го
Ну, в целом, и да и нет) С одной стороны, конечно, лучше придерживаться устоявшейся архитектуры при смене языка/платформы/фреймворка/итд, а с другой стороны, часто бывает так, что комьюнити заперто внутри своей платформы и просто привыкает к ряду проблем, с которыми приходится мириться (типо, ну такой язык, что поделаешь), а человек со стороны, как раз, может привнести что-то новое, фундоментально иное, что поможет справиться с застоявшимися проблемами и решить их. Мне кажется, главное баланс в таких вещах, но почему бы и не привнести что-то новое))
На моем опыте все делятся на тех, кому нравится Go и тех, кто его ненавидит 😁 Могу понять и тех и других, но я из первых, хотя изначально был из вторых. После Swift меня очень бесило отсутствие кучи удобных штук, типо функций высшего порядка, протоколов (интерфейсов) со всеми вытекающими, да и банальных перечислений (enum). Но, со временем, вжился и стал воспринимать это как плюс, а не как минус, так как отсутствие огромного количества "умных" конструкций очень упрощает читаемость кода, особенно, когда это не твой основной язык. Но да, язык Go с приколами, тут не спорю)
так как отсутствие огромного количества "умных" конструкций очень упрощает читаемость кода
мне вот такой пример нравится по читаемости
берем два объекта, с одинаковым методом, например Bomb с методом Exec и LightSwither тоже с методом Exec
но т.к. напрямую указывать типы нинадо и засоряет код, мы тупо верим передаваемому объекту, путаем Bomb и LightSwither и оно взрывается в рантайме
И еще удачи вспомнить где у вас имплементирован этот интерфейс если в проекте 100500 методов с такой имплементацией
тут сразу начинается разговор что "код надо писать обдуманно", "нужны юниттесты".... ооой ну прямо, таких проектов по пальцам одной руки пересчитать, но народ приучиваем к плохому сразу
я очень долго после явы привыкал что питон в рантайме постоянно взрывается...вроде привык, а в го так еще и как приемущество это пытаются показать...не понимаю
Никто не вспомнил про Haskell
Статья классная, я сам придерживаюсь принципа, что нет универсального языка и каждый предназначен для своих задач. Лично мой стек это C++, Python, C#. Каждый стараюсь изучать, продвигаться в них и использовать. Но лично я столкнулся с одной непреодолимой для меня проблемой. Это требование опыта продуктовой разработки для каждого. И вот тут тупик. Я бекенд разработчик и в компании используется исключительно python. И получается у меня идет опыт только по питону, хоть я и самостоятельно изучаю 2 остальных языка и пишу на них пет проекты, для устройства на вакансии бека но с другим языком этого не достаточно(HR не одобряют =) ).И получается либо необходимо раз в 1-2 менять работу возвращаясь на позицию назад, либо писать все равно на одном , а остальные просто как плюсик в карму.
(Я не являюсь прожжённым программистом, и не имею 20 лет опыта за плечами разработки, незнаю, возможно у людей с опытом 15+ уже не смотрят язык на котором писал, а только сферу в которой работали, но пока что я столкнулся с такой проблемой на своем этапе, а и как ее решить пока не понимаю)
О, Вы подняли целый пласт проблем современной айтишки.
Ей в массе своей не нужны люди, умеющие думать головой, а нужны люди, которые умеют умело размахивать нужным конкретно им инструментом с опытом размахивания по нужной траектории на предыдущей работе.
Так сказать, сантехник вантузом может работать только сантехником вантузом, на вакансию сантехника гаечным ключом он не пройдёт.
Как много языков может влезть в одного программиста?