суббота, 7 декабря 2024 г.

Pony

Pony предотвращает гонки данных. Он не может помешать вам писать условия гонки в вашей программе. Чтобы узнать больше о различиях между условиями гонки и гонками данных, ознакомьтесь с книгой «Условие гонки против гонки данных» Джона Регера.

В связи с Ryelang теперь вместо Rust видится golang, а архитектура tiddlywiki продолжает не давать покоя ... Такой кентавр можно оптимизировать и что-то может ещё привнести типа персистентности и контентной адресации, но в целом хочется систему мета моделирования конструировать на базе этих уже существующих артефактов. Из моего Telegram ...

То есть, казалось бы, выбор сделан и уже можно обойтись без чтения подобных комментариев ... Но очень трудно избавиться от искушения посмотреть очередной новый проект ... или просто проект, о котором ещё ничего не знаешь или просто забыл, что уже встречал, но не посмотрел и прошёл мимо, занятый другими вещами ... Reason (Ocaml), Vale, Inko, Hare ... Но уже не столько интересуют, собственно, концепции, сколько их формулировки ... И в этом смысле, именно, Ponylang, точнее его документация или спецификацция показалась содержательной, но даже не столько со стороны описания трюков распределения памяти, сколько отношению к концепции ТИПОВ ДАННЫХ ...

P.S. А, вообще, пора уже, хотя бы для себя продемонстрировать связь между ТИПАМИ и ИНТЕРПРЕТАТОРАМИ * ... И, опять же в рамках модели акторов, кстати, что и заставило внимательнее начать вчитываться в описание проекта Pony.

 ... А ещё на неделе подумалось о связи скобок и сложных препозиций ... как продолжение осознания того, что, то же ЕСЛИ ... ТО ... Это просто имппликация, которая описывается той же обычной стрелкой ... И, видимо это и есть та самая реальная база всего, та самая модель, синхроно возникающая при выделении любого объекта ... вместе с его связью ... хоть с чем ... например, с клозурой ... Без сопряжения мы просто ничего не сможем сделать ... Отсюда же становится понятным провал логических ЛОГЛАНА и ЛОЖБАНА с их "функциональным скобочным синтаксисом" вместо аппликативной природы той же ЛОГИКИ ... Если нам нужна арность, то тогда и нужны скобки ... 

четверг, 28 ноября 2024 г.

Базовый инструментарий для продвинутого пользователя компьютера

Намедни наткнулся на заметку о "зиме программирования" и в этом же контексте на проект пермакомпьютинга. Как-то это пересекается с моими переживаниями, хотя далеко не все. Надо бы концепцию Карла Сассенрата "Назад к персональному компьютеру ... но в сети ..." ещё раз проанализировать и уже с новых позиций или с учетом текущего сложившегося представления.Уже несколько лет перед Рождеством или Новым годом по старой привычке стараюсь подумать об итогах уходящего года и что-то типа о планах грядущего. После того, как ничего подобного от меня уже никто не требует, все равно считаю такой процесс необходимым и, в некотором смысле даже ежедневным для интеллектуального процесса, но попытка сформулировать что-то типа цели не на день, а на год, считаю чем-то особенным в индивидуальном плане. Это приносит меньшее удовлетворение, чем какое-либо решение от чего-то отказаться, но иначе трудно назвать свою собственную жизнь интеллектуальной. Постепенно (!) отказываюсь от присутствия в социальных сетях и думал, что эксперимент с фидевересе уже точно последний, но не удержался и дух экспериментатора заставил заглянуть в новую альтернативу твиттеру. Так вот о цели на год. Погрузиться в Golang, то есть весь год в центре внимания только Ryelang-Go. Вдруг из этого даже что-то и выгорит. В идеале, что-то типа тиддливики без JS и NodeJS. Не то, чтобы самому написать подобный софт, но понять, в принципе, возможно ли это сделать самому или найти развивающийся в этом направлении проект и примкнуть. То есть двигаться к персональному интеллектуальному агенту со стороны "инфраструктуры персонального интеллектуального профиля", навстречу развертывающемуся мейнстриму! Ну а параллельно продолжать работать со структурой ГЛОТЕОНА, CAP-грамматикой и манифестом метамоделирования, оптимизируя и перманентно редуцируя. Это, в конце концов уже результат. А если получится ещё и как-то его использовать в сочетании с практикой программирования, то это будет идеально, но это уже стратегия не на год, а на годы, преодолевая собственную ограниченность.

четверг, 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, что совсем не обязательно для представления персональных систем знаний. Кстати, о последних. Похоже это фундаментальный параметр для выбора проектов для анализа с целью потенциального использования. И надо пересмотреть отношение к выражению "СИСТЕМА ОБЩЕГО НАЗНАЧЕНИЯ".

четверг, 7 ноября 2024 г.

Ryelang-Go ...

На фоне застоя Red-lang и AltScript , в поисках развития аппликативного синтаксиса Rebol наткнулся на список форков Rebol3 , где два проекта привлекли безусловное внимание, прежде всего своей концептуальностью ... Arturo-Nim ... и Rye-Go. Последняя пара (интерпретатор-хост) показалась самой конструктивной и перспективной, как и идея и дальше анализировать проекты в связи с хостами ... типа JavaScript-C++, Lua-C, Elixir-Erlang, Raku-Perl, Elm-Roc ... и так далее ... Кстати, именно линия Rebol наиболее концептуально содержательна и дает возможность конструктивного рефакторинга, в результате которого я уже снес с компьютера все материалы и следы экспериментов с Phyton (Кстати недавно узнал, что Fortran до сих пор развивается!, как, например, та же Ada), Lua, Curl, Factor, Fort, Fresh (документацию flatassembler пока оставил как пример естественного описания практики без стереотипов), Racet, CommonLisp, Smalltalk (целых две реализации!) ... Tcl/Tk ... и так далее ... Кусты Apple и на все что связано с Java я откинул со старта анализа перспектив, пусть продолжают свою маркетинговую и "перпендекулярную" политику ... Буду продолжать подсматривать напраления Prolog (или Refal?, SQL, Datalog) и APL (K-System?, J) ... Но кажется, что и эту линию удалось уложить в общий концептуальный вектор ... Есть ещё персистентность UNISON, Phantom OS, HistoricModeling ... Но на текущий момент увлекла связка Ryelang-Go и кажется, что теперь уже на постоянно ... Это, именно то, что искал и откуда можно отталкиваться. Принципиальный и важный момент. Для меня. Найти тот фундамент, на который можно опереться. Уверен, что всем проектам типа Vlang, Zig, Crystal-Ruby ... не обойти Rust, бросившему вызов C/С++ и реально это сможет сделать только Go, с его профессионализмом разработчиков и мощной корпоративной поддержкой. Все проекты хороши и любой может развиваться и это как страны, а мы как пользователи и программисты ищем свой VirtualLand.

понедельник, 28 октября 2024 г.

MyOntoWeb

При попытке акцентировать концепции интерфейсов компьютерных систем, ловлю себя на мысли, что сама собой возникает приватная база, так называемых, "компьютерных языков" или "языков программирования", что немного пугает, так как возникает желание такой список систематизировать ... Но я знаю про PLDB и HOPL, списки в википедии, умирающую "прогопедию" ... где уже около 10 000 фиксированных фактов и есть попытки выделить параметры класификации и, в принципе, принципы, как "инкапсулировать такие объекты" ... Активные? С сообществами? Тьюринг полные? Компилируемые? Интерпретируемые? Устанавливаемые на "голое железо"? Графические? Системы разметки? Интерфейсы БД? ... И так далее ... И тому подобное ... Уверен, что любой интерфейс к любой системе - есть "тот самый объект", который хоститься над другой ... и вся эта "башня" на "машиином коде" ... С точки зрения жизнеспособности, до сих пор развиваются, например, такие проекты как Fortran, COBOL Ada ... Недавно узнал, что существует в пределах Канады, например, "язык Тьюринг" ... может по странам? авторам? ... Думаю, что меня интересует, прежде всего, Веб ... все, что вокруг ключего слова "коммуникация" ... именно здесь "зарыта собака", обозначаемая информационными технологиями, а вычислительные процессы - это частный случай всего этого "глобуса". Спецификации протоков и форматов - самые важные элементы этих технологий, по сути, их суть. С этой точки зрения становится очевидной связь браузеров и операционных систем, а с иже с ними, файловых систем или баз данных ... Короче, под этим знаменем, я начинаю создавать свою базу "веб-интерфейсов" ... Когда ясно сформулирована задача, то даже очевидной становится точка старта ... начать можно например, с веб-браузеров ... Ха-ха-ха ... их связь с хостовыми системами автоматически акцентирует и последние ... 

понедельник, 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 и есть. За выделенными проектами стоит следить, хотя бы, с точки зрения интерпретации концепций программирования, например, того же КОНТЕКСТА. Идея интерпретации записи, файла, бокса, сегмента, блока, контейнера, фрейма, объекта, области видимости все того же ассоциативного массива, то есть даже не карты с парой ключ-значение, а с парой значений, огромный шаз вперед в понимании сути вычислительного процесса, как такового, без заумностей в попытках натянуть алгебраические символьные абстракции на концептуализацию, в принципе. Видимо, все-таки, действительно, стоит, МЕТАМОДЕЛИРОВАНИЕ акцентировать отдельно, от той же математики, практики манипулирования с числами, но без потери идеи нумерации как процесса различения и именования.