Если вы сейчас пишете на C#, я думаю, что до конца этого десятилетия вам придётся переквалифицироваться на F#. Однажды вы проснётесь, и все джуниоры будут со смехом смотреть на вас, когда вы начнёте писать на C#. Это просто больше не будет круто.

А если вы думаете, куда вам дальше переходить с Java, C++, да и даже с сишечки? тоже на F# / OCaml 💯 (ну ладно, ещё Elixir — и никаких Go)

В июне сами знаете Кто потерял 7000 папищеков из-за сбоя или ошибки в боте. А это 80 тыс. долл. ежемесячно.

В программной инженерии это всё давным-давно изучено, куча рекомендаций и стандартов (например, ITIL, где чётко сформулировано понятие "повторяющиеся инциденты"). Но вы думаете, хоть кто-то в мире заботится о страховке от подобного на будущее? Технический долг? Петля негативной обратной связи? Организационная инертность? Нет, не слышали.

Более того, Boeing из-за непофикшенного бага в MCAS потеряли 20 млрд. долл., а выход нашли в убийствах инсайдеров :)

Microsoft Update 1809 просто удаляла ваши файлы, что повторилось через джва года в Update 2004 и в многомиллиардное удаление из них долларов.

Facebook из-за багов с приватностью в "View As" и др. потеряла 5 млрд. долл., и т.д.

Достаточно нанять одного спеца за $300k/s $5k/m, чтобы он обеспечил надёжность сервиса 99,999983% , как у Дурова.

Но невозможно объяснить это эффективным менеджерам, ибо "а чего это он будет получать такие деньжищи за ничегонеделание"...

Шуточки от AI:

- Что говорит программист на PHP, когда видит функцию, принимающую другую функцию в качестве параметра?
- Это так же нереально, как и нормальный session_start() без предупреждений!

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

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

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

PHP-код: "У нас есть глобальные переменные и побочные эффекты."
Финансовый советник: "А у нас есть скрытые комиссии и неучтенные налоги."

=

Вспомнилось, в тему: Lambda calculus interpreter in PHP.

Лучший созвон -- которого не было.

Поясняет Дэн Кеннеди ("Жёсткий тайм-менеджмент"):

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

Вся история computer science -- это использование новой абстракции поверх другой.

Всё, что вы создаёте сегодня, базируется на сотне абстракций.

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

Абстракции очень важны. Они хороши. Они нам нужны.

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

Абстракции (как и всё остальное) -- не серебряная пуля. Любая абстракция, которую вы добавляете в свой проект, представляет собой компромисс. Стоит ли абстракция того или нет, зависит от ваших целей.

Mojo is a new programming language that bridges the gap between research and production by combining the best of Python syntax with systems programming and metaprogramming.
Mojo combines the usability of Python with the performance of C, unlocking unparalleled programmability of AI hardware and extensibility of AI models.
With Mojo, you can write portable code that’s faster than C and seamlessly inter-op with the Python ecosystem.

Реально крутая вещь, рекомендую.

Пока никакие LLM-ки его не понимают, поэтому тестовый лайв-кодинг можно проводить на нём :)

Чем больше я думаю о будущем программирования в мире LLM, тем больше радуюсь за тех ребят, кто изучал в университете "бесполезную" computer science и математику. В основном только эти вечные вещи и остаются полезными на перспективу.

Сила software design заключается не в том, что он может сделать, а в том, что он не позволяет вам сделать. Полная противоположность хорошему дизайну -- современные фреймворки. Это артефакты множества плохих идей, которые предлагают вам делать "всё что угодно", но только кривыми способами.

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

Но совсем немногие программисты знают, как это делается, и где этому научиться. В моих новых курсах по software design на различных примерах я покажу это всё, и как эти методы реализуются в реальном программировании.

Если вы пишете код без спецификаций (хотя бы, сознательно учитываемых в вашей голове, на третьем логическом уровне понимания проекта, из СильныхИдей; получше -- на уровне документации/кода; лучше всего -- в формальном виде, например TLA+), то он у вас получится и не плохим, и не хорошим. Это просто будет случайный набор команд с непредсказуемым поведением.

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

На эту тему в частности в СильныхИдеях скоро будет продолжение темы контрактов, интерфейсов и абстракций: как сразу делать ПРОСТО??

(я думаю, он скорее перепутал:)

Сейчас практически все каналы по нейросеткам забиты обсуждением/сравнением нейронок, которые генерируют видео (потом музыка и изображения). То есть пока никакой пользы от подобных сервисов, кроме дофаминовых "развлекалок", нету. А вреда полно ("с вами по видеосвязи хочет поговорить мэр Москвы Сергей Собянин").

По генерации кода всё как-то стихло. В основном LLM-ки растут вширь (многие десятки разных языков, Фортран и Кобол сегодня модно добавлять :), а по качеству за этот год прогресса не видно.

Пока AI успешно развивается преимущественно в человеческую глупость.

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

При этом они ещё и других учат быть глупыми. Они говорят, что учат других, чтобы те стали умнее, получили полезные для работы знания.. но стоит взглянуть на это всё глазами святых computer science, то становится понятно, что их "учения" ведут людей далеко в сторону от истинных знаний по информатике.

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

Для нового курса по software design, для раздела "почему давно работающий код всё ещё содержит баги" подбирал подходящий пример, когда 100% покрытия тестами не даёт гарантии корректности, ибо логика может быть такой сложной, что и сам автор без поллитра не разберётся, какие там возможны критичные случаи.

Взял такой достаточно наглядный пример, как несмещённая оценка дисперсии выборки. Мы стандартно тестируем, когда размер выборки 0, null, а также на ряде типовых примеров, и покрываем все условные веточки. Однако алгоритм подразумевает деление суммы квадратов отклонений не на число элементов, а на число элементов - 1. Поэтому при размере выборки в 1 элемент код будет вылетать с исключением.

Даю конечно рекомендации, что с этим делать, как правильно рассуждать и т.п.

Если вы хотите наиболее простую систему типов, то это вероятно будут зависимые типы (когда сами типы становятся объектами первого класса).
По взрослому, это Coq, F*, Agda, Idris, Lean. Но страшно далеки они от мэйнстрима :)

Однако в питончике уже есть, в некотором смысле, завтипы, т.к. он позволяет манипулировать ими (да и ещё много-много чем) нативно.

И при желании можно вот так легко и просто реализовать dependent types в Python.

Первая моя попытка заюзать первую отечественную IDE (GigaIDE от Сбера) закончилась, пока, фейлом :)

Но я полностью на стороне Сбера (как сразу конкуренты задёргались).

А если бы даже и закопилефтили код недружественных структур, ну и что? Вы кто такие? Идите нафиг. Никакого уважения и никаких переговоров с ними вообще вести не надо, и тем более, что-то им пояснять.

Вот единственно верный ответ:

"Для этого надо и дальше искать критические уязвимости их экономик и бить по ним во всех сферах. Находить проблемы в их важнейших технологиях и беспощадно наносить удары по ним." (с)

P.S. Правильно это называть "Трофейное ПО" 😎

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

Электронный документооборот по-европейски.

Министерство образования Германии оправдывает неразглашение информации тем, что они не могут отправить по электронной почте 132-страничный pdf-файл размером 33 МБ (такой размер, потому что документ был распечатан и отсканирован).

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