Современная разработка погрязла в driven, first и based подходах, недавно этот зоопарк пополнился еще одним заморским зверем под названием AI-driven (пусть меня простят свидетели AGI, но я сознательно не выделяю этот подход на фоне остальных и в конце объясню почему). Но не пытаются ли все эти подходы на самом деле решить одну и ту же проблему, известную еще с середины прошлого века, проблему "абстрактного перехода"?
Под абстрактным переходом я буду понимать переход программирования в целом на новый уровень абстракции. Это должно быть не точечное изменение конкретной технологии или языка и даже не группы языков, а именно переломный момент, поднимающий общий IT-ландшафт на следующую ступень абстракции. В общем я поставить перед собой цель попытаться вывести эти переходы, а зачем мне это нужно понятно станет в конце.
Первый переход
В период с 1942 по 1945 немецкий инженер Конрад Цузе создает первый в мире язык высокого уровня, Plankalkül, который уже содержит переменные, циклы, условные конструкции, массивы и кортежи, и это был первый в истории программирования абстрактный переход от бинарной, и любых арных кодировок к "человеко-читаемым" инструкциям, думаю тут в целом все более менее ясно, переход вполне однозначный. Но это был тот случай, когда идея появляется раньше, чем мир был к ней готов, зато служит прекрасной отправной точкой данной статьи.
С конца 40-х до начала 50-х специалисты в США пытаются решить аналогичную проблему, разрабатывая свои символические языки, в конечном счете это приводит к появлению целого семейства языков под общим названием ассемблер, языка хоть и не такого продвинутого, как Plankalkül, но имеющего индустриальную и коммерческую базу, а вот закрепился в железе и в деньгах первый абстрактный переход пожалуй с появления в 1957 году всем известного языка Fortran, если Plankalkül был переходом идейным, то Fortran подтвердил и развил эту идею на практике. Тут можно конечно возразить, что не язык совершил этот переход, а появление компилятора, но компилятор не возник бы без идеи языка следующего уровня, который нужно компилировать в язык предыдущего, потому он скорее служит исполнительным органом данного намерения.
Сутью первого абстрактного перехода был не конкретный язык, а появление принципа "код как человеко-читаемый текст", этот слой останется доминирующим надолго, из него будут выжимать максимум, в следующие 50 лет появится еще куча языков, пожалуй самыми заметными станут C, SQL, C++, Python, Java, JavaScript, все перечислять не буду. Тут важно отметить одно интересное свойство первого перехода, так как фундаментальный принцип, который он принес, это человеко-читаемость, то языки, которые унаследуют этот принцип будут бороться именно за человека, за право стать его главным инструментом, отсюда возникает идея языка общего назначения и многие будут пытаться им стать, пока сама идея не начнет себя исчерпывать и не появится новый кандидат на звание второго абстрактного перехода.
Второй переход
Я долго думал, что можно считать вторым абстрактным переходом и произошел ли он вообще. Какой язык или технология или даже принцип может на это претендовать, декларативные языки, архитектура или может ООП? Попробуем разобраться.
Декларативное программирование
Да, декларативные языки наделали много шуму, в 1972 году появляется замечательный язык Prolog, который в принципе можно считать первым по настоящему декларативным языком, ты пишешь запрос к набору фактов, а логический движок сам разбирается, как построить вычисления, но тут важно разобраться в сути декларативного программирования, его конечно отделяют от императивного подхода, но я попытаюсь показать, что это разделение отчасти фиктивно, и имеет скорее инженерную природу. Например, тот же Fortran позволял написать:
Y = A * X + B
разве это не декларация намерения, ты описываешь формулу, а не как управлять регистрами, а вот пример на языке ALGOL:
BEGIN INTEGER PROCEDURE Factorial(n); VALUE n; IF n <= 1 THEN Factorial := 1 ELSE Factorial := n * Factorial(n - 1) FI END;
тут твоим намерением становится уже описание алгоритма и ты вполне декларативно его описываешь. Можем ли мы считать Fortarn и ALGOL декларативными языками? Да, можем! Просто в случае с этими языками наши намерения служат описанию формул и алгоритмов, Prolog же имеет более абстрактное основание - логика, но суть остается та же. Это разделение станет заметнее именно с появлением идеи языка общего назначения и усилением принципа не что, а как, но повторюсь, это не фундаментальный сдвиг, а скорее временная подмена понятий, поэтому полноценным абстрактным переходом я его считать не могу!
Архитектура и ООП
Архитектура программного обеспечения в целом на первый взгляд действительно заслуживает стать следующим уровнем абстракции, ведь появился по сути новый язык, который уже описывал что-то над кодом, описывал целые системы, но тянет ли это на следующий уровень абстракции или нет, давайте разбираться! Я не буду говорить об архитектуре в контексте вычислительных устройств или операционных систем, хоть этот слой и заслуживает отдельного пристального внимания, но к предмету данной статьи не относится.
Конечно можно сказать, что деление кода на блоки в первых языках тоже архитектура, но я хочу быть честен и поговорить о том, когда архитектура программного кода становится самодостаточной и о ней говорят отдельно. В 1968-1969 года проходит конференция "NATO Software Engineering Conferences", на которой активно обсуждаются идеи дизайна ПО, ключевой вывод - системы стали слишком сложными, именно этот принцип и приводит к осознанию потребности в архитектурном подходе в написании программ, одна цитата из этой дискуссии очень красноречиво это описывает:
software designers are in a similar position to architects and civil engineers, particularly those concerned with the design of large heterogeneous constructions, such as towns and industrial plants. It therefore seems natural that we should turn to these subjects for ideas about how to attack the design problem.
Peter Naur
За несколько лет до этой конференции на свет появляется язык Simula, который первый предложит классы и объекты, из него вырастет целая религия ООП, кто-то его любит, кто-то нет, но как это связано с архитектурой, понятно станет дальше. А еще раньше язык COBOL, который предложит бизнес-ориентированный код. Казалось бы разные технологии, разные подходы, но цель при этом одна - моделирование реального мира. Но зачем вообще моделировать реальный мир, почему не ограничиться функциями, процедурами и алгоритмами? На этот вопрос отвечает все тот же первый абстрактный переход - для человека! Человек, не машина, он всегда стремится упростить то, что сложно, а любая банковская, корпоративная или государственная системы сложны по своей природе и писать для них софт через алгоритмы и процедуры все равно, что строить замок из спичек. Архитектура же пытается решить абсолютно ту же проблему, просто, когда сам язык не вмещает в себя конструкции, нужные для упрощения разработки, это просачивается наружу и реализуется через паттерны, фреймворки и стандартные библиотеки, но меняет ли это суть принципиально? Думаю нет, просто мы развиваем идею человеко-читаемых программ в идею человеко-понимаемых систем, но суть остается та же!
Эти и многие другие теории не меняли общей сути программирования, одни языки перенимали одни подходы, другие другие, но доминирующей идеи не было, дискуссия о том, какой принцип лучше всего адаптирует разработку под человека затянулась на долгие десятилетия и наверное ответа нет до сих пор. Так может и не произошло второго абстрактного перехода и мы все еще пожинаем плоды первого? Признаюсь честно, тут я немного замешкался и хотел уже оставить затею вывести эти уровни абстракции, все как будто сводится только к удобству восприятия кода человеком, а это все тот же первый уровень абстракции! Признаюсь эта идея не давала мне покоя, у меня был свой интерес в этом разобраться. И вот спустя несколько дней, я сижу на балконе, пью кофеёк и до меня доходит!
Итог
Целью первого абстрактного перехода был человек и в конечном счете любой язык или технология стали понятны человеку. НО! На одном и том же языке (понятном всем) можно написать игру, а можно биллинговую систему, но напишет ли сходу разработчик игр биллинговую систему и наоборот? По мере развития IT в него заходили новые компании и приносили свои предметные области и по сути произошла тихая доменная революция, это был момент, когда человек перестал быть центром разработки, им стала предметная область. Назвать конкретную дату тут конечно сложно, так как ориентация на предметную область случалась и раньше, но в какой-то момент они усложнились настолько, что современный разработчик уже не просто должен знать язык, он вынужден знать доменный стек.
Поняв цель нового перехода, давайте ретроспективно посмотрим, как он повлиял на сами языки, мы ведь ради программирования все это затеяли! Возьмем SQL и Golang, что у них общего? Оба решают разные задачи, имеют разный синтаксис и принадлежат разным парадигмам, но они оба достаточно сильно зависят от своих областей применения, то же становится верным и для остальных! Но есть же полноценные языки общего назначения, как быть с ними? Так как эти языки возникли в первый переход их нынешняя универсальность инерциальна и остается ровно до тех пор, пока не появляются новые pain-killer-ы и не откусывает свои части пирога. Возьмем например C++, Rust забирает performance, делая его безопаснее, Go серверную разработку. Или Java, Kotlin вытесняет её из Android, Scala забрал часть серверной и data-инженерии, тот же Go забирает инфраструктурные и backend задачи, в общем список можете продолжить сами, он большой.
В общем именно идея предметно ориентированных языков и технологий сейчас правит балом, главное свойство, это дробление монолитных технологий и рождение новых "маленьких" языков и технологий. Тут конечно можно было бы и остановиться, по сути мы подошли вплотную к сегодняшнему дню и все более менее встало на свои места, но у второго перехода есть одно крайне негативное свойство - хаос. Тысячи технологий, сотни языков, доменный стек разработчика растет с каждым годом, ничего не напоминает? Все та же пресловутая сложность, с которой долгие годы боролись целые поколения инженеров! Но как современному разработчику вырваться из доменного рабства, как будто человеку нечего противопоставить предметной области, она по-умолчанию выше него, но давайте разберемся, так ли это на самом деле!
Предметная область усложняется в основном горизонтально. Возьмем простой пример, веб-сайт. В 90-е годы это было относительно простое клиент-серверное приложение, причем и клиент, и сервер были достаточно тонкими. Один человек вполне мог держать всю систему в голове. Сегодня клиент того же веб-сайта, это уже десятки фреймворков и подходов, бэкенд и того хуже: множество баз данных под разные задачи, контейнеризация, оркестрация, кеширование, очереди, CI/CD, инфраструктура, мониторинг, безопасность. Тут можно возразить, что нагрузки выросли кратно, отсюда и сложность системы, но это лишь часть правды. Да, системы стали обрабатывать больше данных, пользователей и запросов, но рост нагрузки сам по себе не объясняет такого разнообразия технологий. Если бы дело было только в нагрузке, мы бы увидели эволюцию вглубь: более мощные базы данных, более быстрые серверы, более эффективные алгоритмы. Но вместо этого мы видим взрыв вширь, десятки альтернативных решений для одной и той же задачи, каждое со своим подходом, своими ограничениями и своим языком. Более того, подавляющее большинство проектов никогда не достигает масштабов, требующих такой сложности, но при этом используют те же инструменты. Это означает, что сложность стала не следствием нагрузки, а следствием самой раздутой экосистемы.
И в этом смысле разработчик действительно оказывается в своеобразном доменном рабстве: чтобы решить даже относительно простую задачу, он вынужден ориентироваться в десятках технологий, каждая из которых диктует свои правила, ограничения и способы мышления. Проблема в том, что это рабство не навязано извне, оно возникает естественным образом из фрагментации знаний. Мы сами строим системы, которые уже не можем целиком удержать в голове, и потому вынуждены подчиняться их частям.
Но если это так, то возникает вопрос: действительно ли предметная область стала выше человека, или же мы просто потеряли способ работать с ней как с единым целым?
Третий переход
И вот тут интересно! Скажу сразу, третий переход, наступает на пятки сильно быстрее второго, потому что управлять этим зоопарком сложно. На этом фоне возникают различные подходы, направленные на решение этой проблемы, как раз всякие driven, first и based подходы, но решают они ее только отчасти, да, где-то код становится писать проще, что-то генерится автоматически, но все они имеют свой base слой, который также часто зависим, например API-first предлагает нам воспринимать ПО как придаток к API, но API явно не тянет на универсальный язык, так как некоторые системы монолитны по своей сути, например игры. Тогда может Domain-driven? Нет, потому что бизнес - очень слабая абстракция, один и тот же бизнес может иметь множество разных форм реализации на земле и лепить из этого единый язык все равно, что пытаться найти лжеца в игре, где лгут все. Тогда наверное AI-driven, уж он то точно предлагает реальную независимость! Не совсем, но давайте разбираться!
Искусственный интеллект
AI-driven подход состоит из двух элементов: язык и сам AI, начнем с языка. Как уже писалось в прекрасной статье "Почему наш язык — худший язык для программирования" естественный язык, на котором мы сейчас общаемся с ИИ не подходит, но что если создать достаточно строгий, формальный язык общения с ИИ? Ну он конечно уже создается, например CodeSpeak, но представим, что мы создали прям идеальный язык "программирования" ИИ, неужели мы тогда действительно совершим третий переход? Тут перейдем ко второму элементу - самому ИИ.
История у него богатая и сам по себе Искусственный интеллект имеет кучу разных оснований, и вероятностный, и логический, и эволюционный, но поговорить я хочу про то основание, вокруг которого весь хайп, а именно вероятностный.
Современные LLM содержат в себе миллиарды параметров, и эти параметры отражают знания из огромного корпуса данных в том числе и программного кода. Миллионы репозиториев, тысячи подходов, бесконечное количество реализаций одних и тех же идей, всё это попадает внутрь модели. Если посмотреть глубже, то пространство программирования устроено неравномерно. С одной стороны, у нас есть относительно ограниченное количество фундаментальных сущностей: принципы, алгоритмы, паттерны и вряд ли их очень много. С другой стороны, у каждого из них есть множество проекций на конкретные технологии и вот это пространство уже растет экспоненциально. LLM работают именно в этом расширенном пространстве. Они не оперируют напрямую принципами, они оперируют их реализациями. В результате одна и та же идея может быть представлена десятками, а иногда и сотнями различных вариантов, от удачных до откровенно слабых. Модель не знает, какая из них лучшая в абсолютном смысле, она лишь оценивает вероятность той или иной последовательности в заданном контексте. И здесь возникает ключевой момент. LLM отлично справляются с ролью навигатора: они помогают быстрее находить решения в огромном пространстве реализаций, подсказывают варианты, ускоряют разработку. Но они не уменьшают само это пространство. Если же мы хотим предсказуемости и гарантированного качества, нам приходится отбрасывать неэффективные реализации, или как-то заставлять ее применять эффективные. Но тогда, если нас интересует однозначное соответствие эффективный принцип - эффективная реализация, то зачем нам система, которая по своей природе устроена иначе? На самом деле у меня есть свое видение третьего перехода.
Мета-язык
Что еще за мета-язык и зачем он вообще нужен? Давайте разбираться!
Как я уже сказал, есть проблема избыточности решений, вызванная вторым переходом, язык + LLM не работает, что же делать? Неужели мы и вправду в конце времен и нам суждено утопать в этом алом океане? Не совсем!
Скажу сразу, я разрабатываю свой мета-язык, о котором расскажу в следующей статье, а пока продолжим!
На самом деле мета-язык это не что-то новое, история уже помнит некоторые попытки создания подобных языков, в той же дискуссии "NATO Software Engineering Conferences", а это 1969 год, уже говорилось о неком SSL (Software Specification Language), но тогда не было конкретных предложений, только намеки. При этом за несколько лет до этого уже была придумана методология VDM (Vienna Development Method), а в 1970 году она обзавелась своим языком VDM-SL, который важен лишь в контексте истории и разумеется полноценным мета-языком не является. Но что же дальше?
А дальше рождается куча как языков спецификации, так и языков конфигурации, каждый из которых решает частные задачи: кто-то для формального описания требований, кто-то для генерации кода, кто-то для автоматизации инфраструктуры. В 80–90-е годы появляются CASE-средства, языки вроде SDL (Specification and Description Language), а также развивается идея визуального описания систем, которая в итоге приводит к появлению в 1995 году языка UML. UML стал, пожалуй, одной из самых амбициозных попыток подняться не только над кодом, но и над предметной областью, но на практике он так и не стал универсальным языком разработки, оставшись инструментом документации и проектирования. Дальше уже возникают более прикладные форматы, которые постепенно становятся частью инженерской повседневности. В 1998 году появляется XML, язык разметки для структурированных документов, который быстро превратился в универсальный инструмент обмена данными между системами. В ответ на громоздкость XML возникают более легковесные форматы: JSON в 2001 году становится стандартом для веб API и клиент-серверного взаимодействия, YAML чуть позже завоевывает популярность в DevOps. Не отстают и другие форматы, TOML появляется как удобная разметка конфигурационных файлов, Proto дает бинарный и компактный способ сериализации данных, а внутри инфраструктуры и облачных платформ рождаются свои языки и инструменты: HCL у Terraform, Kustomize и Helm Charts у Kubernetes. Каждый из этих языков и форматов решает узкую задачу: кто-то описывает структуру данных, кто-то инфраструктуру, кто-то бизнес-правила. Но при этом ни один из них не умеет объединять все эти уровни в единую систему. Так как все эти мета-языки появились в основном во втором переходе, они дают мощные инструменты для своего домена, но проблему хаоса разумеется не решают.
Думая об этих языках можно заметить закономерность: все они пытаются описывать системы на более высоком уровне, но каждый делает это внутри своей области и своими средствами. Никто из них не претендует на универсальность, и, более того, большинство из них не ставят перед собой такой цели. Отсюда возникает вопрос, а каким вообще должен быть язык, который действительно способен претендовать на следующий уровень абстракции, какие требования мы к нему предъявляем?
Давайте попытаемся сформулировать эти требования! Я предлагаю следующее:
Принципиальная абстракция: язык должен быть независим от конкретных предметных областей, языков и технологий, но при этом позволять описывать их внутри себя.
Уровни абстракции: развивая первый пункт, язык должен позволять описывать произвольные уровни абстракции, не смешивая их между собой.
Выразительность: язык должен обладать достаточной выразительной силой, чтобы описывать широкий спектр предметных областей, от инфраструктуры до бизнес-логики.
Формальность: язык должен быть достаточно строгим и формальным, чтобы любые конструкции имели однозначную интерпретацию и могли быть проверены автоматически.
Компилируемость: программы на этом языке должны компилироваться не в одну конкретную технологию, а в набор технологий, соответствующих задаче.
Компактность: программа на этом языке должна быть сильно проще и короче, в идеале в разы, чем на языке второго уровня абстракции, мы ведь упростить себе жизнь хотим!
Предсказуемость: результат компиляции должен быть детерминированным, один и тот же код всегда приводит к одному и тому же результату.
Интероперабельность: язык не должен ломать существующую экосистему, а наоборот, уметь в нее встраиваться.
В ходе своего рассуждения я выделил три абстрактных перехода в истории программирования. Возможно, вы выделите другие или не согласитесь с моей интерпретацией, и это нормально, сама тема требует обсуждения. Но если в этих рассуждениях есть рациональное зерно, то мы сейчас находимся в точке, где программирование снова готово изменить форму: от кода к знаниям о коде. И если это действительно так, то следующий язык, который изменит индустрию, будет не просто языком программирования, он будет языком мышления.
Не буду кривить душой, я очень заинтересован в дискуссии на эту тему, ведь как я и сказал, я разрабатываю свой мета-язык, поэтому, если у вас есть, что сказать или возразить, или поддержать, прошу вас пишите в комментариях или мне в телеграмм:
Искренне благодарю вас, что дочитали до конца!
Комментарии (36)
amcured
10.04.2026 11:51UML стал, пожалуй, одной из самых амбициозных попыток подняться не только над кодом, но и над предметной областью
Вы путаетесь в уровнях абстракции, UML — это инстанс MOF. Невозможно разработать «метаязык», потому что он станет еще одним инстансом AST. А вот MetaAST разработать как раз можно, и я мог бы даже подискутировать, если бы вы показали ваш подход к построению AST (и примеры самого дерева).
Но устанавливать ради этого кривое поделие юродивого Пашеньки я не готов, @ammotion:matrix.org
Dhwtj
10.04.2026 11:51Половина UML гвоздями прибита к ООП: классы, объекты, наследование, пакеты
amcured
10.04.2026 11:51Разумеется. Потому что UML — это инстанс MOF для этой предметной области. При этом Хаскель волшебно описывается на FMS, который ничто иное, как неуклюжий потомок FML, который тоже инстанс MOF.
Но это все слишком сложно, тут разработка, а не компутер саенс, так что просто захреначим «метаязык» и будет счастье.
NekitaKamenev Автор
10.04.2026 11:51Невозможно разработать «метаязык», потому что он станет еще одним инстансом AST
Смотря, что понимать под мета-языком и про какой именно AST вы говорите, если речь про AST целевых языков, то я скорее говорил о модели, которая описывает систему до выбора конкретных языков и технологий, следовательно независящей от их внутренних представлений.
А если вы говорите про AST самого мета-языка, то мета-уровень здесь достигается не за счет синтаксиса, а за счет семантики, язык описывает структуру и поведение системы: сущности, отношения, ограничения, синтаксис тут вторичен.amcured
10.04.2026 11:51я скорее говорил о модели, которая описывает систему до выбора конкретных языков и технологий, следовательно независящей от их внутренних представлений
Это метамодель, а для ваших целей нужна мета-мета-модель.
Код, короче, покажите — я объясню, что с ним не так.
NekitaKamenev Автор
10.04.2026 11:51О каком коде вы говорите? BNF грамматика, CST или AST? Или семантический анализ или код на самом мета-языке? Я планирую в следующей статье/статьях рассказать подробнее о языке с примерами кода и конкретными техническими решениями.
OlegZH
10.04.2026 11:51Невозможно разработать «метаязык», потому что он станет еще одним инстансом AST.
А не поясните, что такое AST? Abstract syntax tree? Что же Вы имеете в виду?
amcured
10.04.2026 11:51Ну я же дал ссылку на MOF. Реализация — это инстансы, M⁰. Модель — это классы, M¹, UML — это классы классов, мета-модель, M². MOF — это M³, мета-мета-модель.
Любой язык обречен болтаться на уровне реализации M², а для того, чтобы сделать то, что хочет автор — нужна M³. MetaAST, реализацией которого станут AST (M²), со своими языками — M¹.
Абстрактное синтаксическое дерево для выражения синтаксических деревьев низшего порядка. Никакими «семантиками, структурами и поведениями системы» выразить M³ не получится в принципе, поэтому автор либо лукавит, либо у него есть в голове неплохая идея, как выразить которую — он не имеет ни малейшего представления. Ну поглядим, делов-то. Направление очень верное, но непростое.
NekitaKamenev Автор
10.04.2026 11:51Любой язык обречен болтаться на уровне реализации M²
Ну это, если мы принимаем продукцию OMG как нечто незыблемое, на деле же, это не совсем так. Думаю MOF - не предел выразимости.
у него есть в голове неплохая идея, как выразить которую — он не имеет ни малейшего представления
Мой подход основывается не на моделях из мира ООП, я идейно отталкиваюсь от логического подхода. Рассуждение простое, любая предметная область или технология - данные, но не простые данные, а вполне структурированные логически
связанные данные, представимые в виде отношений, например:функция1 вызывает функцию2у нас есть отношение вызывает(функция1, функция2), как если бы мы писали на языке вроде Datalog, но для подобных языков нет разницы между субъектом, предикатом и объектом, по сути это просто комбинаторика констант, переставляем их местами (SPO, SOP, PSO ...), строим префиксные боры и делаем запросы, но на практике есть некоторые вполне универсальные свойства отношений, такие как включение, направленность, ассоциативность и так далее, которые в классических логических языках отдельно не представлены, также нет отдельного позиционирования сущностей, если хотим выразить декларацию сущности, пишем что-то типа существует(сущность), также нет разделения на миры (онтологии), что крайне важно для разделения на уровни абстракции и оптимизации вычислений, в общем оcнование крайне мощное, но под те требования, что я перечислил оно не адаптировано. Мой язык является попыткой решения этих проблем, более конкретно о том, как именно он это решает я попытаюсь рассказать в следующей статье/статьях, разумеется я не пытаюсь создать Datalog++, но идейно мне это направление кажется верным.
Но соглашусь с вами, задача действительно сложная, я тут не пытаюсь выдать мнимое за действительное, я сам хочу разобраться в том, как вообще можно реализовать такой язык.
amcured
10.04.2026 11:51если мы принимаем продукцию OMG как нечто незыблемое, на деле же, это не совсем так. Думаю MOF — не предел выразимости.
[…] на моделях из мира ООП
Боюсь, вы недооценили консорциум. MOF не имеет никакого отношения к миру ООП, ровно наоборот, смысл мета-мета-модели как раз в том, что в проекциях этого измерения одинаково легко выражать ООП, ФП и любое другое П. UML — это просто одна из проекций (инстансов), для ООП (потому что ООП тогда было на коне, она и проработана лучше всего, но это не значит, что FML — и её неуклюжий потомок FMS — как-то вдруг сложно реализуемы).
OlegZH
10.04.2026 11:51Принципиальная абстракция: язык должен быть независим от конкретных предметных областей, языков и технологий, но при этом позволять описывать их внутри себя.
Это как? Давайте рассмотрим какие-нибудь примеры. Есть люди, у каждого человека есть фамилия, имя и отчество. (Бывают и особенности — национальные или исторические.) Каждый человек участвует в различных отношениях: здесь он — конечный пользователь системы, вот здесь — контрагент, там — директор фирмы или разработчик, а ещё — пользователь (читатель) библиотеки, и т.д. и т.п. У человека/организации есть адрес, может быть счёт в банке, ИНН, БИК, СНИЛС. И... куча всего!
Где, куда и как абстрагировать?
Это для нас некий набор цифр — это номер телефона. Мы это знаем. Для себя. А для системы — это просто набор цифр и набор действий, которые нужно с этими цифрами делать. Семантика всегда оказывается за пределами рассмотрения, а метаданные — это, как раз, немного другой (более высокий) уровень абстракции. Семантика, всё-равно, от нас так или иначе ускользает.
А что предписывает наука?
Наука предписывает, что у каждой предметной области должен быть свой язык. У такой области, как программные системы то же имеется свой язык — язык представления программных систем. А ещё должен быть и третий язык — язык для перевода (трансляции) первого языка на второй. Вот эта конструкция из трёх языков и есть решение задачи.
Продолжение следует... (с)
NekitaKamenev Автор
10.04.2026 11:51Вопрос концептуальный и он очень правильный.
Где, куда и как абстрагировать?
Вы сами отчасти ответили на свой вопрос. Вы начинаете с человека как универсальной абстракции, а потом иерархически спускаетесь по своим уровням абстракции и приходите к константным сущностям, вроде ИНН или СНИЛС.
Наука предписывает, что у каждой предметной области должен быть свой язык. У такой области, как программные системы то же имеется свой язык — язык представления программных систем. А ещё должен быть и третий язык — язык для перевода (трансляции) первого языка на второй. Вот эта конструкция из трёх языков и есть решение задачи.
В целом как будто да, но этот третий язык должен одинаково хорошо переводить языки друг в друга, отсюда как раз возникает проблема его универсальности, если из одного в другой мы как-то можем перевести, то как быть с их декартовым произведением, каким будет третий язык в этом случае?
forthuse
10.04.2026 11:51И, ни слова про Форт (Forth) язык или другой конкатенативный! Обидно прям. :)
P.S. А, ведь были же умельцы, статья: Цифровая капсула времени: как я в 2026 запустил свой IDE, написанный в 1998 году на FORTH, что общего между Фортом и 1С, и что скажет о проекте современный ИИ https://infostart.ru/1c/articles/2634967/
VanKrock
10.04.2026 11:51На самом деле тут можно представить немного иначе 1 уровень: Абстракция над железом (языки программирования) 2 уровень: Абстрация над над реализацией(протоколы JSON, SQL, XML…) но не столько как сами эти технологии, сколько апи построенное на их базе 3 уровень: по идее это должна быть абстракция над интерфейсом, я не считаю что ИИ как то решает эту проблему, я скорее воспринимаю ИИ как инструмент, например как IDE. А вот тот же neuralink и вполне возможно
2medic
10.04.2026 11:51Не с того начинаете. Начинать нужно с природы самого мышления. Многие считают, что мышление неотделимого от разговорного языка. Мол, мы думаем словами и мыслить без этого невозможно. Но это не совсем так, доказано пару веков назад Иваном Сечиным.
В работе «Рефлексы головного мозга» он прямо указывает, что мышление имеет физиологическую основу и не сводится к речи. В другой своей работе, «Элементы мысли» он развивает эту идею.
Если упростить: у нас уже есть «механизм мышления», встроенный на уровне физиологии. Язык не создаёт мысль — он лишь оформляет её и делает доступной для передачи.
У человека есть потребность делиться мыслями, он удовлетворяет её с помощью речи. Если речь недоступна, вход идёт жестовый язык, как, например, у глухих.
Язык — это инструмент коммуникации, а не сама мысль. Как любой инструмент, он вносит искажения. В языке неизбежно появляется абстракция. Когда мы формулируем мысль словами, мы её упрощаем, отбрасываем детали, подгоняем под существующие конструкции.
То есть теряем точность.
У Никонова есть прекрасный текст:Образовательный, нравственный, интеллектуальный уровень попов разный, и на один и тот же вопрос они зачастую дают разные ответы.
В итоге Бог в нашем мире ведет себя так, будто его нет.
Но даже если бы Он начал по пятницам выступать по телевизору со своими проповедями и инструкциями по правильному поведению в разных ситуациях, уже через пару недель несчастный Господь увяз бы в поправках, разъяснениях и подпунктах: «Те слова, которые, применительно к ситуации, что я описывал как пример в позапрошлую пятницу, и которые, как выяснилось, не все правильно поняли, в иных ситуациях, о которых я доложу ниже, необходимо понимать с учетом тех поправок, которые будут ясны из следующих примеров…».
А уж если учесть, что люди постоянно умирают и рождаются, несчастный Господь совсем измучился бы в повторах, разъяснениях и примерах конкретных ситуаций. Потому что в разных ситуациях участвуют разные люди, и на всех единых инструкций не напасешься
И вот тут мы возвращаемся к программированию.
Когда кто-то говорит: «Давайте создадим язык, на котором можно программировать почти как думаешь» — в этом заложена ошибка. Думаем мы не на языке. Мысль — это более глубокий процесс, который существовал ещё до появления языка.
Любой язык — будь то Python, SQL или «супер-человеко-понятный DSL» — будет вводить структуру, навязывать свою модель, отбрасывать нюансы.
То есть неизбежно искажать исходную мысль.
Поэтому не будет волшебного языка, который уберёт разрыв между мыслью и кодом.
OlegZH
10.04.2026 11:51Поэтому не будет волшебного языка, который уберёт разрыв между мыслью и кодом.
Подождите! У нас же есть свой собственный язык. На котором мы говорим и пишем, и, надеюсь, и думаем. Почему нельзя использовать естественный язык? Разве LLM не есть реализация такого подхода? Разве это не то самое литературное программирование, о котором говорил в своё время Дональд Кнут?
2medic
10.04.2026 11:51У нас же есть свой собственный язык
У нас есть свой язык. У глухих свой. Да тоже не один. У французов есть слово, обозначающее дерево без листьев, у нас нет. Зато у нас есть слово «спешиться», а у них нет, и они используют: ноги на землю. Серьёзно. У них даже дорожный знак такой есть для велосипедистов, с этими самыми словами.
Это уже показывает, что язык — это не отражение мышления, а система соглашений, которая по-разному кодирует один и тот же опыт.
и, надеюсь, и думаем
Мыслить можно и без разговорного языка. Иначе пришлось бы признать, что глухонемые не думают (что очевидно не так), животные не думают (что тоже противоречит наблюдениям), ребёнок до освоения речи не обладает мышлением.
Теперь к идее «почему бы не программировать на естественном языке».
Проблема в том, что естественный язык зависит от контекста. Многие смыслы слов достраиваются из контекста. Естественный язык многозначен и допускает интерпретации.
То есть он не точен в принципе.
Именно поэтому в программировании появились формальные языки — не потому что люди «не додумались» до естественного, а потому что он плохо подходит для точного описания.
Что касается LLM.
Большие языковые модели — это не исполнение естественного языка, а скорее статистическое угадывание наиболее вероятной интерпретации текста. Исполнение алгоритма: найди мне текст, максимально похожий на ответ вот на этот вопрос (промт).
Они создают иллюзию понимания, но под капотом всё равно требуется формализация, уточнение и снятие неоднозначностей.
Именно поэтому с ними приходится переписывать промпты, уточнять формулировки и бороться с галлюцинациями.
Если бы естественный язык был точным — этого бы не было.
Теперь про Дональда Кнута и про его Литературное программирование.
Там идея немного другая.
Кнут не предлагал заменить код естественным языком. Он предлагал писать программу как текст для человека, где код встроен в объяснение.
То есть язык остаётся формальным, а естественный язык используется для пояснения.
bagrovdigital
10.04.2026 11:51Спасибо за глубокий комментарий. Вы абсолютно правы в том, что естественный язык (и любой линейный синтаксис) вносит искажения при фиксации мысли — это классическая проблема, которую ещё Платон описывал в «Федре».
Но позвольте задать вопрос в развитие вашей мысли: а что, если проблема не в «языке вообще», а в том, что мы до сих пор используем для программирования знаковые системы, оптимизированные под коммуникацию, а не под фиксацию инвариантов деятельности?
Есть направление — СМД-методология (Г.П. Щедровицкий, Анисимов), — которое как раз исходит из того, что:
Мышление — это деятельность, а не просто «процесс в голове»
Знак может быть не только словом, но и схемой, где элементы фиксируют онтологические категории, а не грамматические конструкции
Искажение минимизируется не за счёт «приближения к мысли», а за счёт рефлексивного проектирования самой знаковой системы
В этой рамке «мета-язык третьего перехода» — это не «волшебный язык, на котором думаешь», а искусственная знаковая система, где схема деятельности может быть верифицирована, исполнена и перепроектирована без потери инвариантов.
Если вам интересно копнуть в эту сторону — рекомендую начать с работ О.С. Анисимова по «схематизации» или лекций П.Г. Щедровицкого о промышленных революциях и мета-навыках.
Как вы смотрите на то, что проблема «разрыва мысли и кода» может решаться не через «более человеческий синтаксис», а через иную онтологию знака?
OlegZH
10.04.2026 11:51Мне кажется, что философы ещё где-то в первой половине 20-го века заметили, что языки делятся на аналитические, позволяющие хорошо описывать структуры, вложенность одних объектов в другие, то есть — наличное бытие, а есть — синтетические, позволяющие описывать динамическое поведение и создание нового. Всё, с чем мы имеем дело, это суть аналитические языки. Включая и UML. А нужны какие-то новые языки.Ориентированные на процессы. В этом смысле, функциональное программирование предлагает некий подход к решению этой проблемы. Действительно, что такое
1 + 10? Это процесс последовательного увеличения числа не единицу! И так 10 раз!!
2medic
10.04.2026 11:51Даже научные формулировки — это уже сжатие смысла в термины. Например, «филогенез повторяет онтогенез» — это не сырая мысль, а упаковка сложных теорий в знаковую конструкцию, где каждый термин уже несёт выбор границ и интерпретаций.
Поэтому мы никогда не оперируем мыслью напрямую — только знаками, в которые она заранее сжата.
vadimr
10.04.2026 11:51Тут проще всего заметить, что применение компьютеров не ограничивается мыследеятельностью и даже не очень с ней связано. Поэтому ключ Щедровицкого не от того замка.
Сам он на своих семинарах мгновенно пресекал неправильно, по его мнению, поставленные вопросы.
Любая программа, включая искусственный интеллект – это, в некотором смысле, противоположная мыследеятельности вещь, так как представляет собой целесообразную деятельность, обособленную от мышления.
rukhi7
10.04.2026 11:51удивительно читать свои мысли в чужих формулировках! Хотя я не знал что
Начинать нужно с природы самого мышления.
но определенно думал о том что "не будет волшебного языка, который уберёт разрыв между мыслью и кодом." то есть универсального языка, который подходит к любой предметной области.
Я больше думал о том как сформулировать что до того как написать решение вычислительной задачи, нужно четко сформулировать саму задачу как вычислимую(!) задачу. Основная проблема программирования в том что мы пытаемся запрограммировать (написать алгоритм вычисления) того что не получается, что называется, посчитать в лоб, в условиях ограничений реального мира, то есть ограниченного времени, памяти, отсутствия должной синхронизации между вычислениями и процессами реального мира (предметной области) с которыми эти вычисления должны взаимодействовать. То есть проблема как раз с абстракциями, НО при формулировке задачи. С абстракциями, которые отбрасывают условия реального мира которые на самом деле необходимо учитывать.
Но это еще если не рассматривать ситуации когда запрограммировать пытаются вообще без более менее сформулированной идеи-мысли, просто по наитию, перебирая варианты, пока, вдруг, не заработает. Как ни странно есть очень много кода который работает не потому что сделали чтобы работало, а потому что случилось чудо - ВДРУГ заработало и никто не знает и не пытается понять почему это стало возможно. Никакой язык тут очевидно не поможет, если изначально нет идеи никакой синтаксис не будет достаточно удобным чтобы волшебным образом выразить то чего нет.
OlegZH
10.04.2026 11:51Уровни абстракции: развивая первый пункт, язык должен позволять описывать произвольные уровни абстракции, не смешивая их между собой.
Может быть, для каждого уровня абстракции иметь свой язык?
Например, есть номер телефона. На уровне базы данных, номер телефона — это набор цифр определённого формата. А на уровне пользовательского интерфейса? По идее, мы должны полностью описать табличное поле на стороне базы данных, но, в действительности, мы воспроизводим в пользовательском интерфейсе тот же самый тип данных, что и в БД. А можно не делать этого? На самом деле, в пользовательском интерфейсе есть просто какое-то поле для ввода, но его функционирование должно брать весь код из БД.
OlegZH
10.04.2026 11:51Выразительность: язык должен обладать достаточной выразительной силой, чтобы описывать широкий спектр предметных областей, от инфраструктуры до бизнес-логики.
А чем плохо, если у нас будет два языка для двух различных предметных областей и ещё один язык для написания трансляторов с языка одной предметной области на язык на другой?
Если у нас есть уровни, то связь уровней осуществляется через интерфейс, то есть — через посредство отображение сущностей одного уровня на сущности другого.
Free_Artist
10.04.2026 11:51Если будет создан универсальный язык для программистов, то его будут также лениться учить и всё равно пользоваться моделями, которые с высокой вероятностью угадывают в пользовательском бормотании релевантные паттерны и накидывают варианты. Мечта о халяве и одной кнопке, которая "делает волшебство" неискоренима)
AbitLogic
10.04.2026 11:51Абстрогируй, абстрогируй но не доабстрагируйся... Какой инженер? Первую абстракцию сделала Ада Лавлейс за 100 лет да него, увидев в аналитической машине Бэббиджа нечто большее чем просто посчитать логарифм
ayrtonSK
10.04.2026 11:51На самом деле останутся только те кто создает смыслы и те кто делает что то руками(пока).
Если 30 лет назад надо было сидеть и программировать месяцами для простого, то сейчас вот вот наступит эра когда можно будет не управлять десятками и сотнями разработчиков и других, а просто ии сказать делай то и то и самому управлять созданием приложения, а не ждать пока руки свои или других разработчиков это сделают. Сейчас пока ещё нужна мощная структура, архитекторы, разработчиков, qa, devops и прочих, а скоро это не надо будет. Хватит одного.
qmained
10.04.2026 11:51Однажды роботы будут сделаны при относительной доступности столь хорошо, что смогут заменить весь ручной труд. Тогда всё человечество на мороз. Особенно, если они научатся чинить самих себя.
vadimr
Это (в императивном языке) не декларация намерения, а всего лишь алгоритм вычисления. Разница проявляется, когда есть побочные эффекты (а без них императивное программирование невозможно).