Ораклу зачёт: классно троллит мировое ИТ )))

JEP 445: Unnamed Classes and Instance Main Methods

Отношения между интерфейсами и реализациями (между типами модулей и самими модулями) -- это отношения "многие ко многим". Одно из направлений этого отношения общеизвестно: интерфейс может иметь несколько реализаций. Но другое направление не менее важно, но гораздо менее оценено: реализации удовлетворяют нескольким интерфейсам.

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

Когда я узнал, что Роберт Харпер (один из святых computer science, написавший кучу курсов для CMU) выгнал Java из учебных планов, настояв на преподавании OCaml и SML (семантику которых он описал формально), то сперва подумал, что он просто выдумывает причины, чтобы навязать свой любимый язык всем остальным. Теперь же я уверен, что он абсолютно прав, и поэтому в частности прикладной курс по ФП сделал на F#.

Java просто откровенно плоха в предоставлении нескольких интерфейсов для одной и той же реализации. Харпер пытался научить этому модульному принципу в Java в течение многих лет и потерпел неудачу. Сейчас я и сам иногда с этим сталкиваюсь, когда прошу курсантов привести примеры одной реализации с несколькими интерфейсами, и в 80% случаев получаю пример одного интерфейса с несколькими реализациями.

=

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

Забавная вещь происходит, когда система декомпозируется на модули, а затем позволяет их комбинировать (исчисление модулей в OCaml). Если это делать правильно, то в проекте появляется новая сущность, отдельная от системы и более долговечная, чем сама система: интерфейс.

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

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

Причём скиллы композиции и декомпозиции, конечно, ортогональны, и изучать их надо осознанно по отдельности.

В продолжение интерфейсов и реализаций. Например, программисты на OCaml могут писать модули, которые не привязаны к какой-либо конкретной реализации своих зависимостей. Общий термин для этого -- "динамическая архитектура", и большинство не функциональных языков поддерживают это весьма плохо. Как правило, они полагаются на #ifdef-ы -- или, что ещё хуже, на систему сборки.

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

Это сейчас такой прям модный-модный мем, что только под эту фотку не придумывают. Мой вариант: "за 3499 долларов, математики смогут наконец визуализировать многомерные пространства".

Однако вот более реалистичная версия...

Хорошее:

The C4 model — misconceptions, misuses, and mistakes... includes notation, abstraction levels (number of & naming), abstraction vs organisation, ADRs, DDD, event modeling, microservices, message-based architectures, and more.

От автора учебника "Software Architecture for Developers"

Его же "The lost art of software design"

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

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

Ну, это только потому, что вы не понимаете, как это работает :) Разберитесь, пройдите курсы по ФП (а для начала просто активно применяйте в своём коде map/reduce), и будете получать от использования функций высших порядков огромное удовольствие.

В продолжение про интерфейсы.

Например, мы вполне можем убрать из интерфейса стека специальные слова push и pop, и назвать эти операции просто add и remove. Потом мы можем создать интерфейс очереди, также используя операции add и remove. Когда я делал курсы по алгоритмам, сразу отметил, насколько похожи интерфейсы классов стека и очереди. Фактически, если заменить push и pop на add и remove, мы получим идентичный интерфейс! Не знаю, хорошо это или плохо, но люди, которые хотят объединить эти два интерфейса, встречаются примерно так же часто, как люди, которые требуют, чтобы их обслужили первыми, потому что они вошли в очередь последними.

Это показывает, что когда мы думаем об интерфейсах, мы думаем не только о том, содержит ли модуль функции с определёнными сигнатурами. Мы также думаем о спецификации -- о том, какого именно поведения мы ожидаем от этих функций. Возможно, рядом с функцией pop() есть комментарий, говорящий, что она обратна функции push(). Этот факт можно считать частью типа модуля в той же мере, что и сами сигнатуры функций, потому что знание этого факта необходимо для использования модуля! В идеале его надо сделать "физической" частью типа.

Существует несколько языков с достаточно мощными системами типов, чтобы выразить связь между push() и pop() -- например, Coq, Agda, Idris. Я могу показать вам, как это выглядит на любом из них, но к большому сожалению это совсем непрактично. Поэтому пока основное решение -- материалы из СильныхИдей, где я постоянно поясняю, как правильно думать на более высоком логическом уровне -- абстракциями, которые в обычном коде отсутствуют по определению.

Несколько потоков? Давайте запустим их в голове последовательно.

Иммутабельное состояние? В наших головах оно постоянно изменяется и читается атомарно.

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

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

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

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

И затем переделайте это так, чтобы оно стало проще. Вот этот способ.

Правильнее сегодня бояться не гонки суперинтеллектов AI, а гонки человеков, кто из них больший идиот...

(Так-то AI уже давно бы с нами покончил, если бы не python packaging...)

Как человек, который занимается архитектурными темами десятилетия, я совершенно уверен, что в ближайшее время нет и не будет никакого AI, способного разумно рассуждать на темы software/system design.

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

В прошлом году американские кадровые ИТ-консультанты стали жаловаться на существенное снижение спроса со стороны разработчиков на их услуги -- причём впервые за 10+ лет, раньше постоянно был регулярный рост (даже, можно сказать, бум спроса на сеньоров в крупные компании). Началось падение ещё весной 2022-го, задолго до явления ChatGPT. С чего бы это? )))

Статья в Computer World, где поясняются причины и приводится весьма обширная статистика по сокращениям.

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

На картинке: как снижался интерес программистов к помощи карьерных консультантов (преимущественно поиск новой работы), а доходы этих консультантов упали на 70-90%. Они, кстати, берут приличный процент от того повышения зарплаты, которое получает клиент (а моя помощь курсантам по карьере бесплатна).

Кто поклонник "Начала" Нолана и в целом многоуровневых фильмов "про подсознание", наконец появился его духовный наследник -- "Гипнотик". Очень хороший, рекомендую, многомерная реальность (только уже не во снах), местами в духе "Мистера Робота". Смотреть надо внимательно, и финал неплохой (только досмотрите после финальных титров, не пропустите).

Не знаю, почему у нас подобные фильмы не снимают? "Гипнотик" не особо бюджетный, а тема очень ходовая. Снять что-нибудь подобное, но пооригинальнее, чтобы например в финале, как во "Внутри Лапенко", оказалось, что вообще всё происходящее было шизой, как у Инженера или Эллиота.

P.S. Ёлки, не в тот канал отправил )))

В России же ситуация на рынке труда такая, что джуниоры уже довольно давно особо никому не нужны, и спрос на высокооплачиваемых сеньоров ощутимо снизился (компании не хотят вкладываться в нестабильной обстановке; причём и в США спрос упал сильнее всего именно на них), а вот крепкие миддлы чувствуют себя прекрасно, и платят им хорошо, и компании предпочитают растить сеньоров из своих проверенных кадров.

Дело в том, что книги курсы по карьере (да и не только) хороши максимум на 80%, однако важнее всего внедрять некоторую методологию развития карьеры для конкретной ситуации конкретного человека, а это возможно только в индивидуальном порядке. Мне, кстати, особо интересно помогать ребятам, у которых в плане карьеры сложилась самая сложная ситуация, какая только могла сложиться :) Потому что в таких ситуациях и я сам здорово прокачиваюсь как тренер. Типичная болезненная ситуация: хороший миддл получил 1-2 оффера, и начинает паниковать и метаться ))) принять или нет? а если принять, как не продешевить по зарплате?

Не удаётся в сложных ситуация помогать в основном джуниорам без опыта, ну тут я бессилен... Вот такой совет начинающим: ставьте себе 2 года опыта, и продумайте хорошую легенду, как/где вы их получили, договоритесь с знакомыми айтишниками.
Да и не нужна особо моя помощь джунам, потому что определённая свобода в переговорах появляется в основном на высоких окладах.

Главное ограничение индивидуальной помощи в том, что она не масштабируется. И при этом хочется помочь как можно большему числу людей, хм. (Уловка-22)

Когда пишешь на языках с динамической типизацией )))

(Я действительно не понимаю, почему люди отказываются от преимуществ, предоставляемых системой типов)

"Intelligent Machines and Idiotic Humans: A Startup Story"
(идеи для AI-стартапов)

Серия 8. Мета-автоматизация.

8 направлений, по которым сегодня можно неплохо использовать ChatGPT в помощь программистам.

1. Использование в качестве помощника/ментора в обучении программированию. Для начинающих очень хорошо, решения несложных задачек подробно объясняются.
2. Мозговой штурм.
3. Генерация шаблонного кода под вашу задачу (с которым потом всё же придётся поразбираться, как и с ответами на SO). Полезно попутно просить сразу написать тесты к решению (возможно, со 100% покрытием).
4. Code review.
5. Написание документации к коду.
6. Аннотации данных для машинного обучения.
7. Перевод кода с одного языка на другой.
8. SQL-запросы к БД. Только надо подробно объяснить схему базы, зато можно также, например, просить построить визуальные представления (мапы, графы...).

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

"World Wide Web получился ровно таким, которого мы всеми силами старались избежать: отсутствие необрываемых ссылок, постоянно меняющиеся или отсутствующие ссылки, цитаты, которые вы не можете отследить до оригинала, отсутствие версионного контроля и контроля за правами..."
— Ted Nelson, изобретатель гипертекста, легендарный ИТ-пророк, особо недолюбливающий HTML/XML и браузеры :)

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

"Generative AI is the source of digital effluence that is releasing massive quantities of textual shit, leaving a stain on everything it touches. As several others have observed, this moment in time delineates the Web not unlike nuclear testing did for low background steel."
-- Гради Буч, автор UML, IBM Research

Теория типов -- это наука о том, как взять всю красоту программирования и сжать её до нескольких (почти никому не понятных) строк с математическими буковками. Или же, теория типов -- это искусство обнаружения того, как тонкие аспекты математических определений приводят к появлению новых странных универсумов программирования.