По поводу последнего поста, надо все-таки прояснить. Вы уж меня поймите, это не специально спроектированный наброс, я не хотел никого специально спровоцировать. Так уж у меня мозг работает, к сожалению: я думаю текстами. Сначала нужно написать, а потом я уже смотрю со стороны и понимаю, что же я на самом деле имел в виду.

Имел я в виду примерно следующее. Конечно, я никого не считаю бесполезными, ни дизайнеров, ни программистов. Не знаю, почему это так прочитали дизайнеры. Нет, все профессии нужны, и пост в первую очередь это реакция на высказывание, что время дизайнеров априори дешевле времени программиста. Я был раздражен и немного перегнул в другую сторону. Маркетинг все равно в 10 раз уделывает любые наши потуги, и дизайнеров, и программистов 🙂

Во-вторых, месседж там все-таки был, но очень сильно замаскированный, так что логично, что его никто не прочитал. Попробую еще раз.

Предыдущий пост — моя собственная рефлексия по поводу своего места и своего собственного развития, и ругаю я там в первую очередь себя, хоть и обобщил немного из-за страха слишком открыться.

А предмет рефлексии — что, собственно, делать программисту с 15-летним опытом? Первые два года ты, понятно, джун, учишься, смотришь, что бывает, совершаешь ошибки. Еще года два-три ты мощная рабочая единица, делаешь что просят, можешь решать задачи от и до, клепаешь проекты один за другим, приносишь максимум пользы. Может повезет даже поруководить кем-то. Пик взаимной эффективности, короче.

Ну вот, а потом что? В этом и был главный вопрос предыдущего поста: бизнесу-то ничего сверх этого не нужно! Понятно, что тебе начнет становиться скучно клепать одни и те же формы, строить сайты, создавать продукты по одной и той же, рабочей, очень эффективной схеме. Получается хорошо, КПД высокий, только программист скучает.

И вот что ему делать? Изучать новые языки. Фреймворки. Экспериментировать. Разрабатывать что-то новое. Дизайнить уникальные системы. Это все классно, интересно, драйвово, но эффективность падает, а бизнесу так это и вообще не нужно. Под это нельзя найти работу. Таких вакансий в принципе не бывает. Как мне сказали на собеседовании в Pitch, когда я вывалил им ворох своих идей по поводу приложения: идеи не нужны, а вот писать код, куда скажут, можешь?

Все, что волнует бизнес — взять что-то готовое, максимально быстро это готовое завернуть, чтобы была хоть какая-то крупица пользы для юзеров, и в печать. Не сделать лучше. Не сделать качественнее. Не совершить прорыв. Не потратить год на ресерч. Этим, как говорится, дома, под одеялом будешь заниматься.

Причем я не говорю, что это неправильно — правильно, к сожалению, я и сам это понимаю. Мне самому бывает противно, когда тут в Джетбрейнс говорят: иди верстай форму, а я ною, отлыниваю, жалуюсь на все на свете и ищу выход энергии и место приложения мозга. Про ворчащего сеньора с эффективностью хуже джуна из прошлого поста — это как раз про меня. В конце концов, та самая форма все-таки нужна, и нужна объективно, а все мои душевные метания чисто моя забота.

И вот что, спрашивается, делать опытному программисту? Куда податься?

Когда-то давно, лет, скажем, 15 назад, я программировал на Джаве. Джава тогда была, ну, не то чтобы новорожденная, но в юношестве точно. И все эти корпоративные «серьезные» программисты только начинали ее окучивать. Spring, Hibernate, Java EE — все это только начиналось.

Ну и вот, на этой волне придумал какой-то лидер мнений Dependency Injection, он же Inversion of Control. Почему названия два? Наверное, лидера было два, хз. У обычных людей это называется просто «передача параметра в функцию», но у Java это обязательно должен быть какой-то паттерн, движение, идеология.

Конкретно это движение возникло из патологической боязни «new» и ответственности. По не до конца ясным мне причинам, код в Java, который что-то на самом деле делает, считается зашкваром. Самый лучший код — тот, который ничего не делает и не решает, а просто перекладывает задачу на следующего. Да, прямо как бюрократический аппарат. Особенно мило на это смотреть, когда все классы пишет один и тот же человек, и перекладывает он работу от самого себя самому себе.

Ну вот, короче, решил я узнать, что за шум. Все-таки я ж архитектор и тимлид тогда был (не то что сейчас), надо держать руку на пульсе. Открыл доку, как сейчас помню, по Guice. Это такая гугловая вариация Спринга, типа, щадащая (да, в Джава мире даже такая большая компания как Гугл не может вырвать пальму первенства по говенности кода у настоящих Java-архитекторов).

Открыл, в общем, читаю, а там пишут: DI это то-то и то-то, new зашквар, фабрики зашквар, присоединяйтесь к революции, удаляйте все свои new Papaya() и делайте IPapaya, PapayaImpl, обмазывайте их аннотациями, заводите Module, реализуйте configure, биндите ваш класс с вашим классом, заводите Injector, инициализируйте модулем (да, даже тут без `new`), и наконец просите у него ваш класс создать. Чтобы точно никто никогда не догадался, кто у вас там кого создает и откуда что берется.

И дальше, внимание, следующая фраза: «Мы понимаем, что вам придется переделать почти все свое приложение. Мы знаем, что это займет много времени. Скорее всего, в середине пути вы начнете спрашивать себя: а зачем я это делаю, не дурак ли я? Так вот, помните: вы делаете это потому что так будет лучше».

Ну я поверил и пошел переделывать. День переделывал. Два. Три. Переделал. Зашибись, думаю. Теперь заживем. Прислушался к ощущениям — неа, нифига не поменялось. Ну то есть добавилась еще одна библиотека. Код запутался еще на один виток абстракции и индирекции. Но в целом — нет, лучше не стало.

С тех пор я Java-архитекторам не верю. Я вообще никому на слово теперь не верю. Если есть предложение, как улучшить код — просто расскажи, в чем предложение. Если оно нормальное, как-то специально рекламировать или убеждать кого-то в его необходимости не нужно — само предложение все скажет само за себя. А если написано «поверьте, нет времени объяснять» — это очевидная наебка и вам пытаются впарить прокисшее говно.

Вообще, всякая «идеологическая правильность» существует только в голове и на словах того, кто вам ее впаривает. В коде никакой идеологической правильности быть не может, код либо работает, либо нет. И уж тем более никакая программерская идеология и «правильность» не стоит простоты реализации и прагматизма. Думайте головой, дышите носом, короче.

Я уже упоминал неоднократно, как выгорел от Джава экосистемы 10 лет назад. Так вот, неделю назад я имел неосторожность ввязаться в живую дискуссию по поводу Ant/Maven/Groovy как раз с ребятами из мира Java. ПТСР стрелял с регулярностью три минуты.

И вот о чем мне эта дискуссия напомнила, и из-за чего, по моему мнению, наша индустрия находится в такой жопе. Да, пример будет про Джаву, извините, это не неделя хейта, просто так получилось, ну вот такой пример под рукой. Я в конце обобщу.

В пылу спора на вопрос, нафига им такая сложная и умная система сборки, Вова Ситников мне ответил: ну как же, вот смотри, у нас есть пятнадцать логгинг фреймворков (ага, xkcd про competing standards как раз с Джавы рисовал), дальше, каждый фреймворк распилен на запчасти, чтобы можно было подключать не целиком, и есть еще энное количество коннекторов, которые переводят один фреймворк в другой. А, еще у этих фреймворков есть версии, и не все версии совместимы друг с другом, а взять можно только одну. А, ну и конечно, все твои _нормальные_ зависимости уже что-то выбрали, скорее всего разное, ты без них не можешь, так что хочешь-не хочешь надо вертеться.

И что сделали Джависты? Они идентифицировали это как проблему. А как серьезные, взрослые программисты решают проблемы? Правильно, пишут код. Ну и пошли и написали код, который якобы в этом разбирается даже без поллитры, а тебе ничего делать не нужно.

Видите проблему? Видите? Да, это именно из-за нее в жопе не только русское кино, но и русское Айти. Да любое Айти, в принципе.

Проблема в том, чтобы вместо того чтобы трезво взглянуть на что-то, что сделано неправильно, признать, что ошиблись, пойти и сделать нормально, программисты просто пожимают плечами, «хм, новый челленж», и идут строить поверх, просто оставив все как было.

Куча несовместимых логгинг-библиотек это не что-то, что можно починить написанием еще одной библиотеки. Если юнит-тесты сложно запустить без системы сборки, которая по сложности вот-вот пройдет тест Тьюринга, это не значит, что надо поднажать в части системы сборки. Проблема не в системе сборки блин!

Это примерно как не убирать мусор в аэропорту: вместо уборки его обносят аккуратными флажками и начинают думать, как бы поудобнее перенаправить пассажиропоток вокруг накапливающейся кучи.

Докер, кстати, прекрасная иллюстрация той же проблемы. Не осилили сложность — подождали, когда компьютеры станут достаточно жирными — начали носить эту сложность с собой и тиражировать в идиотских количествах.

Я, конечно, в той дискуссии про Гредл сильно разгорячился. Но для меня просто удивительно, как взрослые, опытные люди могут быть прекрасными программистами (я уверен) и очень хорошо решать проблемы, но не там, где они на самом происходит, а там, где им удобнее, и в упор не видеть суть. Умножение сложности — грех, за который программистов надо наказывать, а не сертификаты и премии выдавать.

А вообще, если вы, как и я, вляпались зачем-то в Java экосистему, особенно энтерпрайзную, и начинаете все больше и больше испытывать отвращение к программированию, все острее чувствовать абсурдность происходящего и бояться за свой рассудок, помните:

С вами все в порядке. Вы молодец и все делаете правильно. Проблема в консерватории, ее уже не починить.

Также помните, что рядом тоже полно нормальных, адекватных людей, которые создают куда более приятные экосистемы. Такие, в которых люди не соревнуются в том, кто кого переусложнит и у кого Hello World займет больше строчек, сервисов и ресурсов. В которых проекты измеряются не миллионами строк кода, а десятками тысяч, и ни в чем не уступают по функционалу. Проекты, которые зарабатывают миллионы долларов и меняют мир, ничуть не менее «серьезные», вопреки мнению тех самых энтерпрайзных джавистов.

И туда всегда можно перейти, найти свое счастье и душевное спокойствие. Я в свое время сбежал на Питон, потом на Erlang, и в конце концов на Clojure.

В любом случае, бежать к адекватным людям и здравому смыслу было лучшим решением в моей жизни. Рекомендую.

На этом неделя Java в канале официально объявляется закрытой, и мой гештальт тоже. Надеюсь, в следующий раз услышу о ней не раньше чем через еще 10 лет.

P.S. Если вам нормально — ну и классно, просто проигнорируйте этот пост
P.P.S. JVM все еще нежно люблю, пост исключительно о java как экосистеме
P.P.P.S. Убрал языки, про которые я знаю только понаслышке. Там тоже может быть хорошо, но обещать не могу

Перестаем ныть и переходим к конструктиву. В комментах к прошлому посту спрашивали, как же починить проблему логирования, когда есть 15 разных библиотек?

Действительно, логирование штука очень неудобная, в первую очередь потому что библиотеки. Каждая библиотека выбирает свой фреймворк, вы выбираете 15 библиотек (это еще по-божески) и привет, у вас в приложении 15 разных логгеров. Вот что с этим делать?

Давайте применим дизайнерское мышление и проанализируем ситуацию. Сторонние библиотеки не работают, потому что кто-то нет-нет да и напишет новую, а какой-нибудь глупец соблазнится на сиюминутные преимущества и заиспользует ее, проигнорировав общую картину. То есть сразу нет.

Методом исключения получаем, что логирование должно быть в стандартной библиотеке языка. Иначе никак.

Кстати, в Java логирование _есть_ в стандартной библиотеке, но проблема осталась. Почему так? Почему никто не переехал на java.util.logging? У меня две версии, и подозреваю, они сыграли обе.

Первая — потому что мало сделать новый логгер, надо еще перестать использовать старый. В программировании вообще недооценен процесс возвращения и переделывания того, что было сделано, а зря. Дописывание — да, за милую душу, а вот переписывание не любят. Хотя я, например, обожаю переделывать и переписывать, потому что перфекционист и с первого (и даже со второго) раза нормально сделать не могу (нормально по моим меркам, по меркам индустрии у меня и с первого раза очень неплохо получается).

Вторая версия — что java.util.logging вышел куцым по функциональности в сравнении с «настоящими» логгерами. Мне-то как раз это нравится, а вот Java-программистам, подозреваю, не зашло.

И тут я выскажу радикальное мнение: по мне, так логгинг должен быть максимально куцым. Тот же log4j может: срать в несколько файлов, обкусывать файлы, менять файлы в зависимости от дня недели, фильтровать записи, форматировать записи, грузить конфиги, перезагружать конфиги, варить кофе^W^W. Это полноценный фреймворк, на настройку которого можно потратить не один день.

Что же в этом плохого? Опять же, давайте посмотрим на общую картину (дизайн мышление, помните?). Если логгер умеет делать так много, это значит что он будет делать так много, то есть, все эти настройки будут гвоздями прибиты к вашему приложению.

А это не задача вашего приложения — решать, где я хочу видеть логи, сколько и как часто. Генерить логи — да, пожалуйста, но фильтрация, хранение, организация — это явно другой уровень и решаться должно снаружи. Когда это делается изнутри, это негибко, это лишний функционал и плохая интеграция. Будете в следующий раз пить аспирин после настройки log4j — задумайтесь об этом. 12 factor apps всем, пацаны!

Так что же, как в итоге должен выглядеть идеальный логгер? Идеальный логгер — это println.

Джон Блоу (да-да, тот самый, который Preventing the Collapse of the Civilization) высказывает (ну как высказывает, высказывал, в январе еще) интересную мысль в подкасте On The Metal.

Во-первых, насколько обидно, что мы наконец более-менее унифицировали процессоры, убрали барьер железной совместимости, зато понаставили новых — в этот раз операционных систем. Обидно, что единственное, что мешает взять файл, скомпиленный у меня на компьютере, и запустить ровно этот же файл у тебя на компьютере это какие-то глупые, мелочные детали, эхо войны вендоров ОС и их полная неспособность дружить и договариваться. Хотя процессору, вообще говоря, все равно, и делать он будет в конечном итоге одно и то же.

Во-вторых, по его мнению, появление динамических языков — это своего рода ответ на вот эту вот потребность «взять файл, который работал у меня, и запустить ровно этот же файл у кого-то еще». Понятно, что есть еще аспект «высокоуровневости», но про файл тоже интересно.

Ну и в третьих он считает, что в принципе программы в компьютере плохо дружат. Есть, типа, shell, в котором программы обмениваются строками через пайп, и это стыд, конечно. И есть, причем очень давно, нормальный способ переиспользовать чужой код — C calling conventions и, соответственно, динамические/статические библиотеки.

В общем-то, проблема всех остальных языков, которые не C, в том, что они сделали этот вариант сотрудничества максимально неудобным, и вместо того чтобы дружить с уже существующим кодом стали строить весь мир с нуля. Ну и они не только с С не дружат, но и между собой тоже, так что каждый из них это такой Walled Garden без каких-либо планов на стать чем-то большим.

Такая вот перспектива, издалека. Даже какой-то смысл в WASM появляется, даже не для браузеров, а для обычных десктопных утилит и программ

Главное правило хорошей программы — код должен работать. Любой код, который не запускается регулярно, протухает и ломается. Да, даже если его не трогать. Особенно, если его не трогать. Прям как продукты, хоть и сделан из чистой информации.

Например, в Grumpy Website есть авторизация, которая сбрасывается раз в две недели. Почему? Да потому что это гарантия, что она будет работать. Если бы она жила вечно, то прошло бы полгода-год, кому-то понадобилось бы зайти с нового компа и мы все бы узнали, что авторизация, оказывается, давно сломана. А так она тестируется регулярно и всегда в форме.

Отсюда следствие: общих механизмов должно быть как можно больше, а специальных — как можно меньше. Например, попробовать отправить письмо сразу, а если не получилось — положить в очередь и попробовать позже — мина отложенного действия. Большинство писем будет уходить сразу и даже если очередь сломана, вы сможете долго этого не замечать. Правильно — складывать в очередь всегда и разгребать ее на общих основаниях, без каких-либо «оптимизаций».

Да, анекдот про вылить воду из чайника и перейти к шагу 1 (налить воду) совсем не анекдот, а очень хороший совет. А вы что думали, шутки про программистов — это шутки?

Давайте расскажу вам про главное правило пет-проектов. Главное правило пет-проектов: придумать, как ничего не делать.

Многие программисты могут подумать, что ничего не делать — это что-то автоматизировать. Нет, наоборот, автоматизирование добавляет головной боли, а мы хотим ее избежать. Например, мне в прошлом посте про «пассивный код — мертвый код» порекомендовали не мучать пользователя постоянными разлогинами, а завести тестового юзера и автоматизировать:

«Скрипты. Планировщик в CI запускает тесты, оформленные в pytest/junit/whatever, рисует красивые картинки, срёт уведомлениями, если что-то пошло не так. Надо только определиться, кто отвечает за реакцию на уведомления.»

Это, конечно, путь для нормальных систем, где программистам платят зарплату, чтобы они не дергались и делали то, что сами добровольно никогда бы делать не захотели.

Но в пет-проектах, к сожалению, зарплату не платят, поэтому приходится адаптироваться. Что не так с этим предложением?

Во-первых, очень много работы. Скрипты надо написать, всю эту машинерию — настроить. Во-вторых, очень много мейнтенанса — за CI надо следить, на уведомления реагировать. В-третьих, это все будет ломаться, это надо обслуживать, что явно будет лень делать, т.к. ломается оно всегда не вовремя, а проектом не каждую неделю есть время заниматься.

Трюк с пет-проектами в том, чтобы обмануть себя и успеть сделать что-то, что можно показать людям до того, как ты устанешь и тебе надоест. А тебе устанет и надоест, trust me. Поэтому количество нерелевантной работы надо резать жестко и беспощадно. И поэтому я так доволен решением с авторизацией: работы нет, а тестирование выполняется.

Классическая иллюстрация этого принципа это «не пишите движок блога». Потому что устанете быстрее, чем напишете первый пост. Люди, которые хостятся на Github Pages с готовым шаблоном или на Wordpress — те, которым интересно решить проблему; люди, которые пишут движок — те, которым интересно попрокрастинировать. Поэтому вы читаете этот текст в Телеграмме, а не на каком-то самописном сайте с собственным компилятором — я бы этот компилятор до сих пор писал.

Другой пример из недавнего — Roam Research. Чуваки лет то ли пять, то ли семь сидят без сервера вообще, тупо складывают все в Firebase и ничего, работают, денег подняли. Во всей инфраструктуре нет ни одного сервера. Потом пришел создатель Athens Research, решил склонировать Roam, но еще больше не заморачиваться, и не стал делать даже Firebase. Просто сделал локального клиента, так еще и без авторизации обошелся. И все равно 2 ляма поднял. Легенда.

Все это иллюстрирует один принцип: чем меньше работы вы себе придумаете, тем выше шансы все это закончить. И наоборот, будете делать «по-нормальному», «правильно» — и не закончите никогда. Потому что лето, пиво, дети, диван, друзья или плейстейшн побеждают «отдых программированием» в 100% случаев. Да вообще все что угодно его побеждает. И это нормально, с этим ничего не сделаешь, надо просто придумать, как в таких условиях работать.

Иногда я говорю, что не понимаю чего-то, но на самом деле конечно понимаю, просто несогласен. Но есть вещи, которые я сколько умом ни пытался понять, так и не смог.

Одна из таких — поведение NaN в IEEE 754 и NULL в SQL. Как вы знаете, NaN != NaN, а NULL <> NULL.

И вот тут вопрос: ПОЧЕМУ БЛЯДЬ???

Это классический foot gun же: ты думал, что a == a, и оно почти всегда да, кроме случаев, когда нет. Хочешь проверить, что функции вернули одно и то же? == будет недостаточно. Хочешь тест написать? == не хватит. В мапу положил, а потом найти не можешь? Смотря как ищещь. Передал по сети и сравниваешь JSON с эталонным? Не сравнится, потому что в глубине где-то есть NaN. Про SQL я вообще молчу.

Это столько всего ломает и столько неудобств создает, что словами не передать. Про это надо в каждой дырке помнить, обкладываться if-ми и OR-ами, ну или надеяться, что никогда их не увидишь. Как будто без этого в программировании разочарований не хватает.

Вашему внимаю представляется список сложнейших, практически неразрешимых задач в IT:

- Инвалидация кэша
- Придумывание названий
- Off-by-one ошибки
- Кнопка «Назад»
- Плавный скролл
- Запомнить позицию скролла
- Плавные веб-анимации
- Звук на видеоконференциях
- Верстка имейлов
- Выравнивание текста и иконки
- Файловые пути с пробелами
- Запоминание «Запомнить меня»
- Не писать еще один пакетный менеджер (ой, написал)
- Логгирование в Джаве
- Юнит тесты в Джаве
- Сборка проекта в Джаве
- Выделение текста в PDF
- Оценка оставшегося времени в прогресс-барах
- Кража фокуса
- Запись в файл (надежная)
- Парсинг XML (надежный)
- Переключение режимов монитора в Windows
- Поиск пути, куда установлена Visual Studio
- Запоминание, на каком мониторе открывать окно
- Плавное изменение размера окна
- Подключение Bluetooth-наушников
- Цветовые пространства
- Ввод текста
- Вывод текста
- Часовые пояса

UPD (из комментов):

- Синхронизация файлов в iCloud
- Принтеры
- Выход из vi
- Счетчик непрочитанных
- Настройка фронтенд-проекта

Ох как я ненавижу логины и аккаунты.

Сегодня пытался залогиниться в посудомоечную машину. Почему, зачем? Ну она мне шлет нотификации, мол, пора меня чистить. Я бы и кнопками почистил, но там же иконки, а не подписи — пойди угадай, какая что значит.

Короче, сначала пытался понять, какое приложение вообще ей управляет. Машина — Siemens, поиск по Siemens или там Dishwasher конечно ничего не дал. В итоге листал тупо список всех вообще приложений на телефоне в поисках незнакомого. Home Connect называется.

Ладно, захожу. Оно говорит — нет устройств! Как нет-то, ты же, падла, нотификации мне шлешь.

Ну окей, давайте добавим. Жму добавить — оно говорит: сначала залогинься. Ну епт. А что это за приложение — я в душе не помню, но видимо когда-то его настраивал, раз нотификации приходят.

А раз настраивал — должен был аккаунт создать? Но почему тогда он слетел? Телефон я не менял, приложение не переустанавливал. Жму логин — 1Password — нет аккаунта.

Ну ладно, нет так нет, может раньше не требовался? Жму создать, заполняю блядскую форму на восемьнадцать полей, придумываю, конечно, пароль, ввожу два раза, и емейл, конечно, тоже два раза. И конечно, посудомоечной машине нужно знать где я живу и какой у меня телефон, чтобы полоскать мои чашки. ВСЮ ФОРМУ ДО КОНЦА ЗАПОЛНЯЮ! Все с телефона, то есть максимально неудобно, в квадратике 2 на 2 сантиметра. Жму: создавай.

Создала, говорит. Иди в емейл. Иду в емейл. А там — есть такой аккаунт уже. Попробуй залогиниться, лузер. И все, даже ссылки обратно, сука, нет. А СРАЗУ НЕЛЬЗЯ СКАЗАТЬ БЫЛО???

Иду логиниться. Пароля, конечно, взять неоткуда. Жму восстановить. Иди опять в почту. Иду в почту. Вот ваш временный пароль. О, думаю, зашибись. Его-то и оставлю. Ввожу емейл и копирую пароль. Зашибись, говорит! Но пароль-то временный. Давай новый придумывай. Ну ё-маё, ну что опять началось...

Ладно, придумываю. Соглашается. Пускает. Добавляю, наконец, машину в апп. Безболезненно достаточно, кстати — потому что Я ОДИН РАЗ ЭТО УЖЕ ДЕЛАЛ КУДА ОНА ПОДЕВАЛАСЬ? А? А?

Зашибись, думаю. Теперь-то запущу чистку. Нахожу режим в приложении. Подношу палец к кнопке. ЗАПУСК ИЗ ПРИЛОЖЕНИЯ ЗАПРЕЩЕН. ИДИ ПАСИСЬ.

(Ну или если хочешь можешь еще час в ютубе гуглить, как remote start разрешить, но у меня уже сил не было, честно).

Короче, я просто спалил, какая иконка у режима чистки в приложении.

А потом подошел к машинке ногами И НАЖАЛ ТОЧНО ТАКУЮ ЖЕ КНОПКУ. Просто подошел и просто нажал. Все. Одно действие. НИКАКИХ, БЛЯДЬ, ЛОГИНОВ. ПОЧЕМУ В ТЕЛЕФОНЕ НЕЛЬЗЯ ТАКЖЕ???

Вы удивляетесь, почему «умный дом» никто так не любит? Ну вот поэтому.

Ну и про проблему логинов и того, что их пихают везде, где нужно и где не нужно.

Во-первых, идите со своими логинами нахуй.

Во-вторых, идите-идите, я не шутил.

Во-третьих, если уж вас укушенный маркетологом менеджер заставил их делать, как насчет того, чтобы эти логины не терять? В идеале я хочу вводить логин один раз в жизни. Ну может один раз за время жизни компьютера. КАК ЛОГИН МОЖЕТ ПОТЕРЯТЬСЯ???

В-четвертых, одного поля «email» достаточно ДЛЯ ВСЕГО. Просто email — письмо со ссылкой — нажал — ты внутри. Логин, регистрация, восстановление — все одинаково. В вашей форме БУКВАЛЬНО не должно быть НИ ОДНО поля, кроме email. БУКВАЛЬНО.

В-пятых, на тему логинов обязательно посмотрите «Jonathan Blow tries Razer BlackWidow TE Chroma v2 keyboard» на Ютубе. Руководство к действию.

В-шестых, идите нахуй.

Нанять классных программистов — не проблема. Они сами к тебе бегут, на самом деле. Говорю из опыта.

Вот предложить им что-то интересное, чтобы побежали — вот это проблема.

Так что в следующий раз, когда у вас будут проблемы с наймом, задумайтесь: а тем ли вы в жизни занимаетесь? Хотели бы вы сами у себя работать? А то, может, потому и не бегут.

Если к программам относиться слишком серьезно, можно заподозрить себя в шизофрении. Потому что программы сплошь и рядом говорят одно, а делают другое.

Например, сейчас вот нажал pull в Идее, а она пошла и переформатировала какие-то свои iml файлы, а потом говорит: не могу пуллиться, У ТЕБЯ изменения. Хотя изменения, конечно, не у меня.

Или на грампи был недавно пример: комп перезагрузился, репортер предлагает репортить об ошибке, а собиратель ничего не собрал. В итоге репортить нечего, что делать юзеру — неясно. И зачем было его беспокоить тоже.

Или одна часть системы говорит: сегодня ночью поставлю апдейты! А вторая не ставит их уже неделю, потому что... не знаю почему! Что-то где-то пошло не так, видимо.

Говорят, при Стиве Джобсе было хорошо: программисты делали, что они обычно делали, а он потом приходил, запускал программу ЛИЧНО и на весь бред пальцем показывал: вы че, ребят, ну так нельзя же.

А Билл Гейтс, говорят, как-то раз не смог Паинт с сайта своей же компании скачать, так там было все запутано. Но исправлять не стал, пригрустил просто.

Такая вот разница между Эпплом и Майкрософтом. Была. Сейчас-то они сравнялись, конечно: Эппл отстал, Майки подтянулись. Только вот нормальному человеку идти стало совсем некуда.

Окей, рил толк. Сегодня я вас научу главному правилу хорошего кода, про которое никто не говорит и про которое знают только принципал инженеры. Вот оно:

«Названия переменных и функций должны содержать ровно одно слово.»

Не два, не три, не полтора. Без сокращений (сокращения — отстой), но и без растекания мыслью по вээскоду.

Вот, например, типичный код из публичного собеседования с канала Хекслет:

export const get = (keySequence, nestedObject) => {
  const keyArr = keySequence.split('.');
  let tempObj = nestedObject;
  for (let i = 0; tempObj && i < keyArr.length; i++)
    tempObj = tempObj[keyArr[i]];
  return tempObj;
};

Все классно, к алгоритму вопросов нет, классов не наплодили, что тут улучшишь?

Опытные программисты заметят сразу: глаз вязнет, потому что в каждой переменной по два слова! Очень неудобно читать, потому что вроде бы сущность одна, название ты ее прочитал и морально уже готов посмотреть, что там с ней делать будут, а тут на тебе: читай еще одно слово. Неудобненько.

А вот действительно звенящий идеал кода:

export const get = (path, obj) => {
  const keys = path.split('.');
  let temp = obj;
  for (let i = 0; temp && i < keys.length; i++)
    temp = temp[keys[i]];
  return temp;
};

Чувствуете, как полегчало, да? Как будто из болота на шоссе выехали и свежим ветерком подуло. Так что будете в следующий раз программировать — задумайтесь. И друзьям расскажите.

Вот что я решительно не перевариваю — это needy программы. То есть такие, которые не работают на тебя, а которые ты должен обслуживать.

Возьмем Idea как пример (просто потому что под рукой). Создание файла. Казалось бы — простейшая операция, что может быть тривиальнее? Ну так вот, если нажать Cmd+Shift+N в Idea, она... не создаст новый файл! Она начнет допекать тебя вопросами: а как назвать? А какой тип? А какая версия? А в файле будет класс лежать или интерфейс? И только продравшись через все эти дебри, ты получишь наконец возможность что-то написать. Хотя к этому моменту, наверное, уже и забыл, что.

Но она ведь помогает? Не. Это не помощь. Точнее, помощь, конечно, но предложенная неудобно и не вовремя. Такая, что заколебет больше, чем сохранит сил.

При работе с программой может быть два режима: а) ты отдаешь команды — программа действует, или б) программа что-то от тебя хочет. Первый — абсолютный кайф, позволяет поймать поток и чувствовать себя творцом-демиургом, полностью подчинившим себе инструмент.

Второй — полная противоположность, беспомощный «помощник», который сам ничего не может и дергает тебя по пустякам. В сущности ты, вместо того, чтобы решать свои проблемы и воплощать свои замыслы, переключаешься на нужды программы и делаешь то, что ей в данный момент зачем-то нужно. Ей, а не тебе.

Но ведь это обязательные параметры? Как без них? Да легко! Я нажал «создать файл» — вот тебе пустой файл. Не нравится формат? Нажму и поменяю. Имя неправильное? Переименую. Разница в том, что это происходит, когда мне это нужно, когда у меня возникает эта проблема. У меня, а не у программы.

Другой яркий пример такого абьюзивного поведения: нотификации. Самое страшное, что произошло с ИДЕ, с момента изобретения ИДЕ. Нотификации — это проблемы программы, которые она считает нужным сделать моими проблемами. Часто нотификации даже близко не имеют отношения к тому, что я делаю. Плагин, например, обновился. Или сломалось что-то внутри. Или «псс, парень, не хочешь подсветку синтаксиса поискать»? Ну блин, если бы хотел, я бы пошел и поискал, епта. Или «смотри, смотри, я поняла кажется что тут написано, вот тебе пяток иконок по этому поводу!»

Еще один — настройка проекта. «Сначала все настрой, потом я начну работать» это программный эквивалет вотерфолла, методология, которая, как известно, никогда толком не работала. Я не хочу ничего настраивать кроме того, что мне прямо сейчас нужно, я хочу работать, а не обслуживанием софта заниматься.

Ну и апдейты, конечно. Ну вот любят программисты в момент обновления переделать/передумать/переизобрести какие-то внутренности, а потом гордо мне сообщить, что теперь у меня формат конфига неправильный, или нужно файлы какие-то закоммитить, или просто что больше ничего работать не будет. Но я-то тут причем, зачем вы меня этим мучаете?

Короче, программы, не спрашивайте у пользователя ничего. Дайте ему команды и возможность их дергать. Когда ему понадобится (ему, а не вам!), он придет и сам вас позовет. А до тех пор, ради бога, оставьте его в покое. И не блокируйте работу.

Какой программист не мечтает написать свой блог-движок? Я тоже неспеша в эту сторону думаю, потому что у меня типа есть блог. Но только я не хочу никуда дергаться, пока не пойму не только как сделать «не хуже», а как сделать именно существенно лучше. Пока мысли такие:

Блог в первую очередь про формат. В Телеграм, например, пишется легко и свободно в основном потому, что тут минимум оформления и максимум содержания. Шрифт не выберешь, заголовки не расставишь, картинку не приложишь. Этот аскетизм помогает и писателю (не отвлекаешься от мысли — некуда), и читателю: не надо привыкать к очередному дизайну перед поглощением информации, у всех всё одинаковое.

В Грампи у нас был такой же принцип: одна картинка и минимум текста, без заголовков, категорий, тегов, комментов, вообще без ничего. Я готов объявить эксперимент успешным: за три года писать в него так и не стало обузой. Да, иногда хочется добавить еще одну картинку, или сослаться куда-то, или процитировать, но знаете что? Чем дальше, тем больше ценишь, что возможности ограничены.

Вторая важная вещь для блога — коммьюнити. В Телеграме с этим вышло очень удачно: комменты зашли просто идеально. Я списываю этот успех на простоту комментирования: ты уже залогинен, отправлять сообщения уже умеешь, как будет выглядеть представляешь по прошлому опыту, интерфейс вылизанный и минималистичный. В каком-то смысле канал в Телеграме это не блог, это коммьюнити. Но главное — это весело! Примерно как ранний ЖЖ.

Тут, конечно, возникает вопрос: а как такие вайбы перенести в веб, в персональный блог? Непонятно. Заставлять создавать акк, чтобы комментить — порог великоват. У Бирмана, например, в канале десятки комментариев, а в блоге — единицы. То есть buzzkill примерно десятикратный. Встраивать Disqus? Он очень страшный. Сделать нормальный Disqus? Ну а кто им будет пользоваться? Выносить обсуждение на HN/Reddit/Twitter? Пока самый реальный вариант: да, там есть жизнь, но она как-то отдельно как будто. Плюс HN еще туда-сюда, а вот в Reddit и Twitter сложные ветвистые обсуждения вести мучительно.

Третья мысль — hosted или self-hosted? Хостинг «у дяди» я люблю за простоту, конечно. Но также и не люблю за, понятно, «а что если закроется», а также «а что если я вот такое хочу, а его нет», ну и за «плати нологи^W денюжку».

Хостинг у себя я не люблю тоже, потому что, как я уже говорил, я хочу писать, а не администрировать виртуалки. Даже с one-click deploy (какой-нибудь, допустим, докер) это как будто сложновато звучит, да? Ну и возможностей кастомизации как будто нет, а гемор с виртуалками есть.

Ну а если не one-click, а собирать из исходников, то вот ты его докрутишь под себя, а как потом обновляться? Дизайн я тоже, как правило, хочу свой, а придумать такую платформу, на которую можно было бы спокойно натягивать дизайны (по-настоящему разные, с разными функционально блоками, лайаутами, страницами, не просто темы, короче), не переделывая вообще всего — та еще задача.

Короче, ситуация патовая, я это понимаю, но все равно люблю перебирать в голове эти три варианта, прислушиваться, что из этого действительно кажется важным, а с чем можно смириться. Ну и сталкиваю мысленно друг с другом в попытка придумать какой-то фьюжн.

Последняя проблема, над которой я пассивно ломаю голову (знаю, утомил, потерпите еще чуть-чуть) это как сделать дизайн интересным. На самом деле, когда я слышу «standalone blog», у меня уже непроизвольно скулы сводит от скуки. А если там еще и «черный текст на белом фоне», то просто пиши пропало, они же все одинаковые, как под копирку. Куда самовыражение вставлять?

Но и придумать что-то лучше черного текста на белом фоне сложновато, будем честны. Поэтому вопросик подвешен. И не надо мне писать про желтый фон моего сайта, это не то решение, которое я на самом деле предлагаю. Оно есть, но по другим причинам, и я тоже не до конца с ним счастлив.

Короче, ничего не знаю, предложить нечего, делитесь своими мыслями, спасибо что прочитали!

Реалити чек! У StackOverflow вышел Developer Survey 2021, и я решил собрать тут факты, которые меня больше всего удивили.

Языки:

- JavaScript самый популярный язык (68%)
- Rust и Clojure два самых любимых языка (87% и 81% loved)
- Objective-C – один из самых устрашающих (27% loved), в одной лиге с VBA, Cobol, Groovy, Perl и Assembly
- За Clojure платят в больше всего ($95k), на $15k больше, чем ближайшим конкурентам (F#/Elixir/Erlang/Perl (?)/Ruby, все по $80k). Есть гипотеза, что это потому, что к Clojure приходишь, когда уже набрался опыта и надоела вся эта суета

ОС:

- Мне всегда навскидку казалось, что все разработчкии сидят с макбуками, но это, видимо, мой круг общения. На самом деле 41% на Винде, только 30% на Маке, и еще 25% на Линуксе

БД:

- NoSQL эра прошла, самая популярная NoSQL база — MongoDB — на 28%
- MongoDB хоть и не пользуются, но любят (60%). Это к вопросу о маркетинге и DX

Веб:

- React наконец обогнал jQuery (41% против 34%, еще в прошлом году было 37% против 43%)
- Самый прибыльный веб-фреймворк — RoR ($77k)

Cloud:

- Несмотря на весь шум, Kubernetes пока всего на 20%

Аналитика:

- Оказывается, четверть (!) всех разработчиков сидят на некоей Pandas, про которую я не слышал даже названия (!!). Стареем-с.

IDE:

- VS Code занимает 71%. Микрософту респект — смогли! Главное теперь не превратить то хорошее, что у них есть, в Visual Studio
- Ближайший конкурент VS Code — IntelliJ — всего 30%. Серьезный повод для беспокойства
- Самые богатые программисты сидят в Textmate (?) – $80k

Mobile:

- Developer, mobile получает меньше вообще всех ($41k). Это меньше сисадмина, тестировщика, аналитика, дизайнера, ученого. Странно, мне казалось, мобильщики наоборот, гребут деньги лопатой.

Кидайте вашу зарплату и любимый редактор в комменты, будем строить корреляции!

Сел я, значит, Fira Code попрограммировать. Дай, думаю, соберу — у меня там и скрипты наготове. Работавшие!

Нажимаю, а оно: pip устарел. Это еще скажите спасибо, что у меня pip вообще был установлен. Как я его ставил это отдельная история.

Обновить, говорит? Ну давай. Введите, говорит,

/opt/homebrew/opt/python@3.9/bin/python3.9 -m pip install --upgrade pip

Почему не просто pip upgrade pip, мы никогда не узнаем, но это уже придирки. И почему upgrade, а не update?

Обновился. Но все равно ругается. Че там? Да вот, говорит:

DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621

Ну идем читать. А там написано:

If you have been directed here from a pip warning, you don't need to take any action at this stage. Nothing is currently expected to break until Python 3.12, and a full solution will be implemented well before then.

Спасибо что предупредили, как говорится. А также спасибо за ворнинг, от которого нельзя избавиться, но который ничего от меня не требует. Но, типа, хотя бы не блокер.

Ладно. Пойдем этот ваш Pip использовать. Тут надо сказать, что компиляция шрифтов — то еще сборище костылей и подпорок. Оно работает (если вообще работает) не благодаря, а вопреки. Например, у меня в скрипте сборки ставится шесть (!) разных тулз от разных разработчиков, через разные пакетные менеджеры, просто чтобы собрать один шрифт. А еще там есть такие, например, строки:

pip install -U Pillow==5.4.1 idna==2.8 requests==2.21.0 urllib3==1.24.1
export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig"

Почему именно такие? Да хрен его знает, с другими не работало. Что они делают? Да тоже хрен его знает. Такой вот парадокс — шрифты нужны всем, а тулинг разрабатывается тремя энтузиастами в свободное время.

Ну ладно, жму

pip install git+https://github.com/googlefonts/gftools

Не могу, говорит. Почему? Да вот ttfautohint-py не нашла. Как не нашла-то? Никак не нашла.

Иду гуглить. Нахожу issue, в котором какие-то случайно проходившие мимо люди обсуждают, как они какими-то правдами и неправдами, но умудрялись собрать эту ttfautohint-py для M1. Мейнтейнер, к слову, поскольку эта библиотека на 19 звездочек, в дискуссии участвует исключительно с общими ни к чему не обязывающими комментариями типа «проблема нашей ситуации в том, что...», а никак не патчами.

То есть библиотека с 19 (!) звездочками идет как hard requirement для гуглового gftools, на котором весь Google Fonts ездит. То есть понимаете масштаб «серьезности» и «основательности», да? Еще и названия у них там, типа, Pillow Wheel Builder. Че за подушка? Че за колеса? Детский сад, ей богу.

Самое обидное, что ttfautohint, библиотека очень важная и популярная, у меня прекрасно ставится через brew. А вот питонья обертка — ни в какую.

В общем, я остался без скриптов, а вы — без Fira Code. Я, кстати, не пожаловался, что текущий пайплайн собирает (ну, собирал раньше) шрифт за 50 секунд? ПЯТЬДЕСЯТ, карл! За это время на луну можно слетать на стрекозе и обратно, а не двухмегабайтный файл обработать.

Короче, питоний менеджмент пакетов надо сжечь, тут уже ничего не спасти. Я немножко в шоке, это второй по популярности язык в мире, и настолько помойка.

А после того, как сожжем, переписать все, что касается шрифтов, на Rust. Оно будет собираться из исходников час, промежуточных файлов нагенерит на 50 гигабайт, но главное что никаких, сука, опций. Гугл, выдели миллион-другой, проспонсируй?

Продолжение: поставил Докер. Докер, понятно, тоже в arm64 все собирает, то есть хрен мне, а не ttfautohint-py.

Но! Докер можно принудить запускаться на неродной архитектуре. --platform linux/amd64. И это сработало! Только шрифт собрался за 18 минут вместо обычных 60 секунд. ВОСЕМЬНАДЦАТЬ! МИНУТ! Карл. Так что спасибо всем, кто советовал, пойду еще посмотрю.

Обмануть питон и запуститься через Rosetta 2 тоже, увы, не получилось. То есть шелл-то получилось, но питон где-то внутрях выкупает настоящую архитектуру процессора.

Пробуем собрать ttfautohint-py локально. Читаем:

DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.

pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.

Опять в PIP что-то сломается. К счастью, не сегодня, сегодня пока еще 21.2 😅

Процесс идет, не хватает bison. Это гнушный парсер-генератор из 90-х. Идет аж в составе XCode. Нужен 2.5+, а в XCode только 2.3 2006 года. Работает — не трогай.

К моему счастью, bison нашелся в brew! Вот только zsh его не подхватил. И из .zshenv не подхватил. Почему? Потому что у zsh есть еще четыре (!) конфига, которые исполняются после .zshenv. И затирают твои настройки, мда.

Окей, пишем ТОТ ЖЕ САМЫЙ $PATH в ~/.zprofile, вроде работает. Ура! ttfautohint-py наконец собран. Поверить не могу. Что дальше?

Дальше из ниоткуда выскакивает skia-pathops. Нет, говорит, колеса.

Ну, Skia я знаю, тот еще пепелац на двух тыщ сиплюсплюсных исходников (не преувеличение). А че не собирается? А вот:

New python executable in .../pip-install-64pexhpq/.../build/temp.macosx-11-arm64-3.9/src/cpp/skia-builder/skia/venv2/bin/python

ERROR: The executable .../pip-install-64pexhpq/.../build/temp.macosx-11-arm64-3.9/src/cpp/skia-builder/skia/venv2/bin/python is not functioning

ERROR: It thinks sys.prefix is '.../pip-install-64pexhpq/...' (should be u'...-pathops_b27a67e8ecbc45de8eb5b7954cb8d084/build/temp/...-arm64-3.9/src/cpp/skia-builder/skia/venv2')

ERROR: virtualenv is not compatible with this system or executable

То есть, внимание, внутри одного питона запустисля другой питон, причем второй, и он «думает», что где-то не там оказался, а наружний питон его «анализирует». «Not functioning». «It thinks». Thinks, блин!!

Решаю помочь ему, починив pip2 заранее. Это тоже нетривиально, потому что sudo python2 -m easy_install pip падает с

Best match: pip 21.2.3
...
    def read(rel_path: str) -> str:
                     ^
SyntaxError: invalid syntax

То есть Питон 2 нашел версию для Питон 3 и не осилил синтаксис. Тут, ребята, урок, что совместимость должна быть не только обратная, но и прямая, то есть на будущее.

Гуглим последнюю совместимую версию, ставим. Для меня-то оно заработало, а для skia-pathops нет. Видимо, кто-то внутри дергает python или pip без цифры 2, получает третий питон и пиши пропало. Что тоже намекает, как делать миграцию, да? Молча подменять старое новым — путь к страданиям.

Но зато я нахожу опцию BUILD_SKIA_FROM_SOURCE=0, которая позволяет подложить уже собранную Skia! И, по совершенно невероятному стечению обстоятельств, такая у меня как раз есть! По работе! Собрать ее заняло не один день, вот бы сейчас я встрял.

И... это сработало! Я, конечно, получил полный экран депрекейшн ворнингов, но... это сработало!

Запускаем time ./script/build и... вуаля! Через каких-то 77 секунд (а не 18 минут) получаем свеженькие ttf.

Вот так вот я провел почти все воскресенье. Приключения в мире людей, которые не стесняются импортировать чужие библиотеки. Как говорится, хочешь сделать что-то хорошо — делай это сам.

И если у вас еще остались иллюзии, что то что мы тут с вами сегодня пишем, другие люди смогут запустить через 50 лет, то ха! Даже через 10 не смогут.

После приключений с Питоном я задумался: а как вообще писать код, чтобы его можно было запустить через 50 лет? Только нормально, без геморроя и черной магии.

Во-первых, людям верить нельзя. Это основополагающий принцип. Работает то, что жестко энфорсится машиной, исключения не работают, соглашения не работают. В Java нельзя использовать private или sun.misc, но если очень хочется, то можно — всё, это сразу часть публичного АПИ. Minor версия в SemVer должна быть совместима по АПИ, но если нет, то коллеги застыдят? Всё, единственный вариант — считать каждую минорную версию уникальной и несовместимой. На маленьких масштабах соглашения работают, на 50 лет — уже нет.

Во-вторых, очевидно, нельзя ничего удалять. Leftpad помните? Слава богу, что бэкапы были. В этом смысле гитхаб как репозиторий меня напрягает — да, git почти иммутабельный. Но почти. При желании можно и удалять ветки, и двигать теги, да и вообще репу удалить. Обычно этого не происходит, но это соглашение, а соглашения что? Правильно, не работают.

В-третьих, менять in place тоже нельзя. То есть нельзя пофиксить багу, бампнуть минорную версию и сказать, что она точно такая же. У меня до сих пор холодок от систем, где можно указывать диапазоны зависимостей. Еще очень люблю, когда системные библиотеки подключаются динамически: давайте возьмем libfreetype.so, авось примерно нам подойдет. Так мило и наивно, ми-ми-ми.

Как же исправлять ошибки и развиваться, если менять код нельзя? Очень просто: у КАЖДОЙ версии должен быть свой уникальный неймспейс. Да, даже у минорных. И они должны уметь сосуществовать в рамках одной программы.

В-четвертых, duck typing. Совместимость должна проверяться по форме, а не по названию. OrderV2 должен подходить туда, где подходит OrderV1, пока у него есть тот же набор полей. А иначе пофиксил микробагу и все, изобретай весь мир заново. Не полетит. Позднее динамическое связывание — единственный способ future proof-а.

В-пятых, все входы программы жестко фиксировать. Это я на C/C++ библиотеки смотрю, которые можно собрать с разными define-ами. И если например подключаешь динамическую библиотеку, тебе мало иметь от нее header, надо еще угадать, какие define-ы были включены. Reproducible builds, причем жестко, до последнего байта.

В-шестых, опции в сборке противопоказаны. Идеальный билд/запуск должен работать как «кинул в котел этот файл, этот, этот и оно само разобралось и все сделало». Если хоть что-то сверх этого, хоть малейшая толика свободы, то все, пиши пропало. Разброд и шатания, которые на масштабе в 50 лет похоронят все что можно. Да, это терпимо для одной программы, но совершенно невыносимо, когда тебе надо собрать десять-сто-тысячу.

В-седьмых, вся вообще инфраструктура должна быть декларативной. Потому что семантика. Если в конфиге написано: исходники в папке src, то понятно, на что компилятор натравливать, но также понятно, например, как приделать linter. А если в билде написано «возьми все файлы из src и натрави на них компилятор», то с этим особо ничего больше не сделать, кроме как непосредственно исполнить. Декларатив выживает, потому что с ним можно работать по-разному, а за 50 лет точно захочется.

В-восьмых, жесткая унификация и автоматизация. Человеческое вмешательноство недопустимо ни на какой стадии сборки/запуска, просто потому что оно а) протухает со временем (человек забил/ушел/умер, экспертиза потерялась) и б) не масштабируется.

В-девятых, про версии языка. Тут либо жесткая, брутальная обратная совместимость, либо несколько версий языка должны уметь сосуществовать. ХЗ, можно ли это устроить.

В-десятых, про хранение. Хранить только в исходниках, иначе протухнет. Потому что за 50 лет может и проц новый выйти, и еще что-то. В общем-то, все предыдущие пункты про вот это, как сделать так, чтобы хранение в исходниках работало на серьезных машстабах. Отсюда, кстати, следует полный опен-сорс: бинарники не сработают, обфускация не сработает.

Такие вот мысли. Пойду дальше мечтать.

Когда я учился в универе на программиста, лет так 20 назад, у нас был курс ООП. И вот препод читает нам лекцию, что бывает инкапсуляция, полиморфизм, и тут натыкается на какой-то термин, название которого существовало на тот момент только на английском. И произносит такую фразу: «Как это по-русски называть я не знаю, область новая, русский словарь еще не устоялся, __надо будет им как-нибудь заняться__».

И тут у меня мир перевернулся немножечко. Ну то есть процесс обучения so far был такой, что есть некий корпус знаний, а лекторы его нам пересказывают. Типа, мы изучаем статичный мир.

А тут лектор—обычный такой программист, практикующий, своя айти фирма, живет рядом с нами, бесконечно крутой для нас тогда, но тем не менее в пределах достижимого: обедает в тех же столовых, учился когда-то в том же универе, ну может лет на 10 нас старше.

И он, получается, в том числе лично создает тот самый мир, в который нам предстоит влиться. И мир-то не статичный, а меняется прямо сейчас, пока мы скучаем на лекциях.

И эта разница в мировоззрениях преследует меня до сих пор, особенно в дискуссиях в интернете. Одни видят мир программирования как что-то статичное: вот нам дан Ruby on Rails, например, он такой, какой есть, его можно изучать, его можно (и нужно) использовать, и это в общем-то все. Рассуждения про то, чего там не хватает, или как надо было бы правильно его устроить, в рамках такой модели кажутся беспочвенными, примерно как рассуждать, что было бы, если бы не было налогов или существовал магнитный монополь. В лучшем случае можно обсуждать, какие еще библиотеки уже существуют и можно взять прямо сейчас. На месте RoR мог бы оказаться кто угодно, конечно: Нода, или C++, или Хаскель, или даже Win API.

Другой способ смотреть на мир в том, что он создается точно такими же программистами, как и мы, постоянно, прямо сейчас. И он действительно создается, ничего еще не решено, ничего не устаканилось, все меняется, все под вопросом. Есть люди, которые пишут новые библиотеки, есть люди, которые пишут новые фреймворки, новые игровые движки, новые базы данных, новые языки, да даже операционки. Они же не с неба на нас упали. И это ВСЕ в пределах достижимого, и ВЕЗДЕ есть потенциал для улучшения. Лично для меня это самая интересная часть профессии: двигать статус кво дальше, находить проблемы и потенциал для улучшения. По возможности на практике, но чаще даже просто на словах.

А проблема, собственно, что людям из этих двух категорий, как правило, сложно друг друга понять. «Некогда думать, делать надо», «зачем обсуждать то, чего нет» с одной стороны; и «все плохо, никто не умеет программировать, как же так получается, индустрия в жопе» с другой.

Ну, в общем, это моя наивная попытка чуть улучшить ситуацию, объяснив, что происходит. Ну и немножко сформировать ожидания, чтобы было понятно, что мы тут обсуждаем и почему именно так. Продолжайте мечтать!