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

Да.

кстати, тут несколько раз поминали надежды на "линейщину", под которой понимается "жираровщина" https://www.sciencedirect.com/science/article/pii/0304397587900454

От Жирара многое пошло, но не всё можно так называть.

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

Нууу, это слишком широко. Многое можно посчитать порождённым.
Скажем, так и вообще всё с сетями взаимодействия можно...

тогда уточните Вы, как оно точнее ))

Как-то по-другому называть те вещи, в которых он не участвовал.
Например, дифференциальщина ;-)

большинство людей под дифференциальщиной будут подразумевать нечто иное...

В линейно-логиках, из важного, он изобрёл поляризацию-фокусинг, ну и сети доказательств.
А конкретные примеры, на мой взгляд, были несколько неудачными (например, в чистом виде GoI мне совершенно не нравится).

Потому, я и пишу что-то типаа линейщина-дифференциальщина ;-)

Да хрен знает, как лучше обзывать...

Сначала на естественных языках осуществляется формализация контента для языков программирования, затем уже из осуществлённого образуются «логические триплы», и укладываются в персептроны (нейронные сетки), — и при этом теряется трипловая форма. Т.е. сначала становится неочевидной логика каждого из трех слагаемых одного логического трипла, а потом сама логика трипла становится неочевидной, путем своего представления уже без основания на сущности логического трипла. Другими словами, сначала забыли о логике слагаемых трипла, а потом забыли о том что забыли.
А самое грустное во всем этом методе «логических триплов» то, что формализация контента на естественных языках для слагаемых логических триплов (для формальных языков программирования), вообще осуществляется без учета существенного различия языков, различных групп естественных языков.
Логика причин (но не факта) различия групп языков — цель научно-исследовательской аналитической деятельности, достижение которой необходимо для решения проблем, сформулированных в целеполаганиях этой группы здесь (в телеге).

Maxim, триплы не всегда "логические", в смысле формальной математической логики. Gellish - яркий тому пример, когда триплы есть, но это просто ограниченное подмножество естественного языка (Formal English - см. https://www.gellish.net/ ).

Да, но суть мной описанной проблемы, и пути ее решения — те же, что и с логическими. Речь ведь о сущности слагаемых для триплов, а не о видах полученных триплов. Логические взяты как пример из линка.

Да те же самые ножницы. Сначала про in-the-small. Например, сломалась ручка ножниц. Берём отпиливаем (одну) ручку от других ножниц, и привариваем к этим. Даже если в БД заведены таблицы как для самих ножниц, так и для их половинок и винтиков, и даже для функциональных блоков "ручки" и "ножи", то такие нестандартные ситуации непонятно как учитывать. А когда in-the-large, то всё ещё хуже, когда ножницы есть в БД проектного института, БД завода-изготовителя, БД транспортной компании, БД склада, БД швейной фабрики, БД ремонтной матерской, БД бухгалтера на подряде, и т.д. И первичные ключи вроде одних и тех же ножниц не соотносятся между собой один-к-одному. Интеграционные сценарии спасают положение, но не универсально, а только для ножниц именно в этом "бизнес-процессе".

Да, ваши последние записи я в LJ видел.  Кстати,  о птичках,  т.е близкой мне системе SAP.

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

Дело в том,  что в SAP нельзя просто так напрямую создать табличку с полями.  Нужно пойти в словарь данных, для полей таблички сослаться на элементы данных,  в элементах данных описать из назначение и сослаться на домены,  в доменах опять описать назначение и сослаться на один из базовых типов.  Если сослался на элемент данных с количественным типом в домене - будь добр укажи поле с единицей измерения,  аналогично для стоимостных полей нужно указать валюту.  И все это трассируется по where used,  т.е можно посмотреть в каких табличках фигурирует вот этот элемент данных "номер заказа на продажу".  

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

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

Производственная практика показывает, что программист приземляет на систему типов своего языка программирования не концептуальную модель БД, а физическую.  Вчера был вопрос "насколько часто типы вообще используются для описания домена" - вот оно здесь. Какие физические таблицы и поля завели в БД, такие типы в программе обычно и заводятся (ORM для незнающих SQL). То есть, тип данных pump в программе обычно появляется только если в БД есть таблица с насосами, и программисту неважно какие насосы - складские, установленные на станции, разбираемые, или другие, так как он делает типы "для вычислений".

Как всегда - есть, но не всегда то, что хочется.
Видели обзор https://medium.com/@mikhailparfentev/%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7-%D0%BB%D1%83%D1%87%D1%88%D0%B8%D1%85-%D0%BC%D0%B5%D0%B6%D0%B4%D1%83%D0%BD%D0%B0%D1%80%D0%BE%D0%B4%D0%BD%D1%8B%D1%85-%D0%BF%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D1%8F-%D0%B8-%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC-%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%BC%D0%B0%D1%81%D1%82%D0%B5%D1%80-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D0%BC%D0%B8-8b57fd39696f