Есть ли перспективы у no-code? Нет, абсолютно. Потому что в этой темке не бывает никаких революционных изобретений. Это просто поиск компромиссов между универсальностью и простотой UI, стараясь угодить выбранной рыночной нише. Вдобавок за этим стоит, очевидно, достаточно объёмный код, и этот легаси-хвост сильно затрудняет быструю подстройку под нужды разных клиентов. А агрессивная монетизация даёт в основном саморазрушительный эффект.
Расходимся, в no-code вообще не на что смотреть.
А вот low-code, где есть хотя бы немножечко кодинг, перспективно однозначно. Причём чем визуальнее тут программирование, тем лучше, как в scratch или squeak например -- потому что сегодня это направление очень сильно взлетает и в профессиональной разработке, на моём новом формате занятий "hard work" будем это обязательно изучать.
Расходимся, в no-code вообще не на что смотреть.
А вот low-code, где есть хотя бы немножечко кодинг, перспективно однозначно. Причём чем визуальнее тут программирование, тем лучше, как в scratch или squeak например -- потому что сегодня это направление очень сильно взлетает и в профессиональной разработке, на моём новом формате занятий "hard work" будем это обязательно изучать.
scratch.mit.edu
Scratch - Imagine, Program, Share
Scratch is a free programming language and online community where you can create your own interactive stories, games, and animations.
Если вы не можете записать что-то на русском языке, вы не сможете это запрограммировать.
Дико уважаю:
I started BPS.space almost 7 years ago in the fall of 2015 with the goal to propulsively land a model rocket. I had no background in aero, EE, coding, etc so it took a lot of trial and error, but today I finally stuck the landing
I started BPS.space almost 7 years ago in the fall of 2015 with the goal to propulsively land a model rocket. I had no background in aero, EE, coding, etc so it took a lot of trial and error, but today I finally stuck the landing
This media is not supported in your browser
VIEW IN TELEGRAM
Что такое хорошая абстракция? Пока на сегодня лучшее и достаточно формальное определение, которое я нашёл для учебных целей :) такое:
matt.might.net/articles/intro-static-analysis/
Например, множество целых чисел ...,-2,-1,0,+1,+2,... отображаем в абстрактный домен {-,0,+}, где "-" -- все отрицательные числа, "+" - все положительные.
Теперь можем сделать раскладку операций над этим доменом:
{+} + {+} = {+}
{+} + {-} = {+, 0, -}
{+} * {-} = {-}
и т. п.
И теперь мы можем выполнять очень простой статический анализ без необходимости оценивать полное выражение, то есть нам не надо вычислять -4 * +3, чтобы понять, что результат будет отрицательным.
На мой взгляд, это короткое, симпатичное и полезное отображение абстракции.
Точно так же, как мы можем создать абстрактное отображение между целыми числами и набором знаков, мы можем создать абстрактное отображение от реального мира к нашему абстрактному состоянию в проекте (в виде абстрактного типа данных например). Наше абстрактное состояние содержит только те детали, которые нам нужны. Однако операции и выразительность в этой более ограниченной области всё ещё говорят нам полезные вещи о реальном мире, причём, более того, мы можем получать нужные нам результаты просто и наглядно, отсекая множество ненужных вычислений из "реального мира".
Подробно разбираем в СильныхИдеях эту крайне важную тему.
matt.might.net/articles/intro-static-analysis/
Например, множество целых чисел ...,-2,-1,0,+1,+2,... отображаем в абстрактный домен {-,0,+}, где "-" -- все отрицательные числа, "+" - все положительные.
Теперь можем сделать раскладку операций над этим доменом:
{+} + {+} = {+}
{+} + {-} = {+, 0, -}
{+} * {-} = {-}
и т. п.
И теперь мы можем выполнять очень простой статический анализ без необходимости оценивать полное выражение, то есть нам не надо вычислять -4 * +3, чтобы понять, что результат будет отрицательным.
На мой взгляд, это короткое, симпатичное и полезное отображение абстракции.
Точно так же, как мы можем создать абстрактное отображение между целыми числами и набором знаков, мы можем создать абстрактное отображение от реального мира к нашему абстрактному состоянию в проекте (в виде абстрактного типа данных например). Наше абстрактное состояние содержит только те детали, которые нам нужны. Однако операции и выразительность в этой более ограниченной области всё ещё говорят нам полезные вещи о реальном мире, причём, более того, мы можем получать нужные нам результаты просто и наглядно, отсекая множество ненужных вычислений из "реального мира".
Подробно разбираем в СильныхИдеях эту крайне важную тему.
Залипательное: shark.fish/curiosity/
Ну, да, программистам нередко вот так именно и приходится разбираться -- с легаси-кодом, с issues тимлида, с "ТЗ" заказчика :) А то и с официальной документацией, которая подчас круче любого квеста.
Я где-то около 10 лет назад наверное играл в его же cube composer (сами найдите), тоже крайне рекомендую, микро-тренировка в функциональном мышлении.
Ну, да, программистам нередко вот так именно и приходится разбираться -- с легаси-кодом, с issues тимлида, с "ТЗ" заказчика :) А то и с официальной документацией, которая подчас круче любого квеста.
Я где-то около 10 лет назад наверное играл в его же cube composer (сами найдите), тоже крайне рекомендую, микро-тренировка в функциональном мышлении.
Вот наконец и топовые гуру вроде ЛеКуна заговорили о важности symbol manipulation в современном ML/DL/AI.
NOEMA
Deep Learning Alone Isn’t Getting Us To Human-Like AI
Artificial intelligence has mostly been focusing on a technique called deep learning. It might be time to reconsider.
Ребята без особого проектного опыта, которых повысили и поставили на новый проект с нуля, часто в порыве энтузиазма (но уже немножечко учитывая предыдущий печальный опыт, когда хотелки менеджеров/заказчиков постоянно меняются и растут) заявляют так: "Я хочу разработать универсальную систему, которую можно будет использовать для случаев, которые я ещё не предусмотрел!".
Если вы не математик, то вы не сможете, даже и не пытайтесь. Одно-единственное новое требование за пределами ваших слепых когнитивных пятен испортит вам годы труда и покажет, что вся ваша архитектура - это одна огромная преждевременная оптимизация.
Если вы не математик, то вы не сможете, даже и не пытайтесь. Одно-единственное новое требование за пределами ваших слепых когнитивных пятен испортит вам годы труда и покажет, что вся ваша архитектура - это одна огромная преждевременная оптимизация.
Это самая большая ошибка в программировании: не иметь чёткого представления о том, как данные "движутся" в программе, что из чего вытекает и что куда втекает.
Если вы не имеете чёткого понимания, кому нужны те или иные данные, и как те (функции), кому они нужны, получат к ним доступ и будут их изменять, значит вы ещё не проделали настоящую работу со своим кодом.
Проще всего понатыкать в классы геттеров-сеттеров, но это совсем детский сад.
Если вы не имеете чёткого понимания, кому нужны те или иные данные, и как те (функции), кому они нужны, получат к ним доступ и будут их изменять, значит вы ещё не проделали настоящую работу со своим кодом.
Проще всего понатыкать в классы геттеров-сеттеров, но это совсем детский сад.
Смешное (в продолжение вчерашнего поста в вк) про то, что 99% ребят "учатся" программированию в стиле "безответственно плодить кучу недопустимых состояний", и потом тащат с собой этот кривой скилл всю жизнь, во все самые серьёзные проекты -- например, когда пилишь биткоин :)
https://github.com/bitcoin/bitcoin/...
Тут недопустимых состояний удаётся избежать за счёт долгого тщательного мучительного кодирования на уровне реализации.
А я моим курсантам в августе дам более строгий, формальный способ проектирования: как за 15 минут научиться пожизненно правильно думать о всех видах состояний в программе, заведомо избегая недопустимых.
https://github.com/bitcoin/bitcoin/...
Тут недопустимых состояний удаётся избежать за счёт долгого тщательного мучительного кодирования на уровне реализации.
А я моим курсантам в августе дам более строгий, формальный способ проектирования: как за 15 минут научиться пожизненно правильно думать о всех видах состояний в программе, заведомо избегая недопустимых.
Лаборатория Математики и Программирования Сергея Бобровского pinned «Смешное (в продолжение вчерашнего поста в вк) про то, что 99% ребят "учатся" программированию в стиле "безответственно плодить кучу недопустимых состояний", и потом тащат с собой этот кривой скилл всю жизнь, во все самые серьёзные проекты -- например, когда…»
Привлекательность ООП в том, что вы можете притвориться, что ваша иерархия никогда в дальнейшем не будет сжиматься или расширяться, и что безответственно плодить мутабельные состояния где попало тут и там и в любой момент -- это нормально.
По моему опыту, это просто плохое умение программировать.
По моему опыту, это просто плохое умение программировать.
Программирование будущего будет примерно таким:
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 ("код с запашком") -- кривой стилистически код, что потенциально чревато ошибками (на курсе "Ясный код" довольно подробно разбираем, как правильно). И программисты обычно говорят о "коде с запашком" как о чём-то плохом; но что, если ваш код пахнет картошечкой с жареным лучком?