Вышел очередной "супер-кодер" DeepSeek Coder V2 (236B), можно поиграться онлайн тут, даже впн не нужен. Особо ничем не впечатлил, примерно как и GPT-4o.

Просил обоих написать совсем элементарное, для начинающих с нуля: "наивный" (без эвристик) алгоритм Бойера-Мура -- так и не смогли, как ни умолял их. То КМП выдадут, то вообще за O(N*M). Ну наверное, если потратить кучу времени, можно добиться правильного ответа, но зачем тогда мне вообще такой джун-"помощник"?

Идите пока нафиг со своим AI-кодером.

В курс карьеры добавлен 87-й материал "Универсальность или специализация - 2".
Вот вопрос, который мне регулярно задают: "Как мне понять, стоит ли больше/глубже изучать текущий стек на работе, или следует добавить новые навыки в других областях? Следует ли мне идти вширь или вглубь?"
Итак, куда лучше инвестировать своё время (ваш самый ценный актив)?

В СильныеИдеи добавлен материал "93) Почему любые дефлотные параметры -- зло".
Разбираемся, как в разных языках (Python, Java, C#, F#, TypeScript) поддерживаются дефолтные параметры, какие они несут скрытые проблемы, и как их правильно готовить.

Обновлён курс "SQL для начинающих" (добавлено 14 задач с разбором по игре Dwarf Fortress). Кто его проходил, рекомендую допройти.

Однако напомню наш стратегический принцип:

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

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

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

Ну, с трудовым понедельником! 💪🏻
Приступаем к GOVNO.works

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

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

Если вы сейчас пишете на 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-программирования именно эти скиллы станут наиболее полезными и прагматичными.