Подивився тут інтерв’ю з Миколою Аліменковим , і, після купи дуже розумних думок наприкінці (45:12) він каже: “яка різниця, на якій мові це робити”. Вочевидь, в мене на це питання прямо протилежна точка зору (інакше б я десь біля джави чи якогось пхп тусувався, правда?): інструменти дуже сильно впливають на результат.
Вони впливають як прямо — на швидкість розробки, так і дотично — які задачі тобі здаються досить великими, щоб піти зробити таску у трекері замість просто зробити зараз, чи вже час переходити на мікросервіси, бо твоя команда вже дуже велика і ви наштамповали сотні тисяч строк коду і їх вже неможливо менеджити, та й взагалі на реалізацію інтерфейсів (тут більше про программні, ніж про користувацькі).
Ну, насправді, у джаві будь-що — це неуявний ефорт. Донедавна навіть створити мапу — це був багаторядковий квест. А ще ООП… чи впливає парадігма мови на все життя проекту? Авжеж впливає. З того, як пишеться і структурується система, випливають ті чи інші складності і зовсім різні компроміси приходиться приймати під час реалізації проектів.
Так, у кінці не в технологіях річ. Так, бізнес може не розуміти трейд-оффів того чи іншого підходу, тим більше, що все це неможливо помацати власними руками. Але це має такий самий вплив на бізнес, як і будь-які інші великі архітектурні рішення. Такі самі рішення є у логістиці, у маркетингу, будь-де, коли людина, не будучи зануреною в тему, не може нормально вирішити. А й потім, є проста аналогія — чи будеш ти поля обробляти тисячма людей з сапками? Авжеж, коли в тебе невеличка ділянка, трактор можна не брати, але ми дуже вже давно відійшли від таких ділянок, і на асмі цілі ігри ніхто не пише.
Це не через те, що люди втратили змогу. Ні, завжди є ті, кого пре копатися у найменших деталях і асемблер був би їм до смаку. Але складність проектів зростає експоненційно з кожним роком. І технології — це спосіб вирішення тої складності. А ліпші технології — це найкращій спосіб вирішення.
Повертаючись до Колі — мені здається, що тут історія у наступному. Він багато займався пошуками покращення продуктивності через підходи та процеси. А я, у свою чергу, теж хотів все швидше та якісніше робити - але набагато більше приділяв увагі інструментам. Ось і результат. :-)
Тож viva la Clojure та єдиному пророку її: Річу Хікі! 🤣