Если джуны толпами рвутся на вакансии без опыта (это неправильно, поясняю на курсе карьеры, что сегодня надо с этим делать -- и нет, это не (далеко не только) накрутка опыта), то толпы сеньоров также шаблонно мечтают о FAANG/МОСЯ -- но зачем? Во-первых, компаний, где вы можете заработать существенно больше в чистом виде, многие тысячи, в т.ч. и в любимой Российской Федерации, во-вторых, можно заработать программированием куда больше просто другими способами, нежели впахивать на топовых галерах.
Некоторые думают, что МОСЯ -- это такой супербонус для резюме, да нифига. Всем пофиг на то, где вы работали. Конечно, работа в Яндексе даст +5% например, но не больше. Если вы не подходите под проект, то кому какое дело, где вы там раньше работали.
Если вы хотите действительно супербонус для резюме, чтобы брали куда угодно в мировом ИТ просто "за гитхаб", надо делать действительно взрослые специализированные вещи.
(В целом, чем заниматься, если вы сеньор и вам становится скучно, но программирование вы бросать не хотите, сегодня в паблике для неначинающих небольшой пост выложил.)
(между прочим, новая мода брать фразы с точкой в круглые скобочки, это не русская, а американская грамматика.)
Действительно крутых задачек бесконечное число, причём сегодня классические научные темы прекрасно ложатся на прикладуху. Ну например, компиляция с одного языка на другой через term rewriting. Есть классический учебник Филда и Харрисона "Функциональное программирование", который был написан в 1988 г., и все идеи того времени актуальны и сегодня -- потому что это хорошо отшлифованная математика, тут ни убавить, ни прибавить.
Или, как написать супер-блокчейн с использованием линейной темпоральной логики и реляционной модели, или SAT-солвер на conflict-driven clause learning + BDD, и т.д. и т.п...
Некоторые думают, что МОСЯ -- это такой супербонус для резюме, да нифига. Всем пофиг на то, где вы работали. Конечно, работа в Яндексе даст +5% например, но не больше. Если вы не подходите под проект, то кому какое дело, где вы там раньше работали.
Если вы хотите действительно супербонус для резюме, чтобы брали куда угодно в мировом ИТ просто "за гитхаб", надо делать действительно взрослые специализированные вещи.
(В целом, чем заниматься, если вы сеньор и вам становится скучно, но программирование вы бросать не хотите, сегодня в паблике для неначинающих небольшой пост выложил.)
Действительно крутых задачек бесконечное число, причём сегодня классические научные темы прекрасно ложатся на прикладуху. Ну например, компиляция с одного языка на другой через term rewriting. Есть классический учебник Филда и Харрисона "Функциональное программирование", который был написан в 1988 г., и все идеи того времени актуальны и сегодня -- потому что это хорошо отшлифованная математика, тут ни убавить, ни прибавить.
Или, как написать супер-блокчейн с использованием линейной темпоральной логики и реляционной модели, или SAT-солвер на conflict-driven clause learning + BDD, и т.д. и т.п...
👍13✍5🤯4🫡4❤2
Рабочий понедельник в разгаре! Вовсю фигачите тикеты? :)
Если вы ООП/императивный разработчик, то вам даже кофе не нужен.
Когда пишешь на Java или Python, C# или JavaScript, постоянно захлёстывает адреналин от осознания того, что любая твоя строка кода может сломаться 10 различными способами 😁
Какое ещё функциональное программирование? Нет уж, спасибо, я лучше оформлю пять уровней наследования для моего FactoriesManagerFactorySingleton, с нулл-чекингом каждые 2-3 строчки.
Если вы ООП/императивный разработчик, то вам даже кофе не нужен.
Когда пишешь на Java или Python, C# или JavaScript, постоянно захлёстывает адреналин от осознания того, что любая твоя строка кода может сломаться 10 различными способами 😁
Какое ещё функциональное программирование? Нет уж, спасибо, я лучше оформлю пять уровней наследования для моего FactoriesManagerFactorySingleton, с нулл-чекингом каждые 2-3 строчки.
😁36✍5🐳3🫡3🤔2
В продолжение поста про 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 крыша сразу слетит 😇 Но зато коллеги будут офигевать от вашей крутости.
Не тратьте время жизни на изучение фигни, ну правда. Любая такая книга прокачает ваш ум в десятки раз круче, чем какой-нибудь учебник по веб-фреймворкам (который скорее ваш ум только затупит :). Слово пацана!
Курсантам рекомендую индивидуально, как лучше всего эти темки поизучать, в контексте конкретной карьеры.
Ну тут тем множество... Для каждой задачи свой раздел. В матрице компетенций в 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 крыша сразу слетит 😇 Но зато коллеги будут офигевать от вашей крутости.
Не тратьте время жизни на изучение фигни, ну правда. Любая такая книга прокачает ваш ум в десятки раз круче, чем какой-нибудь учебник по веб-фреймворкам (который скорее ваш ум только затупит :). Слово пацана!
Курсантам рекомендую индивидуально, как лучше всего эти темки поизучать, в контексте конкретной карьеры.
✍24🔥3👍2❤1🫡1
Однажды (например, пройдя большинство моих курсов и позанимавшись на hard work), вы откроете для себя правильный способ программирования: то, что придаёт всему этому смысл.
Вы убедитесь на собственном опыте, что в айтишке всё было бы намного лучше, если бы и все остальные тоже программировали правильно.
Правильным способом лично для вас может стать разработка, управляемая тестированием, или функциональное программирование, формальные методы или программирование "по контракту"... или одна из миллиона других вещей.
Но всегда помните, что программирование, за которое вам платят деньги -- это прежде всего беспорядок и разочарование, независимо от того, каким правильным способом пользуются (или не пользуются) люди. И вы также поймёте, что можете создавать отличные программы, не придерживаясь правильных подходов.
Однако если вы будете стабильно придерживаться первого правила Школы, то со временем изучите 50 (или 100500) других правильных способов, и, самое главное, научитесь продуктивно сочетать их с конкретной проектной задачей — и станете x1000 просветлённым, в сравнении с окружающими вас сонными бедолагами, не желающими расти в профессии...
Вы убедитесь на собственном опыте, что в айтишке всё было бы намного лучше, если бы и все остальные тоже программировали правильно.
Правильным способом лично для вас может стать разработка, управляемая тестированием, или функциональное программирование, формальные методы или программирование "по контракту"... или одна из миллиона других вещей.
Но всегда помните, что программирование, за которое вам платят деньги -- это прежде всего беспорядок и разочарование, независимо от того, каким правильным способом пользуются (или не пользуются) люди. И вы также поймёте, что можете создавать отличные программы, не придерживаясь правильных подходов.
Однако если вы будете стабильно придерживаться первого правила Школы, то со временем изучите 50 (или 100500) других правильных способов, и, самое главное, научитесь продуктивно сочетать их с конкретной проектной задачей — и станете x1000 просветлённым, в сравнении с окружающими вас сонными бедолагами, не желающими расти в профессии...
👍17😇8🫡4🐳1
Читал статью "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 стиля программирования")
Напомню, кто проходил мои курсы по 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 стиля программирования")
✍12👍2🫡1
То, чему я учу на курсах -- на 90% академические университетские темки. Но это не взятые с потолка условные курсы по матану например (маркетинговая "математика для программистов"), нет.
Я отобрал курсы для 5 ключевых треков, которые действительно поднимут вас до звания Программист — так, как эта самая сложная инженерная профессия понималась ещё лет 20 назад.
1. Как понять в программировании всё. Семантика Software Design, 5 базовых вычислительных моделей (декларативная/функциональная, императивная, объектная, реляционная, и UI-модель).
2. Объектно-ориентированный анализ и проектирование.
3. Функциональное программирование.
4. Теория highload-систем.
5. Параллельные вычислительные модели.
+ формат hard work (software design на практике).
Это вечные классические темы, к которым и прибавить особо нечего.
Вы не только узнаете программистскую истину, но и познакомитесь со всем мета-стеком научных понятий информатики, а не только с теми кусочками, с которыми вы оказались случайно связаны по работе.
Потому что без знания базы вы будете работать со всеми языками и технологиями как с "чёрными ящиками". Но "чёрный ящик" редко оправдывает свою репутацию. Да, есть вещи, которые могут оставаться "чёрными ящиками" какое-то (возможно, и весьма долгое) время в вашей карьере, но в конце концов это просто чья-то абстракция. И в конце концов, без понимания она обязательно даст течь =>
"The Law of Leaky Abstractions"
Поэтому будьте готовы забраться в эту кроличью нору как можно глубже, и посмотреть, во что будет превращаться ваш код. Вам будет от этого только лучше.
Я отобрал курсы для 5 ключевых треков, которые действительно поднимут вас до звания Программист — так, как эта самая сложная инженерная профессия понималась ещё лет 20 назад.
1. Как понять в программировании всё. Семантика Software Design, 5 базовых вычислительных моделей (декларативная/функциональная, императивная, объектная, реляционная, и UI-модель).
2. Объектно-ориентированный анализ и проектирование.
3. Функциональное программирование.
4. Теория highload-систем.
5. Параллельные вычислительные модели.
+ формат hard work (software design на практике).
Это вечные классические темы, к которым и прибавить особо нечего.
Вы не только узнаете программистскую истину, но и познакомитесь со всем мета-стеком научных понятий информатики, а не только с теми кусочками, с которыми вы оказались случайно связаны по работе.
Потому что без знания базы вы будете работать со всеми языками и технологиями как с "чёрными ящиками". Но "чёрный ящик" редко оправдывает свою репутацию. Да, есть вещи, которые могут оставаться "чёрными ящиками" какое-то (возможно, и весьма долгое) время в вашей карьере, но в конце концов это просто чья-то абстракция. И в конце концов, без понимания она обязательно даст течь =>
"The Law of Leaky Abstractions"
Поэтому будьте готовы забраться в эту кроличью нору как можно глубже, и посмотреть, во что будет превращаться ваш код. Вам будет от этого только лучше.
🔥14🫡10👍4
Когда отправил пулл-риквест в свою любимую игру, а тебе ответили:
"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"
😁
"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"
😁
😁20👏1
Исходники GTA кстати ужасающи, сплошной говнокод.
У меня ребята, кто прошли самые первые начальные курсы с полного нуля, такое не пишут. Высокая цикломатическая сложность, циклы, вложенные в условия, вложенные в циклы, while вместо for, куча unsafe указателей...
Смесь плюсов, питона и, вроде, max noscript... Нескончаемые сотни багов, некоторые из которых стали культовыми...
И ведь это не исключение, а самый что ни на есть печальный стандарт разработки в мэйнстриме.
Единственная причина, по которой люди считают функциональное программирование сложнее, чем императивное/ООП, заключается в том, что они просто сталкиваются с ним позже. Поэтому в топовых университетах мира уже с первого курса студентов принуждают к хаскелю…
И вот когда обычный программист почти справился с ужасами управления памятью, мутабельными типами данных, дизайном и наследованием классов, модификаторами доступа к полям, запоминанием того, какие вещи могут быть null, а какие нет, и т. д. и т. п., используя компиляторы, которые делают самый минимум, чтобы помочь вам со всем этим, и сборщики, которые больше запутывают ваш проект... И теперь вы хотите поговорить с ним о совершенно новой функциональной парадигме, которая использует "математические принципы"? Нет, бро, пожалуйста, не надо, я так устал от этого всего...
Возможно, разработчики, приученные к императивному программированию, делают это из ошибочного представления, что простое совершенство чистого функционального программирования -- это фантазия, и нет никакого способа когда-либо достичь полного совершенства -- ни физического, ни математического -- в недетерминированной Вселенной.
Ну, в целом, конечно, неполнота по Гёделю это факт, но в каждом конкретном проекте достичь идеала вполне возможно, и это как раз давно доказано и математически, и инженерно.
У меня ребята, кто прошли самые первые начальные курсы с полного нуля, такое не пишут. Высокая цикломатическая сложность, циклы, вложенные в условия, вложенные в циклы, while вместо for, куча unsafe указателей...
Смесь плюсов, питона и, вроде, max noscript... Нескончаемые сотни багов, некоторые из которых стали культовыми...
И ведь это не исключение, а самый что ни на есть печальный стандарт разработки в мэйнстриме.
Единственная причина, по которой люди считают функциональное программирование сложнее, чем императивное/ООП, заключается в том, что они просто сталкиваются с ним позже. Поэтому в топовых университетах мира уже с первого курса студентов принуждают к хаскелю…
И вот когда обычный программист почти справился с ужасами управления памятью, мутабельными типами данных, дизайном и наследованием классов, модификаторами доступа к полям, запоминанием того, какие вещи могут быть null, а какие нет, и т. д. и т. п., используя компиляторы, которые делают самый минимум, чтобы помочь вам со всем этим, и сборщики, которые больше запутывают ваш проект... И теперь вы хотите поговорить с ним о совершенно новой функциональной парадигме, которая использует "математические принципы"? Нет, бро, пожалуйста, не надо, я так устал от этого всего...
Возможно, разработчики, приученные к императивному программированию, делают это из ошибочного представления, что простое совершенство чистого функционального программирования -- это фантазия, и нет никакого способа когда-либо достичь полного совершенства -- ни физического, ни математического -- в недетерминированной Вселенной.
Ну, в целом, конечно, неполнота по Гёделю это факт, но в каждом конкретном проекте достичь идеала вполне возможно, и это как раз давно доказано и математически, и инженерно.
🤔15🔥10👍2🫡2✍1
Что мы ждём от AI в 2024-м прежде всего?
Anonymous Poll
32%
AI-подружки
3%
AI-парни
14%
AI-друзья
51%
AI-программист
🤔1
Есть такое важное понятие, как типо-безопасность, в computer science более известное как soundness. И есть также понятие логической консистентности, которое с ним часто путают. Так вот, soundness -- это про то, что термы "не могу ошибаться". Терм у нас может быть либо значением, либо его можно продолжать редуцировать дальше.
Например, мы определили деление как операцию только для ненулевых знаменателей. Тогда терм 'x / 0' нельзя далее редуцировать, но он при этом и не значение.
=
А логическая консистентность подразумевает, что не существует способа сконструировать терм из любого типа.
Ну например в F# возможно такое:
let rec foo() = foo()
Задайте foo любой тип, и получите терм этого типа.
Это означает, что данный язык плохо подходит для организации логических построений. А в общем случае все Тьюринг-полные языки логически неконсистентны.
=
И что из этого? Ну, не понимая такие вещи, вы не сможете продуктивно программировать на языках с зависимыми типами, да и вообще работать с HoTT-типами, следовать type-level программированию и метапрограммированию с dsl-ями, да и просто правильно применять генерики. И никогда не станете x1000 программистом.
Хватит уже лежать физиономией в салатах, поднимайтесь! :)
Например, мы определили деление как операцию только для ненулевых знаменателей. Тогда терм 'x / 0' нельзя далее редуцировать, но он при этом и не значение.
=
А логическая консистентность подразумевает, что не существует способа сконструировать терм из любого типа.
Ну например в F# возможно такое:
let rec foo() = foo()
Задайте foo любой тип, и получите терм этого типа.
Это означает, что данный язык плохо подходит для организации логических построений. А в общем случае все Тьюринг-полные языки логически неконсистентны.
=
И что из этого? Ну, не понимая такие вещи, вы не сможете продуктивно программировать на языках с зависимыми типами, да и вообще работать с HoTT-типами, следовать type-level программированию и метапрограммированию с dsl-ями, да и просто правильно применять генерики. И никогда не станете x1000 программистом.
Хватит уже лежать физиономией в салатах, поднимайтесь! :)
😁19🫡11❤5🤯3👍2
А как достичь 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...
Например,
1. Переходите с C# на F# и получаете в 10 раз меньше кода и в 10 раз выше надёжность (за счёт более сильной системы типов).
= x10
2. Переходите с F# на F* (всё никак не выложу моё введение во введение в F*) и получаете следующие x10 за счёт мышления в парадигме зависимых (от значений) типов.
Вы учитесь "сворачивать" разрабатываемую систему во всё более мощные абстракции.
= x100
3. Переходите с F*, ну куда-нибудь "окончательно" в "высшие" типы, HKT, HoTT...
Получаете за счёт "просветления" ещё x10. Начинаете думать непосредственно на языке предметной области, который формализован в вашем уме через соответствующие абстракции.
= x1000
...
Да, но, Сергей Игоревич, мы ведь вынуждены писать на C#...
Так просветление и подразумевает процесс полного совпадения мышления в языке домена с прозрачной реализацией сформулированной на нём системы на любом языке программирования. Я пояснял, почему это трудно -- потому что мы строим ментальную модель системы инженерно, совсем слабыми абстракциями, а то и просто наобум. Она получается неполной, нечёткой, хрупкой, постоянно разваливается...
Так делать это надо через математику.
Никто вам не мешает начать использовать уже сегодня на
Вы можете начать в любом языке, например, с использования императивных монад, монад I/O, монад побочных эффектов, выразите через монады мутабельность, потом переходите к свободным монадам, in-bounds/out-of-bounds...
✍32🤯7👍3❤2😁1
Новый пост: Как сделать ИТ-Россию великой, и зачем нам стремиться к зарплате/доходу в миллион рублей в месяц.
VK
Лаборатория Программирования Сергея Бобровского. Пост со стены.
Как сделать ИТ-Россию великой? Зачем? Ну например США заявили, что их цель — понизить доход России о... Смотрите полностью ВКонтакте.
🔥13🫡6❤2🤔2👍1
Пять лет не заглядывал в линкедин, вчера посмотрел, и вот что я написал там в 2019-м =>
"Обучаю MLTT, HoTT, индуктивным типам, процесс-алгебрам/pi-калкулусу, кодированию топосов, hopf fibrations и прочей попсе, которая сделает вас полностью unemployable." )))
Но сам сервис стал совсем зашкварным. Вот кстати фишечка, как скрыть все "рекомендуемые" посты:
https://www.linkedin.com/#%23span:has-text(/Suggested/):upward(4)
"Обучаю MLTT, HoTT, индуктивным типам, процесс-алгебрам/pi-калкулусу, кодированию топосов, hopf fibrations и прочей попсе, которая сделает вас полностью unemployable." )))
Но сам сервис стал совсем зашкварным. Вот кстати фишечка, как скрыть все "рекомендуемые" посты:
https://www.linkedin.com/#%23span:has-text(/Suggested/):upward(4)
🤓7👍4🔥4😁1
Для курсантов в раздел "Элитный программист" добавил 37-й материал "Как справляться с некомпетентными новичками".
К программистам придираются далеко не только нетехнические менеджеры и офисные начальники. Я уже сбился со счёта, сколько раз наблюдал, как опытные программисты возмущаются глупыми ошибками, которые допускали младшие разработчики. Но это тоже ситуация, с которой можно справиться, взяв ответственность на себя.
Например, сеньоров раздражает, когда джуниоры не используют git, или фигачат комиты сразу в мастер, не пишут юнит-тесты, задают глупые вопросы, ответы на которые можно нагуглить за пять минут...
Действительно, возня со всем этим отнимает у старших немало времени и сил. И вот что с этим делать ...
и 38-й - "Как справляться с назойливыми рекрутерами".
Рекрутеры в исходной задумке -- это здорово. Подразумевается, что вам как профессиональному разработчику больше не нужно подавать множество заявок на вакансии вручную. Остальное сделают рекрутеры, и те из них, которые полагают, что вы подходите на доступные им вакансии, начнут звонить вам.
Но рекрутеры -- это обычные продавцы, работающие по заказу ...
На курс карьеры добавлен 83-й материал "Как проходить стажёрство/испытательный срок". Главное, что вам надо делать, когда вас взяли стажёром или на испытательный срок -- это понять 5 важных принципов...
К программистам придираются далеко не только нетехнические менеджеры и офисные начальники. Я уже сбился со счёта, сколько раз наблюдал, как опытные программисты возмущаются глупыми ошибками, которые допускали младшие разработчики. Но это тоже ситуация, с которой можно справиться, взяв ответственность на себя.
Например, сеньоров раздражает, когда джуниоры не используют git, или фигачат комиты сразу в мастер, не пишут юнит-тесты, задают глупые вопросы, ответы на которые можно нагуглить за пять минут...
Действительно, возня со всем этим отнимает у старших немало времени и сил. И вот что с этим делать ...
и 38-й - "Как справляться с назойливыми рекрутерами".
Рекрутеры в исходной задумке -- это здорово. Подразумевается, что вам как профессиональному разработчику больше не нужно подавать множество заявок на вакансии вручную. Остальное сделают рекрутеры, и те из них, которые полагают, что вы подходите на доступные им вакансии, начнут звонить вам.
Но рекрутеры -- это обычные продавцы, работающие по заказу ...
На курс карьеры добавлен 83-й материал "Как проходить стажёрство/испытательный срок". Главное, что вам надо делать, когда вас взяли стажёром или на испытательный срок -- это понять 5 важных принципов...
👍12🔥5🫡3❤1