О языках программирования вообще и Clojure в частности
Я не очень много читал об архитектуре программного обеспечения, всего 3 книги, но послушал про неё много подкастов, пока гулял с новорождённой дочерью.
Вопрос, который мне казался настолько очевидным, что я ждал ответа на него всегда с первых страниц был таким: «Как выбрать язык, на котором должно быть написано ПО»? Каково же было моё удивление, когда такой вопрос вообще не рассматривался.
Как же так?! Разве это не первое, что мы должны решить?! Даже со всей этой опциональностью, пропагандируемой в «Чистой архитектуре» и ещё кое-где. Нам же нужно нанимать людей и что-то делать. Языки же должны отличаться чем-то друг от друга в вопросе технических характеристик.
Техническая литература безмолвствовала. Подкасты молчали. В одном из разговоров с коллегой с серверной части я прижал его своими расспросами и выяснил, что он никогда не упирался в производительность языка, чтобы думать о его смене. Хм.🤔
Я начал подмечать, что выбор языка имеет куда больше смысла в бизнес-контексте, чем в техническом. Хотите максимизировать вероятность найти кандидата под ваш язык? Смотрите в сторону Java. Хотите работать с начинающими разработчиками? Выбирайте низкий порог входа JavaScript'а.
Хотите собрать модных ребят? Тут возможны варианты. Если вас переполняет энтузиазм и вы истинно верите, что это язык будущего, то вкладывайтесь в Clojure. Нужна вера помощнее? Тогда Haskell со всей его элитарностью.
Вот как мы быстро перескочили от бизнеса к социальным вещам. Используя нишевые языки, вы делаете вашу лодку труднопокидаемой, но также несёте и дополнительные издержки в виде необходимости развивать экосистему или мириться с особенностями конкретных людей.
Многие часто выступают за то, что JS (и другие высокоуровневые языки с не очень, скажем так, удачным дизайном — тот же PHP) нельзя учить как первый язык, т.к. они (люди) подразумевают, что если ты первым изучаешь "более подходящий язык", то ты станешь более сильным программистом.
Вот в этом треде можно найти ещё несколько факторов для принятия решения: twitter.com/shaukote/statu….
Но так ли сильно отличаются разные языки друг от друга? В уже многократно упомянутом «Совершенном коде» есть отличная рекомендация: «программировать с использованием языка, а не на языке». По мере приобретения опыта в голове начинают формироваться идеи, применимые повсеместно.
Сразу оговорюсь и предостерегу от необдуманных решений. Перед тем, как всем рассказывать, как надо, почитайте всё же, что пишет сообщество и какие идеи провозглашает.
Сильно ли отличается по своей идее массив в JavaScript и вектор в Clojure? Идея в том, что это набор ячеек с доступом по индексу. И ладно, что в первом случае массив реализован с помощью Hashmap (или, возможно, настоящего массива), а во втором — при помощи дерева.
Прорывная идея и там, и там состоит в том, что эти массивы не требуют предустановки длины, как это требуется в некоторых других языках. А что насчёт тестов? Сильно отличается идея документирования своих ожиданий от языка к языку? Нет, суть остаётся та же.
Что насчёт разницы между Redux, Mobx, Recoil и ClojureScript'овским re-frame'ом? Кажется, у нас во всех этих случаях используется однонаправленный поток данных, акцентирование внимания на их изменении через лихо закрученные конструкции.
Щадить не буду, мы тут не в шашки играем, пойдём дальше. Какая разница между JavaScript'ым Event Loop'ом и еженедельным обзором задач в методологии продуктивности Getting Things Done? В общем, есть общие идеи в разных языках.
Если и есть за что мне любить Clojure, то это точно не за инструменты. Всё же разные JS-примочки с моментальной обратной связью: линтеры, форматтеры, вотчеры на тестах, позволяют двигаться куда увереннее. А как богаты возможности рефакторинга в WebStorm в сравнении с Cursive!
В последнем даже нет возможности извлечь кусок кода как функцию. И это в функциональном-то языке!
Люблю Clojure за следующее:
• Во-первых, это гомоиконично.
• REPL.
• :keywords как решение проблемы шакальных магических строк.
• Генеративное тестирование.
• Умение работать с бесконечностью через лень.
• Возможность использовать библиотеки Java.
Остановлюсь только на генеративном тестировании. В этой классной штуке вы описываете форму входных и выходных данных (привет, TypeScript!) функции, задаёте дополнительные проверки. Затем Clojure генерирует 1000 различных тестов на основании описания и запускает их. Мощь!!!
Есть один момент персональной боли в Clojure: там слабее деструктуризация по сравнению с JS. Если в JS мы имеем чудесный rest-оператор [...everythingElse], то в Clojure [...ага-ишь-чего-захотел] не сработает.
Спасибо за то, что дочитали!
Герман Тебиев