Привлекательность ООП в том, что вы можете притвориться, что ваша иерархия никогда в дальнейшем не будет сжиматься или расширяться, и что безответственно плодить мутабельные состояния где попало тут и там и в любой момент -- это нормально.
По моему опыту, это просто плохое умение программировать.
По моему опыту, это просто плохое умение программировать.
Программирование будущего будет примерно таким:
unison.cloud
unison.cloud
Пока Гугл и М*** соревнуются в пиаре, у кого круче спецы по AI,
IBM втихомолку набирает ударную группу учёных в проект Systems Neuroscience Approach to General Intelligence (SynAGI). ...To design, build, and code novel architectures for artificial neural networks that exhibit many of the capabilities of biological intelligence while mirroring certain observations in brain anatomy, systems physiology, and behavior.
Особо порадовало такое требование к академикам: ...and develop/implement example AI constructs plus validation methods in Python/C++.
Ну а чего сразу с козырей, сразу плюсы?:)
Между Python и C++ дистанция космического размера.
IBM втихомолку набирает ударную группу учёных в проект Systems Neuroscience Approach to General Intelligence (SynAGI). ...To design, build, and code novel architectures for artificial neural networks that exhibit many of the capabilities of biological intelligence while mirroring certain observations in brain anatomy, systems physiology, and behavior.
Особо порадовало такое требование к академикам: ...and develop/implement example AI constructs plus validation methods in Python/C++.
Ну а чего сразу с козырей, сразу плюсы?:)
Между Python и C++ дистанция космического размера.
Как быстро и легко использовать сильные вещи на Python для решения сложных проблем -- с помощью
- Breadth and Depth First Search
- SAT Solvers
- Reinforcement Learning
- Temporal Logic with TLA⁺ and Z3
- Generic MCTS with CNN and Reinforcement Learning
- Breadth and Depth First Search
- SAT Solvers
- Reinforcement Learning
- Temporal Logic with TLA⁺ and Z3
- Generic MCTS with CNN and Reinforcement Learning
Красивое:
The language that all programmers use
Программирование будущего будет именно таким: просто так вводить в умном редакторе вообще ничего нельзя. А как поставил точечку, он тебе на выбор предлагает корректный список допустимых функций например, из которых дальше можешь выбрать подходящее, и всё. Просто комбинируешь допустимые возможности в рамках строго заданных логических ограничений.
Примерно как Copilot, только не тупо угадывающая нейросетка, а на основе хорошего движка формального вывода и верификации под капотом.
The language that all programmers use
Программирование будущего будет именно таким: просто так вводить в умном редакторе вообще ничего нельзя. А как поставил точечку, он тебе на выбор предлагает корректный список допустимых функций например, из которых дальше можешь выбрать подходящее, и всё. Просто комбинируешь допустимые возможности в рамках строго заданных логических ограничений.
Примерно как Copilot, только не тупо угадывающая нейросетка, а на основе хорошего движка формального вывода и верификации под капотом.
YouTube
The language that all programmers use
We code in many different languages, but there's one language that all programmers use.
This video introduces the issue and presents Lamdu's approach for code I18N.
Music:
* Background music at second half of video are recording from a beta-testing session…
This video introduces the issue and presents Lamdu's approach for code I18N.
Music:
* Background music at second half of video are recording from a beta-testing session…
Классный курс по System Design, рекомендую.
github.com/karanpratapsingh/system-design
Отлично работает на пару с учебником
"System Design. Подготовка к сложному интервью".
github.com/karanpratapsingh/system-design
Отлично работает на пару с учебником
"System Design. Подготовка к сложному интервью".
GitHub
GitHub - karanpratapsingh/system-design: Learn how to design systems at scale and prepare for system design interviews
Learn how to design systems at scale and prepare for system design interviews - karanpratapsingh/system-design
В продолжение вот этого: в бортовом софте американской боевой ракеты (1995 г.) обнаружились утечки памяти, но всем пофиг, всё равно же она потом взорвётся.
Однако всё оказалось не так просто; специально был взят объём утечек, которые могли бы слиться за максимально возможное время полёта, после чего его тупо умножили на два, и таким образом получили дополнительный объём памяти, который был добавлен в аппаратную часть, чтобы "поддержать" утечки.
Ну да, классическое "инженерное" решение: а давайте "для страховки" поставим в два раза больше оперативки (почему в 2, а не в 3.14 например?). И ведь подобных решений "на глазок" сегодня наверняка полным-полно в самых разных критических важных системах.
Кстати, в материале "Три уровня рассуждений о программной системе" для моих курсантов разбираю, на примере механики формальной верификации как раз применительно к утечкам памяти, как об этом правильно думать на третьем логическом уровне.
"Вы закономерно можете спросить: ну и чем поможет такая формальная система спецификаций, если мы всё равно не можем контролировать конкретную реализацию malloc из некоторой стандартной библиотеки, как правило завязанной вдобавок на конкретную ОС (а то и на конкретную версию ОС), когда нету доступа к её исходным текстам?"
Однако всё оказалось не так просто; специально был взят объём утечек, которые могли бы слиться за максимально возможное время полёта, после чего его тупо умножили на два, и таким образом получили дополнительный объём памяти, который был добавлен в аппаратную часть, чтобы "поддержать" утечки.
Ну да, классическое "инженерное" решение: а давайте "для страховки" поставим в два раза больше оперативки (почему в 2, а не в 3.14 например?). И ведь подобных решений "на глазок" сегодня наверняка полным-полно в самых разных критических важных системах.
Кстати, в материале "Три уровня рассуждений о программной системе" для моих курсантов разбираю, на примере механики формальной верификации как раз применительно к утечкам памяти, как об этом правильно думать на третьем логическом уровне.
"Вы закономерно можете спросить: ну и чем поможет такая формальная система спецификаций, если мы всё равно не можем контролировать конкретную реализацию malloc из некоторой стандартной библиотеки, как правило завязанной вдобавок на конкретную ОС (а то и на конкретную версию ОС), когда нету доступа к её исходным текстам?"
Есть такой термин code smell ("код с запашком") -- кривой стилистически код, что потенциально чревато ошибками (на курсе "Ясный код" довольно подробно разбираем, как правильно). И программисты обычно говорят о "коде с запашком" как о чём-то плохом; но что, если ваш код пахнет картошечкой с жареным лучком?
Python — это фреймворк для Си.
Красивое: lyrajs.io
Lyra is a modern, dependency-free full-text search engine written in TypeScript. It has been built with speed in mind and completes most search lookups in a few microseconds.
Lyra is a modern, dependency-free full-text search engine written in TypeScript. It has been built with speed in mind and completes most search lookups in a few microseconds.
Oramasearch
Orama - Full-text, vector, and hybrid search at the edge
Full-text & vector search at the edge. Run unlimited full-text and vector search queries in 300 locations around the world. For free. Trusted by engineers at Meta, Speakeasy, Platformatic, and more.
Проект становится существенно сложнее изменить под некоторую новую фичу, если в нём есть несколько вещей, которые под эту фичу придётся менять "одновременно". Вот это и есть классическая "coupling", которую всегда надо максимально понижать.
Хотя и "cohesion", доведённая до абсурда, тоже нехороша: даже если класс достаточно автономен и хорошо отвечает SRP, внутри него может быть такое сцепление, что он сам превратился в несокрушимый монолит с кучей недопустимых состояний.
Для курсантов на прошлой неделе выложил формальную думательную машинку в СильныхИдеях -- как правильно проектировать систему, чтобы в ней таких состояний не возникало. Дальше будет большая тема, в несколько заходов, как понижать coupling/избавляться от зависимостей.
Ну например, нам нравится (ошибочно) думать, что если A не зависит от B, то изменение B не может повлиять на A. Но что если вы измените B таким образом, что появится новая зависимость? Например, если вы измените глобальную переменную, которую использует A?
Разберём 10 видов зависимостей, и как с ними правильно поступать.
Хотя и "cohesion", доведённая до абсурда, тоже нехороша: даже если класс достаточно автономен и хорошо отвечает SRP, внутри него может быть такое сцепление, что он сам превратился в несокрушимый монолит с кучей недопустимых состояний.
Для курсантов на прошлой неделе выложил формальную думательную машинку в СильныхИдеях -- как правильно проектировать систему, чтобы в ней таких состояний не возникало. Дальше будет большая тема, в несколько заходов, как понижать coupling/избавляться от зависимостей.
Ну например, нам нравится (ошибочно) думать, что если A не зависит от B, то изменение B не может повлиять на A. Но что если вы измените B таким образом, что появится новая зависимость? Например, если вы измените глобальную переменную, которую использует A?
Разберём 10 видов зависимостей, и как с ними правильно поступать.
Концепция динамической архитектуры была формализована Калифорнийским университетом в 1990-е годы. Это когда система уже была построена, но потом её спецификация стала (сильно) меняться, ну и не хотелось бы переделывать всё/многое заново. Финансировали эту работу военные: Rome Laboratory и US Air Force Materiel Command.
В некотором смысле это похоже на инъекцию зависимостей, только когда эти зависимости совсем не зависимости, а условные "объекты", репрезентующие элементы архитектуры. Подозрение, что и Clean Architecture, и DDD, и им подобные родились из этой и подобных научных работ.
При соответствующей инструментальной поддержке можно изолировать изменённые части архитектуры, выполнить subtyping и внести необходимые изменения в работающую систему в некоторых случаях (если динамичесвие языки используются) даже в реальном времени, в горячем режиме.
Разберём этой осенью в СильныхИдеях (после 10 типов зависимостей) соответствующий архитектурный паттерн, он довольно простой, ему достаточно просто следовать "по форме". Конечно, это не универсальный подход, но в немалом числе случаев вполне подходящий (что доказали соответствующие американские проекты по критическим информационным инфраструктурам).
В некотором смысле это похоже на инъекцию зависимостей, только когда эти зависимости совсем не зависимости, а условные "объекты", репрезентующие элементы архитектуры. Подозрение, что и Clean Architecture, и DDD, и им подобные родились из этой и подобных научных работ.
При соответствующей инструментальной поддержке можно изолировать изменённые части архитектуры, выполнить subtyping и внести необходимые изменения в работающую систему в некоторых случаях (если динамичесвие языки используются) даже в реальном времени, в горячем режиме.
Разберём этой осенью в СильныхИдеях (после 10 типов зависимостей) соответствующий архитектурный паттерн, он довольно простой, ему достаточно просто следовать "по форме". Конечно, это не универсальный подход, но в немалом числе случаев вполне подходящий (что доказали соответствующие американские проекты по критическим информационным инфраструктурам).
Интересное исследование Microsoft Research "What is it like to program with artificial intelligence?"
Утверждается, что хотя программирование с AI-помощниками наподобие Copilot и имеет некоторую поверхностную схожесть с парным программированием и с "программированием" гуглением + stackoverflow, существуют фундаментальные различия как в техническом потенциале этого подхода, так и в практической работе. Авторы выражаются политкорректно, но засада в том, что когда такими инструментами пользуются разработчики низкой квалификации, то вероятность накосячить сильно вырастает, потому что предлагаемый AI код отнюдь не точный, очень вероятно содержит ошибки, и его надо ещё прилично допиливать, подробно разбираться с ним и т.д. Ну понять-то надо как минимум?
Но для качественного разбирательства в чужом коде требуется сам по себе достаточно продвинутый скилл, и такое разбирательство с сомнительным кодом вполне может потребовать прилично времени и для опытного программиста. При этом однако создаётся опасная иллюзия "всё норм", когда код вроде бы собрался и на простых тестах не падает.
Думаю, что в итоге с массовым распространением подобных AI-ассистентов, когда обещается, что "до 40% кода AI напишет за вас всего за 10 долларов в месяц", и без того невысокий средний уровень программистов вообще пробьёт дно, потому что можно будет вообще не думать.
Утверждается, что хотя программирование с AI-помощниками наподобие Copilot и имеет некоторую поверхностную схожесть с парным программированием и с "программированием" гуглением + stackoverflow, существуют фундаментальные различия как в техническом потенциале этого подхода, так и в практической работе. Авторы выражаются политкорректно, но засада в том, что когда такими инструментами пользуются разработчики низкой квалификации, то вероятность накосячить сильно вырастает, потому что предлагаемый AI код отнюдь не точный, очень вероятно содержит ошибки, и его надо ещё прилично допиливать, подробно разбираться с ним и т.д. Ну понять-то надо как минимум?
Но для качественного разбирательства в чужом коде требуется сам по себе достаточно продвинутый скилл, и такое разбирательство с сомнительным кодом вполне может потребовать прилично времени и для опытного программиста. При этом однако создаётся опасная иллюзия "всё норм", когда код вроде бы собрался и на простых тестах не падает.
Думаю, что в итоге с массовым распространением подобных AI-ассистентов, когда обещается, что "до 40% кода AI напишет за вас всего за 10 долларов в месяц", и без того невысокий средний уровень программистов вообще пробьёт дно, потому что можно будет вообще не думать.
Ричард Фейнман говорил, что учить надо не "что делать", а "как делать". В университетах этому принципу кое-как ещё пытаются следовать, а на онлайн-курсах, конечно, повсеместно уже давным-давно учат только "что делать". В результате сегодня многие компании в резюме кандидатов и не смотрят, и даже тема хорошего гитхаба, хорошие ссылочки на сайд-проекты в резюме, актуальная буквально пару лет назад, сегодня тоже быстро схлопывается, потому что у 98% на гитхабе одни и те же "прикладные практические проэкты", сделанные под копирку по шаблонам известных онлайн-школ, которые (шаблоны) не меняются годами.
Это кстати в некотором смысле хорошо, и вот почему.
"что делать" -- это фактически тупое обучение на примерах нейросетки в вашей голове. Если хардвер вашего ума от природы мощный (повезло/карма), то пройдя например мой курс обучения программированию с нуля, где вы грузите в свой ум, в свою условную GPT-3, текст теории + решаете сотни задачек + потом разбираете эталонные примеры, вы научитесь достаточно успешно решать задачки соответствующей мощности автоматически. У вас в уме появился Copilot 1-го левела, а так как обученные модельки ресурсы/энергию почти не потребляют, то и решать соответствующие задачки вам удаётся легко.
Потом проходите следующие курсы, решаете более сложные задачки -- дообучаете свой копилот до следующих уровней, и этот процесс тяжёлый, потому что обучение нейросетки задача очень ресурсоёмкая, а мозг тратить энергию крайне не любит. Но зато у вас доступна и соответствующая готовая модель для быстрого решения несложных (для вашего текущего копилота) задач -- бессознательная компетентность.
И дальше, по такой же схеме всю жизнь, вы периодически изучаете разные новые незнакомые технологии, фреймворки, а в основном просто пользуетесь своими готовыми нейромоделями.
Но вы при этом всё равно остаётесь на уровне "что делать". Вам дали задачку, вы загрузили её в ум, внимательно несколько раз прочитав ТЗ -- что надо сделать, и потом в голове через несколько минут/часов просто "всплыла" готовая схема решения, ваш копилот отработал. Как правило, это будет нечёткая, приблизительная, довольно общая схема (потому что мозгу на получение более детализированной картины требуется резко больше энергии), ну и дальше вы уже сознательно допиливаете первичное решение до работающего чисто инженерными приёмами -- правите/дорабатываете код, пишете тесты, и т. п.
Это кстати в некотором смысле хорошо, и вот почему.
"что делать" -- это фактически тупое обучение на примерах нейросетки в вашей голове. Если хардвер вашего ума от природы мощный (повезло/карма), то пройдя например мой курс обучения программированию с нуля, где вы грузите в свой ум, в свою условную GPT-3, текст теории + решаете сотни задачек + потом разбираете эталонные примеры, вы научитесь достаточно успешно решать задачки соответствующей мощности автоматически. У вас в уме появился Copilot 1-го левела, а так как обученные модельки ресурсы/энергию почти не потребляют, то и решать соответствующие задачки вам удаётся легко.
Потом проходите следующие курсы, решаете более сложные задачки -- дообучаете свой копилот до следующих уровней, и этот процесс тяжёлый, потому что обучение нейросетки задача очень ресурсоёмкая, а мозг тратить энергию крайне не любит. Но зато у вас доступна и соответствующая готовая модель для быстрого решения несложных (для вашего текущего копилота) задач -- бессознательная компетентность.
И дальше, по такой же схеме всю жизнь, вы периодически изучаете разные новые незнакомые технологии, фреймворки, а в основном просто пользуетесь своими готовыми нейромоделями.
Но вы при этом всё равно остаётесь на уровне "что делать". Вам дали задачку, вы загрузили её в ум, внимательно несколько раз прочитав ТЗ -- что надо сделать, и потом в голове через несколько минут/часов просто "всплыла" готовая схема решения, ваш копилот отработал. Как правило, это будет нечёткая, приблизительная, довольно общая схема (потому что мозгу на получение более детализированной картины требуется резко больше энергии), ну и дальше вы уже сознательно допиливаете первичное решение до работающего чисто инженерными приёмами -- правите/дорабатываете код, пишете тесты, и т. п.
14-летний пацан за один час взломал код с четырьмя уровнями криптозащиты, который был опубликован на памятной 50-центовой монете, выпущенной Агентством кибербезопасности внешней разведки Австралии.
"Just unbelievable. Can you imagine being his mum?
So we're hoping to meet him soon ... to recruit him."
Ну, просто никогда не надо недооценивать человеческую изобретательность.
"Just unbelievable. Can you imagine being his mum?
So we're hoping to meet him soon ... to recruit him."
Ну, просто никогда не надо недооценивать человеческую изобретательность.
Инверсия зависимостей из SOLID рекламируется массам якобы в целях устранения зависимостей: вместо того, чтобы A статически связывал/вызывал модуль B, программа передаёт A ссылку на B во время выполнения. Но A всё равно откажет, если откажет B. Ну и?
Уж не говоря о том, что упоминать DI в техническом контексте фреймворков вообще полный зашквар.
Вдобавок, в DI мы теряем множество полезных проверок статического тайп-чекинга, рискованно полагаясь на косолапый полиморфизм (не путать с сабтайпингом).
И это был всего лишь один из сотен когнитивных багов, которым вас старательно учат(!) под вывеской "программной инженерии" (как "правильно" делать), и не только в учебниках и на онлайн-курсах, но и в университетах (ну, исключая разве что MIT, CMU etc). Вся эта бесконечная робертмартинфаулерщина -- зато, очень хорошо продающаяся.
Уж не говоря о том, что упоминать DI в техническом контексте фреймворков вообще полный зашквар.
Вдобавок, в DI мы теряем множество полезных проверок статического тайп-чекинга, рискованно полагаясь на косолапый полиморфизм (не путать с сабтайпингом).
И это был всего лишь один из сотен когнитивных багов, которым вас старательно учат(!) под вывеской "программной инженерии" (как "правильно" делать), и не только в учебниках и на онлайн-курсах, но и в университетах (ну, исключая разве что MIT, CMU etc). Вся эта бесконечная робертмартинфаулерщина -- зато, очень хорошо продающаяся.
Небольшое дополнение-пример к большому вчерашнему посту в вк
Diagrams -- DSL для векторной графики, написанный на хаскеле.
Diagrams -- DSL для векторной графики, написанный на хаскеле.
Какая красотища: birch.ink — low-code будущего.
Интересно, вам рассказывали в университете на информатике (если вам вообще повезло там учиться :) про "N-version programming" из 1970-х?
Тогда эта идея была модной: если 5 человек пишут одну и ту же программу, то вероятность, что во всех их версиях кода будут одни и те же ошибки, исчезающе мала, верно? Мы берём, конечно, профессиональных разработчиков; так то у меня на курсе с нуля 98% начинающих делают одни и те же ошибки :)
Таким образом, вы можете попросить 5 человек реализовать одну и ту же (очень подробную) важную спецификацию (например, для управления АЭС), и пусть сами программы голосуют, что им делать на каждом своём шаге выполнения; до тех пор, пока три человека не сделают одинаковых ошибок в спецификации (что крайне маловероятно), программа всегда будет работать в соответствии со спецификацией, верно?
Увы нет; это классический когнитивный баг, незнание механизмов статистики, которые часто выдают совершенно неочевидные результаты.
Вот эмпирическое опровержение данной методики:
ieeexplore.ieee.org/document/6312924
по одной и той же спецификации было подготовлено 27 (!) версий программы, совершено независимо, в двух разных университетах, после чего они были прогнаны через миллион тестов. Результаты показали, что хотя по отдельности программы были чрезвычайно надёжны, однако количество тестов, в которых не сработало более одной программы, было значительно больше, чем ожидалось.
Это значит, что нужно быть очень осторожным, когда вы разрабатываете инструменты (особенно для критических инфраструктур) и предлагаете их для использования. К сожалению, современная ИТ-сфера, основанная прежде всего на бабле, а не на интересах общества, совсем не "осторожна" в этом плане.
Тогда эта идея была модной: если 5 человек пишут одну и ту же программу, то вероятность, что во всех их версиях кода будут одни и те же ошибки, исчезающе мала, верно? Мы берём, конечно, профессиональных разработчиков; так то у меня на курсе с нуля 98% начинающих делают одни и те же ошибки :)
Таким образом, вы можете попросить 5 человек реализовать одну и ту же (очень подробную) важную спецификацию (например, для управления АЭС), и пусть сами программы голосуют, что им делать на каждом своём шаге выполнения; до тех пор, пока три человека не сделают одинаковых ошибок в спецификации (что крайне маловероятно), программа всегда будет работать в соответствии со спецификацией, верно?
Увы нет; это классический когнитивный баг, незнание механизмов статистики, которые часто выдают совершенно неочевидные результаты.
Вот эмпирическое опровержение данной методики:
ieeexplore.ieee.org/document/6312924
по одной и той же спецификации было подготовлено 27 (!) версий программы, совершено независимо, в двух разных университетах, после чего они были прогнаны через миллион тестов. Результаты показали, что хотя по отдельности программы были чрезвычайно надёжны, однако количество тестов, в которых не сработало более одной программы, было значительно больше, чем ожидалось.
Это значит, что нужно быть очень осторожным, когда вы разрабатываете инструменты (особенно для критических инфраструктур) и предлагаете их для использования. К сожалению, современная ИТ-сфера, основанная прежде всего на бабле, а не на интересах общества, совсем не "осторожна" в этом плане.
Пришёл спам пригласительное письмо от Мэрии Москвы (рассылается, понято, всем, кто зарегистрирован на mos.ru) с приглашением проголосовать на выборах онлайн. Однако когда туда заходишь, выдаётся вот такое.