Системная информатика

Системная информатика

by Евгений Волков -
Number of replies: 0
Пишет Anatoly Levenchuk ( ailev
2016-06-23 16:37:00

Системная информатика

Моя идея остаётся прежней: моделирование, программирование, онтологизирование (и, думаю, обучение как в machine learning) -- это предметная область для одного и того же отношения абстрагирования, как мереология -- это предметная область одного и того же отношения "часть-целое" в разных его ипостасях и вариантах. 

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

Конечно, акценты тут разные:
-- программирование (поскольку сюда неявно включается алгоритмика как абстрагирование действий и работа с данными как абстрагирование объектов и свойств со всеми оговорками, что объекты могут сами по себе абстрагировать действия) тут наиболее общо, но оно позволяет "оживлять" абстракции, манипулировать ими, строить имитационные модели. В программировании также уделяется много внимания формализму моделирования: синтаксису и семантике. Глубина абстрагирования -- метапрограммирование.
-- Моделирование тоже наиболее общо, ибо это сама суть абстрагирования: оставлять в одной системе самое важное от другой, абстрагирование в чистом виде. Но, увы, акцент на запуск модели на исполнение, "оживление" этой абстракции тут не делается. Ничего, мы пойдём другим путём: при языках моделирования очень часто можно найти каки-то более-менее полноценные (полнотьюринговые) языки программирования -- как языки запросов или декларативные языки ограничений. Например, SPARQL при RDF (чтобы не сложилось впечатления, что речь идёт только о процедурных языках) или OCL при UML/SysML. Глубина абстрагирования -- гирлянда метамоделей.
-- Онтологизирование само по себе наиболее общо, ибо в программировании и моделировании неважно что абстрагируется, а онтологизирование обращает внимание на реальность мира и аспекты "истинности" моделирования (глубоко занимается самим отношением абстракции), привносит философскую логику и заставляет задумываться о способах моделирования пространства, времени, а также задумываться о преобразованиях одних классов моделей в другие, парадигмах абстрагирования и их совместимости друг с другом. Глубина абстрагирования даже не рассматривается, ибо органически входит в дисциплину.
-- Обучение тоже наиболее общо, ибо обращает внимание на эпистемологический аспект абстрагирования, "как получили эту абстракцию", а не онтологический "что там наабстрагировали". Глубина абстрагирования явно обсуждается в современном machine learning. А ещё обсуждаются разные парадигмы моделирования, включая многоуровневые распределённые представления (machine learning).

Работа с абстракциями, воплощёнными в текст и коды (понимаемый широко, "всё есть текст", включая паттернирование "символами" на картинках и т.д.) -- это информатика, работа агентов (людей и компьютеров) с текстами и кодами я разбирался с этим тут:http://ailev.livejournal.com/1008054.html, дисциплины информатики там были философская логика, когнитивная наука, лингвистика, компьютерная наука. По факту, к уже выраженному в этих прежних (это был июнь 2012) текстах добавилось (машинное) обучение. Ну, и "компактное описание" я заменил на "абстрагирование" (тут я шёл как раз от deep learning, в коннекционистской парадигме уровни нейронной сети как раз уровни абстракции, равно как и в гирляндах символического метамоделирования -- цепочек классификаций и специализаций).

Логический уровень, уровень абстракции, уровень объективации, все эти "мета" -- это всё про одно и то же (http://ailev.livejournal.com/1073932.html):

Подробней про разные "мета" -- http://ailev.livejournal.com/1204705.html, про формальное образование в этой области --http://ailev.livejournal.com/1263511.html, логические уровни Бейтсона (эпистемологические, "обучения", а не онтологические его результатов) затрагиваются в разделе "когнитивной архитектуры" http://ailev.livejournal.com/1210678.html, многступенчатая объективация и объективизация --http://ailev.livejournal.com/1132449.html. И, конечно, сюда нужно добавить коннективизм в количестве: отношение между представлениями в разных уровнях нейронной сетки, разные уровни абстракции и архитектуры из разных стеков (уход от чистой иерархии слоёв-уровней, выход в сложные fully differentiable architectures с памятью, вниманием, различными обработчиками логики, выполнением алгоритмов и т.д.). 

Системный подход включает в себя абстрагирование как основной метод борьбы со сложностью, включая абстрагирование в рамку деятельностного подхода (ага, подход в подходе): 
-- Конкретное абстрагирование оформляет (frame) интерес стейкхолдера (деятельностной позиции, абстракции мыслящего существа, оставим на потом спекуляции про мыследействующих и абстрагирующих существ). Так сказать, "теория субъективной информации" (http://ailev.livejournal.com/66325.html, 2003).
-- Мереология ведущее отношение для абстрагирования (системы это холоны), она даёт возможность договориться по поводу того, что именно в реальном мире в конечном итоге абстрагируется в длинных цепочках метаабстрагирования. Системный подход -- это аналог структурного (иерархического) внимания в окружающий мир. Это позволяет строить описания каких-то частей мира, соответствующим системам в их границах, отделять фон от систем. В моих учебниках это "zoom-select". Подробней это раскрывается в http://ailev.livejournal.com/860017.html
-- есть жизненный цикл системы (указание на обеспечивающую систему -- http://ailev.livejournal.com/1248044.html), практики абстрагирования (практики определения и документирования определений -- создания полного описания) в этом жизненном цикле обязательны. Моделирование всегда было неотъемлемой составной частью системного подхода, а проектирование -- составной частью системноинженерного подхода. Программирование в какой-то момент через кибернетику тоже неудачно пыталось вписаться (пока не стало понятно, что кибернетика с её обратной связью совсем-совсем не эквивалентна информатике как таковой, и даже классической computer science как части информатики).
-- Поскольку деятельность коллективна, стейкхолдеров в ней много и ещё больше их интересов, то абстрагирований тоже нужно много, и разных для удовлетворения разных интересов. Но все полученные абстракции связаны между собой тем, что они про одну и ту же систему (или её части): любая абстракция это абстракция системы (или типа систем).
-- в силу коллективности деятельности, любое абстрагирование по мере роста его объема становится абстрагированием-в-большом (programming-in-the-large -- и см. как пример http://ailev.livejournal.com/748188.html, 2009г., и тамошний разбор сервис-ориентирования в современном программировании)
-- абстракции есть всегда, если есть система (наше знание о том, что есть система -- это уже абстракция), но они должны быть документированы для работы с ними -- разница между system definition и system description.
-- каждая абстракция имеет модальность (алеатическую, деонтическую, темпоральную), эти модальности могут меняться в ходе жизненного цикла.

Если соединить системный подход и расширенную распределёнными представлениями и коннекционизмом (http://ailev.livejournal.com/1228029.html) информатику (т.е. учесть, что все тексты и коды -- это описания тех или иных систем на разных уровнях абстрагирования, и эти описания отвечают разным интересам коллективно действующих стейкхолдеров), то будет системная информатика. Конечно, при этом придётся как-то справиться с коннекционисткой проблематизацией и в информатике (все эти end-to-end fully differentiable architectures) и в системном подходеhttp://ailev.livejournal.com/1252230.html

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

Например, можно считать, что все существующие языки -- это на каком-то уровне абстракции различные частные методы описания (viewpoint) каких-то определённых (view) системы.

Заново подойти к SysMoLan как языку системного абстрагирования (онтологизирования, программирования, моделирования и т.д.) --http://ailev.livejournal.com/1127145.html (2014 -- обратите внимание, там как раз попытка выйти на "системную информатику", но на примере одного языка и без попыток обозначить предметную область, чисто на "обобщениях из практики"), http://ailev.livejournal.com/1169972.html (2015, требования к формализму), или даже ещё более старым идеям Симултрека (http://ailev.livejournal.com/611877.html -- 2008, "Датацентрика -- это концептоцентрика. Документоцентрика -- это символоцентрика"). 

В принципе, можно было бы ввести концепцию "достроения языка до системного", считая каждый язык каким-то частным методом описания (veiwpoint), порождающим "частное описание" (veiw, которое само состоит из набора моделей -- всё строго по ISO 42010). Для этого нужно понять, что же означает в информатике наличие какого-то текста на языке? Означает только одно: исполнение его в каком-то смысле. В этом-то и секрет, что исполнение или оценка языка совершенно необязательно предписаны! Одна и та же модель/программа/онтология (не заморачиваемся тут разницей между definition и description -- например, разницей между онтологией и онтологическим описанием) может быть оценена (eval) или исполнена (execute) в разных смыслах: из одного текста можно породить разными способами много других, например можно текст программы интерпретировать, а можно сначала компилировать (т.е. изготовить по образцу одного текста другой текст). и только потом интерпретировать. Программа для станка с ЧПУ так вообще приводит при её интерпретации к изменениям в реальном мире (впрочем, даже обычная компьютерная программа тоже приводит к изменениям в реальном мире, только очень маленьким -- типа краски из пикселей на бумаге или по-разному пропускающих свет фотонов на экране). А 3D-модель тоже оказывается вполне исполнима: она декларативна, но это не мешает её исполнять 3D-принтеру, воплощая систему. Так сказать, "обратное моделирование", reverse modeling, воплощение!

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

В принципе, никакой особости определения системной информатики нет. Системная химия (http://ailev.livejournal.com/1117783.html -- про разные сложные и самоорганизующиеся молекулярные системы, в которых проявляются какие-то нетривиальные эмерджентности), системная биология -- это всё про физический мир. Мы же тут о мире абстрактных объектов и его связи с физическим миром (через носители/media, выполнители/interpreters и всё такое).

В этом плане системная информатика должна как-то собирать различные описания в кучку. Скажем, в проекте http://rosettacode.orgсравниваются описания решений математических главным образом задач на разных языках программирования. Там есть классический T-shirt: описание задачи (текст выходных данных + что нужно сделать), алгоритм (что делается = модель-решение для "что нужно сделать", текст на языке программирования) и output (текст выходных данных). Если брать языки моделирования, то сразу становится очевидным, что их нельзя сравнить с языками программирования: там нет этой тройки текстов "вход-алгоритм-выход". Но это не совсем так! С точки зрения системной информатики, всё это моделирование имеет смысл только для ответа на какие-то вопросы. Это просто означает, что есть ситуация (описание модели), модель (код, формальный текст решения для данной ситуации -- результат абстрагирования, выраженный в языке какой-то метамодели) и есть вопросы, которые задаются модели, предполагающие её исполнение в каком-то смысле. То есть интерпретатор тут не "виртуальная машина языка" (читающая программу и выполняющая её над входными данными -- интерес при этом фиксирован: выполнение программы), а "виртуальная машина модели" (читающая запрос для какого-то интереса и выполняющая его над моделью как входными данными). Этот интерпретатор может быть либо человеком, либо нет -- и тогда язык запросов это и есть язык моделирования! Это хорошо видно на парах декларативных языков OCL и UML (и любая запись на UML может быть выражена в OCL!), SPARQL и RDF/OWL. Получается, что языки моделирования -- это какие-то подмножества для своих часто стремящихся к полнотьюринговости языков запросов, просто выраженные в другом синтаксисе и отражающие только часть возможностей языка запросов.

Замечу, что этот подход отличается от "интеграции моделей на базе онтологий", к чему вели и Sztipanovits в http://ailev.livejournal.com/675208.html и https://www.simantics.org/ и наш собственный заход в dot15926. Онтологии никуда не делись, но они "внутри". И появилось явно выполнение этих онтологий, они не рассматриваются вне языка запросов. А язык запросов к онтологиям оказывается просто хорошим языком программирования, во всей его полноте и мощи. Ну, или его можно легко реализовать с учётом какой-то специфики модели -- тоже как встроенный DSL.

Тем самым для всех языков моделирования либо нужно надстраивать для них языки запросов рано или поздно (что мы видим буквально для всех языков моделирования -- "хорошая мысля приходит апосля", языки запросов потом надстраиваются в разнообразии над удачными языками моделирования, а потом стремятся к полнотьюринговости, невзирая на разность своих парадигм. Взять хоть SQL для языка реляционного моделирования данных, хоть потуги определить язык запросов для XML -- XQuery и вся сопутствующая дискуссия и причины не слишком большой распространённости этого языка, его заменяют "просто языком программирования", и не случайно). 

Либо можно пойти другим путём: нужно взять язык с развитой рефлексией и метапрограммированием (например, какой-нибудь Лисп. См., например, контекст появления Лиспа в дискуссии про универсальные языки моделирования/программирования http://justy-tylor.livejournal.com/246591.html и http://justy-tylor.livejournal.com/246877.html) и считать, что это и есть системный язык -- и порождать дальше языки моделирования из него по потребности (ну, или писать на нём в соответствии с удачными другими языками моделирования). Например, можно думать о том, чтобы (пока justy-tylor не предложит какого более удачного решения) брать тот же язык Julia, в котором в части рефлексии и метапрограммирования вполне Лисп внутри, и
-- реализовать на нём DSL для выражения моделей ArchiMate 3.0 (при этом можно даже сохранить вывод этих моделей в виде правильных графических диаграмм! Это ж просто будет такой viewpoint -- графическое описание). Дальше два использования: 1. просто глазеть на диаграммы, используя подмножество языка для удобной их текстовой записи (или даже удобного графического редактирования), 2. выполнение запросов. Учитывая, что ArchiMate 3.0 подразумевает расширения себя разными атрибутами и типами элементов, то легко можно представить самые разные запросы -- от "сколько практик у нас в модели" до "посчитай необходимую производительность для сервера" (этот пример про подсчёты на основании диаграмм архимейта -- прямо из книжки автора языка. Но там ArchiMate даётся как внешний DSL, и этот подсчёт реализуется независимыми от языка средствами. А у нас ArchiMate является встроенным DSL к Julia, поэтому просто пишем на Julia запрос к структурам ArchiMate-на-Julia. Julia к этому ArchiMate является и языком ограничений (хотя так не принято называть, это ж не логический язык!) и языком запросов (хотя так тоже не принято называть, не подразумевается какой-то модели данных) -- но если допустить, что внутри самого языка (а не сбоку на диске) есть модель, то всё становится на свои места.
-- выполнить план по линии Modelica-на-Julia, описанный в третьем пункте тут: http://ailev.livejournal.com/1271980.html
* * *
Тем, кто меня читает много лет, должно быть всё понятно. Кто читает совсем недавно -- не будет понятно ничего. Единственное, что могу посоветовать, это попробовать прочесть посты и материалы по ссылкам из текста. Если и там непонятно -- то в тех материалах тоже много ссылок, и так "до дна", пока не станет понятно. 

По-хорошему, дальше две линии работ:
-- нужно как-то вытащить все эти обрывки мыслей по ссылкам, развернуть их, причесать и сделать учебник. Ибо как россыпь постов это всё необозримо. Когда-то у меня было такое же состояние дел в части системного мышления, пока я не сосредоточился и не написал учебник, аж две версии (http://techinvestlab.ru/systems_engineering_thinking). Вот и тут нужно писать учебник системной информатики, при всех текущих с ней непонятках.
-- взять какой-то язык с похожим на лисповое метапрограммированием (а хоть и Julia -- заодно там нет тяжёлого наследства программистской объект-ориентированности), и дорастить его до языка системного моделирования (оно же программирование, оно же онтологизирование, оно же проектирование и т.д.). Точнее, "спустить" его до DSL моделирования в его составе (что потребует описания на нём соответствующих метамоделей).
-- ну, и нужно отслеживать что там происходит в части коннекционистского моделирования-как-обучения (моделирования естественного языка, моделирования языков программирования, моделирование планов и цепочек действий, выражения концептов и понятности моделей-в-распределённых-представлениях и т.д.).
* * *
UPDATE: системная информатика -- это "информатика с системным мышлением в голове". Системная инженерия тоже так определяется: как "просто инженерия", только с системным мышлением в голове (ср., например, с http://ailev.livejournal.com/1157398.html).

UPDATE: некоторая дискуссия к этому посту ещё и тут: https://www.facebook.com/ailevenchuk/posts/10207409851418535
 
 
разделение на стейкхолдеров-субъектов и абстрактные черные ящики-объекты начиная с какого то уровня сложности системы (особенно с ИИ и соответственно недетерминированым поведением (невычислимо детерминированым) становится довольно условным и не позволяет корректно описывать поведение метасистемы.
ну вот: "Программа для станка с ЧПУ так вообще приводит при её интерпретации к изменениям в реальном мире (впрочем, даже обычная компьютерная программа тоже приводит к изменениям в реальном мире, только очень маленьким -- типа краски из пикселей на бумаге или по-разному пропускающих свет фотонов на экране). "
несколько пикселей на экране стейкхолдера приводят к таким изменениям в физическом мире (посредством решений стейкхолдера) какие и никакому станку не снились, показали стейкхолдеру скажем биржевую котировку и он принял решение продать акции станкостроительного завода. и встает вопрос насколько корректно можно поведение стейкхолдера считать субъектным, его действия довольно детерминированы. а действия скажем ИИ (и любой сложной абстракции) наоборот недостаточно детерминированы с точки зрения стейкхолдера. появляется зазор, люфт в системе. и для сложной системы учет и управление таких люфтов становится ключевым для успешного функционирования, жесткость и строгая абстрактность ухудшают интегральное качество сложных систем.
Я тут не сочиняю по ходу дела, а просто ссылаюсь на теорию -- в том числе абсолютно практичную теорию системной инженерии (хотя и с некоторыми оговорками). Слово "стейкхолдер" вы используете не терминологически, у вас это какие-то люди. У меня (и в теории) это не люди, а роли. Подробней попробуйте почитать в учебнике, это последняя ссылка в посте.
а стейкхолдерами могут быть только люди или и другие объекты тоже, скажем компьютеры, программы ?
Исполнять роль стейкхолдера на сегодня могут те, у кого есть интересы в силу их роли в деятельности. На сегодня это люди, а там посмотрим.

redreptiloid

24 июня 2016, 02:42:15 UTC Комментарий изменен:  24 июня 2016, 02:44:53 UTC

 
это не так, стейкхолдерами могут быть не только люди. свежий пример - The DAO и смарт-контракты в Ethereum. Или мы признаем The DAO стейкхолдером само по себе, как безсубъектную организацию со своей ролью или получаем безсубъектные (не только в юридическом смысле но и фактическом) контракты, что не имеет смысла потому что тогда теряется весь декларируемый смысл The DAO как организации без человеческого управления и признается что The DAO обычная организация.
У меня есть схема, в ней есть стейкхолдер: у стейкхолдера есть интерес к системе и её проекту, а есть выполняющий роль стейкхолдера агент. Если в эту схему не укладывается, то это не стейкхолдер. Если вы хотите назвать какую-то другую сущность стейкхолдером, то нет проблем. Русский язык вполне разбирается с фразами типа "косил Косой с косой косой косой на косе". Так и ваше обзывание DAO стейкхолдером (вместо DAO) тоже пойдёт. 

Дальше нужно разбираться с понятием агента (философского, а не в отношениях агент-принципал. Ибо DAO больше участвует в обсуждениях по линии агент-принципал, чем по линии философских агентов. Но я, когда вслед за Charles Stross замечал, что ИскИны могут прятаться за какими-то DAO, учитывал и философский вариант агента). 

Я часто и много пишу на эти темы. Но к текущему посту обсуждение терминологии системного подхода считаю оффтопом. Попробуйте почитать мой учебник (http://techinvestlab.ru/systems_engineering_thinking), там про стейкхолдеров подробно написано и даны соответствующие метафоры и схемы по ISO 42010. После этого обсуждать. Меньше всего хотелось бы превратиться в эзотерическую секту, где каждое слово наделено каким-то особым значением, не принятым в инженерной культуре, а сочинённым прямо тут, в комментах ЖЖ. Я согласен, что может быть несколько таких слов, но всё-таки словами инженерного языка лучше пользоваться аккуратно, максимально близко к определениям в инженерных стандартах.
Языки запросов - не очень подходящий термин, просто так сложилось. Любой язык запросов это на самом деле язык мэппинга. Например, SQL это куцый набор средств мэппинга из таблицы в таблицу. Если надо что-то иное (например, мэппинг в дерево), то добавляются массивные костыли на других языках.

И даже "просто данные" это мэппинг. Файл с табличкой в CSV это такой мэппинг в CSV с "нуля".

А языки общего назначения (general-purpose languages), это языки одновременно всех мэппингов. Любой добавляется библиотечкой. А уж в какой форме - сильно зависит от качества хост-языка. smile

Разбивать эти возможности на разные языки очень невыгодно. Тем более, что в нативном человеческом восприятии таких разбиений нет, всё в одном языке и контексте: "нарисовать цифру один ... нарисовать цифру пять", "нарисовать цифры от единицы до пяти", "нарисовать цифры, которые в данный момент видны на мониторе", etc.
Терминологию нужно, конечно, рихтовать. Тот же "мэппинг" -- это одно из описаний для T-shirt им.VPRI (и я немного его описал в тексте словами, без употребления термина), а ещё когда я писал, то очень хотел использовать слово "отражение" (поскольку в меня-то вбили когда-то азы гносеологии, и тамошняя концепция отражения действительности через познание в пассивном медиа, а хоть и сознании -- вот она всё время вылезала как отношение картирования, соотнесения. Я люблю переводить mapping как "соотнесение", хотя "соотнесение с" в разы на слух декларативней, чем абсолютно по-русски процедурный "мэпиинг в", а по-английски там ведь тоже не слишком глагольно, тоже "отглагольное существительное" при надлежащем переводе!).

Есть ещё языки трансформаций (XSLT), тоже мэппинг. Всё что угодно сводится к мэппингу: "вход -- мэппинг -- выход", в языке математики это "универсальная функция": "входные значения -- функция -- выходные значения" (и тоже, понятно, мэппинг).

Возвращаясь к Julia и тому же multiple dispatch, там как раз будет "нарисовать" -- и указание разных типов данных. При этом будет работать multiple dispatch, что не есть method overloading (подробности в http://nbviewer.jupyter.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22). В Julia этот пример ровно так и будет говориться. И добавление новых видов рисования не будет приводить к перекомпиляции всего кода с остальными рисованиями. Это важное свойство для языка, поднимает модульность.
Принятое в Julia решение плохо масштабируется даже на их собственную систему модулей. Вопросы specificity и идентификации "какие из вариантов активны в данной точке кода" как чинили несколько лет назад, так и до сих пор чинят. Это общая проблема локальности/глобальности паттернов, независимо от *-time их применения. Но в C++ и Scala, например, в какой-то момент остановились на кривых, бюрократических, но непротиворечивых решениях. Видимо это ждёт и Julia, потому что потери совместимости со старым кодом в их случае ведут к ещё менее желательным последствиям.
Там вроде как открыты к изменениям, версия всего 0.5 в разработке. И главное там сейчас в этой версии -- убрать тормоза в реализации массивов, это ведь у них mission critical для заявленного класса приложений.

У них самые большие траблы по модульности, конечно, в выводимости типов. Там теоретически ещё не всё понятно. Что же в части модульности, то это практически не обсуждается. Там идут два независимых процесса:
-- тупой перенос всего, что видится вокруг (переписывание с максимальным сохранением источника, "перекомпиляция")
-- wrapping (и такое впечатление, что это основной процесс), даже без перекомпиляции alien packages и libraries, но с каким-то вмазыванием интерфейса (например, макросы "для красоты").
-- честная переписка "в стиле Julia", т.е. выполнение заветов авторов языка:

Meaning is hard and there are a lot of "protocols" that we still need to abstract out.

There are separate plot functions in every plotting package
Ideally, there should be a single commong plot function

These kinds of abstract protocols are "narrow waists"

like TCP/IP in networking or byte streams in UNIX

Figuring out the right ones is hard but essential work.

(это в самом конце текста http://nbviewer.jupyter.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22).

Это очень интересный ход, но поскольку весь мир к общему знаменателю не приведёшь, при его массовой реализации будут нарывы на настоящие ограничения принятой в Julia реализации модульности. Пока же с интересом следим, как они будут управлять многочисленными реализациями какого-нибудь вычисления якобиана на самой Julia, как будут выбирать любимую реализацию из присутствующих на одном и том же интерфейсе в части типов и операций, так сказать module dispatch в рамках заявленной интерактивности и рефлексивности.

3744 words