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

Чем больше у вас в проекте полиморфизма (который не надо путать с генериками), тем больше у вас будет glue code (это тёмная материя программного обеспечения, которая в значительной степени невидима, и мы знаем о ней очень мало :).

Вообще, сила системы типов абсолютна: порядок всегда бьёт класс.

Забудьте про любые "вычисления" на уровне значений, пока не сформируете формальную унифицированную схему предметной области (как в ООП это делать например, поясняю на треке по ООАП). Другое дело, что хорошо бы добавлять на уровне типов семантические аннотации и разумное количество полиморфизма/наследования, но только для уточнения такой схемы.

Итак, идите и пишите правильный код, и да пребудет с вами Сила Куба Барендрехта! :)

P.S. Лет шесть назад кстати я писал об этом, вот думаю, не вернуться ли к тем планам? Все остальные курсы для Школы, которые хотел, уже сделаны.

...Вы сможете предлагать уникальный сервис, где вообще нету конкурентов -- разработку мощных языков программирования (верифицированных!) под конкретные ниши ML, с доказательством корректности кода. ...Совсем прозаическое -- что-то хотя бы на уровне System F для 1C :)
...Вы встанете вровень с Джеймсом Гослингом и Ван Россумом, Аланом Кэем и Андерсом Хейлсбергом, Юкихиро Мацумото и Грейдоном Хоаром. Это проект саморазвития даже не на одну жизнь, а на многие жизни вперёд.
...Ну и в любом случае, вы научитесь мыслить в программировании так, как никто больше практически, ну может несколько сотен человек во всём мире. Это объективно самый программистский топ.

"В правоохранительных органах ТАСС сообщили, что сбой в базах ГИБДД произошел по стране в связи с переходом на новое программное обеспечение..."

Совершенно не удивлён, и дальше, по мере роста объёмов кода, будет только хуже.

Азы программной инженерии? PMBoK? SMBoK?
Хотя бы CI/CD на студенческом уровне?
Нет, не слышали.

Я не зря сделал это девизом Школы :)
"Why the fuck do we let people that have no computer science backgrounds write code? Unacceptable!"

В США нельзя получить достаточно серьёзный гос- или оборонный ИТ-заказ, если подрядчик не сертифицирован хотя бы по 3-му (из 5) уровню модели зрелости программных процессов CMM Карнеги-Меллона, много об этом писал.

В конце 90-х одна московская контора (сотни программистов работали по оффшорным подрядам) прошла эту сертификацию на 4 (из Америки к ним приезжал CMM-гуру), я тогда большой материал об этом писал. Ну и ISO 9001 где-то рядом. Они действительно серьёзно работали над рабочими процессами, покупали например аналитические отчёты Cutter -- 2-3 странички стоили 300-400 долларов, мне их босс по дружески сканировал, и я потом классные статьи писал по эксклюзивной инфе 😎

=

Но для подобной сертификации нужна действительно независимая организация, с гарантированно неангажированными экспертами, а где же таковых в России найти? )))

Эта мания с тёмным режимом в вашей IDE и ваших редакторах должна наконец прекратиться! :)

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

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

Я давно ещё писал, почему подсветка синтаксиса -- вообще зло.

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

Лучшие книги и курсы для программистов -- это не те, которые вы читаете/проходите в начале своей карьеры. Это те, которые вы начинаете ценить лет через пять.

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

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

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

Как правильно? Объяснять фундаментальные принципы, универсальные базовые строительные блоки, и позволить вам самостоятельно разбираться в деталях.

Хардкорное кодирование -- это когда допускается открыть в браузере только одну вкладку.

Дам пацанам бесплатные советы :)

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

Почитать эту статью, обратиться к автору,
ну и действительно, попробовать самим написать на плюсах Clickhouse UDF/UDAF.

Можно также поэкспериментировать с Presto или Spark, они тоже с регэкспами работают. Druid, Kylin...

Да, но даже 3rps не тянет :) Когда архитектурная ошибка была сделана исходно стратегически, поздняк метаться :)

P.S.1. Как тут не вспомнить разработку IBM IMS/DB в 1970-х, когда программисты говорили: "Мы ненавидим сложность, она почти всегда ненужная. Мы можем легко и просто хранить данные в плоских файлах, организованных в иерархию. Просто скажите нам ваши запросы, прежде чем мы начнём работать над дизайном схемы БД".

P.S.2. Ну и вообще-то любая аналитическая БД по дефолту подразумевает быстрое чтение и тормоза на запись. Тут уж либо OLAP, либо OLTP :)

Однажды я проработал ~12 часов, причём за это время я:

1. Не написал ни одной строчки кода.
2. Не набрал (и не написал) ни одного символа, связанного с работой.
3. Не читал и не слушал ничего связанного с работой.
4. Ни с кем не разговаривал ни о чём, связанном с работой.

Тем не менее я упорно трудился и добился немалых успехов.

Прежде чем ныть, что очередной ютубер "неправильно прочитал документацию" по вашему любимому языку/библиотеке (например, вот так :), попробуйте сами написать сотни строк проекта с нуля в прямом эфире перед сотнями зрителей, развлекая их (а некоторые целенаправленно пытаются отвлечь вас в чате:). Да, и всё это бесплатно.

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

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

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

Но дело в том, что, например, вы можете нотариально заверить всё своё личное имущество, нажитое за долгие годы непосильным трудом, и заставить потом подругу подписать брачный договор, в котором (как в лицензии) говорится, что ни при каких условиях при разводе она не сможет претендовать на ваше всё, и она такая подписывает, нежно улыбаясь... А через год ставит вам рога, разводится, и -- сюрприз! -- суду совершенно пофиг на вашу лицензию ваш брачный договор, и 50% всего вашего имущества уходит ей.

Поэтому, предлагаю посоздавать побольше прецедентных случаев.

Сегодня в Москве несколько часов не работал мтс-овский петушеринг:
"У нас прилег сервис, мы видим проблему и стараемся решить её как можно быстрее."
(раз используете "ё", так уж будьте последовательны, ставьте везде)

Причин три:
1) либо условный "джун" задеплоил что-то не то: виноват сеньор, не сделавший code review;
2) либо накосячили dev/sys - админы: что-то не то сконфигурировали, что-то "само" апдейтнулось криво, сервак сгорел, забыли хостинг оплатить... -- виноват тимлид, не настроивший рабочие процессы;
3) либо хакеры -- виноват безопасник (а если такого нету, то CTO).

"Совершенно не удивлён, и дальше, по мере роста объёмов кода, будет только хуже."

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

Важнейший навык в разработке качественного программного обеспечения -- глубокое понимание домена (предметной области). Если вы плохо понимаете задачу, ваша система, скорее всего, будет представлять собой хаотичный набор всяческих use cases, связанных условными операторами, выполненный в архитектуре "говнокод".

Иногда я бываю в сильной растерянности... С одной стороны, для СильныхИдей хотелось бы готовить материалы примерно такого уровня:
"Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire"
We develop a calculus for lazy functional programming based on recursion operators associated with data type denitions. For these operators we derive various algebraic laws that are useful in deriving and manipulating programs.

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

Вот вчера курсант рассказал:
Готовлю аргументацию по внедрению подхода описания тестов через аннотацию DisplayName. Не ожидал, что простое и понятное предложение использовать достаточно простую аннотацию для повышения ясности теста встретит сопротивление, поэтому приходится готовить защиту для этого.

Совершенно не удивлён, и дальше, по мере роста объёмов кода, будет только хуже.

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

Ну и как бы выглядит довольно фантастически.

За 500т? Если ты действительно на такое способен, так в США это на удалёнке 2-3 сотни тысяч долларов (на руки) в год минимум.

Ставь китика, если реально имеешь

-- опыт управления командой разработчиков
-- опыт разработки архитектуры приложений с учетом масштабируемости, производительности и совместимости с различными устройствами
-- опыт разработки мобильных клиентов на Kotlin и Swift и в серверах Node.js и Unreal

Ну, с Днём Науки! (в СССР он был третьим воскресеньем апреля)

Гипотеза лингвистической относительности Сепира-Уорфа однозначно верна для многих людей и в программировании: языковая структура формирует мышление человека и способ познания им реальности мира.

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

Да знаю я отлично, как это работает. Это просто то, на что я жалуюсь. Я говорю, что это запутанно и неинтуитивно, и подход ФП всегда лучше.

Но мне в ответ дают ещё больше объяснений, как это работает "правильно" )))

Да... Я знаю. И я говорю снова и снова, что то, как это работает в ООП, плохо и тупо. Мне уже не кажется -- я знаю точно, что люди изучают всё программирование на том языке, на котором они его изучают. Понимаете, о чём я? И в итоге они воспринимают подход этого языка как единственно возможный. Я пытаюсь пофиксить этот когнитивный баг с помощью треков по вычислительным моделям и ФП.

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

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

=

Программирование -- это мышление + синтаксис. Может быть, 90% мышления и 10% синтаксиса. Если синтаксис можно автоматизировать, то научить правильному мышлению можно только того, кто умеет думать.

Llama 3 теперь бесплатно доступна оффлайн, в удобной оболочке =>
LM Studio
+ много разных моделек на выбор.
5 гиг памяти, и на среднем компе почти в реальном времени пишет код. Потестировал её на Python, TypeScript, C# и F#, ну получше чем ChatGPT и даже Cloude.
Можно через API локально сервер поднять, дообучать модель под свои нужды, и всё такое. Очень доволен.