Исследования-дыбр
После некоторого перерыва (включавшего как летние танцы/приключения, так и дела) продолжаю с компилятором. Не секрет (уже мелькало в чатах), что разработка прототипа ведётся на C#. Лет 5 назад я бы сам удивился такому решению, но сейчас .NET это прямо из коробки открытая и кроссплатформенная экосистема, дающая желаемую скорость итераций в exploratory programming.
Параллельно всплыла ещё одна тема - динамический синтез единой конфигурации из разрозненных (и местами противоречивых) требований. Управление правами доступа (к сущностям в базе данных или файлам на диске), описание правил сборки ПО, интеграция каких-либо сервисов или приложений в операционную систему, интеграция плагинов в расширяемый программный продукт - всё это работа с фрагментами требований, авторы которых не могут предсказать содержимого фрагментов из других источников на целевой системе, намерений, с которыми они созданы, а также всего множества ситуаций, возникающих при взаимодействии двух и более фрагментов. Похоже, что мне удалось подобрать представление фактов и алгоритм вывода, работающий с такими фрагментами независимо от предметной области, и дающий интуитивно понятные (а также идеально воспроизводимые на тех же исходных данных) результаты интеграции конфигураций. Ещё в 2011 году, когда мы работали над .15926, vvagr задал мне вопрос, можно ли логикой (а не вставкой extension points и кода на Python) описывать расширения и кастомизацию UI продукта. Я ответил "наверное да, но настоящего решения пока нет, и его поиск может занять очень долгое время" (добавление интерпретатора Prolog или miniKanren создало бы лишь "иллюзию логики", не решая проблему фрагментарных описаний). А сейчас решение есть. Но на 8 лет позже. И хоть и может быть применено в компиляторе (про который в абзаце выше) в какой-то момент, но к разработке ядра компилятора отношения не имеет. В общем, хорошо что случилось, чуть жаль, что только "сейчас", а не "тогда".
Также, продолжил старую тему идентификации криптохэшами, начатую в https://justy-tylor.livejournal.com/252597.html Как по части 4D-идентификации ролей, так и по части идентификации данных для content-addressable storage. Но это заслуживает отдельного поста.
Параллельно всплыла ещё одна тема - динамический синтез единой конфигурации из разрозненных (и местами противоречивых) требований. Управление правами доступа (к сущностям в базе данных или файлам на диске), описание правил сборки ПО, интеграция каких-либо сервисов или приложений в операционную систему, интеграция плагинов в расширяемый программный продукт - всё это работа с фрагментами требований, авторы которых не могут предсказать содержимого фрагментов из других источников на целевой системе, намерений, с которыми они созданы, а также всего множества ситуаций, возникающих при взаимодействии двух и более фрагментов. Похоже, что мне удалось подобрать представление фактов и алгоритм вывода, работающий с такими фрагментами независимо от предметной области, и дающий интуитивно понятные (а также идеально воспроизводимые на тех же исходных данных) результаты интеграции конфигураций. Ещё в 2011 году, когда мы работали над .15926, vvagr задал мне вопрос, можно ли логикой (а не вставкой extension points и кода на Python) описывать расширения и кастомизацию UI продукта. Я ответил "наверное да, но настоящего решения пока нет, и его поиск может занять очень долгое время" (добавление интерпретатора Prolog или miniKanren создало бы лишь "иллюзию логики", не решая проблему фрагментарных описаний). А сейчас решение есть. Но на 8 лет позже. И хоть и может быть применено в компиляторе (про который в абзаце выше) в какой-то момент, но к разработке ядра компилятора отношения не имеет. В общем, хорошо что случилось, чуть жаль, что только "сейчас", а не "тогда".
Также, продолжил старую тему идентификации криптохэшами, начатую в https://justy-tylor.livejournal.com/252597.html Как по части 4D-идентификации ролей, так и по части идентификации данных для content-addressable storage. Но это заслуживает отдельного поста.