Обсуждение

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

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

а стейкхолдерами могут быть только люди или и другие объекты тоже, скажем компьютеры, программы ?

Исполнять роль стейкхолдера на сегодня могут те, у кого есть интересы в силу их роли в деятельности. На сегодня это люди, а там посмотрим.

Языки запросов - не очень подходящий термин, просто так сложилось. Любой язык запросов это на самом деле язык мэппинга. Например, SQL это куцый набор средств мэппинга из таблицы в таблицу. Если надо что-то иное (например, мэппинг в дерево), то добавляются массивные костыли на других языках. И даже "просто данные" это мэппинг. Файл с табличкой в CSV это такой мэппинг в CSV с "нуля". А языки общего назначения (general-purpose languages), это языки одновременно всех мэппингов. Любой добавляется библиотечкой. А уж в какой форме - сильно зависит от качества хост-языка. :) Разбивать эти возможности на разные языки очень невыгодно. Тем более, что в нативном человеческом восприятии таких разбиений нет, всё в одном языке и контексте: "нарисовать цифру один ... нарисовать цифру пять", "нарисовать цифры от единицы до пяти", "нарисовать цифры, которые в данный момент видны на мониторе", etc.

Терминологию нужно, конечно, рихтовать. Тот же "мэппинг" -- это одно из описаний для T-shirt им.VPRI (и я немного его описал в тексте словами, без употребления термина), а ещё когда я писал, то очень хотел использовать слово "отражение" (поскольку в меня-то вбили когда-то азы гносеологии, и тамошняя концепция отражения действительности через познание в пассивном медиа, а хоть и сознании -- вот она всё время вылезала как отношение картирования, соотнесения. Я люблю переводить mapping как "соотнесение", хотя "соотнесение с" в разы на слух декларативней, чем абсолютно по-русски процедурный "мэпиинг в", а по-английски там ведь тоже не слишком глагольно, тоже "отглагольное существительное" при надлежащем переводе!). Есть ещё языки трансформаций (XSLT), тоже мэппинг. Всё что угодно сводится к мэппингу: "вход -- мэппинг -- выход", в языке математики это "универсальная функция": "входные значения -- функция -- выходные значения" (и тоже, понятно, мэппинг). Возвращаясь к Julia и тому же multiple dispatch, там как раз будет "нарисовать" -- и указание разных типов данных. При этом будет работать multiple dispatch, что не есть method overloading (подробности в http://nbviewer.jupyter.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22). В Julia этот пример ровно так и будет говориться. И добавление новых видов рисования не будет приводить к перекомпиляции всего кода с остальными рисованиями. Это важное свойство для языка, поднимает модульность.

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

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

Принятое в 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 в рамках заявленной интерактивности и рефлексивности.