Студии разные нужны, студии разные важны
Студия (от итальянского studio) -- это помещение для занятия каким-то искусством, оборудованное соответствующим образом (аудиостудия аппаратурой звукозаписи, художественная студия -- мольбертами и палитрами). Ещё студией называют комнату, в которой жилое помещение и кухня объединены в одну комнату. Давайте обсудим виртуальные студии, которые нам нужны, чтобы делать различные прикладные информационные системы -- они предполагают как специальные viewpoints для своих "искусств", так и объединение "кухни" по разработке с "жильём" -- использованием уже разработанного, т.е. exploratory programming/modeling/designing/querying.
Сегодня всевозможные Studio -- это некоторое обобщение IDE (interactive development environmet) на описания (veiw), не сводящиеся к программному коду. Так, Visual Studio Code https://code.visualstudio.com кроме языков программирования позволяет редактировать и "запускать в дело" (отлаживать) всевозможные текстовые данные (начиная с форматов CSS и XML), а Azure ML Studio https://studio.azureml.net даёт возможность интерактивной работы над числовыми данными. Если данные главным образом числовые и не стоит прямой задачи разработки приложений, а только анализа данных, то эти Studio не менее часто называют Lab (laboratory), например MoBILAB https://sccn.ucsd.edu/wiki/MoBILAB для обработки данных mobile brain/body imaging (MoBI).
Конечно, начав с анализа, неизбежно оказываешься в синтезе программ моделирования: анализ данных это разработка (development) разнообразных моделей -- любая Lab растёт в сторону Studio. И наоборот, когда ты разрабатываешь какую-то модель (алгоритмическую или любою иную), то тебе отчаянно нужны средства exploratory modeling/programming/querying, прежде всего REPL.
А ещё как для данных, так и для создающихся моделей нужно управление конфигурацией.
Вы уже догадались: на следующем шаге вам мало будет одного viewpoint и захочется их иметь десяток, мало будет одного окна и захочется иметь их множество, к этим viewpoints захочется добавить intellisence, потом потребуется привлечь к работе сотрудников на другом конце планеты -- разработчики Studio и Labs сталкиваются с примерно одинаковыми concerns, и поэтому их продукты проходят более-менее похожие пути развития.
Вот, например, Azure ML Studio. Начиналась она с поддержки viewpoint визуальных dataflow сценариев работы со скриптами (главным образом в R и Python). Но там не было REPL, плюс визуальные языки оказываются хорошо демонстрируемыми и продаваемыми, но не такими уж хорошими в работе. Классический тут пример -- дегустация с одного глотка напитков, при которых побеждают сладкие напитки, но если пить нужно бутылку -- побеждают менее сладкие, об этом красиво рассказывал Малкольм Гладуэлл в книге "Озарение", http://www.marketing.spb.ru/lib-around/socio/momentary_opinion.htm. Так и тут: графические языки хороши на демонстрациях и в коротеньких работах, но при серьёзной долгой работе уже не обойтись без текстовых представлений быстро распухающих сценариев с быстро растущим числом параметров в их шагах. Нуже полноценный язык программирования, плюс REPL. И множество view, конечно. Чтобы получить это всё, в состав Azure ML Studio включили многоязыковую студию с multi-view и REPL, а именно -- включили Jupyter Notebook (https://blogs.technet.microsoft.com/machinelearning/2015/07/24/introducing-jupyter-notebooks-in-azure-ml-studio/) с классическим обоснованием exploratory programming/modeling: Jupyter Notebooks provide a delightful interface for quickly running code, visualizing data, exploring insights, and trying out ideas. Так сказать delightful interface от Jupyter внутри delightful interface для того же самого от Azure ML Studio. Бутылочку несладкого текста, которую можно пить внутри бутылочки сладкого визуального первого глоточка: visual dataflow выигрывает на демонстрациях и суперпростых задачах, но потом аппетит вырастет, и вы всё равно перейдёте к традиционным вычислительным экспериментам с текстами code snippets и графиками результатов в Notebook.
Посмотрите roadmap в конце поста про включение Jupyter Notebook в Azure ML Studio по приведённой ссылке: скоро ожидается больше intellisence, PowerShell integration, Git integration, средства публикации разработанных в Notebook моделей. А контейнеризация, масштабируемость по подтягиванию ресурсов из облака у них уже есть "из коробки", это ж Azure!
Все заявленные в roadmap свойства, как и многие другие, неспецифичны именно для Azure ML Studio + Jupyter Notebook. Любая IDE работы с каким-то одним языком дрейфует в сторону относительно похоже выглядящих многооконных и многоязыковых Studio и Lab, всем им хочется иметь одни и те же фичи, независимо от предмета разработки. Это не случайно, эту похожесть в фичах "идеальных" Studio и Lab, получающихся в ходе многолетних разработок и выполнения длинных список фич в их таких разных, но таких одинаковых roadmaps, можно предсказать заранее, без понимания специфики приложений этих систем.
Для этого можно вспомнить о системной информатике и обсуждении возможных архитектур программных средств для построения сложных систем: новинки архитектуры systems framework http://ailev.livejournal.com/1277009.html, доступность в нём "нейро" и машинного интеллекта http://ailev.livejournal.com/1275143.html, http://ailev.livejournal.com/1273208.html, и это всё на базе формулирования практики "системная информатика" -- http://ailev.livejournal.com/1274210.html, http://ailev.livejournal.com/1272169.html.
Да, системная информатика -- это более-менее давно известная (хотя и менее популярная, чем computer science и software engineering) дисциплина "информационные системы" (IS, только тут в более общем варианте, чем MIS, management information systems), только "с системным подходом в голове", как и системная инженерия -- это любая инженерия с системным подходом в голове.
Тем самым о многих и многих потребностях информационной работы по моделированию/изучению/проектированию какой-то целевой системы (даные о которых обрабатывают в ML Studio, создавая там программы машинного обучения), или нейросистемы (данные о которых обрабатывают в Lab, создавая там программы обработки сигналов) или учебной системы (создавая там задания и проверочные тесты для этих заданий) можно по большому счёту сказать заранее. И хорошо бы сделать код, поддерживающий эти потребности, одним и тем же для всех этих случаев. Это как операционная система на новом витке: ей пользуются (в её среде, ибо это framework) работают все приложения, будь это приложения для разработки machine learning алгоритмов, приложений обработки нейроданных или работы с учебными мирами в тренажёрах.
Нельзя сказать заранее только про конкретные способы обработки, конкретные методы описания целевой системы (viewpoints), используемые в них представления/языки данных и программ обработки этих данных. Операционная система тем и хороша, что в ней возможны самые разные приложения. А если позволять приложениям работать на "голом железе", то через некоторое время и много версий спустя выяснится, что в этих приложениях появляется как "криво написанный и неэффективный интепретатор Common Lisp", так и "криво написанная и неэффективная операционная система". А я добавлю: точно так же появляется и криво написанный и неэффективный systems framework, поддерживающий работу с мультимодельным описанием системы и контролем конфигурации. Инструментарий для мегамоделирования (разработки и интеграции множества методов описания/viewpoints и далее редактирования множества частных описаний/views). Это я уже подробно прописывал, смотрите материалы по ссылкам в абзаце чуть выше.
Так что я бы приветствовал разработку специального инструментария, systems framework (http://ailev.livejournal.com/1277009.html) который "из коробки" обеспечивает необходимые свойства разрабатываемых на его основе прикладных студий.
А теперь, насмотревшись на сегодняшние разной степени осознанности подходы к организации systems framework, попробуем в полной осознанности и с выраженным чувством мечты наступить на сороколетней давности грабли "эффекта второй системы" (http://webkomora.com.ua/ru/articles/web/management/man-month/5.html, когда после первой удачной версии с минимумом фич и элегантной архитектурой во вторую версию втыкают одновременно все возможные фичи и архитектура безнадёжно деградирует, равно как требуемые для разработки ресурсы).
"Пустой" systems framework не умеет ничего, как и любой framework. Он будет мигать окошками, не более. Напомню, что framework -- это как кассетница, куда нужно вставлять какие-то plug-ins (обеспечивающие различные viewpoints) и add-ons (обеспечивающие рост базовой функциональности). Но в любом случае, для начала работы потребуется программировать эти плагины и аддоны, для чего нужно будет создать на базе пока ещё пустого system framework
-- мультиязыковую IDE: для разработки исполняемого программного кода плагингов и аддонов и редактирования их структурированных данных. Та же Visual Studio Code или Eclipse Che тут хорошие примеры.
Для нормальной работы различных IDE требуется довольно много интеллекта, а хоть и для intellisence. Если мы хотим пойти по пути расширенных подсказок (http://ailev.livejournal.com/1269236.html -- автоматизации добавления мультур к культур), то нам потребуется полноценная система создания интеллектуальных приложений на базе машинного обучения, т.е.
-- интеллект-студия: для разработки интеллектуальных систем машинного обучения, которая должна закрывать уровни интеллект-стека (http://ailev.livejournal.com/1210678.html -- 1. Прикладной уровень, 2. Когнитивная архитектура, 3. Обучающиеся алгоритмы, 4. Вычислительные библиотеки, 5. Вычислительные языки программирования, 6. Аппаратное ускорение вычислений). Все эти уровни требуют различных viewpoints на создаваемую интеллект-систему, так что смело можно считать, что требуется поддержать несколько подстудий (уровней 2-5, ибо уровень 1 это уже уровень целевой задачи, а на уровнях 5-6 мало кто работает из прикладных разработчиков, там всё давно "коммодитизировано"):
2) собственно intellect studio: разработка когнитивной архитектуры. Тех же нейронных сетей обычно требуется множество разных, плюс нужны средства построения из них ансамблей и самых разных дополнительных обработок, в том числе с алгоритмами других школ машинного обучения, а также зачастую довольно хитрыми структурами обучения с подкреплением, использования внешней памяти и т.д.. Сегодня этот уровень ничем не поддерживается, кроме обычных IDE языка программирования и Notebooks для объединения в рамках одного multiview сниппетов кода с вызовами алгоритмов машинного обучения и графиков с результатами их отработки. Разобраться с этим уровнем и поддержать его специализированными viewpoints для описания когнитивных архитектур (вроде как язык описания структуры мозга из отделов мозга и связей между ними) -- это отдельная задача. Это сейчас направление главного удара. Уже упоминавшаяся Microsoft Azure ML Studio явно целится в эту точку со своим dataflow редактором сценария экспериментов над данными, но там явно ещё есть куда улучшаться -- для обкатки интеллекта тоже нужно использовать exploratory modelling/programming, и нужно иметь языковую консоль и REPL (а не только красивую визуализацию dataflow). Буквально три года назад архитектуры тех же нейронных сетей, как и задачи вероятностного программирования поддерживались непосредственно языком программирования и IDE с Notebook, а не специальными DSL (viewpoints) описания dataflow архитектур нейронной сети и вероятностными языками с их компиляторами -- а сегодня специализированные редакторы архитектур нейронной сети есть почти в каждом deep learning фреймворке, да и вероятностных языков программирования уже несколько. Но по большей части на этом уровне предлагаются не столько studio, сколько просто наборы отдельных API (ср. IBM Watson с http://www.ibm.com/cloud-computing/bluemix/watson/ и Cortana Intelligence Suite https://www.microsoft.com/en-us/cloud-platform/cortana-intelligence-suite, да и все эти deep learning frameworks предоставляют главным образом API, но не среду разработки сложных когнитивных архитектур). Нужно заметить, в intellect-studio вполне возможно задействование не только алгоримов машинного обучения, но и каких-то других алгоримов "ручной разработки" -- например, классических экспертных систем. Но предполагается, что в intellect-studio разрабатываются именно алгоритмы, а не прикладные системы. Прикладные системы и их интерфейсы идут уровнем выше. Например, умный алгоритм для интеллектуального чата или intellisence разрабатывается в intellect-studio, но информационная система колл-центра или учебного тренажёра, где будет задействованы эти intellisence или чат разрабатывается обычным образом, как прикладная система (то есть в моём варианте -- как приложение на базе systems framework).
3) neural network studio и probabilistic programming studio: разработка алгоритмов машинного обучения -- тут прежде всего dataflow диаграммы нейронных сетей (чаще всего приводят в пример TensorFlow), а также коды алгоритмов на вероятностных языках программирования. Такие архитектуры обычно нужно уточнять для каждого класса целевых задач, библиотеки тут редки (хотя и тут бывают. Например, AlexNet пример такой "именованной" структуры сети, которая может использоваться as is, в том числе и в обученном уже варианте, а не разрабатываться и тренироваться на этом уровне). Все текущие "редакторы-визуализаторы нейронных сетей" в сегодняшних фреймворках deep learning поддерживают именно этот уровень -- большинство картинок "архитектуры нейронной сети" и "полностью дифференцируемых архитектур" ровно отсюда, и эта работа выполняется в подобных редакторах.
4) numeric studio: разработка вычислительных библиотек (все эти Torch, Theano и т.д. начинались с библиотеки эффективно реализованных матричных операций, а алгоритмы типа backpropagation просто продолжили эти библиотеки. Опять же, вычислительные алгоритмы нужно разрабатывать и для вероятностных языков программирования (http://ailev.livejournal.com/1211950.html -- недаром говорят, что для байесовского обучения вероятностные языки программирования могут стать тем же, чем стало backpropagation для нейронных сетей) и много чего другого "численно-библиотечного", а хоть и разработка средств Autodiff для работы на более высоком уровне fully differentiable architecture. Тут уже не столько разработка "обучения", сколько разработка вычислительных строительных блоков для него. Именно на этом уровне имеет значение "проблема двух языков" (когда на скриптовом языке прототипируют алгоритм, а потом на Си реализуют быструю версию алгоритма), т.е. наиболее эффективно использовать Julia (http://julialang.org/) именно на этом уровне. Сейчас в качестве numeric studio повсеместно используют Notebook (обычно Jupyter notebook), за редкими исключениями. Вот и Azure ML Studio как intellect-studio добавили возможность экспортировать/импортировать данные через CSV для последующей их численной обработки на более низком уровне детальности, но с использованием REPL и полноценных языков программирования (а не визуального языка "когнитивного dataflow").
Когнитивные архитектуры, разработанные при помощи intellect studio и помогающих ей neural netwrok studio, probabilistic programming studio, numeric studio, вполне могут быть использованы в самых разных других прикладных системах, например при создании:
-- Neuro studio, которая помогает создать систему обработки данных о состоянии человека. Аппаратура и софт из http://www.gtec.at/Products/Hardware-and-Accessories/g.MOBIlab-Specs-Features и https://sccn.ucsd.edu/wiki/MoBILAB как раз позволяют ровно это. Но в нашем случае ситуация будет получше: мы будем использовать для создания neuro studio ровно тот же systems framework, в котором в плагинах уже доступны и numeric studio (для алгоритмов обработки сигналов) и даже полная intellect-studio. Тем самым не удивлюсь, если выяснится, что Neuro studio окажется лишь какой-то небольшой прикладной модификацией-настройкой intellect studio для работы с биоданными. Я склонен включать neuro studio в базовый комплект плагинов к systems framework, ибо в конечном итоге с информационными системами в большинстве случаев работают исполнители ролей стейкхолдеров из плоти и крови, и интересно было бы учитывать не только приходящую с клавиатуры информацию, но и разную другую (направление взгляда, cognitive load, утомляемость и отвлечения т.д. -- это могло бы помочь дать лучше UX для работы с итоговой прикладной системой).
-- trainer studio: разработка учебных тренажёров, студия для методистов учебных систем, описанных в тексте "мимо школы" (http://ailev.livejournal.com/1280262.html). Тренажёр изначально должен поддерживать несколько разных viewpoints -- позволять редактировать задания (вопросы и ответы, например, условие задачи и тестовые примеры при изучении алгоритмики), но также он должен уметь адаптивно строить образовательный маршрут, учитывая как уже пройденный и планирующийся к прохождению материал, так и успешность решения задач, и кроме того ещё и состояние обучающегося. Для это возможно задействование интеллект-алгоритмов (но у нас для этого уже есть intellect-studio), а также алгоритмов обработки биосигналов (но у нас для этого уже есть neuro studio). Тем самым каждый методист сможет при помощи trainer studio создать и отладить тренажёр для какого-то предмета, плюс дополнительно можно будет разрабатывать варианты комбинирования заданий из разных тренажёров с использованием как адаптационного обучения на базе алгоритмов машинного обучения/машинного интеллекта, так и состояния учащихся. Вообще, весь предлагаемый студий как плагинов и аддонов к systems framewrok -- это "скрипка Энгельбарта" (http://ailev.livejournal.com/1158826.html), на которой очень мало кто захочет учиться играть, ведь отнюдь не все горят желанием тратить своё время на овладение теорией музыки и искусством игры на инструментах, чтобы получать потом удовольствие от музицирования. К разработке сложных информационных систем это всё относится в такой же полной мере. Такая разработка требует беглости владения инструментом (в данном случае systems framework и его "студиями"), и нужно попотеть, чтобы добиться беглости (fluency, http://ailev.livejournal.com/1278095.html) в игре на таком сложном (не менее сложном, чем скрипка: учиться на нём играть может потребоваться тоже несколько лет) инструменте. Нужно играть гаммы и этюды, для этого нужно иметь тренажёр (см. темы про тренажёр в http://ailev.livejournal.com/1280262.html). Эти тренажёры тоже было бы неплохо поставлять "из коробки". Так что замкнутый круг: для разработки тренажёров нужно создать студию, разработать тренажёры и включить тренажёр в комплект поставки. Так что результатом заодно будет и набор тренажёров для конкретных учебных предметов, поддерживающих дисциплины system thinking, software engineering и information systems, numerical computing, deep learning и т.д. -- все те, технологии которых будут поддержаны обсуждающимися "студиями".
-- systems engineering studio: мегамоделер для MBSE (можно думать как о поддержке viewpoints для SysMoLan -- http://ailev.livejournal.com/1169972.html, ArchiMate 3.0, Modelica и прочих инженерных viewpoints/языков -- включая, возможно, разные эксперименты типа Mojulica http://ailev.livejournal.com/1168256.html, пункт 3 в http://ailev.livejournal.com/1218155.html, пункт 3 в http://ailev.livejournal.com/1271980.html). Я уж столько об этом писал, что не буду много повторяться. Ну, а другие желающие могут добавить OPM, SysML, AADL и всякое разное остальное.
-- conceptual studio: разработка концептуальной модели традиционно выходит за рамки MBSE, подробнее об этом я писал в "Коллективное моделеориентированное концептуальное проектирование и нейро-технологии" -- http://ailev.livejournal.com/1229950.html, и можно перечитать этот длинный текст по ссылке, переводя там написанное в приглашение к реализации на описанном в настоящем тексте наборе инструментальных средств на базе systems framework, включая интеллект-студию и нейро-студию.
Про PLM/issue tracker и организацию бэкенда к этому набору студий я писать не буду, но всё равно в связи с последними "студиями" есть интересный поворот: они уже не все "однопользовательские", не все их view предполагаются к работе в режиме АРМ (автоматизированное рабочее место). Некоторые требуют более-менее синхронной работы команды:
-- нейростудия подразумевает экспериментатора и человека, чьё состояние мониторится и, возможно, изменяется. Иначе не отладиться!
-- студия тренажёра требует работы методиста предмета и/или методиста по всем предметам (если образовательная траектория имеется ввиду общая) и ученика. Иначе тоже не отладиться.
-- студия системной инженерии сразу подразумевает командную работу.
-- студия концептуального моделирования тоже подразумевает работу команды.
Так что нужно будет поддержать и многопользовательский режим работы, в том числе и поддержку командного режима работы. Это поразумевает не только разработку "индивидуальных" компонент в составе итоговой системы, но и "групповых" -- примерно по тем линиям, что обсуждались на примере коллективного моделеориентированного концептуального проектирования и нейро-технологий http://ailev.livejournal.com/1229950.html. Но там (это давний текст ноября 2015 года) приведены отнюдь не все необходимые применения, возможные с нынешним планируемым набором студий. И даже мартовский 2016 текст про примеры для проекта создания виртуального фасилитатора сотрудничества http://ailev.livejournal.com/1256648.html не позволяет представить всех возможных функций. Так, можно думать об не только о поддержке группы в её работе по концептуальному проектированию, но и обучению её такому проектированию (включая обучение позиции фасилитатора) -- в том числе и обучению на специальном групповом тренажёре. А учитывая, что можно также разрабатывать тренажёры системного мышления и тренажёры для студии системной инженерии, то можно говорить о поддержке подобной системой инженерного образования.
Ну, и дальше можно думать ещё и многопользовательском варианте публичного образовательного сервиса, как это описано в тексте "мимо школы" -- http://ailev.livejournal.com/1280262.html, создание не только "методического портала", где разные методисты создают самые разные тренажёры для самых разных курсов, но и "чебного портала", где этими курсами могут воспользоваться ученики. Это добавит множество различные viewpoints и поддержку view для администраторов портала, идентификацию и аутентификацию для учеников, добавка к systems framework систем идентификации и аутентификации и т.д.
В какой мере собирать такую систему из готовых платформ, а в какой мере разрабатывать "с нуля" под обозначенные в настоящем посте потребности, какой язык программирования мог бы там быть базовым (если вообще в таких больших системах можно говорить о базовых языках), какой мог бы быть roadmap для такой системы, чтобы всё-таки избежать эффекта второй системы, как организационно могла бы быть устроена разработка такой системы (там ведь не одна команда разработчиков могла бы быть), где можно было бы поискать ресурсы для разработки такой системы, и даже как могла бы называться конкретная система такого типа, если бы начали её разрабатывать -- это я вынесу за пределы настоящего поста. И так уже многабукофф.
Мне кажется, что даже если ничего не делать, существующий инструментарий системного программирования будет приближаться и приближаться год за годом к описанному тут виду. Вопрос, не поставить ли этому неспешливому эволюционному процессу своё плечо. Ибо, как говаривал Алан Кей, лучший способ предсказать будущее -- это создать его.
Сегодня всевозможные Studio -- это некоторое обобщение IDE (interactive development environmet) на описания (veiw), не сводящиеся к программному коду. Так, Visual Studio Code https://code.visualstudio.com кроме языков программирования позволяет редактировать и "запускать в дело" (отлаживать) всевозможные текстовые данные (начиная с форматов CSS и XML), а Azure ML Studio https://studio.azureml.net даёт возможность интерактивной работы над числовыми данными. Если данные главным образом числовые и не стоит прямой задачи разработки приложений, а только анализа данных, то эти Studio не менее часто называют Lab (laboratory), например MoBILAB https://sccn.ucsd.edu/wiki/MoBILAB для обработки данных mobile brain/body imaging (MoBI).
Конечно, начав с анализа, неизбежно оказываешься в синтезе программ моделирования: анализ данных это разработка (development) разнообразных моделей -- любая Lab растёт в сторону Studio. И наоборот, когда ты разрабатываешь какую-то модель (алгоритмическую или любою иную), то тебе отчаянно нужны средства exploratory modeling/programming/querying, прежде всего REPL.
А ещё как для данных, так и для создающихся моделей нужно управление конфигурацией.
Вы уже догадались: на следующем шаге вам мало будет одного viewpoint и захочется их иметь десяток, мало будет одного окна и захочется иметь их множество, к этим viewpoints захочется добавить intellisence, потом потребуется привлечь к работе сотрудников на другом конце планеты -- разработчики Studio и Labs сталкиваются с примерно одинаковыми concerns, и поэтому их продукты проходят более-менее похожие пути развития.
Вот, например, Azure ML Studio. Начиналась она с поддержки viewpoint визуальных dataflow сценариев работы со скриптами (главным образом в R и Python). Но там не было REPL, плюс визуальные языки оказываются хорошо демонстрируемыми и продаваемыми, но не такими уж хорошими в работе. Классический тут пример -- дегустация с одного глотка напитков, при которых побеждают сладкие напитки, но если пить нужно бутылку -- побеждают менее сладкие, об этом красиво рассказывал Малкольм Гладуэлл в книге "Озарение", http://www.marketing.spb.ru/lib-around/socio/momentary_opinion.htm. Так и тут: графические языки хороши на демонстрациях и в коротеньких работах, но при серьёзной долгой работе уже не обойтись без текстовых представлений быстро распухающих сценариев с быстро растущим числом параметров в их шагах. Нуже полноценный язык программирования, плюс REPL. И множество view, конечно. Чтобы получить это всё, в состав Azure ML Studio включили многоязыковую студию с multi-view и REPL, а именно -- включили Jupyter Notebook (https://blogs.technet.microsoft.com/machinelearning/2015/07/24/introducing-jupyter-notebooks-in-azure-ml-studio/) с классическим обоснованием exploratory programming/modeling: Jupyter Notebooks provide a delightful interface for quickly running code, visualizing data, exploring insights, and trying out ideas. Так сказать delightful interface от Jupyter внутри delightful interface для того же самого от Azure ML Studio. Бутылочку несладкого текста, которую можно пить внутри бутылочки сладкого визуального первого глоточка: visual dataflow выигрывает на демонстрациях и суперпростых задачах, но потом аппетит вырастет, и вы всё равно перейдёте к традиционным вычислительным экспериментам с текстами code snippets и графиками результатов в Notebook.
Посмотрите roadmap в конце поста про включение Jupyter Notebook в Azure ML Studio по приведённой ссылке: скоро ожидается больше intellisence, PowerShell integration, Git integration, средства публикации разработанных в Notebook моделей. А контейнеризация, масштабируемость по подтягиванию ресурсов из облака у них уже есть "из коробки", это ж Azure!
Все заявленные в roadmap свойства, как и многие другие, неспецифичны именно для Azure ML Studio + Jupyter Notebook. Любая IDE работы с каким-то одним языком дрейфует в сторону относительно похоже выглядящих многооконных и многоязыковых Studio и Lab, всем им хочется иметь одни и те же фичи, независимо от предмета разработки. Это не случайно, эту похожесть в фичах "идеальных" Studio и Lab, получающихся в ходе многолетних разработок и выполнения длинных список фич в их таких разных, но таких одинаковых roadmaps, можно предсказать заранее, без понимания специфики приложений этих систем.
Для этого можно вспомнить о системной информатике и обсуждении возможных архитектур программных средств для построения сложных систем: новинки архитектуры systems framework http://ailev.livejournal.com/1277009.html, доступность в нём "нейро" и машинного интеллекта http://ailev.livejournal.com/1275143.html, http://ailev.livejournal.com/1273208.html, и это всё на базе формулирования практики "системная информатика" -- http://ailev.livejournal.com/1274210.html, http://ailev.livejournal.com/1272169.html.
Да, системная информатика -- это более-менее давно известная (хотя и менее популярная, чем computer science и software engineering) дисциплина "информационные системы" (IS, только тут в более общем варианте, чем MIS, management information systems), только "с системным подходом в голове", как и системная инженерия -- это любая инженерия с системным подходом в голове.
Тем самым о многих и многих потребностях информационной работы по моделированию/изучению/проектированию какой-то целевой системы (даные о которых обрабатывают в ML Studio, создавая там программы машинного обучения), или нейросистемы (данные о которых обрабатывают в Lab, создавая там программы обработки сигналов) или учебной системы (создавая там задания и проверочные тесты для этих заданий) можно по большому счёту сказать заранее. И хорошо бы сделать код, поддерживающий эти потребности, одним и тем же для всех этих случаев. Это как операционная система на новом витке: ей пользуются (в её среде, ибо это framework) работают все приложения, будь это приложения для разработки machine learning алгоритмов, приложений обработки нейроданных или работы с учебными мирами в тренажёрах.
Нельзя сказать заранее только про конкретные способы обработки, конкретные методы описания целевой системы (viewpoints), используемые в них представления/языки данных и программ обработки этих данных. Операционная система тем и хороша, что в ней возможны самые разные приложения. А если позволять приложениям работать на "голом железе", то через некоторое время и много версий спустя выяснится, что в этих приложениях появляется как "криво написанный и неэффективный интепретатор Common Lisp", так и "криво написанная и неэффективная операционная система". А я добавлю: точно так же появляется и криво написанный и неэффективный systems framework, поддерживающий работу с мультимодельным описанием системы и контролем конфигурации. Инструментарий для мегамоделирования (разработки и интеграции множества методов описания/viewpoints и далее редактирования множества частных описаний/views). Это я уже подробно прописывал, смотрите материалы по ссылкам в абзаце чуть выше.
Так что я бы приветствовал разработку специального инструментария, systems framework (http://ailev.livejournal.com/1277009.html) который "из коробки" обеспечивает необходимые свойства разрабатываемых на его основе прикладных студий.
А теперь, насмотревшись на сегодняшние разной степени осознанности подходы к организации systems framework, попробуем в полной осознанности и с выраженным чувством мечты наступить на сороколетней давности грабли "эффекта второй системы" (http://webkomora.com.ua/ru/articles/web/management/man-month/5.html, когда после первой удачной версии с минимумом фич и элегантной архитектурой во вторую версию втыкают одновременно все возможные фичи и архитектура безнадёжно деградирует, равно как требуемые для разработки ресурсы).
"Пустой" systems framework не умеет ничего, как и любой framework. Он будет мигать окошками, не более. Напомню, что framework -- это как кассетница, куда нужно вставлять какие-то plug-ins (обеспечивающие различные viewpoints) и add-ons (обеспечивающие рост базовой функциональности). Но в любом случае, для начала работы потребуется программировать эти плагины и аддоны, для чего нужно будет создать на базе пока ещё пустого system framework
-- мультиязыковую IDE: для разработки исполняемого программного кода плагингов и аддонов и редактирования их структурированных данных. Та же Visual Studio Code или Eclipse Che тут хорошие примеры.
Для нормальной работы различных IDE требуется довольно много интеллекта, а хоть и для intellisence. Если мы хотим пойти по пути расширенных подсказок (http://ailev.livejournal.com/1269236.html -- автоматизации добавления мультур к культур), то нам потребуется полноценная система создания интеллектуальных приложений на базе машинного обучения, т.е.
-- интеллект-студия: для разработки интеллектуальных систем машинного обучения, которая должна закрывать уровни интеллект-стека (http://ailev.livejournal.com/1210678.html -- 1. Прикладной уровень, 2. Когнитивная архитектура, 3. Обучающиеся алгоритмы, 4. Вычислительные библиотеки, 5. Вычислительные языки программирования, 6. Аппаратное ускорение вычислений). Все эти уровни требуют различных viewpoints на создаваемую интеллект-систему, так что смело можно считать, что требуется поддержать несколько подстудий (уровней 2-5, ибо уровень 1 это уже уровень целевой задачи, а на уровнях 5-6 мало кто работает из прикладных разработчиков, там всё давно "коммодитизировано"):
2) собственно intellect studio: разработка когнитивной архитектуры. Тех же нейронных сетей обычно требуется множество разных, плюс нужны средства построения из них ансамблей и самых разных дополнительных обработок, в том числе с алгоритмами других школ машинного обучения, а также зачастую довольно хитрыми структурами обучения с подкреплением, использования внешней памяти и т.д.. Сегодня этот уровень ничем не поддерживается, кроме обычных IDE языка программирования и Notebooks для объединения в рамках одного multiview сниппетов кода с вызовами алгоритмов машинного обучения и графиков с результатами их отработки. Разобраться с этим уровнем и поддержать его специализированными viewpoints для описания когнитивных архитектур (вроде как язык описания структуры мозга из отделов мозга и связей между ними) -- это отдельная задача. Это сейчас направление главного удара. Уже упоминавшаяся Microsoft Azure ML Studio явно целится в эту точку со своим dataflow редактором сценария экспериментов над данными, но там явно ещё есть куда улучшаться -- для обкатки интеллекта тоже нужно использовать exploratory modelling/programming, и нужно иметь языковую консоль и REPL (а не только красивую визуализацию dataflow). Буквально три года назад архитектуры тех же нейронных сетей, как и задачи вероятностного программирования поддерживались непосредственно языком программирования и IDE с Notebook, а не специальными DSL (viewpoints) описания dataflow архитектур нейронной сети и вероятностными языками с их компиляторами -- а сегодня специализированные редакторы архитектур нейронной сети есть почти в каждом deep learning фреймворке, да и вероятностных языков программирования уже несколько. Но по большей части на этом уровне предлагаются не столько studio, сколько просто наборы отдельных API (ср. IBM Watson с http://www.ibm.com/cloud-computing/bluemix/watson/ и Cortana Intelligence Suite https://www.microsoft.com/en-us/cloud-platform/cortana-intelligence-suite, да и все эти deep learning frameworks предоставляют главным образом API, но не среду разработки сложных когнитивных архитектур). Нужно заметить, в intellect-studio вполне возможно задействование не только алгоримов машинного обучения, но и каких-то других алгоримов "ручной разработки" -- например, классических экспертных систем. Но предполагается, что в intellect-studio разрабатываются именно алгоритмы, а не прикладные системы. Прикладные системы и их интерфейсы идут уровнем выше. Например, умный алгоритм для интеллектуального чата или intellisence разрабатывается в intellect-studio, но информационная система колл-центра или учебного тренажёра, где будет задействованы эти intellisence или чат разрабатывается обычным образом, как прикладная система (то есть в моём варианте -- как приложение на базе systems framework).
3) neural network studio и probabilistic programming studio: разработка алгоритмов машинного обучения -- тут прежде всего dataflow диаграммы нейронных сетей (чаще всего приводят в пример TensorFlow), а также коды алгоритмов на вероятностных языках программирования. Такие архитектуры обычно нужно уточнять для каждого класса целевых задач, библиотеки тут редки (хотя и тут бывают. Например, AlexNet пример такой "именованной" структуры сети, которая может использоваться as is, в том числе и в обученном уже варианте, а не разрабатываться и тренироваться на этом уровне). Все текущие "редакторы-визуализаторы нейронных сетей" в сегодняшних фреймворках deep learning поддерживают именно этот уровень -- большинство картинок "архитектуры нейронной сети" и "полностью дифференцируемых архитектур" ровно отсюда, и эта работа выполняется в подобных редакторах.
4) numeric studio: разработка вычислительных библиотек (все эти Torch, Theano и т.д. начинались с библиотеки эффективно реализованных матричных операций, а алгоритмы типа backpropagation просто продолжили эти библиотеки. Опять же, вычислительные алгоритмы нужно разрабатывать и для вероятностных языков программирования (http://ailev.livejournal.com/1211950.html -- недаром говорят, что для байесовского обучения вероятностные языки программирования могут стать тем же, чем стало backpropagation для нейронных сетей) и много чего другого "численно-библиотечного", а хоть и разработка средств Autodiff для работы на более высоком уровне fully differentiable architecture. Тут уже не столько разработка "обучения", сколько разработка вычислительных строительных блоков для него. Именно на этом уровне имеет значение "проблема двух языков" (когда на скриптовом языке прототипируют алгоритм, а потом на Си реализуют быструю версию алгоритма), т.е. наиболее эффективно использовать Julia (http://julialang.org/) именно на этом уровне. Сейчас в качестве numeric studio повсеместно используют Notebook (обычно Jupyter notebook), за редкими исключениями. Вот и Azure ML Studio как intellect-studio добавили возможность экспортировать/импортировать данные через CSV для последующей их численной обработки на более низком уровне детальности, но с использованием REPL и полноценных языков программирования (а не визуального языка "когнитивного dataflow").
Когнитивные архитектуры, разработанные при помощи intellect studio и помогающих ей neural netwrok studio, probabilistic programming studio, numeric studio, вполне могут быть использованы в самых разных других прикладных системах, например при создании:
-- Neuro studio, которая помогает создать систему обработки данных о состоянии человека. Аппаратура и софт из http://www.gtec.at/Products/Hardware-and-Accessories/g.MOBIlab-Specs-Features и https://sccn.ucsd.edu/wiki/MoBILAB как раз позволяют ровно это. Но в нашем случае ситуация будет получше: мы будем использовать для создания neuro studio ровно тот же systems framework, в котором в плагинах уже доступны и numeric studio (для алгоритмов обработки сигналов) и даже полная intellect-studio. Тем самым не удивлюсь, если выяснится, что Neuro studio окажется лишь какой-то небольшой прикладной модификацией-настройкой intellect studio для работы с биоданными. Я склонен включать neuro studio в базовый комплект плагинов к systems framework, ибо в конечном итоге с информационными системами в большинстве случаев работают исполнители ролей стейкхолдеров из плоти и крови, и интересно было бы учитывать не только приходящую с клавиатуры информацию, но и разную другую (направление взгляда, cognitive load, утомляемость и отвлечения т.д. -- это могло бы помочь дать лучше UX для работы с итоговой прикладной системой).
-- trainer studio: разработка учебных тренажёров, студия для методистов учебных систем, описанных в тексте "мимо школы" (http://ailev.livejournal.com/1280262.html). Тренажёр изначально должен поддерживать несколько разных viewpoints -- позволять редактировать задания (вопросы и ответы, например, условие задачи и тестовые примеры при изучении алгоритмики), но также он должен уметь адаптивно строить образовательный маршрут, учитывая как уже пройденный и планирующийся к прохождению материал, так и успешность решения задач, и кроме того ещё и состояние обучающегося. Для это возможно задействование интеллект-алгоритмов (но у нас для этого уже есть intellect-studio), а также алгоритмов обработки биосигналов (но у нас для этого уже есть neuro studio). Тем самым каждый методист сможет при помощи trainer studio создать и отладить тренажёр для какого-то предмета, плюс дополнительно можно будет разрабатывать варианты комбинирования заданий из разных тренажёров с использованием как адаптационного обучения на базе алгоритмов машинного обучения/машинного интеллекта, так и состояния учащихся. Вообще, весь предлагаемый студий как плагинов и аддонов к systems framewrok -- это "скрипка Энгельбарта" (http://ailev.livejournal.com/1158826.html), на которой очень мало кто захочет учиться играть, ведь отнюдь не все горят желанием тратить своё время на овладение теорией музыки и искусством игры на инструментах, чтобы получать потом удовольствие от музицирования. К разработке сложных информационных систем это всё относится в такой же полной мере. Такая разработка требует беглости владения инструментом (в данном случае systems framework и его "студиями"), и нужно попотеть, чтобы добиться беглости (fluency, http://ailev.livejournal.com/1278095.html) в игре на таком сложном (не менее сложном, чем скрипка: учиться на нём играть может потребоваться тоже несколько лет) инструменте. Нужно играть гаммы и этюды, для этого нужно иметь тренажёр (см. темы про тренажёр в http://ailev.livejournal.com/1280262.html). Эти тренажёры тоже было бы неплохо поставлять "из коробки". Так что замкнутый круг: для разработки тренажёров нужно создать студию, разработать тренажёры и включить тренажёр в комплект поставки. Так что результатом заодно будет и набор тренажёров для конкретных учебных предметов, поддерживающих дисциплины system thinking, software engineering и information systems, numerical computing, deep learning и т.д. -- все те, технологии которых будут поддержаны обсуждающимися "студиями".
-- systems engineering studio: мегамоделер для MBSE (можно думать как о поддержке viewpoints для SysMoLan -- http://ailev.livejournal.com/1169972.html, ArchiMate 3.0, Modelica и прочих инженерных viewpoints/языков -- включая, возможно, разные эксперименты типа Mojulica http://ailev.livejournal.com/1168256.html, пункт 3 в http://ailev.livejournal.com/1218155.html, пункт 3 в http://ailev.livejournal.com/1271980.html). Я уж столько об этом писал, что не буду много повторяться. Ну, а другие желающие могут добавить OPM, SysML, AADL и всякое разное остальное.
-- conceptual studio: разработка концептуальной модели традиционно выходит за рамки MBSE, подробнее об этом я писал в "Коллективное моделеориентированное концептуальное проектирование и нейро-технологии" -- http://ailev.livejournal.com/1229950.html, и можно перечитать этот длинный текст по ссылке, переводя там написанное в приглашение к реализации на описанном в настоящем тексте наборе инструментальных средств на базе systems framework, включая интеллект-студию и нейро-студию.
Про PLM/issue tracker и организацию бэкенда к этому набору студий я писать не буду, но всё равно в связи с последними "студиями" есть интересный поворот: они уже не все "однопользовательские", не все их view предполагаются к работе в режиме АРМ (автоматизированное рабочее место). Некоторые требуют более-менее синхронной работы команды:
-- нейростудия подразумевает экспериментатора и человека, чьё состояние мониторится и, возможно, изменяется. Иначе не отладиться!
-- студия тренажёра требует работы методиста предмета и/или методиста по всем предметам (если образовательная траектория имеется ввиду общая) и ученика. Иначе тоже не отладиться.
-- студия системной инженерии сразу подразумевает командную работу.
-- студия концептуального моделирования тоже подразумевает работу команды.
Так что нужно будет поддержать и многопользовательский режим работы, в том числе и поддержку командного режима работы. Это поразумевает не только разработку "индивидуальных" компонент в составе итоговой системы, но и "групповых" -- примерно по тем линиям, что обсуждались на примере коллективного моделеориентированного концептуального проектирования и нейро-технологий http://ailev.livejournal.com/1229950.html. Но там (это давний текст ноября 2015 года) приведены отнюдь не все необходимые применения, возможные с нынешним планируемым набором студий. И даже мартовский 2016 текст про примеры для проекта создания виртуального фасилитатора сотрудничества http://ailev.livejournal.com/1256648.html не позволяет представить всех возможных функций. Так, можно думать об не только о поддержке группы в её работе по концептуальному проектированию, но и обучению её такому проектированию (включая обучение позиции фасилитатора) -- в том числе и обучению на специальном групповом тренажёре. А учитывая, что можно также разрабатывать тренажёры системного мышления и тренажёры для студии системной инженерии, то можно говорить о поддержке подобной системой инженерного образования.
Ну, и дальше можно думать ещё и многопользовательском варианте публичного образовательного сервиса, как это описано в тексте "мимо школы" -- http://ailev.livejournal.com/1280262.html, создание не только "методического портала", где разные методисты создают самые разные тренажёры для самых разных курсов, но и "чебного портала", где этими курсами могут воспользоваться ученики. Это добавит множество различные viewpoints и поддержку view для администраторов портала, идентификацию и аутентификацию для учеников, добавка к systems framework систем идентификации и аутентификации и т.д.
В какой мере собирать такую систему из готовых платформ, а в какой мере разрабатывать "с нуля" под обозначенные в настоящем посте потребности, какой язык программирования мог бы там быть базовым (если вообще в таких больших системах можно говорить о базовых языках), какой мог бы быть roadmap для такой системы, чтобы всё-таки избежать эффекта второй системы, как организационно могла бы быть устроена разработка такой системы (там ведь не одна команда разработчиков могла бы быть), где можно было бы поискать ресурсы для разработки такой системы, и даже как могла бы называться конкретная система такого типа, если бы начали её разрабатывать -- это я вынесу за пределы настоящего поста. И так уже многабукофф.
Мне кажется, что даже если ничего не делать, существующий инструментарий системного программирования будет приближаться и приближаться год за годом к описанному тут виду. Вопрос, не поставить ли этому неспешливому эволюционному процессу своё плечо. Ибо, как говаривал Алан Кей, лучший способ предсказать будущее -- это создать его.