С 01.01.24 правила занятий существенно обновляются; в частности, по развитию карьеры буду общаться теперь только с теми, кто работает программистом/ищет работу программистом. Кто "вырос" в тим/тех/лиды, всё, пока :) это билет в один конец.

=

Просили анонсы наших новостей и vk-постов в тг выкладывать, ок.

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

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

Если джуны толпами рвутся на вакансии без опыта (это неправильно, поясняю на курсе карьеры, что сегодня надо с этим делать -- и нет, это не (далеко не только) накрутка опыта), то толпы сеньоров также шаблонно мечтают о FAANG/МОСЯ -- но зачем? Во-первых, компаний, где вы можете заработать существенно больше в чистом виде, многие тысячи, в т.ч. и в любимой Российской Федерации, во-вторых, можно заработать программированием куда больше просто другими способами, нежели впахивать на топовых галерах.

Некоторые думают, что МОСЯ -- это такой супербонус для резюме, да нифига. Всем пофиг на то, где вы работали. Конечно, работа в Яндексе даст +5% например, но не больше. Если вы не подходите под проект, то кому какое дело, где вы там раньше работали.

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

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

Действительно крутых задачек бесконечное число, причём сегодня классические научные темы прекрасно ложатся на прикладуху. Ну например, компиляция с одного языка на другой через term rewriting. Есть классический учебник Филда и Харрисона "Функциональное программирование", который был написан в 1988 г., и все идеи того времени актуальны и сегодня -- потому что это хорошо отшлифованная математика, тут ни убавить, ни прибавить.

Или, как написать супер-блокчейн с использованием линейной темпоральной логики и реляционной модели, или SAT-солвер на conflict-driven clause learning + BDD, и т.д. и т.п...

Рабочий понедельник в разгаре! Вовсю фигачите тикеты? :)

Если вы ООП/императивный разработчик, то вам даже кофе не нужен.

Когда пишешь на Java или Python, C# или JavaScript, постоянно захлёстывает адреналин от осознания того, что любая твоя строка кода может сломаться 10 различными способами 😁

Какое ещё функциональное программирование? Нет уж, спасибо, я лучше оформлю пять уровней наследования для моего FactoriesManagerFactorySingleton, с нулл-чекингом каждые 2-3 строчки.

Знаменитый физик Эрнест Резерфорд, лауреат Нобелевской премии, в 1933-м заявил, что идея получения энергии из расщепления атома абсурдна и нелепа.
Через 12 лет американская атомная бомба уничтожила 100,000 человек в Хиросиме.

А вот как сегодня прогрессирует AI Midjourney например.

В продолжение поста про cs в прикладухе, а также про "изучайте профильную математику в контексте computer science", ребята спрашивают, а что лучше поизучать-то?

Ну тут тем множество... Для каждой задачи свой раздел. В матрице компетенций в computer science есть два трека "теория" и "математика", но это если хочется общую базу получить,

а лучше всего начать с TAPL ("Типы в языках программирования" Пирса) -- саму математику можно пропускать, просто тексты почитать уже будет здорово очень, а непонятки можно у AI уточнять. Есть также наша схожая хорошая книга "Программирование: теория типов" (Швецкий, Кудрявцева).

Теория типов это наш главный хак )

Ну и, собственно, в посте-закрепе ещё 2 года назад пояснял те самые ключевые восемь темок computer science, которые быстрее всего приведут вас к просветлению:

"Как программисту стать значительно умнее? Что изучать, как прокачивать свою квалификацию стратегически? Нужен ли вам теоркат, зависимые типы и homotopy type theory? Восемь рекомендаций, какую абстрактную вычислительную машинку надо собрать и встроить себе в голову, чтобы мозг заработал на топовом мировом уровне и вдребезги расфигачил ваш стеклянный потолок."

В частности, порекомендую книги Даниэля нашего Фридмана:
Little Typer, Little Prover и др.

EoPL конечно must have, у меня аналогичный трек "как понять в программировании всё" по вычислительным моделям.

Но для начала попробуйте осилить смешную "A Little Java, A Few Patterns" (кстати, в СильныхИдеях я много раз подчёркивал, что паттерн visitor очень крут), даже на простенькой Java крыша сразу слетит 😇 Но зато коллеги будут офигевать от вашей крутости.

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

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

Это, типа, AI сгенерировал в ответ на запрос "программист пытается социализироваться" )))

Однажды (например, пройдя большинство моих курсов и позанимавшись на hard work), вы откроете для себя правильный способ программирования: то, что придаёт всему этому смысл.

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

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

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

Однако если вы будете стабильно придерживаться первого правила Школы, то со временем изучите 50 (или 100500) других правильных способов, и, самое главное, научитесь продуктивно сочетать их с конкретной проектной задачей — и станете x1000 просветлённым, в сравнении с окружающими вас сонными бедолагами, не желающими расти в профессии...

Мой котик попробовал войти в айти, и чёт приуныл 😼

Читал статью "An algebra for distributed Big Data analytics", хотел в одном из курсов уточнить, в ней утверждается, что MapReduce всегда будет работать корректно, если промежуточная структура данных, полученная на фазе map -- это моноид в категории эндофункторов для операции reduce.

Напомню, кто проходил мои курсы по highload-системам:

"MapReduce -- модель программирования низкого уровня, предназначенная прежде всего для распределённых вычислений на кластерах машин. Языки запросов более высокого уровня, такие как SQL, можно реализовать в виде конвейера операций MapReduce.
Reduce также потенциально допускает параллельное вычисление -- например, список можно разбить на два, и редуцировать каждый из них независимо, и так далее рекурсивно."

Например, в Hadoop используется вариация MapReduce, которая сперва распределяет блоки данных по физическим узлам, которые далее обрабатываются map параллельно, и формируется временное хранилище ключ-значение. Затем происходит перераспределение: данные с одинаковыми ключами объединяются на конкретных узлах, и теперь они хорошо пригодны для дальнейшей обработки reduce в рамках каждого узла.

Однако сильное подозрение, что моноида будет недостаточно, потому что все типичные примеры вроде карт частотности ключей -- это на самом деле коммутативные моноиды при соответствующей операции reduce.

=

Вот кстати в тему отличные статьи "Абстрактная алгебра в действии" (примеры на прозаическом шарпике!), крайне рекомендую для ознакомления =>
https://habr.com/ru/articles/655059/
https://habr.com/ru/articles/656919/

Автор Степан (StepOne) классно пишет в тг "немного технической духоты на C#" :)

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

Дорогие, ну пишите что-то подобное на Java например (или на F# :), и вас эйчары будут с руками рвать и на коленочках приползут умолять.

=

Так вот, моя гипотеза, что параллельный MapReduce будет давать корректные результаты, только если промежуточная структура данных, которую мы подготовили на фазе map, есть коммутативный моноид при операции reduce. Это более строгое условие для обеспечения действительной корректности крупных реализаций MapReduce, рассчитанных на BigData.

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

(добавил в курс "33 стиля программирования")

То, чему я учу на курсах -- на 90% академические университетские темки. Но это не взятые с потолка условные курсы по матану например (маркетинговая "математика для программистов"), нет.

Я отобрал курсы для 5 ключевых треков, которые действительно поднимут вас до звания Программист — так, как эта самая сложная инженерная профессия понималась ещё лет 20 назад.

1. Как понять в программировании всё. Семантика Software Design, 5 базовых вычислительных моделей (декларативная/функциональная, императивная, объектная, реляционная, и UI-модель).
2. Объектно-ориентированный анализ и проектирование.
3. Функциональное программирование.
4. Теория highload-систем.
5. Параллельные вычислительные модели.
+ формат hard work (software design на практике).

Это вечные классические темы, к которым и прибавить особо нечего.

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

Потому что без знания базы вы будете работать со всеми языками и технологиями как с "чёрными ящиками". Но "чёрный ящик" редко оправдывает свою репутацию. Да, есть вещи, которые могут оставаться "чёрными ящиками" какое-то (возможно, и весьма долгое) время в вашей карьере, но в конце концов это просто чья-то абстракция. И в конце концов, без понимания она обязательно даст течь =>
"The Law of Leaky Abstractions"

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

Когда отправил пулл-риквест в свою любимую игру, а тебе ответили:
"Thanks for the report. This will be fixed in 2.0. In the meantime you can work around this issue by simply not doing that"
😁

А вы уже начали собирать GTA 5 из утекших исходников (40 гиг)?

Исходники GTA кстати ужасающи, сплошной говнокод.

У меня ребята, кто прошли самые первые начальные курсы с полного нуля, такое не пишут. Высокая цикломатическая сложность, циклы, вложенные в условия, вложенные в циклы, while вместо for, куча unsafe указателей...
Смесь плюсов, питона и, вроде, max noscript... Нескончаемые сотни багов, некоторые из которых стали культовыми...

И ведь это не исключение, а самый что ни на есть печальный стандарт разработки в мэйнстриме.

Единственная причина, по которой люди считают функциональное программирование сложнее, чем императивное/ООП, заключается в том, что они просто сталкиваются с ним позже. Поэтому в топовых университетах мира уже с первого курса студентов принуждают к хаскелю…

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

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

Ну, в целом, конечно, неполнота по Гёделю это факт, но в каждом конкретном проекте достичь идеала вполне возможно, и это как раз давно доказано и математически, и инженерно.

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

Эта девушка занимается на моих курсах, и в Новый Год её волнует только один вопрос: как гарантировать холодный старт системы, в которой кэша нету принципиально, за 100 мс?

С Наступающим! 🎄🎄🎄🎄

Есть такое важное понятие, как типо-безопасность, в computer science более известное как soundness. И есть также понятие логической консистентности, которое с ним часто путают. Так вот, soundness -- это про то, что термы "не могу ошибаться". Терм у нас может быть либо значением, либо его можно продолжать редуцировать дальше.

Например, мы определили деление как операцию только для ненулевых знаменателей. Тогда терм 'x / 0' нельзя далее редуцировать, но он при этом и не значение.

=
А логическая консистентность подразумевает, что не существует способа сконструировать терм из любого типа.

Ну например в F# возможно такое:

let rec foo() = foo()

Задайте foo любой тип, и получите терм этого типа.

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

=

И что из этого? Ну, не понимая такие вещи, вы не сможете продуктивно программировать на языках с зависимыми типами, да и вообще работать с HoTT-типами, следовать type-level программированию и метапрограммированию с dsl-ями, да и просто правильно применять генерики. И никогда не станете x1000 программистом.

Хватит уже лежать физиономией в салатах, поднимайтесь! :)

А как достичь x1000 ? Легко и просто.
Например,

1. Переходите с C# на F# и получаете в 10 раз меньше кода и в 10 раз выше надёжность (за счёт более сильной системы типов).
= x10

2. Переходите с F# на F* (всё никак не выложу моё введение во введение в F*) и получаете следующие x10 за счёт мышления в парадигме зависимых (от значений) типов.
Вы учитесь "сворачивать" разрабатываемую систему во всё более мощные абстракции.
= x100

3. Переходите с F*, ну куда-нибудь "окончательно" в "высшие" типы, HKT, HoTT...
Получаете за счёт "просветления" ещё x10. Начинаете думать непосредственно на языке предметной области, который формализован в вашем уме через соответствующие абстракции.
= x1000

...

Да, но, Сергей Игоревич, мы ведь вынуждены писать на C#...

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

Никто вам не мешает начать использовать уже сегодня на C++Rust/C#/Java любые фишки сперва функционального программирования, затем завтипы, и так далее. Есть соответствующие библиотеки, а некоторые языки можно нативно расширять (для F#, помнится, было расширение по зависимым типам).

Вы можете начать в любом языке, например, с использования императивных монад, монад I/O, монад побочных эффектов, выразите через монады мутабельность, потом переходите к свободным монадам, in-bounds/out-of-bounds...

Новый пост: Как сделать ИТ-Россию великой, и зачем нам стремиться к зарплате/доходу в миллион рублей в месяц.

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

Пять лет не заглядывал в линкедин, вчера посмотрел, и вот что я написал там в 2019-м =>

"Обучаю MLTT, HoTT, индуктивным типам, процесс-алгебрам/pi-калкулусу, кодированию топосов, hopf fibrations и прочей попсе, которая сделает вас полностью unemployable." )))

Но сам сервис стал совсем зашкварным. Вот кстати фишечка, как скрыть все "рекомендуемые" посты:
https://www.linkedin.com/#%23span:has-text(/Suggested/):upward(4)