Comments 12
Агглютинативные языки (от лат. agglutinatio - приклеивание) - это модель, где к неизменному корню последовательно присоединяются однозначные суффиксы
Ну вообще-то нет. В финском и эстонском основа меняется. Что составляет отдельную боль для изучающих.
Спасибо за уточнение, коллега! Вы попали в самую точку насчет финно-угорской группы.
Именно этот нюанс (изменение основы в финском/эстонском, чередование ступеней согласных) я и называю в статье "архитектурным техническим долгом". С точки зрения парсера, изменяемый корень - это side effect (побочный эффект), требующий дополнительных проверок и условий при компиляции смысла.
Мой тезис строится на поиске эталонной агглютинативной архитектуры для IT, где корень иммутабелен (неизменен) на 100%. Если мы составим бенчмарк «чистоты» агглютинативных языков, картина будет такой:
Казахский 99-100% Pure Functional Language.
Кыргызский 95-97% Почти эталон, минимальные фонетические мутации.
Турецкий 90-95% Структурно чист, но имеет исторические наслоения (лексический "легаси").
Японский 80-85% Агглютинативный строй, но с контекстной зависимостью, сложной вежливостью и исключениями.
Финский / Эстонский 70-75% Legacy Codebase. Агглютинация есть, но корень мутирует (чередование ступеней). Парсеру нужно знать контекст, чтобы восстановить исходную форму.
Русский / Немецкий 0-10% Spaghetti Monolith. Сплошные мутации состояний, исключения и зависимости.
Поэтому для построения новой архитектуры (или DSL) нам нужен именно "казахский тип" логики, где исключена мутация основы, свойственная финскому.
Устранение когнитивной перегрузки инженеров
Единый протокол вместо "зоопарка"
да, да, никогда такого не было и вот опять )))
Дело не в языке, а в сложности того, что им описывают, а язык вообще можно хоть какой использовать, если верно сложность понять - хоть на 1C писать, хоть на асме.
Зоопарк протоклов не от того, что там матрешка, а от того что данные, которые пытются формализовать очень сложные + ограничение каналов связи + ограничение клиентов - оттуда и вложенность и указание только нужных полей и тд.
Вы гуманитарий? - ибо очень похоже - им постоянно такие идеи приходят в голову, но они, к сожалению, не более чем от не понимания того, что происходит и как это работает.
По поводу "гуманитария" - улыбнуло. Я занимаюсь проектированием ядер для клиринговых систем и пишу на Go/Rust, поэтому боль от parse overhead и сериализации данных мне знакома не из учебников философии.
Вы правы в том, что сложность данных никуда не денется (inherent complexity). Но мой посыл о том, что текущие инструменты добавляют колоссальную привнесенную сложность (incidental complexity). Когда мы пытаемся описать простую транзакцию через 5 слоев абстракций, DTO и адаптеров, потому что наш "язык" (архитектурный паттерн) требует контекста - мы греем воздух.
Агглютинативный подход (как модель) предлагает снизить именно накладные расходы на парсинг и структуру. Это не про то, чтобы писать код на кириллице/латинице, а про линейную логику сборки пакета
Приведите пример такой транзакции, чтобы понять точно о чем разговор.
Так как обычно данные описаны именно на уровне данных и бизнеса, и они просто протягиваются через слои, которые с ними работают. От языка там только названия, никакой доп. сложности ни инструменты, ни слои к данным не добавляют. К общей архитектуре - да, ибо каждый слой - это отдельный сервис.
Т.е. грубо говоря как у вас есть сейчас, и к чему вы хотите прийти на примере.
После этого можно будет поговорить предметно.
Устранение когнитивной перегрузки инженеров
казахский язык
Нет, спасибо
А теперь почитайте что-то про конструирование языков и критику этого дела, и почему все эти волапюки, логланы и прочие философские языки умерли или составляют очень местечковую забаву
Илья, отличный пример с Логланом (Loglan) и Ложбаном! Это классический кейс того, как лабораторная попытка создать "идеально логичный язык" разбилась о реальность человеческой психологии. Люди не роботы, им неудобно говорить на сухом коде.
Но здесь есть два фундаментальных отличия, которые меняют суть дела:
Natural vs Artificial. Волапюк и Логлан умерли, потому что были искусственными конструктами без корней. Я же предлагаю рассмотреть казахский язык именно потому, что это естественная система, которая не умерла, а успешно эволюционировала тысячи лет, сохранив при этом жесткую агглютинативную логику (иммутабельность корня). Это не "философская забава", а выживший в продакшене "код".
Human vs Machine. Статья не призывает людей переходить на новый язык в быту. Речь идет об архитектуре информационных систем. Компьютерам, в отличие от людей, как раз и нужна та самая "скучная" предсказуемость Логлана. В HPC (High Performance Computing), которым вы занимаетесь, борьба идет за каждый такт процессора. И если мы можем парсить протокол за O(N) без контекстных ветвлений (которые неизбежны во флективных моделях), мы получаем выигрыш.
Поэтому я предлагаю смотреть на это не как на попытку возродить Волапюк для людей, а как на поиск идеального паттерна для DSL (Domain Specific Languages) и межсервисных протоколов.
Пример бы
Парсинг языка давно не является проблемой. И это уже давно позволяет в проектировании языков думать о других, более важных, аспектах.
Когнитивная перегрузка инженеров -- это вопрос не столько к языку (хотя и к нему), сколько к коллегам-инженерам и к самому себе. Ну а про языки: идея нанизывания суффиксов скорее породит ад, где надо, читая, удерживать в голове всю цепочку. Плюс длинную цепочку сложно понять "одним взглядом". А чтение слева направо не избавит от необходимости помнить контекст.
Единый протокол невозможен, потому что перед разными протоколами стоят разные задачи. И попытка впихнуть всё это в один создаст такой безумный перегруз, что никто не будет в достаточно мере знать этот протокол, чтобы с ним работать. Вы тут противоречите сами себе. Только что восхваляли unix-стиль, где много мелких простых утилит можно сплести вместе для решения более сложной задачи. Но каждая такая утилита -- это свой "протокол". Единый протокол для всего будет неудобен для всего.
Про "ад из суффиксов": Вы только что описали паттерн Fluent Interface (или Method Chaining), который де-факто является стандартом в современной разработке (Java Streams, LINQ в C#, Rust iterators). Конструкция
object.filter().map().sort().collect()- это и есть чистая агглютинация. Мы нанизываем обработчики слева направо. И это читается на порядок легче, чем "флективный" аналог с вложенностью:collect(sort(map(filter(object)))). Так что линейная цепочка суффиксов - это снижение нагрузки, а не перегруз.Про Unix и противоречие: Вы упускаете базу. Философия Unix (много мелких утилит) работает исключительно потому, что у них есть единый протокол обмена - неструктурированный текстовый поток (byte stream) через stdin/stdout. Если бы
grepотдавал бинарный объект, аawkожидал JSON, никакой Unix-магии бы не случилось. Я предлагаю ровно то же самое: унифицировать структуру взаимодействия (как текст в Unix), чтобы разные модули могли стыковаться без адаптеров. Сейчас же у нас зоопарк именно структур.
Агглютинативный код: почему будущее IT требует смены лингвистического фундамента