October 10th, 2010

2019

Самокритика (она же -- программа исследований).

Я не так много сейчас пишу у себя в ЖЖ, но довольно много в проектных комьюнити -- прежде всего dot15926 и praxos. Эти проекты существенно продвинулись, и самое время навести на них суровую "критику справа" (ибо левой критики, как всегда, и так предостаточно):

1. Для PraxOS совершенно недостаточно опираться на "просто системный подход". Нужен "система-системный подход", который по факту находится в зачаточном состоянии. Мы же пока еще и с "просто системами" не разобрались, увы -- чем и порождаем обильный поток традиционной критики "социальной инженерии". Именно тут разница между systems of systems evolution (что запросто привязывается к "службе развития") и простой organizational development/engineering (что сводится к простой функции "организовывания").

2. Опять же, в PraxOS "организовывание в малом" (внутри фирмы, внутри единоначалия -- если оно может тут в принципе существовать) и "организовывание в большом" (расширенное предприятие, обеспечение модульности) пока не разведены явно, средства этого не описаны.

3. Во всех занятиях инженерным проектированием я не уделяю должного внимания уровню абстракции в методе и созданию соответствующего языка. В частности, мне нужно было бы сосредоточиться на проектах типа DARPA iFAB+META+FANG (ссылки в http://ailev.livejournal.com/859527.html и там еще в комментах), где ускорение времени разработки обещано в пять раз. Оно понятно, что мы занимаемся enabling technologies для этого, но собственно сами технологии проектирования чего бы то ни было у нас пропущены напрочь (наши потуги охватить DSM -- это как-то несерьезно по сравнению с обсуждаемыми DARPA подходами). Отсутствие клиентов на такие разработки объясняет, но не оправдывает наше невнимание.

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

Это я пересказал кратенько http://community.livejournal.com/praxos/11299.html

Действительно, организационные методы/технологии существенно зависят от того, как устроено предприятие (в том числе расширенное) в плане его производственных методов работы (например, как устроен инжиниринг крупных капитальных объектов в рамках расширенного предприятия), методы инжиниринга зависят от доступных айтишных средств (CAD/CAM/CAE/PLM/ERP/EAM/MDM/etc), доступные айтишные средства зависят от применяемых в них платформ (реляционные, объектные или семантические хранилища, SOA, языки и т.д.). Мы, обнаружив тотальную неподдержку современных методов организации наличным корпоративным софтом, вдруг провалились не столько в создание этого софта, сколько в создание платформ для этого софта (ибо dot15926 -- это именно платформа, на ней корпоративный софт еще придется писать!). Это все равно как встретить неудобства в написании Hello World на Java вдруг начать разрабатывать даже не новый язык и его компилятор с виртуальной машиной, и даже не ассемблер процессора, но сразу перейти к разработке микропрограмм -- и потом удивляться, что клиенты никак не понимают, что для Hello World обязательно нужны микропрограммы, всенепременно самые передовые в мире. Этот огромный разрыв крайне напрягает. Как заметил vvagr сегодня, на конференции по софту CAD/PLM (http://isicad.ru/ru/2010/program/eng/) никто этот ISO 15926 даже не помянул. Конечно, абсолютно аналогичные системы предыдущего объектного поколения в нынешнем engineering software интересны только с точки зрения программистов этих систем, но никак неинтересны пользователям, поэтому эволюция инженерного софта обсуждается не в терминах его обеспечивающих и инструментальных систем, а в терминах его функциональности как обеспечивающей системы для пользователей. Мы оказались крайне далеко по supply chain, и меня это несказанно тревожит.

Более того, руки чешутся и тут пройтись на еще более низкий уровень (потому как на каждом технологическом уровне по supply chain этих технологий есть свои грабли). Например, пообсуждать грамматики как объекты первого класса (ибо у нас ведь тучи языков!), пообсуждать RESTful архитектуру (ибо на той же isicad-2010 четко говорилось, что инженерный софт будет развиваться в том же направлении, что и WWW -- а это ведь сейчас обеспечивается в значительной мере прогрессом в RESTful реализациях), пообсуждать архитектуры language workbenches, приложимость идей FONC (телескопы/микроскопы, те же грамматики и Ometa и т.д.), пообсуждать варианты оптимизации онтологий с их ограничениями для графа по сравнению с "тупыми триплами", где перебор может быть только полный -- куда ни ткнись, везеде важно, везде интересно, и каждый такой шаг "вниз" еще больше отдаляет от нужд "служб развития".

Эта размазанность вниз по technology/platform supply chain и напрягает сейчас больше всего.

5. Даже наш выбор ISO 15926 может быть прокритикован как недостаточно соответствующий заявленным на более высоких уровнях technology/platform supply chain целям, ибо:

5.1. Текущий заход в использовании онтологий в инженерном и корпоративном софте -- это всё про данные ("базы данных" еще одного типа), и непонятно как выйти на программирование. Мы понимаем, что "простые приложения -- это сложный код с простыми структурами данных, а сложные корпоративные приложения -- это простой код со сложными структурами данных", но сложный или простой код -- он должен быть! Если "объектные базы данных" хорошо совмещались с объектными языками и объектными платформами программирования, то с какими языками и платформами программирования должны совмещаться семантические базы данных? В комьюнити ISO 15926 никак не задаются этим вопросом, и меня это настораживает. Нужен 15926L, язык. Как может выглядеть такой язык, я себе не представляю -- но делать нужно именно его. Любая реализация ISO 15926 должна предоставлять интерфейс на этом языке, и это отнюдь не SPARQL, как предполагается Частью 9 стандарта.

5.2. ISO 15926 с его федерациями непонятно как обеспечивает модульность онтологии ("программирование-в-большом"). Несмотря на то, что RDL в федерации умеют обменяться сообщениями (хоть и это и "не объектный" и "не язык"), непонятно как обеспечивать целостность и непротиворечивость федерации, распределенную разработку и т.д. "Нюхом чую", что тут теоретическая засада.

5.3. Онтология (а хоть и 4D) предлагает "вечные классы". Это не соответствует принципам конструктивизма, в котором онтологии конструируются (то есть эволюционируют, а не "открываются" готовенькими и далее неизменными). Мне лично даже в языках программирования более симпатичны динамические языки. ISO 15926 никак не соответствует этим ожиданиям. Скажу страшную мысль: может, правильный подход -- это основанный на акторах и прототипах, а не на классах и индивидах. Онтологи наверняка этим занимались, но мне об этом неизвестно -- и это меня страшно напрягает. Эта тема протаскивается как проблема версионирования онтологии/моделей, но мне она кажется более фундаментальной -- проблематизируется собственно нынешняя архитектура "семантической работы".

5.4. Онтология ISO 15926 не вполне деятельностна и ориентирована на выражение метода (понятно, что исторически она была ориентирована на выражение только продукта), и нужно еще разобраться, как ее развернуть в этом деятельностном направлении. То же самое можно сказать о поддержке этой онтологией системного подхода (не говоря уже о системо-системном подходе). Понятно, что это всё выразимо текущими средствами ISO 15926, но мне кажется, что системный подход и деятельностный подход должны быть введены тщательно на уровне upper ontology (т.е. Части 2).
2019

Музицирование-в-малом и музицирование-в-большом

Youtube содержит огромное количество making a beat материалов. Вот парочка примеров, которая очень наглядно показывает не слишком хитрый процесс, снижающий ценз исполнительского мастерства музыканта с консерваторского до старших классов музыкальной школы, но подымающая планку для искусства аранжировщика:





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

То бишь музыку теперь делают не столько "инженеры по специальности", сколько сплошь "системные инженеры", удерживающие в голове ее архитектуру.

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

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

Ничего, это сейчас отрефлектировано и является направлением для размышлений. Так, в FONC сегодня обсуждается, как безграмотно устроено сегодняшнее распределенное программирование для WWW -- все эти HTML+JavaScript.

Disclaimer: не комментируйте, плиз, что все это было понятно в 17 веке, и великие симфонисты творили именно так. Мой пойнт в том, что сейчас любой ребенок имеет шанс стать "симфонистом", а через несколько лет станет понятно, как научить его быть "великим симфонистом" -- и из 10 учеников гарантированно за пару лет получать "великих симфонистов". А еще через несколько лет формализация метода приведет к тому, что любой компьютер будет "великим симфонистом". Этот тезис верен и для системной инженерии, и для многих других дисциплин, сводящихся к "программированию/моделированию/онтологизированию-в-большом". Да, "по наитию" все это было еще в средних веках и доступно было немногим гениям. Я тут о том, что должно быть доступно по учебнику после школьной или вузовской скамьи. Ну, а чуть позже доступно и компьютеру. Планка же "по наитию" будет проходить в этом случае совсем на другой высоте -- или задача просто будет выбывать из разряда "интеллектуальных" ввиду ненужности выполнения ее на уровне более высокой планки.