The post has been translated automatically. Original language: Russian
Most developers treat the program as source code.
The Git repository, thousands of files, tests, documentation — it seems that this is where the system itself is located.
But in 1985, Danish scientist Peter Naur proposed a completely different view.
In his work Programming as Theory Building, he argued that the program exists not only in the form of text.
A real program is a theory that lives in the minds of developers.
It explains why the system works the way it does.
Why the code is not enough
Imagine that a team has been developing a complex system for several years.
Architectural solutions are emerging.
Compromises are accepted.
Dozens of alternatives are rejected.
Internal rules are being developed.
After a while, the new engineer opens the repository.
He sees the source code.
But he doesn't see the main thing.
Why is the processor instruction implemented this way?
Why is this particular memory model used?
Why did the operating system abandon classic processes?
Why did the programming language get this particular architecture?
The code answers the question "what".
But he almost never answers the question "why."
We came across this during the development of Memora8.
We are developing our own Memora8 64-bit processor, the Reganta OS operating system, the Sekura JS programming language, and related tools.
Each change goes through several levels of the platform at once.
The processor architecture affects the ISA.
The ISA affects the compiler.
The compiler affects Sekura JS.
Sekura JS affects the Firmware Kernel.
The Firmware Kernel defines the Reganta OS execution model.
As a result, one decision can change the entire system.
A year after the implementation, no one remembers all the details of the discussion.
It was then that we realized how right Peter Naur was.
The most valuable part of the project is not in the repository.
It exists as an understanding of architecture.
Documentation doesn't help either
The first thought is obvious.
We need more documentation.
We wrote Markdown.
They maintained a Wiki.
We created technical specifications.
But the number of documents grew faster than the understanding of the system.
Different versions of the same idea appeared.
Drafts.
Outdated solutions.
Documents that no one else has opened.
It turned out to be a large repository of information.
But not a unified theory of the system.
That's how Noda appeared.
Initially, Noda was created as an internal tool of the team.
Not for storing all documents.
And for storing current engineering knowledge.
Every architectural idea is discussed.
After that, one canonical article appears.
It becomes part of the general theory of the platform.
If the architecture changes, the canon changes.
If the decision is reversed, it ceases to be considered valid.
In this way, the team supports more than just documentation.
It supports a general model of understanding the system.
Theory becomes available to AI
Today, large language models are able to work perfectly with natural language.
But by themselves, they don't know which information is right for your project.
If you give a model an archive of thousands of documents, she will try to determine on her own what to believe.
This does not always work well.
We use a different approach.
The LLM only gets access to approved canonical knowledge.
It turns out an interesting combination.
The language model is responsible for understanding the question, explaining it, and engaging in dialogue.
The canonical knowledge base is responsible for reliability.
As a result, the AI does not try to guess the architecture of Memora8.
He explains exactly the architecture that the team adopted.
Programming as a theory building
Peter Naur's strongest thought sounds surprisingly modern.
When an experienced developer quits, the company loses much more than the author of the source code.
She's losing someone who understood the system.
This theory cannot be restored automatically.
It cannot be extracted only from the source code.
It cannot be fully obtained even from the documentation.
It exists as a set of accepted engineering solutions.
That is why knowledge becomes the main asset of a complex project.
Noda as a continuation of the idea of Naura
We do not consider Noda to be a documentation search engine.
And we don't consider it another Wiki.
For us, this is a tool for preserving the general theory of the system.
When the developer asks:
"Why is Memora8 designed this way?"
or
"Why does Reganta OS use a modular execution model?"
The AI does not try to deduce the answer on its own.
He refers to the knowledge that has already been generated by the engineering team.
It turns out to be a new generation expert system.
Experts form knowledge.
The team approves canonical articles.
LLM makes this knowledge accessible to humans through natural language.
Instead of output
Forty years have passed since the publication of Peter Naur's article.
During this time, Git, cloud services, DevOps, containers, and large language models have emerged.
But his main conclusion remains unchanged.
A program is not just a code.
It is a theory that combines architecture, engineering solutions, and an understanding of the entire system.
When developing the Memora8 processor, Reganta OS, and the Sekura JS language, we came to the same conclusion.
The source code can be restored from a backup.
Architectural understanding is not.
That is why today we pay so much attention to the preservation of canonical knowledge.
Because they are the ones that allow the system to develop consistently, and the team to speak the same architectural language.
Большинство разработчиков воспринимают программу как исходный код.
Репозиторий Git, тысячи файлов, тесты, документация — кажется, именно здесь находится сама система.
Но в 1985 году датский ученый Питер Наур предложил совершенно другой взгляд.
В своей работе Programming as Theory Building он утверждал, что программа существует не только в виде текста.
Настоящая программа — это теория, которая живет в головах разработчиков.
Именно она объясняет, почему система устроена именно так.
Почему кода недостаточно
Представьте, что команда несколько лет разрабатывает сложную систему.
Появляются архитектурные решения.
Принимаются компромиссы.
Отвергаются десятки альтернатив.
Разрабатываются внутренние правила.
Через некоторое время новый инженер открывает репозиторий.
Он видит исходный код.
Но не видит главного.
Почему инструкция процессора реализована именно так?
Почему используется именно такая модель памяти?
Почему операционная система отказалась от классических процессов?
Почему язык программирования получил именно такую архитектуру?
Код отвечает на вопрос «что».
Но почти никогда не отвечает на вопрос «почему».
Мы столкнулись с этим во время разработки Memora8
Мы разрабатываем собственный 64-разрядный процессор Memora8, операционную систему Reganta OS, язык программирования Sekura JS и сопутствующие инструменты.
Каждое изменение проходит сразу через несколько уровней платформы.
Архитектура процессора влияет на ISA.
ISA влияет на компилятор.
Компилятор влияет на Sekura JS.
Sekura JS влияет на Firmware Kernel.
Firmware Kernel определяет модель исполнения Reganta OS.
В результате одно решение может изменить всю систему.
Через год после реализации никто уже не помнит всех деталей обсуждения.
Именно тогда мы поняли, насколько прав был Питер Наур.
Самая ценная часть проекта находится не в репозитории.
Она существует как понимание архитектуры.
Документация тоже не спасает
Первая мысль очевидна.
Нужно больше документации.
Мы писали Markdown.
Поддерживали Wiki.
Создавали технические спецификации.
Но количество документов росло быстрее, чем понимание системы.
Появлялись разные версии одной идеи.
Черновики.
Устаревшие решения.
Документы, которые никто больше не открывал.
Получалось большое хранилище информации.
Но не единая теория системы.
Так появилась Noda
Изначально Noda создавалась как внутренний инструмент команды.
Не для хранения всех документов.
А для хранения действующих инженерных знаний.
Каждая архитектурная идея обсуждается.
После этого появляется одна каноническая статья.
Именно она становится частью общей теории платформы.
Если архитектура меняется — меняется канон.
Если решение отменено — оно перестает считаться действующим.
Таким образом команда поддерживает не просто документацию.
Она поддерживает общую модель понимания системы.
Теория становится доступной AI
Сегодня большие языковые модели умеют великолепно работать с естественным языком.
Но сами по себе они не знают, какая информация является правильной именно для вашего проекта.
Если дать модели архив из тысяч документов, она будет пытаться самостоятельно определить, чему верить.
Это хорошо работает далеко не всегда.
Мы используем другой подход.
LLM получает доступ только к утвержденным каноническим знаниям.
Получается интересное сочетание.
Языковая модель отвечает за понимание вопроса, объяснение и диалог.
Каноническая база знаний отвечает за достоверность.
В результате AI не пытается угадать архитектуру Memora8.
Он объясняет именно ту архитектуру, которую приняла команда.
Программирование как построение теории
Самая сильная мысль Питера Наура звучит удивительно современно.
Когда опытный разработчик увольняется, компания теряет гораздо больше, чем автора исходного кода.
Она теряет человека, который понимал систему.
Эту теорию невозможно восстановить автоматически.
Ее нельзя извлечь только из исходников.
Ее нельзя полностью получить даже из документации.
Она существует как совокупность принятых инженерных решений.
Именно поэтому знания становятся главным активом сложного проекта.
Noda как продолжение идеи Наура
Мы не считаем Noda системой поиска по документации.
И не считаем ее очередной Wiki.
Для нас это инструмент сохранения общей теории системы.
Когда разработчик спрашивает:
«Почему Memora8 устроен именно так?»
или
«Почему Reganta OS использует модульную модель исполнения?»
AI не пытается самостоятельно вывести ответ.
Он обращается к знаниям, которые уже были сформированы инженерной командой.
Получается экспертная система нового поколения.
Эксперты формируют знания.
Команда утверждает канонические статьи.
LLM делает эти знания доступными человеку через естественный язык.
Вместо вывода
Прошло сорок лет с момента публикации статьи Питера Наура.
За это время появились Git, облачные сервисы, DevOps, контейнеры и большие языковые модели.
Но его главный вывод остается неизменным.
Программа — это не только код.
Это теория, которая объединяет архитектуру, инженерные решения и понимание всей системы.
При разработке процессора Memora8, Reganta OS и языка Sekura JS мы пришли к такому же выводу.
Исходный код можно восстановить из резервной копии.
Архитектурное понимание — нет.
Именно поэтому сегодня мы уделяем столько внимания сохранению канонических знаний.
Потому что именно они позволяют системе развиваться последовательно, а команде — говорить на одном архитектурном языке.
Share
