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

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

Начинающие часто делают такую ошибку: надо написать функцию, возвращающую сумму значений из набора файлов, а если там возникнет любая ошибка (от отсутствия файла до записанного в него нечислового значения), то что с ней делать? выбрасывать своё исключение? что-то "ошибочное" (null/None) возвращать в качестве результата?

Отсюда мы плавно переходим к фабрикам и монадам :)

Но есть нюанс: что делать, если некоторые данные в конструкторе недоступны сразу, и должны быть получены с помощью асинхронного вызова (что само по себе не здорово, но вот такой легаси-код вам достался)?

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

Расскажу дальше чуть подробнее.

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

Вообще, это большая тема, насколько активно и как правильно использовать конструкторы.

Универсального ответа, что делать с исключением в конструкторе, у меня нету :) Если язык достаточно продвинутый, на сегодня в мэйнстриме это наверное только TypeScript (что немудрено, его автор Хейлсберг ранее придумал Delphi и C#), тогда можно например задать тип конструктора как
Dwarf | ValidationException

Если же в случае ошибки вы хотите возвращать null, то тогда используйте фабричный метод, который выдаст Dwarf | null

В общем случае, проблема не в поведении времени выполнения, а в том, насколько соответствующий исходный код типизирован и выразителен.
В Python например вы не используете new, и конструктор там выглядит как функция, что очень здорово :)

dwarf = Dwarf()

И как раз за счёт своей гибкости Python позволяет (как и TS) наглядно записывать типы-объединения (PEP 604), поэтому мы можем конструктор и фабричный метод типизировать совершенно по-разному, и это просто великолепно.

Dwarf | None
Self | None

Тут можно строить очень интересные паттерны, сравнимые с продвинутыми фабричными методами, в том числе "умные конструкторы", которые скрывают недостатки исходного конструктора и принуждают использовать более тонкие подходы. Python, Kotlin, Swift, Go, Rust -- список нонконформистов можно продолжать. Например, в Kotlin есть extension methods, которые отнюдь не синтаксический сахар или эквивалент статическим методам Java. Наверно, можно даже сказать, что это в некотором смысле тайп-классы из ФП, или монады из LINQ...

Ладно, больше не буду морочить вам голову :)

Ну, с Днём Программиста!

Хорошая новость-1, что пока цены для новеньких я повышать не планирую (а кто уже занимается, схема цен замораживается навсегда на момент записи на мои курсы),
однако, все тренды идут к этому :) Я жду, например, 110 к октябрю.
Куда ещё теперь вкладывать эти бессмысленные бумажки, как не в собственное развитие?

Хорошая новость-2, что AI научился писать промпты для AI лучше людей.

Процессы самосовершенствования искусственного интеллекта ускоряются в геометрической прогрессии; обратный отсчёт пошёл на месяцы? :)

По поводу валидации на сервере.

В Dwarf Fortress борода дварфа каждый день увеличивается на 1 единицу длины. Фронтенд запросом API получил JSON, увеличил поле beard на +1 и отправил его обратно. Но по правилам длина бороды не может превышать 1000 единиц. Где её контролировать?

Конечно, на сервере валидация обязательно нужна, но лучше всего, чтобы она была везде.
Что легче: добавить доп.проверку бороды на фронте, или дополнительно парсить ответ сервера на предмет ошибки, если с бородой пошло "что-то" (что?) не так? Понятно, что магические числа вроде 1000 это совсем плохо, поэтому можно добавить запрос по конфигурационным настройкам, и т.п.

Проблема в том, что если клиент написан не на JavaScript, а на другом языке, где нету нативной поддержки JSON (без "ручной" сериализации/десериализации) -- например, это мобильное приложение, то в случае, когда на сервере структура дварфа изменится (добавится новое поле), может поломаться и и фронтенд, и серверная логика игры (например, дополнительное поле, неизвестное клиенту, всегда будет уходить из фронтенда на сервер как null).

Поэтому обычно от сервера в таких случаях требуют не менять схему API-ответа вообще, а если что-то там изменилось, следует создать новую версию и предоставлять её отдельно по другому URI, например api/dwarf/v2/123.json. Клиенты переберутся на неё постепенно (как наивно полагает тимлид :).

Да, но если API активно развивается, то не успеем мы оглянуться, как окажемся на v256, и, скорее всего, многие (если не все) из этих версий будут нуждаться в поддержке!

Как легко и просто реализовывать подобные API на сотню разных версий, не ломая фронтенд и не требуя его переделки, скоро расскажу курсантам в СильныхИдеях всем в основном паблике вк.

В конце августа 14 японских заводов Toyota остановились из-за того, что на каком-то сервере переполнился диск. Это всё, что надо знать о современном уровне system design в самых топовых компаниях.

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

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

=

-- Эй, бэкенд! Нафига вы сломали API инвентаря дварфа? Раньше JSON приходил с ключами, упорядоченными по именам.
-- Нет, это не было гарантировано API, не стоит на это полагаться.
-- Ну и что, зато это разумная и удобная для фронтенда вещь, на которую мы рассчитываем, и её изменение -- это нарушение!

=

"Since the release of Go 1.0, the runtime has randomized map iteration order. Programmers had begun to rely on the stable iteration order of early versions of Go, which varied between implementations, leading to portability bugs."

В инженерии есть такой принцип робастности/надёжности Постела:
"для того, чтобы сделать надежный протокол, нужно как можно точнее придерживаться спецификаций, и в то же время «прощать» тех партнеров, кто не следует спецификациям в точности. Прощать до тех пор, пока вы в состоянии понять, что они хотят сказать."

Но в программировании это прямой рецепт создания хрупкого программного обеспечения.

Когда месяцами пишешь на F#, а затем возвращаешься к C#, мозг немедленно клинит :)
Не получается нормально написать и 20 строчек работающего императивного кода.
Тут поможет книга наподобие "Functional Programming in C#", чтобы вернуться обратно к шарпу.
Но уже никак нельзя развидеть, насколько прост и элегантен фуллстек F# ...

От одного из моих лучших курсантов после задания Hard Work "3+4 важных качества хорошего кода"...

"Во-первых, мне нужно больше уделять время проектированию системы, а не написанию кода. Кол-во плохого кода не идет ни в какое сравнение с хорошим кодом (включающий все 7 свойств).
Спроектировав алгебру, корректность которой можно доказать через Z3 мне не составит написать код, логически верный.
Во-вторых, я пересмотрел свое отношение к паттернам проектирования. До сего момента я искренне не понимал, в чем заключается их польза, но вот теперь, посмотрев на все 7 свойств, на то, как я отношусь в созданию системы, то отношусь к ним как к инструментам, которые действительно могут помочь. Это звучит странно, но для меня это дАвний баг в мышлении.
В-третьих, мое мировоззрение ещё раз перевернулось относительно качество создания систем. Посмотрев свои проекты, ни один из них не соответствует идеалу, даже на текущий момент времени.
Где-то все время обманывал себя, сам того не замечая...."

Интересный тренд.
Казалось бы, как это, уходить от чистого ФП к Rust, почему? Ну, лучшая эргономика, высокая производительность, прямой и простой синтаксис + сильные статические гарантии.

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

Arial -- отличный фонт для редактора кода. Вы сохраняете кучу горизонтального пространства.

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

Инсайдеры меты заявляют, что они намерены открыть исходный код каждой модели вплоть до AGI, так что никакие safe API не помешают злодеям. Эксперты по биооружию полагают, что мы уже всего в 1-3 годах от появления моделей "SuperEbolaGPT" (на основе llama2), которые за тысячу долларов и несколько часов в обход всех защит пошагово проведут до "результата", с которым пока невероятно успешно справляются лишь уиллисы и стэтхемы в боевиках...

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

Затем вы получаете электронное письмо или сообщение в мессенджерах или линкедите с оффером, который кажется слишком хорошим, чтобы быть правдой: у рекрутера есть для вас отличная вакансия, и вы смотритесь как идеальный кандидат для этой роли!

Вы позанимались на моём курсе карьеры, поэтому знаете, что всегда должны рассматривать все доступные вам варианты. Вы договариваетесь с рекрутером о звонке, выясняете подробности вакансии -- звучит довольно заманчиво! -- и даёте добро на то, чтобы вас познакомили с компанией.

А потом (я много раз предупреждал!) всё становится, хм, немного странным...

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

Плюсисты, вы сегодня действительно так пишете? Это круто ) Это уже какой-то другой мир. Реально подумываю о курсе по type-level design на C++.

Правда, даже продвинутые гуру cs говорят, что такое умение пока никому не дано :) Но почему бы не попробовать?
(Возьмусь за 1 миллион рублей :)

P.S. темплейты плюсов тьюринг-полные...

"Не заблуждайтесь: ИИ - это инопланетный интеллект...

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

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

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

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

Future of Life Institute

Все порядочные университеты обязательно рассказывают первокурсникам о структурном программировании Эдсгера Дейкстры и его легендарной статье 1968-го года "Доводы против оператора goto" (на эту тему в паблике скоро будет материал).
Но когда Эдсгера в последние годы его жизни (конец 1990-х) спрашивали про эту статью, он отвечал в таком духе:

Ребята! это было в Голландии в 1960-е, я уже не помню, что тогда курил. Я мечтал вместе с хиппи, что любовь и мир будут воплощаться в элегантный код, в поэзию программирования, что её будут придумывать длинноволосые парни в свитерах с пацифистскими эмблемами.
Ха-ха! А сегодня мы все винтики на галерах, добавляющие патч за патчем в шаткую структуру кода, чтобы поскорее выпустить новый коммерческий продукт.

В начале этого года ИТ-бизнес по всему миру просто... остановился (я писал об этом провале спроса на программистов чуть ли не в 10 раз). Больше никаких предложений о работе. Больше никаких зацепок. Телефон перестал звонить.

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

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

=

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

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

=

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

Вот какие разработчики сегодня ценятся особо высоко:
-- понимающие специфику бизнеса/дела/области..., которое автоматизируют;
-- способные выдавать результат, а не просто высиживать часы;
-- продуктивно работать в команде и на команду (очень шаблонно, но ведь важно!)
-- всегда доводить дело до конца.