Микросервисы и точки отказа.

у нас тут диалог на тему ЯП получается, который мне очень интересен, но сильно не по теме поста

поэтому я тебе написал на твой адрес, который указан в твоих коммитах мемории на github, и на адрес твой_ник_на_лоре собака gmail.com

в целом, я думаю мне стоит изучить и изложить твои взгляды, идеи и то, что у тебя сделано (естественно добавив свой feedback)

в эволюционном подходе DRY идёт лесом

такой эволюционный подход обычно называют регрессом или деградацией

а почему так получается?

с моей наивной точки зрения можно иметь общий интерфейс (допустим даже в отдельной репе) для нескольких команд разработки

Вижу тебя, да. Отлично.

Обсуждаемый ЯП как раз по теме «микросервисов с состоянием», если не уходить глубоко и надолго в детали реализации самого языка, а сфокусироваться на его рантайме и применении.

Обсуждаемый ЯП как раз по теме «микросервисов с состоянием»

я похоже никогда на эту тему не думал, но немного думал в похожих/соседних направлениях, типа «язык гибрида bash & make», «язык init», «язык для пре-/пост-инсталл скриптов», «язык для пользовательских (в противоположность системным) пакетов»

конечно же я еще думал о синхронизации состояния (фактически БД, оставляя за скобками пакеты и файлы ОС) между разными нодами, но не пытался подумать, какой для этого нужен язык

еще очень интересная вещь в рамках «язык для микросервисов с состоянием» — попытки статически типизировать erlang (что получается не совсем), но это я только начал читать

если не уходить глубоко и надолго в детали реализации самого языка

детали реализации, которые оффтопик для этой темы, как раз самое важное, если мы хотим, чтобы язык выжил и захватил если не весь мир, то хотя бы территорию нескольких соседних языков — и меня интересует именно это

Создай отдельную тему в Development и переползаем туда.

я похоже никогда на эту тему не думал, но немного думал в похожих/соседних направлениях, типа «язык гибрида bash & make», «язык init», «язык для пре-/пост-инсталл скриптов», «язык для пользовательских (в противоположность системным) пакетов»

Нам точно не нужен отдельный именно язык для микросервисов. Проблема в том, что рантаймы существующих языков не приспособлены под требования «микросервисов с состоянием». Например, фундаментальная проблема GIL в Python, не дающая возможность ввести туда CSP-подобный режим.

Идти нужно от рантайма (пример - Seastar Framework) (модель памяти, модель данных, модель вычислений), вокруг которого уже и строить какой-нибудь диалект существующего языка (типа твоего «статически типизированного Erlang»), раскрывающего возможности этого рантайма.

совершенно неожиданно для меня дискуссия хорошо пошла здесь — ну так и продолжим пока что здесь

Идти нужно от рантайма (пример - Seastar Framework) (модель памяти, модель данных, модель вычислений),

для меня язык программирования — это прикладная теория познания (прикладная онтология); если у тебя есть потребность внятно, эффективно (по людям) и эффективно (по железу) управлять распределенным состоянием и ты приспособил для этого свои 3 модели, то можно присобачить прикладную онтологию и к твоим 3 моделям, но мне в общем-то почти пофиг к чему ее присобачивать

на самом деле не совсем пофиг, так как управлять распределенным состоянием полезно, денежно, и наконец именно конкретные use cases дают возможность делать полезные теоретические обобщения; последнее особенно важно потому, что сформированной прикладной онтологии у меня нет (хотя идеи есть), и я собрался ее делать «на ходу»

типа твоего «статически типизированного Erlang»

Erlang не мой, я просто разместил объяву (С)

вокруг которого уже и строить какой-нибудь диалект существующего языка

нет

я не знаю ни одного приличного языка (в смысле прикладной онтологии, привязанной к языку программирования); всякие агды-коки-идрисы на мой взгляд ужасны с прикладной точки зрения — да и ты явно не агду имел в виду, когда говорил о «диалекте существующего языка»

Создай отдельную тему в Development и переползаем туда.

ага, думаю об этом; только вот надо уметь набросить так, чтобы отклики были, а то у меня может выйти такой текст, прочитав который все подумают «чувак знает о чем говорит» и промолчат

для меня язык программирования — это прикладная теория познания (прикладная онтология)

Ты мыслишь в правильном направлении. Единственное, что теория познания предполагает действенную и продуктивную Теорию Разума, что сразу выбрасывает нас на самое острие современного ИИ. Ты видел мои наброски как раз по этой теме (проблематика феноменального знания). Если ты хотя бы в принципе понимаешь, что и почему я там пишу, то сможешь и понять, почему я принимаю те дизайнерские решения вокруг всего этого стека, которые принимаю. Мои решения продиктованы следствиями из основных теорем Algorithmic Information Theory.

Что касается ЯП. То, что я называю «продуктивный» предполагает дотягивание инструментария ЯП до уровня моделирования знаний. А соответствующие инструменты описания (онтологий) можно будет заводить в язык через eDSL.

В Мемории будет нативная поддержка (виртуальных) семантических графов («граф знаний» – частный случай СГ). Они будут интегрированы как в рантайм (например через RETE-engine), так и в языки программирования над этим рантаймом.

Для меня всё это выглядит примерно так. Есть хост-язык, который выглядит примерно как «гибрид С++ и Java», и есть его расширения через eDSL и метапрограммирование. Всё это над рантаймом, моделью данных и вычислений, которые дает Мемория.

Единственное, что теория познания предполагает действенную и продуктивную Теорию Разума

с чего вдруг?

для практических приложений вполне можно ограничиться описательной теорией познания, примерно как линней описательно классифицировал животных

с чего вдруг?

Из-за проблемы феноменального (данного непосредственно в переживаниях) знания, которое упирается в проблему Наблюдателя. Моделируя знания, ты моделируешь Наблюдателя, потому что это его знания (субъективность). Иначе, ты моделируешь поведение объекта, представленное в виде его взаимодействий с другими объектами.

Иначе, ты моделируешь поведение объекта, представленное в виде его взаимодействий с другими объектами.

и для ЯП этого вполне достаточно

твои статьи я вообще по диагонали посмотрел, и навскидку скажу, что где-нить ты там делаешь неправомерный переход между поведением и сущностью

но при этом философия вне ЯП тоже крайне интересна

Разумеется. Это более чем достаточно для ЯП. Но ЯП пока еще сам на себе не пишет. А вот программист будет пытаться решать задачи автоматизации деятельности человека, где проблема феноменального знания лезет из всех щелей. Вот как раз для этого и нужны прикладные Теории Разума (формальные модели мышления), чтобы знать, какую онтологию (по сути — структуру данных) под какой кейс выбирать. И что — не решаемо в принципе.

где проблема феноменального знания лезет из всех щелей

вапще совсем не вижу этого, ну просто вот в упор, так что мне кажется ты где-то не прав

что где-нить ты там делаешь неправомерный переход между поведением и сущностью

Это было бы очень печально для меня. Это был бы просто лютый epic fail. Я полностью остаюсь в рамках моделирования поведения, подходя к сущности лишь в пределе применения метода. Просто в процессе применения метода выявляется очень много поведения, которое в обычном состоянии «не видно для субъекта», а потому и не поддается описанию в виде онтологии. Вот об этом речь.

Это было бы очень печально для меня.

и это зря по-моему

вапще совсем не вижу этого, ну просто вот в упор, так что мне кажется ты где-то не прав

Ну вот тебе пример.

«Вася очень любит свою страну».

Нам нужно предложить алгоритм и структуру данных для генеративного (или хотя бы дискриминативного) описания множества отношений в которые вступает объект Вася со своим операционным окружением.

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

Ты хочешь проснуться в мире, где твой утюг предъявит тебе обвинения в домогательствах потому что он теперь, видите ли, sentient being и «чувства имеет»? Не хочешь? Тогда не торопись открывать этот Ящик Пандоры :)

прямой ответ на твой вопрос лучше обсуждать в другом месте

но по делу — то есть по ЯП — если я правильно тебя понял, то ты пытаешься точно смоделировать слишком много из процесса познания

столько много не нужно тащить в ЯП (и даже в теорию познания, прикрученную к ЯП) — по крайней мере на первый раз

если по-твоему я не прав, то тебе нужно привести конкретный пример, только не в терминах «любит», а «покупает», «поставляет», «подтверждает/доказывает» и т.п.

если я правильно тебя понял, то ты пытаешься точно смоделировать слишком много из процесса познания

Совсем наоборот. Я как раз таки не просто не пытаюсь этого делать, но и даю обоснование того, какие задачи (проблематика феноменального знания) будут трудными (очень), и я даже не собираюсь их решать. Что сильно сократит хайповый потенциал разрабатываемого инструмента.

если по-твоему я не прав, то тебе нужно привести конкретный пример, только не в терминах «любит», а «покупает», «поставляет», «подтверждает/доказывает» и т.п.

У большого босса Васи есть секретарша Анечка. Умница-красавица, спортсменка-комсомолка, всё делает на отлично. И, в частности, офигенно умеет сортировать почту босса Васи. К сожалению для Васи, Анечка уходит в декрет, и на долго. И, вот, Вася задался задачей: напрячь свои программистов, чтобы они «обучили эти свои нейросети или что у них там» так, чтобы они сортировали почту так же эффективно, как это делала его секретарша.

Везде, где у тебя возникает задача интефейса человека и машины, будет задача работы с феноменальным знанием.

в такой формулировке уже лучше

возможно стоит это обсуждать в мессенджере (телеграмме скажем), так как я тебя странно понимаю (или вообще не понимаю) слишком часто

а решение проблемы с анечкой простое, скучное и практическое: нанять вторую анечку, а теории познания тут нужны только для того, чтобы помочь первой анечке сформулировать свои наставления второй анечке (проверить их на полноту скажем, и на непротиворечивость, и еще на что-нибудь; а еще можно попробовать подсунуть готовые шаблоны, где остается подставить свое; и даже всем этим может быть должен заниматься аналитик-человек, а не обе анечки)

в рамках проектирования ЯП задачу «чтобы анечка передала знание программе» я не ставлю

достаточно задачи «программист/аналитик передал знание о предметной области другим программистам/аналитикам, а компилятор-на-стероидах оказал в этом посильную для него помощь»

и вот последняя задача до сих пор решается из рук вон плохо (в том смысле, что, как я полагаю, это можно делать гораздо лучше)

а решение проблемы с анечкой простое, скучное и практическое: нанять вторую анечку, а теории познания тут нужны только для того, чтобы помочь первой анечке сформулировать свои наставления второй анечке

Не совсем так. Если я заявляю, например, что (назовем этот язык Memoria PL) позволяет делать онтологическое моделирование, то сразу появляются люди, которые спросят меня, «а можно ли на нем писать скиллы для голосовых помощников». Имеется в виду не только чисто процедурные скиллы, а то, можно ли как-то «программировать понимание». Т.е. предоставляет ли Memoria PL для задачи написание «цифровой Анечки» что-то особенное, что не предоставляют другие языки программирования (и рантаймы).

Например, Python считается «языком для ИИ», но сам он по себе для задач того же GOFAI не предоставляет вообще ничего специфического. Просто библиотеки ML написаны на C++ и используются через CPython. А Python – это просто host-язык для соответствующих eDSL.

А теперь, с другой стороны. Нужно ли нам онтологическое моделирование, если мы пишем проводки товаров по складу? Я считаю, что – нет, если мы, конечно, не страдаем перфекционизмом и не собираемся довести модель данных до идеала (т.е. в данном случае до графа). Нужно просто смириться, что идеальные решения оказываются слишком дорогими на практике, а потому бессмысленными. Расслабиться и пойти жить.

Особенность сегодняшнего момента состоит в том, что сейчас появились задачи, способные обосновать на практике затраты на разработку инструментов для продвинутого моделирования данных. А они – немаленькие. Это раньше Вася нанял бы Танечку вместо Анечки. А сейчас перед Васей стоит уже другая задача: писем стало так много, что даже дивизия Анечек не справится.

А сейчас перед Васей стоит уже другая задача: писем стало так много, что даже дивизия Анечек не справится.

отсюда сразу видно, что это не так

на самом деле Вася стал пытаться кроме писем читать разную макулатуру тоннами (в надежде там намайнить че-то полезное для себя), и пытается под первичную сортировку подтянуть ИИ, чтобы он работал вместо анечки

Если я заявляю, например, что (назовем этот язык Memoria PL) позволяет делать онтологическое моделирование, то сразу появляются люди, которые спросят меня, «а можно ли на нем писать скиллы для голосовых помощников».

на это следует бодро и весело ответить «нельзя» (хотя я конечно утрирую)

Нужно ли нам онтологическое моделирование, если мы пишем проводки товаров по складу?

скорее всего не нужно, но не все однозначно

программисту может показаться, что общую сложность программы можно уменьшить (или пусть сложность увеличить, но и при этом все же и сопровождаемость сильно увеличить), если в коде не заниматься копи-пастом с изменениями, а вместо этого добавить какое-то сложное понятие времени компиляции — вот тут да, онтологическое моделирование может быть очень кстати

А Python – это просто host-язык для соответствующих eDSL.

и все, по сути, что он предоставляет для этого (поверх с++):

1. ключевые параметры
2. неспособность обрушить рантайм

так что не надо брать на себя слишком большие задачи

кстати, c# для eDSL предоставляет побольше — expression tree например (хотя это и отягощено лишними фичами)

тогда следует бодро и весело ответить «нельзя»

Забегая вперед, я именно так и отвечу. И дело тут не в самом онтологическом моделировании, а в том, что скиллы такой сложности писать руками (белый ящик) уже нельзя, тут нужно машинное обучение (черный ящик) – просто из-за размерности (и объема) промежуточных данных.

Но пока что нам предстоит дать ответ на вопрос, а нужно ли нам что-то большее, чем просто перекладывание байтов из потока в поток или условный Golang (или Rust) – это всё, что нам по жизни надо?

Иными словами, если мы говорим о каких-то продвинутых инструментах моделирования, то нужен класс задач, для которого эти инструменты необходимы. Например, Мемория началась с необходимости иметь продвинутые пространственные индексы, чтобы использовать их в тех сценариях, в которых нейросети не могли то, что мне было нужно. Персистентная модель данных, все эти кучи разных контейнеров и хранилищ – это просто обвязка, необходимая для их эффективного функционирования (а так же просто побочный эффект).

че-то я подозреваю, что я где-то тебя неверно понимаю, и вот почему:

я за собой вижу стремление делать излишне большие шаги, а ты с моей точки зрения пытаешься делать мега-супер-крупные, и вроде как не понимаешь моих аргументов, что шаги нужны помельче

Если говорить о CPython, то у него есть еще одна важная фича — ARC, что позволяет подцеплять RAII к питоновскому коду. А вот у Julia, которая на голову выше Python во всем, уже трассирующий GC. И, извини, управляй нативными ресурсами вручную. Спасибо, но я этого в Java наелся. То же самое относится и к C#.

Как я уже сказал, бесшовная интеграция с С++ для меня — императив. Если она не требуется, то вариантов сразу становится значительно больше. В том числе и уже существующие.

Иными словами, если мы говорим о каких-то продвинутых инструментах моделирования, то нужен класс задач, для которого эти инструменты необходимы.

я предлагаю класс задач, в которых уже устоялась человеческая формализация предметной области (или хотя бы устоялись подходы к такой формализации), но при этом она (формализация предметной области) еще не перенесена удобную для человека и читаемую/проверяемую машиной форму

update: более того, иногда даже читаемая/проверяемая машиной форма есть, но без слез ее использовать нельзя, так что требуется resyntaxing

Как я уже сказал, бесшовная интеграция с С++ для меня — императив.

тут я согласен

Ты всё верно подмечаешь. Мне просто давно уже нужно было больше написать на сайте Мемории, что она умеет. Эти супер-крупные шаги я уже сделал. А, так, я полностью в твоей парадигме «маленьких шажков». Только так и можно куда-то прийти.

я предлагаю класс задач, в которых уже устоялась человеческая формализация предметной области (или хотя бы устоялись подходы к такой формализации), но при этом она (формализация предметной области) еще не перенесена удобную для человека и читаемую/проверяемую машиной форму

Давай я для ясности уточню. Речь идет о детерминированном моделировании. Т.е., например, вероятностные модели мы не рассматриваем.

И, если всё так, то, чудненько. Наша задача сводится к задаче эффективного представления обычных (не вероятностных и без других расширений) семантических графов. Соответственно, язык должен обеспечивать удобную среду для такого моделирования, а рантайм — эффективные вычисления в ней. Этакий RDF4J, но сделанный по-другому.

тут нужно машинное обучение

да

(черный ящик)

нет (я полагаю что черный ящик не обязателен, но нынешние люди не научились без него обходиться)

Я неточно выразился. Тут нужно не машинное обучение, а т.н. индуктивное программирование. Это когда машина выводит программу сама. Машинное обучение является частным случаем индуктивного программирования.

Одна из причин «онтологического апокалипсиса» проекта Cyc состоит в том, что человеку вручную онтологии писать уже очень сложно. Мы не такие уж и хорошие программисты. Сложные онтологии уже приходится выводить индуктивно, машинными методами. И, да, такой ЯП должен полностью поддерживать режим, когда возможна ручная доводка индуктивно выведенных онтологий. Вот это нам надо.