Это моя предпоследняя запись в этом блоге . Аннотируемые страницы в состоянии версии 1.0 и можно уже даже попробовать просто вручную перенести контент этого блога на одну страницу в UI.CENTER (UIC). В принципе, не смотря на то, что до версии 1.0 для персональных вики ещё далеко, можно даже попытаться что-то перенести уже и туда . Планировал оба сервиса в версии MVP сделать к Новому году . В принципе, в режиме аврала это можно было бы и сделать . В прошлой жизни я даже был и менеджером и имею опыт завершать работу вовремя . Но ещё тогда понял, что время - качество . А, в принципе, процесс и время - суть, из одного теста и концепции даже не одной темы, а разные дефиниции одной концепции, то есть , одно и та же концепция по сути . Именно, процесс определяет время , а любые попытки назначить время для процесса, это как бы вывернуть все наизнанку . Так что впредь буду просто тщательно планировать процессы, а не навешивать на них время . Время - типа метамодели процесса или даже более определенно, ВРЕМЯ - МОДЕЛЬ ПРОЦЕССА .
воскресенье, 21 декабря 2025 г.
пятница, 21 ноября 2025 г.
Финализация сервиса аннотируемых веб-страниц
После глубокого рефакторинга восстановлена вся старая функциональность и можно было бы на этом поставить точку . Но в процессе рефакторинге появились идеи по дополнительной функциональности . Может не такие принципиальные , но все-таки . Хотя даже их реализация - это ещё не совсем финиш с первым пунктом дорожной карты . В связи с системой глабальных тегов придется ещё раз вернуться . Надо будет теги этого сервиса посылать в систему глобальных тегов . Но пока неизвестно куда посылать и ситуация там на уровне технического задания . Но оно интересное! Надо сделать систему такой , чтобы это стало мостом в мини- LLM . Будет как эксперимент и пока максимум с двумя миллионами узлов .
понедельник, 28 июля 2025 г.
PARADIGMA
Ещё один проект, в надежде, что он облегчит рефакторинг. В отличие от PARSEQ - проекта персонального софта, PARADIGMA планируется для обозначения МЕТАИНТЕРПРЕТАТОРА и является (или будет таковым) совместным детищем с Александром Бурдуковым . То есть, в определенном смысле, это тоже прагматический аспект проекта МЕТАМОДЕЛИРОВАНИЯ.
- https://t.me/METAxPARADIGMA
- https://telegra.ph/PARADIGMA-07-24-2
- https://github.com/users/Serj-Aleks/projects/2
- https://paradigma.tiddlyhost.com
суббота, 21 июня 2025 г.
Программа как граф
Или точнее, последовательность импликаций, последовательность пар, такой двудольный граф или ассоциативный массив, в котором заложена на этом же принципе метаинформация о своей структуре для организации сети, системе пар.
Два подхода к "снарядам" - Gemini и ChatGPT (частично Grok и др. ...которые кажутся явно слабее, хотя честно признаюсь, что пока без комментариев относительно Claude) демонстрируют явную "экономическую эффективность", в том смысле, что экономят время на чтение больших и, якобы, связных текстов, то есть книг и даже учебников. Три - пять промтов в одном чате заменяют сотни страниц ... любых ... бумажных, в вебе или, потраченные на ютуб, часы ...
Архитектура и интерфейс
- https://g.co/gemini/share/7e169880160e
- https://chatgpt.com/share/6853df7f-a04c-8012-8482-b952af1db49d
- https://grok.com/share/bGVnYWN5_10f93b33-cce3-4fd6-be62-dd20da6f0697
Граф
- https://g.co/gemini/share/cc1b391381b9
- https://chatgpt.com/share/685572cb-7834-8012-8d3b-0587bcd8d979
---
Смотрю новую игрушку - LOGSEQ (Как обозначение пересекается с PARSEQ!). И пока не смотрел, но хочу побаловаться с Real AI. А, вообще, в связи с рассуждениями выше, пришла мысль просканировать ещё раз GLOTEON, на предмет добавления туда по каждой теме ссылок на ответы ИИ-ботов, возможно с цитатами ... Идея, года на два, но можно в фоновом режиме ... Это кажется шагом навстречу к большому связному тексту по МЕТАМОДЕЛИРОВАНИЮ! Хотя бы тематической онтологии или просто к банальному глоссарию. Это навскидку, как утилизирвать, но сам процесс интригует, просто любопытно!
среда, 28 мая 2025 г.
Системы с расширяющимся синтаксисом
Сформулировать соответствующий промт для Gemini я сообразил потом, уже после того, как случайно набрел на описание системы Seed7 , что, в свою очередь, вызвало ассоциации с Ring ... и почему-то с curl, о котором стал совсем забывать ...
Конечно, практичеки, любая система позволяет себя расширять ... иначе как мы создаем новые параметры и операции, что и является сутью программирования, конструирование абстракций, символизация, моделированияе... Но вот прямо акцентируют расширение синтаксиса не все ... Может это бесполезный или даже запутывающий акт? Как, впрочем, история с той же метафорой - код это данные ... и чем данные не код ... Может это просто такой маркетинг, флаг, чтобы обратить внимание на себя без какого-то дополнительного содержания, используя моду, тенденцию на определенные мемы, символизирующие некоторый тематический фронтир. Но какой? С этим-то и хочется разобраться, с формализацией процесса расширения синтаксиса ... или все-таки я просто пока не могу сформулировать какую-то другую проблему.
И ещё, параллельно в связи с этой темой ... с темой стереотипов? ... оригинальная точка зрения на модель нейрона ... нейрона с памятью ... а ещё хочется ввести в оборот "продукционно-предикатная модель Ларина". Всему свое время, для того что бы все уложить, подобрать нужный пазл.
среда, 21 мая 2025 г.
АРХИТЕКТУРА И ИНТЕРФЕЙС СИСТЕМ КОДИРОВАНИЯ КОМПЬЮТЕРНЫХ ПРОГРАММ
Абракадабра, которой я почему-то неожиданно горжусь. Можно рассматривать как ПРОМТ для ИИ-бота, поэтому "скормил", в первую очередь, Gemini и пока не пробовал тестировать с ним другие боты, хотя, безусловно, любопытно, Гугл "архитектуру", начал ассоциировать со средами разработки и пришлось дутализировать свою точку зрения, как на структуру или точнее организацию памяти ... интерпретаторов и сообщений, который они интерпретируют ...
В процессе парсинга создаются внутренние структуры данных в памяти (объекты, списки, словари), описанные выше, которые отражают структуру "сообщения".
Тему хочется развернуть и додавить. Жаль, что нет стандарта для документирования кода. Раньше, когда вводили библиотеки или фонды программного обеспечения, при описании программ требоваалось, наряду с указанием окружения, описание используемого алгоритма и отдельно код его реализации. А сейчас все ограничиваются моделью "черного ящика", только вход и выход, ну и имя, как само собой разумеющееся, ну а комментарии, которые должны сопровождать каждую строку кода, превратились в отписки. Ну и как следствие, перманентная мультипликация и миллионы строк кода ... в котором никто никогда до конце разбираться уже не будет, чтобы что-то развивать и оптимизировать ... проще написать новый.
Казалось, бы бери любой существующий фреймворк и погнали ... но что-то держит и мешает это сделать ... недоверие, возникающие, как следствие от чтения документации. Если автор не аккуратен при "кодификации" описания своей системы, то может ли он быть аккуратен при её реализации в коде, в кодировании, в принципе.
среда, 14 мая 2025 г.
Базовый набор операторов вычислительного процесса
Пытался сделать конспект проекта META II, но раздумал ... оставлю ссылку на перевод авторской статьи 1964 года ... В связи с этим и возникла идея сформулировать тему необходимого минимального набора операторов ... Так этот промт интерпретирует Gemini , а это ответ ЖПТ ... и на тот же запрос интерпретация Perplexity ... и самый адекватный ответ от телегра-бота ... который и более структурированный, и обратил внимание на контекст продукционных систем ... Тут же возникла идея трансформировать промт, оптимизировав все предыдущее - необходимый минимальный набор операторов, который обеспечивает:
⦁ Обработку и хранение данных⦁ Управление потоком выполнения
⦁ Манипуляцию с памятью и ввод/вывод
PicoLisp — это результат исследования дизайна языка, пытающегося ответить на вопрос «Какова минимальная, но полезная архитектура для виртуальной машины?». Поскольку мнения о том, что подразумевается под «минимальным» и «полезным», различаются, существует множество ответов на этот вопрос, и люди могут считать другие решения более «минимальными» или более «полезными». Но с практической точки зрения PicoLisp оказался ценным ответом на этот вопрос.Прежде всего, PicoLisp — это архитектура виртуальной машины, а затем язык программирования. Он был разработан «снизу вверх», и «снизу вверх» — это также наиболее естественный способ его понимания и использования: Форма следует за функцией .
среда, 7 мая 2025 г.
WOTA & Misty ... и PARSEQ
Формат от автора JSON. Трудно удержаться, чтобы не посмотреть его же проект Misty ...
При принятии решения за базовый формат, собственно, определяющий и архитектуру, решил внимательно прочитать и даже законспектировать замечания автора JSON https://t.me/HYPERANALYTICS/11377
Если файл для конспекта проекта окажется небольшим, то перенесу информацию в ITOGI, а этот файл удалю, создав об этом отдельное сообщение.
Там же подсмотрел замечательное название для концептуального проекта ... очень нравится ...
Кажется, что если не сделать это, по крайней мере для себя, то можно утонуть в информационных потоках, "ложная полнота" которых "обесценивает значения" ...
понедельник, 21 апреля 2025 г.
Чем можно заменить термин "значение"
Ретроспектива некоторых заметок по проблеме ... Суть в том, чтобы для термина "параметр" установить рекомендацию для обозначения в паре левой и правой части ... Принципа - не использовать национальную лексику ... Исхолим из традиционной научной латино-эллинской этимологии ...
Сначала помучил бот Gemini, который в этом вопросе оказался категоричным и поверхностным, что надо отнести к методологии обучения, базы обучающей выборки, а может и алгоритма принятия решения, не знаю ...
Потом Chat GPT, ответы которого оказались на порядок содержательнее ... в частности, просто конкретнее ... может потому, что промт был сформулирован чуть шире ... без указания на информатику как контекст ...
понедельник, 14 апреля 2025 г.
Первый блин комом
Попытался привлечь к созданию поста Gemini c темой акцентирования общего аспекта Arturo, Rye, Spry и Meta. В целом, бот выделил Rebol как параметр по первым двум проектам, указав ошибочно одного автора для всех четырех и продемонстрировав, что о двух остальных система ничего не знает. Попытка указать ссылки на проекты, естественно, ничем не закончилась, а на иронию, почему система, основанная на поиске в сети, не знает о проектах, существующих несколько лет и не интерпретирует тексты по ссылкам, порекомендовала неизвестно что и, видимо за деньги ... Ну и ладно. Вывод такой, что я могу иметь персонального интеллектуального агента, только сконструировав его сам. Это мне стало наконец, очевидно в полном объеме и как следствие разных целей коммерческих корпораций и даже субъективных представлений членов сообщества развития открытого кода. Технологическое развитие достигло такого предела, что субъект уже не в состоянии проконтролировать потенциальные объемы знаний, с которым можно конструировать персональныой интеллектуальный профиль. То есть надо просто выбрать свой технологический стек типа процессор Risc V, объектной и персистентой OS, интегрированной с Веб браузером и хостовый интерфейс как специализированный интерпретатор для создания DSL. Все существующее не идеально, но тенденции прогнозируемы и все, что можно сделать это оптимизировать выбор ... А с точки зрения, конструирования своего интерфейса, то в качестве старта - это формат обмена, а формат хранения, уже следствие первого, поскольку передается и "хранимый" код. И это формат обмена - ASON AltScript. А четыре упомянутых выше проекта как попытка окончательного анализа для интерпретации формата типа стандартизации в спецификации. Рассматривать Baron и Red не имеет смысла, поскольку это в полном объеме клонирование Rebol без его критического анализа. Итак, формулируем формат! С акцентом на активный голый объект с историей состояний (интерпретаторов и микро баз данных), который взаимодействет с другими объектами посредство объектов месседжей (предикаций). Концентрируемся на их структуре! Можно ли метаинтерпретатор интерпретировать как "почтовый диспетчер", который не только коордиирует распределение процессов, но и распознает безадресные, накапливая опреленную лексику, ранжированный терминологический словарь.
понедельник, 7 апреля 2025 г.
Теория тегированных (маркированных) объектов
В связи с классификацией объектных концепций вспомнил про Wyvern ... и deep-econom обрати внимание на статью A Coq implementation of a Theory of Tagged Objects ...
Почти синхронно (случайно) ... один из авторов, допускаю что, не плохой компьютерной системы акцентировал попытку обобщение своей практики вместо описания архитектуры и интерфейса - вот эта попытка - The Links Theory 0.0.2 и тоже с "притягиванием за уши" пруф-агента, перед этим была попытка "наводить тень на плетень" с помощью теории категорий.
В свзи с чем, посчитал необходимым сфопмулировать свое отношение к автоматизации интерпретации формальных систем ... Понравился комментарий здесь ...
Как-то была попытка погружение в базы данных математических утверждений, позже можно будет здесь в комментариях добавить соответствующие ссылки. Любопытные проекты и, скорее всего, полезные ... Но верификации софта с помощью другого софта - это, как уже здесь замечено, просто очередная интерпретация, демонстрирующая аналогии, изоморфизм и прочее ... двух систем, их сравнение, но ничего более того ... Доказательство - это вычислительный процесс ... любая вычислительная система - формальная система ... со своей системой аксиом и правлами вывода ... Да сравнивать надо ... но для оптимизации и стандартизации ... Акиомы - банальные определения и можно было развивать совместно старый добрый Prolog, расширяя его сферу приложений, вместо того, чтобы генерировать новые системы, поддержка которых может быть заброшена вместе с амбициями их авторов, кстати (Implementation of a Proof Assistant in Prolog).
P.S. Начало создание постов вместе с интеллектальными ботами отложилось, в связи с этим эскурсом ... Но это тоже стоило того, акцентировать ещё раз вычислительный процесс, как символическое моделирование, кодификацию как классификацию и детерминацию, ещё проще говоря, ДЕФИНИРОВАНИЕ ... Определения, определение определений ... и так далее ... Ради утверждения МЕТАМОДЕЛИРОВАНИЯ! ... На пути к своему QED-манифесту! А ещё в сухом остатке тема POPLmark вызова ... а точнее её более точное выражение - ПРОБЛЕМА ВЫРАЖЕНИЯ!
Цель состоит в том, чтобы определить абстракцию данных, которая является расширяемой как в своих представлениях, так и в своих поведениях, где можно добавлять новые представления и новые поведения к абстракции данных, без перекомпиляции существующего кода и при сохранении статической безопасности типов (например, без приведения типов). Постановка проблемы выявляет недостатки в парадигмах программирования и языках программирования , и ... она все еще считается нерешенной ...
воскресенье, 16 марта 2025 г.
Не "чистые", а "голые" объекты
Круг замкнулся. Не считая нескольких лет, когда я занимался моделированием уравнений матфизики, точнее моделями, описывающимися уравнениями матфизики и компьютерные системы были исключительным инструментом для реализации соответствующх алгоритмов, осознанно, к этим инструментам я стал подходить позднее, когда стал менеджером в разных организациях, требующих автоматизировании их "бизнес-процессов". Так вот, имея навык исключительно с "процедурной" концепцией и немного с реляционной теорией SQL и теорией продукций PROLOG, я попал в самый апогей дискурса между ООП и функциональным программированием. При этом меня тотально окружали приверженцы последнего , а я был типа "белой вороны", отстаивающий объектный подход. Но теперь, я "прошел" путь от полного презрения концепции функций к её пониманию и связи всех концепций, в принципе. Совсем мало анализируются, собственно, архитектуры систем и все сводится, как привило, к обсуждению синтаксиса или интерфейса к этим архитектурам. То, что говорят, когда сравнивают, например, Форт, Лисп ,АПЛ и Смолтолк - совсем не то и совсем не о том, особенно когда это все ещё неявно замешивается с алголо-подобным синтаксисом или сранения, в конечном итоге, с ним. Короче ... тема интересная, хотя может и не важная ... с точки зрения оптимизации, которая, как правило, нужна в последнюю очередь, когда, действительно, "куда-то клюнул петух". А когда все работает и страшно все это менять, а вдруг сломается ... зачем ... то очевидно, что до этого нет никому дело, кроме кучки энтузиастов, которые всегда были и, наверное, будут. Так вот. Экскурс в Self привел к IO, а через автора последнего к СИСТЕМЕ ПРЯМОГО МАНИПУЛИРОВАНИЯ СТРУКТУРИРОВАННЫЗ ДАННЫХ ... Вот так просто и ясно сформулирована коечная цель.
И сразу все встало на свои места! Даже отношения клиент-сервер и хост-домен, не говоря уже о MVP (в обоих смыслах). Теперь надо просто это все осмыслить с позиции модели акторов, где акторы - интерпретаторы ... P2P ... смарт-контракты ... и Web GUI в ядре ... Но ... при этом, все объекты (включая процессы), объекты внимания, где их базовая характеристика, только инкапсуляция, а все остальное факультативно. Объекты-интерпретаторы ... объекты-месседжи ... объекты-ресурсы ... объекты-инструменты ... и т.д. и т.п. Функции - интерпретаторы ... и те же объекты! И, похоже, что двух архитектур, прототипами, которых являются Erlang и Tiddlywiki, вполне достаточно и они универсальны! И вот что надо иметь в виду (может подсматривая за ассоциативнм массивом AWK) при реализации PicoLisp на WASM с базовым форматом ASON.
пятница, 7 марта 2025 г.
Ещё две неожиданные темы
Перечитывал документацию Self. Есть новое текущее понимание как все должно быть и с этим новым пониманием некоторые старые тексты понимаются по-другому и не только глубже, но и шире ...
А ещё одна тема - концепция local-first, * которая очевидна, но стала модной в прошлом году и по этой причине, была проигнорирована, но случайно авторитетные специалисты обратили внимание ...
Перевариваю ... параллельное погружение в PicoLisp и WASM создают ментальные перегрузки, заставляют теперь все новые вещи интегрировать и примерять в едином ключе, в некоторой обощенной концепции, а мозг уже стал лениться ... учиться чему-то новому ... которого при внимательном рассмотрении-то и нет, но что тоже требуется понять через призму новых интерпретаций и другой лексики, увидеть аналогии в "разных пространсвах имен".
И по старой привычке зачем-то полез экспериментировать с очердной и новой для меня соцсетью Zulip ... https://metamodelling.zulipchat.com Отказался от твиттера и фейсбука, хотел сузить присутствие в сети, а в результате прибавилось мест в пять раза больше (!) ... В некоторых присутствую только как читатель, подписавшись. Надо думать как это теперь использовать, утверждается, что удобно работать с темами, на что, собственно и купился. В крайнем случае, буду опять же, читателем, поскольку там есть новые проекты компьютерных языков.
пятница, 21 февраля 2025 г.
Два параметра объекта GLOBAL
С чего стартует спецификация потенциального интерпретатора на WASM, а по пути неколько принципиальных замечаний:
1. Архитектура должна быть тотально параметрической, везде где только можно, если нет четких критериев оптимизации. Только эксперименты, сначала эвристика.
2. Отсюда и первый парамтер для типизации связного списка - односвязный, двусвязный ... и может быть и регулярный массив ... MEM-LINK.
3. Второй параметр - MEM-ATOM ... 128 bit, 256, 512, 1024 ...
4. Все параметры привязаны к объекту, фрейму. "Примитивный параметр" как пара слотов ассоциативного массива принципиально инициируется как фрейм (объект), со всем вытекающими последствиями. "Неизменяемая архитектура" базового объекта интерпретатора в "WASM-песочнице" ... в системе других распределенных "классов объектов" в сети ...
5. Ортогональность как принцип обуславливает прозрачную базовую архитектуру. Динамиеский список над регулярным массивом. Это и есть синтаксис системы, у которой интерфейс синтаксический формат.
6. Термин FUNCTION используется в математичесом смысле. Общий термин для выражения операций, алгоритмов и программ - INTERPRETATOR.
7. При "перписывании" структур, когда на выходе имеет место многопараметрическая структура, интерпретаторы специфицируются как процедуры, команды, инструкции или макросы.
...
Далее будет развертываться данная спецификация, уточнятся, детализироваться ... и так далее ... до очевидной реализацюю. К базовому словарю: ПАРАМЕТР, ФРЕЙМ, ОБЪЕКТ, ИНТЕРПРЕТАТОР, ФУНКЦИЯ, ПРОЦЕДУРА, КОМАНДА, ИНСТРУКЦИЯ, МАКРОС, АССОЦИАТИВНЫЙ МАССИВ, БИТ, БАЙТ, СЛОТ, СТРУКТУРА, СИСТЕМА, АРХИТЕКТУРА, АДРЕС, СИНТАКСИС, СЕМАНТИКА, ИНТЕРФЕЙС, ФОРМАТ ...
пятница, 14 февраля 2025 г.
Представление кода на графе
Ищу способы выражение кода на графе. Нет проблем отобразить графом фрагменты "физического пространства", ясно как выражаются переходы от состояния к состоянию (от одной именованной структуры к другой), но вот повторить имя на одном холсте с размещением графа уже проблема. То есть, если повторяется параметр, входящий или выходящий из разных процессов или вызов одной и той же процедуры (функции) с разными параметрами, то просто "инкаписулировать" одно имя не выходит ... на одном холсте просто имя можно повторить только один раз. И это не рекурсия в классическом понимании. То есть. Кстати, по пути и возникает тема выражение рекурсии на графе. А может и цикла. Указание стрелки, перехода на само имя теряет семантику ... Возможно существуют способы, о которых мне пока не известно. Буду пробовать маневрировать холстами. То есть для описания "имени", а так же вызова имени - отдельный холст для графа. Может в этом даже что-то есть принципиальное. Имя как модель и код модели всегда следует отделять, как и факты представления и реализации.
вторник, 28 января 2025 г.
PicoLisp и LLVM
Как-то само сабой получилось так, что инициировал тиддливики файл для исследования LLVM, на котором написан базовый "PicoLisp asm64", на котором уже, в свою очередь, написан сам интерпретатор Pil21, чтобы детальнее исследовать, собственно, интерппретатор, с целью попыток проделать тоже самое для WASM-WASI вместо LLVM.
Не знаю, как это далеко меня заведет, но пока даже интересно и все это только вдохновляет учиться и понимать современное состояние дел в кодировании. Что уже бросается в глаза ... современные ассемблеры, синтаксически, невольно от их создателей трансформируются в некоторый конвенциональный интерфейс ... пока ещё не один в один, но, видимо, это рано или поздно случится. По крайней мере на этих двух ассемблерах это уже явно, а ещё если к ним прибавить проект flat assembler. Такое впечатление, что после некоторой интеграции архитектур и синтаксисов может, в связи с домbнирование RISC V аппаратной архитектуры или какого-то дальнейшего её разития, а попытки уже есть ... это что-то полностью заменит C/C++, а еже с ними и все другое как хосты ... И страшное слово ассмблер или "макроассемблер" перестанет наводить ужас. Их ортогональность к аппаратным реализациям возьмет вверх. Более того, возобладает концепция адресности, вернувшись на своё законное место. Иначе со сложность не побороться.
Естественно, что "пара-ленточная" архитектура здесь останется пока "над" процессом, но явно как развитие процесса организации "динамических списков над регулярными массивами". Это тренд, вектор развития кодификации вычислительных процессов. Только потом все остальное, включая интеллектуальных агентов и их сетей.
И как помогает Tiddlywiki своим ортогональным интерфейсом! Вот так должны выглядеть универсальные приложения будущего, не касаясь какой-то специфической предметной сферы, которые все равно могут быть и плагинами. И такие аналоги агентов могут быть ограничены в памяти, но работать в некоторой общей распределенной среде. Форматы ... Протоколы ... И их трансформеры друг в друга ...
суббота, 7 декабря 2024 г.
Pony
Pony предотвращает гонки данных. Он не может помешать вам писать условия гонки в вашей программе. Чтобы узнать больше о различиях между условиями гонки и гонками данных, ознакомьтесь с книгой «Условие гонки против гонки данных» Джона Регера.
В связи с Ryelang теперь вместо Rust видится golang, а архитектура tiddlywiki продолжает не давать покоя ... Такой кентавр можно оптимизировать и что-то может ещё привнести типа персистентности и контентной адресации, но в целом хочется систему мета моделирования конструировать на базе этих уже существующих артефактов. Из моего Telegram ...
То есть, казалось бы, выбор сделан и уже можно обойтись без чтения подобных комментариев ... Но очень трудно избавиться от искушения посмотреть очередной новый проект ... или просто проект, о котором ещё ничего не знаешь или просто забыл, что уже встречал, но не посмотрел и прошёл мимо, занятый другими вещами ... Reason (Ocaml), Vale, Inko, Hare ... Но уже не столько интересуют, собственно, концепции, сколько их формулировки ... И в этом смысле, именно, Ponylang, точнее его документация или спецификацция показалась содержательной, но даже не столько со стороны описания трюков распределения памяти, сколько отношению к концепции ТИПОВ ДАННЫХ ...
P.S. А, вообще, пора уже, хотя бы для себя продемонстрировать связь между ТИПАМИ и ИНТЕРПРЕТАТОРАМИ * ... И, опять же в рамках модели акторов, кстати, что и заставило внимательнее начать вчитываться в описание проекта Pony.
... А ещё на неделе подумалось о связи скобок и сложных препозиций ... как продолжение осознания того, что, то же ЕСЛИ ... ТО ... Это просто имппликация, которая описывается той же обычной стрелкой ... И, видимо это и есть та самая реальная база всего, та самая модель, синхроно возникающая при выделении любого объекта ... вместе с его связью ... хоть с чем ... например, с клозурой ... Без сопряжения мы просто ничего не сможем сделать ... Отсюда же становится понятным провал логических ЛОГЛАНА и ЛОЖБАНА с их "функциональным скобочным синтаксисом" вместо аппликативной природы той же ЛОГИКИ ... Если нам нужна арность, то тогда и нужны скобки ...
четверг, 21 ноября 2024 г.
DBMS vs FileSystem
Подобно широкому дискурсу вокруг интерфейсов систем и чаще синтаксиса, реже, но более аргументировано противопоставляют файловы системы и базы данных. Но как бы мы не обозначали "это" - память, хранилище, магазин, журнал ... "это" - основа информационной системы, её суть, а любая функциональность в любом случая проявляется в динамике её структуры, а доступ и есть тот самый "видимый интерфейс". Ну да, есть специфика в форматах или протоколах, как и в случае транспортировки кода или данных (кстати, опять же, только игра слов в случае использования терминов как абстракций высшего уровня). Кто-то использует DB для хранения "кода", а кто-то пытается иронизировать ... но над чем? Попытки с экспериментами в проектах Plan 9 или Plan B, опять же обозначая сегменты памяти (или записи?) файлами или боксами нисколько нам новых знаний не прибавили. Точно так же как попытки кортежи называть фреймами или объектами ... А вот как раз декларации, что "все есть файл ..." или "все есть URL ..." имеют содержательный аспект и по сути акцентируют, как центральную, модель акторов. И это уже не проблема контейнеров и контента, хотя перманентно хочется избавиться не только от термина "файл", но и термина "значения" ... или "ключ" ... Это я намекаю на ассоциативный массив или двудольный граф - как фундаментальную структуру любой модели. Да, без спецификации "левого" и "правого" слотов (кстати, вот ещё пример термина с измененным смыслом) ... Конечно, в целях "оптимизации", скорости реализации, можно специфицировать данные и метаданные, структуры и метаструктуры, таблицы и метатаблицы ... и так далее ... кому как нравится, но от этого суть не изменится.
П.С. Но чтобы не уйти в сторону от обозначения темы поста. Не настаиваю на специфике "коммерческих" информационных систем, то есть для обеспечения бизнеса, информационного обеспечения колхозов и кооперативов, федеративного или коллективного продуцирования и мультипликации информации ... но для персональных систем знаний, настаиваю на тотальной оптимизации всей этой болтовни и искусственном разделении. Оказывается, что игра слов и не такая уж безопасная. Короче ... Для "персональных систем" (хотя коммуникация обуславливает оптимизацию в любом случае) точно нет никакого смысла в разделении "кода и данных" ... "операцонной среды и системы хранения" ... "терминальной строки и блока" ... "адреса и URL" ... и так далее ... То есть необходимо движение не столько за открытый код, который, кстати, автоматически станет открытым, если демонстрировать реальные структуры, а не прятать их, даже под лозунгами безопасности и не эффективности, сколько движение за "персональные системы" ... И это более важный этап развития, чем персональные интеллектуальные агенты и даже, сорее всего, тот самый путь к ним, более прямой и поэтому естественный. Но для этого необходима переоценка всего созданного "зоопарка" с выделением проектов, акцентирующихся для отдельных персон, а не для компаний.
четверг, 14 ноября 2024 г.
Web browser как базовый интерфейс к современной информационной системе
Итак, есть конструктивная концепция акцентировать коммуникационный аспект процессов интерпретации. А значит не просто лингва, а лингва франка, но если расширять фокус символизации, то расширять глифы не только увеличением количества строк в терминале или с перпедикулярной стороны, например, иероглифами, но графическими репрезентациями, в принципе, графиками, схемами и графами, как в развивающейся концепции notebook. Что и делается, но пока в рамка, исключительно, предметной области, в качестве диалектов, реализованных отдельными библиотеками и даже не входящими в стандартную библиотеку ядра базовой операционной среды. С другой стороны, проявляется тенденция не только смотреть на веб-браузер как ОС, но и использовать его как хост. И многие "старые системы", итменно, на этой стадии выходят из игры. Конечно, джава-скрипт, реализованный на С/С++ и когда-то джава аплеты на джаве, развили все потенциальные практики программирования и теперь даже в недрах крупных корпораций, развивающие алтернативные лингва типа си шарпа, дарта ... и прочее, напрочь отсутствуют попытки переоценить наспех сотворенный интернет-интерфейс ... Если что-то и происходит, то скорее "исторически", типа как в unix-традиции (FLTK) или того же Qt. То есть евангелисты С/С++ конкурируют друг с другом, типа кто круче, а остальные пока как бы в стороне, хотя очевидно, что любая система расширяема и ничто не мешает такой внешней конкуренции, хотя бы как например, делают сторонники Common Lisp. Может потому, что проще сделать транспилер в С/С++, но тогда так и надо последовательно действовать, в сторону интерпретации новых скриптов, без компиляции в машмнный код ... или уж если что-то доказывать, то по-настоящему. Иначе все упирается только в альтернативный синтаксис. Почему на Schema до сих пор нет своего браузерного движка, если они утверждают, что это лучший Lisp. А ведь тенденция налицо (https://webui.me). Действительно, чем десктоп не проводник, а проводник не браузер ... И тот же вопрос для любого редактора или фреймворка ... Уж если и делать возможность несколких рабочих столов (представлений), то почему они такие одинаковые ... а не сделать, например, "проводник на холсте" ... я бы с удовольствием такое представление системы в целом, использовал.
То есть, Web browser - GUI для JavaScript системы, кстати, где уже, CSS начинает конкурировать с JS, вытесняя его в сторону обслуживания внешней ОС, а те же markdown и прочие wiki-разметки гипертекста, заставляют задематься о том, что не переборщили ли разработчики со стандартами HTML и XML, пытаясь реализовать "издательский" SGML, что совсем не обязательно для представления персональных систем знаний. Кстати, о последних. Похоже это фундаментальный параметр для выбора проектов для анализа с целью потенциального использования. И надо пересмотреть отношение к выражению "СИСТЕМА ОБЩЕГО НАЗНАЧЕНИЯ".
понедельник, 21 октября 2024 г.
Rebol-синтаксис
Мечтая об интерпретаторе для конструирования синтаксиса, в конце концов, я прихожу к выводу, что спецификация Rebol, который и позиционируется как система для конструирования диалектов, и есть та самая модель интерпретатора, у которой могут быть разные реализации, но с общим форматом типа того же ASON AltScript ... Не случайно идеи проекта не отпускают тех, кто когда-то сталкивался с Rebol-синтаксисом ... Кстати, стоит выделить, из попыток последних реализаций, проекты Arturo (Nim) и Ryelang (Go). Последний (А ведь, не только я интерпретирую ЯЗЫК как ИНТЕРФЕЙС!) заставил ещё раз перечитать спецификацию Go с его, "якобы" 25-ью ключевыми словами в противовес с 35-ью Си и с около сотни С ++. Какими бы не казались, на первый взгляд, грозными конкурентами C/C++ такие проекты типа Vlang, Zig или Crystal, они очень далеки до демонстрации, с помощью них, больших распределенных систем и, вообще, глядя на скорость развития этих проектов, мало надежд на то, что они выдержат весь путь, в принципе, в конкуренции с тем же JavaScript, догоняя его функциональность ... А с другой стороны, участие в идеологии Golang разработчиков Limbo (Inferno) безусловный аргумент, а то, что, фактически, один из участников, ещё и участовал в разработке того же Си, то аргумент вдвойне. То есть, если у algola-подобного синтаксиса Си и есть конкурент, то это, скорее всего, Golang и есть. За выделенными проектами стоит следить, хотя бы, с точки зрения интерпретации концепций программирования, например, того же КОНТЕКСТА. Идея интерпретации записи, файла, бокса, сегмента, блока, контейнера, фрейма, объекта, области видимости все того же ассоциативного массива, то есть даже не карты с парой ключ-значение, а с парой значений, огромный шаз вперед в понимании сути вычислительного процесса, как такового, без заумностей в попытках натянуть алгебраические символьные абстракции на концептуализацию, в принципе. Видимо, все-таки, действительно, стоит, МЕТАМОДЕЛИРОВАНИЕ акцентировать отдельно, от той же математики, практики манипулирования с числами, но без потери идеи нумерации как процесса различения и именования.