Не хочу тебя расстраивать, но, скорее всего, язык программирования, за разработку на котором тебе платят - барахло.
Но ты ведь так не считаешь, правда?
У тебя классная команда единомышленников.
Про твой язык есть отдельная именная конференция от Онтико, дяди Баруха или веселых ребят из твиттера.
Про твой язык есть подкаст, несколько каналов в телеграмме и несколько тысяч вакансий в hh.ru в обеих столицах.
Твой язык есть в пятерке TIOBE, Stackoverflow insights и Github.
Ладно, в десятке.
Ладно, в двадцатке.
Ты с ходу назовешь пяток сильных мест своего языка - хорошая стандартная библиотека, низкий уровень вхождения, быстрая компиляция, большой набор пакетов для любого случая, мощная IDE, признание в интерпрайзе, его придумал японец или он почти такой же быстрый как Си... Ну или тебе просто хорошо платят.
А теперь покажи свой язык человеку, который зарабатывает деньги, программируя на другом языке. Или сам попробуй сменить стек.
Получится как-то так:
Что за фигня?
Не переживай, это всего лишь стокгольмский синдром.
Ты просто застрял inside the box.
Ты привык к уродскому синтаксису, к тому что в компе должно быть 64 гига оперативы для твоей любимой IDE, к скроллу двух экранов при любой ошибке или к тому, что табы это часть языка. И тебе не комфортно, когда как-то бывает как-то иначе.
Знаете что происходит, когда человек, который писал в институте на Си пытается в Javascript? Он помнит, что не стоит выделять много памяти и его учили переиспользовать переменные. То, что в Javascript нет строгой типизации дает возможность сделать переменную сначала строкой, потом числом, потом объектом. Перефразируя классика: "трех переменных должно хватить каждому".
А из Java в Javascript? Код мгновенно обрастает фабриками, билдерами и плагинами. И еще null. Всегда надо проверять на null.
Из Elixir в любой язык тащится %lang%Rx, акторы и обсерверы. Сколько людей в мире умеет покрывать тестами реактивный код?
Человек, который переключается на Go из Javascript откладывает кирпичи из-за отсутствия исключений.
Ну да, это нормально. Языки создавались разными людьми в разное время и для разных целей.
Для разных целей, но потом что-то пошло не так.
Python делали для обучения программированию. Какого черта вы пишете на нем свои нейросети, когда есть прекрасный R? Кому пришло в голову писать на нем веб?
Java задумывался для программирования бытовых электронных устройств. Зачем писать на нем базы данных и социальные сети? Кто догадался засунуть виртуальную машину в мобильный телефон?
Лулзы: FizzBuzz Enterprise Edition
PHP это Personal Home Page Tools. Инструменты для персональной домашней страницы. Откуда там взялись классы? Почему половина интернета работает на wordpress?
Perl - Practical Extraction and Report Language. Про него совсем бы никто не вспоминал под конец первой четверти 21ого века, если бы крупнейший сайт по аренде отелей не был бы написан на нем.
Лулзы: 93% of Paint Splatters are Valid Perl Programs
Ты душный бумер. Что плохого в том, что языки развиваются?
Ничего плохого. Это отлично.
Проблема в отсутствии генерального плана.
Давайте признаемся хотя бы сами себе, что нам всем наплевать на производительность. Если бы мы хотели, чтобы наши программы работали быстро и ели мало памяти, мы бы писали на Си и ASM. Или Rust, если мы родились после 1991.
Но мы этого не делаем. Мы продали душу дьяволу, имя которому Automatic Memory Management. Мы не хотим думать о тиках, тредах, мьютексах, алокации памяти и указателях. Это сложно, скучно, это для красноглазиков. Мы поменяли это все на разные вкусы синтаксического сахара.
И разработчики языков с нами согласились:
Черт с вами, мы сами все запилим, только не выгорайте
В итоге мы имеем 3 языка, компилируемые в байткод для JVM, два разных райнтайма у Python, обещание сделать исключения с дженериками в Go, а треды по роадмапу Rust читаются как детектив.
Что разработчику нужно от языка? Давайте отбросим скорость работы программы, количество сжираемой памяти, сложность деплоя, скорость компиляции. Мне бы хотелось от языка пары вещей:
- выразительность
Wikipedia говорит, что выразительность - качество языка, показывающее, насколько разнообразны идеи, которые можно реализовать на этом языке, и насколько легко они читаются.
Второе свойство мне кажется даже более важным, чем первое. Сейчас на любом языке можно реализовать любую идею, если отбросить узкие специализации. А вот от количества строк кода напрямую зависит количество ошибок в этом коде и количество усилий, требуемое разработчику на удержание контекста у себя в голове.
Были попытки составить рейтинги по выразительности, но метрики, выбранные для этой цели, явно не выдерживают никакой критики.
- выявление максимального количества рантайм ошибок до запуска программы
Здорово бы было писать программы, которые не падают. Такие программы придется меньше дебажить, меньше тестировать и меньше времени тратить на code-review. Вперед здесь вырываются функциональные языки в компании с Rust. Для остальных языков придумали статические анализаторы. Вот тут можно подобрать себе по вкусу.
Если подытожить - нам бы хотелось больше творчества и меньше думать о всякой скучной ерунде. Это законное желание, но тут мы приходим к следующей проблеме: мы творцы, решать проблемы - не наш профиль.
Все что выходит за пределы возможностей известных нам архитектур, структур данных и возможностей языка, мы колхозим.
Когда у тебя в руках есть только молоток, тогда все вокруг превращается в гвозди
Нам некогда разбираться, мы делаем как привыкли.
Мы боимся признать, что решать проблему привычным подходом на привычном языке программирования не стоит. Мы же не можем признаться в своей слабости! Да и кто тогда нам вообще заплатит?!
И как тут не вспомнить дедушку Карла Маркса, который полтора столетия назад отметил, что
Бытие определяет сознание
Мы распространяем свои привычные подходы на все вокруг. Во-первых, начинает казаться, что так делают все, а во-вторых, что так делать можно.
- Зачем нужны мудреные структуры данных? Разложим все по файлам на диске!
- Типы? Типы для слабаков! VM красноглазики писали, она разберется, где какой тип!
- Зачем нам sql? Его придумали пол века назад, давайте засунем все в ORM!
- 6 нормальных форм реляционной модели данных? Пфф, у меня по-вашему DIT degree? Берем MongoDb!
Учитывая то, что большая часть нашей работы заключается в трансформации JSON, фильтрации массивов и покраска кнопок, мы, как правило, не можем нанести большой ущерб качеству кода и скорости приложения в этих местах. Но на стыках наших костылей с внешним миром все становится по-настоящему плохо.
В подкрепление своих слов приведу цитаты более уважаемых людей:
Data dominates. If you’ve chosen the right data structures and organized thing well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
— Rob Pike.
I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
— Linus Torvalds
Может показаться, что речь про другое. Но перечитайте пару раз, мы говорим об одном и том же!
Плохо то, что натягивание совы на глобус вошло в привычку. Этот подход поощряется коллегами, разработчиками инструментов и всей индустрией.
В итоге мы имеем ситуацию, где считается достижением не хранить данные в Postgresql и значения агрегатов складывать в ElasticSearch, а городить страшную систему на триггерах и рекомендательных блокировках. Если это не кажется очевидным - оба подхода ужасны.
Или, к примеру, иметь базу данных на файлах.
Можно ли ожидать такого от разработчиков, например, на Go? Конечно можно, если они джуны. Но мы говорим о крупной компании, которая не то что продает это за деньги, но и учит других делать так же.
Откуда у меня такая уверенность? В Go не используют ORM, не говоря уж о том, чтоб сделать его главным достоинством языка. Да и написание условных операторов задом на перед там не считается best practice :)
Почему же мой язык барахло?
Потому что он позволяет тебе писать плохой код. Кожаные мешки ненадежны, не стоит им позволять слишком многого :)
А что насчет JavaScript? Ты не шеймил только его!
Да все то же самое! Там нет типов, там мракобесный reduce и есть undefined. В VM нет хвостовой рекурсии, и можно свихнуться, если захочется организовать очередь асинхронных вызовов.
Но дело в том, что сейчас только самоубийцы пишут на чистом JavaScript.
JavaScript сейчас target для транспиляции из других языков.
При этом v8, кажется, самая динамично развивающаяся VM из мейнстримовых. Новые возможности в язык добавляются очень быстро, производительность увеличивается. Дошло до того, что в Postgresql процедуры написанные на JavaScript выполняются быстрее процедур, написанных на других языках. Пруфов не будет, это мнение от разработчиков Postgresql, озвученное на одной из конференций.
Есть ли смысл обсуждать JavaScript? Мне кажется, что нет.
Есть смысл обсудить плюсы и минусы самых популярных языков из которых обычно транспилируется код - TypeScript и Flow, но это выходит за пределы данной статьи. Оставлю пару ссылок - TypeScript’s darkest secret и «Строгий» JavaScript: типы против реальности.
Да, есть компании, которые делают продукты на чистом JavaScript. Счастья им, здоровья и держаться...
И что мне теперь делать-то?
Всегда сомневайся
Скорее всего, сейчас ты пишешь говнокод, который в лучшем случае уберут при рефакторинге. В худшем - из-за твоей поделки будет выделено столько лишнего CO2, сколько не сгенерируют все самолеты над атлантикой, тысячи людей потеряют деньги, а владелец твоей компании поменяет машину на полгода позже запланированного.
Подумай - не фигню ли ты делаешь. И выкинь уже ORM из своего кода :)
Знай свою тему
Начни с инструментов типизации в твоем основном языке, если их там еще нет. Если есть - попробуй статические анализаторы. Попробуй новые версии, ознакомься с роадмапом.
Изучай другие языки
Желательно из другой парадигмы. Например, функциональные. Будущее за более строгими языками с зависимыми типами, но сейчас мы явно к этому не готовы. Принеси в свою работу новые подходы.
Расширяй кругозор
Разберись с базами данных, очередями, структурами данных, паттернами проектирования.
Это все?
Да. Можно выполнять :)
PS: вот вам еще один лонгрид: моё разочарование в софте.
