Обсуждение

Составляющие продукта: 1. Интеграция приложений в контекст многопроектной и многопредметной деятельности пользователя. За точку нуля здесь Firefox+TreeStyleTab. 2. Интеграция между приложениями. 3. Зоопарк viewpoints. Плохой путь - делается свой зоопарк, к нему гвоздями прибиваются огрызки [1] и [2]. Хороший - делаются полноценные [1] и [2], которые дают быструю пользу на старой попсе из [3], но одновременно минимизируют затраты на создание непопсы. Можно и без диссонанса. :)

Ну да, что-то типа того. Т.е. предлагается серьёзно отнестись к фразе, что "в каждом усложняющемся от старости продукте появляется язык, который является кривой донельзя реализацией Common Lisp" и начинать разработку с IDE этого языка. А поскольку речь идёт о зоопарке viewpoints, то думать об этом легче как о браузере разных view. Мне не нравится аналогия FireFox+TreeStileTab, но я понимаю, почему трудно предлагать другие аналогии: -- Eclipse не предполагает зоопарка view: все окошки там хоть и view, но они крутятся вокруг одного главного veiwpoint, плюс в нём нет языковой консоли -- Jupyter тут не отличается от Eclipse, в нём зато есть языковая консоль, но променяно многообразие вспомогательных view на эту самую консоль: будет только один viewpoint -- PLM подразумевает много viewpoints, но любой browser это для него отдельный продукт и в состав PLM обычно не входит Чем не нравится FireFox? Нет поминания языковой консоли (аспекта IDE, и JavaScript тут совсем не то), нет потенциального разнообразия viewpoints (ибо понятно же, что там просто HTML5 как viewpoint), нет более причудливого управления окошками, как возможно в Eclipse (ибо ещё нужно сообразить, что внутри окошка можно делать iframes). Но всё так: либо в проекте порождается зоопарк viewpoints-приложений, и потом дико мучается без ALM/PLM к нему, либо сначала делается ALM/PLM, а потом все viewpoints оформляются не как приложения, а как плагины.

Есть консоль. Плюс отладка, вплоть до "отладить кусочек файрфокса в файрфоксе" и работы с не-JavaScript кодом. Вписать туда Jupyter или профессиональные UI-фичи из IDE и CAD можно. В этом отличие от упомянутых аналогий, с которыми уже ничего сделать нельзя.

Непонятно это мне. Браузер отлично сам вписывается в любое окошко, как view для HTML. К тому же конкретный FireFox -- что, прямо таки codebase FireFox брать, и начинать работать с ним?! Хотя я согласен, что про "код" можно вспоминать всякие там прилады типа NaCL и сетования в FONC, что браузеры с самого начала должны были идти именно по этому пути: допуска нативного кода на страницах. С другой стороны, тот же Jupyter появляется в браузере, и ничего. Если бы Atom тоже появлялся в браузере (а это легко, как я понимаю), и ещё окна Eclipse появлялись в браузере, то всё было бы ОК. Но браузер тогда даже делать не нужно, он ведь уже есть, и не один?

Не браузер, а профессиональная среда организации view. На базе одного из существующих решений: Firefox, NW.js, Electron, голый Chromium (как у Яндекса), что-либо ещё. Это разные затраты и возможности. Простой "iframe на страничке" возможностей не даёт, и для таких задач никогда не предназначался.

Ага, взять Electron и для начала написать над ним Atom, а потом продолжить плагинами к нему ))) Или взять Electron и написать на нём по-быстрому Jupyter, чтобы продолжить бэкендами разных языков. А потом написать сбоку к нему Atom, продолжить плагинами к нему ))) Ну, и заодно решать все эти вопросы с фронт-эндом и как-то распределённым бэкендом (не путать с бэкендами разных языков в Jupyter) -- тут уж ничего не подтянешь. Если же в это не ввязываться, но будет просто "конвертилка файлов", а файлы россыпью. Ну, или надеяться на API к чужим бэкендам, что тоже непросто. В этом плане и Eclipse не более (но и не менее) чем профессиональная среда для организации view. Но явно не на JavaScript. Впрочем, на Julia есть тоже UI рисовалка на разные типы файлов (чтобы было удобно ноутбуки для математиков делать: https://github.com/shashi/Escher.jl). Но трудозатраты на всё это, конечно, совсем разные. Как-то не хочется в основу JavaScript брать, хотя это, похоже, мейнстрим сейчас для любых табовых приложений (куда уже и редакторы попали, и даже IDE -- тот же Electron это показывает). Не, я знаю, что JavaScript неплохой язык, но почему-то его недолюбливаю, и сильно. Невзирая на бешеную его популярность. И на то, что он уже давно и прочно сидит в основе веба, и поэтому от него никуда не деться.

Свои клоны Atom или Jupyter это уже зоопарк. Не стоит усилий. Оно и так есть, плюс может быть адаптировано (не важно кем) под возможности новых сред выполнения. А для разработки следующих поколений необходим опыт использования этих новых сред. Когда знание "я смогу ..." заменяется интуицией "я могу ... прямо здесь и сейчас". JavaScript можно не писать, а генерировать. Впрочем, как и любые артефакты веба.

Так я разве я не то же самое написал? Клонирование неинтересно. Новая же среда выполнения -- если это на базе Electron или даже остального перечисленного, так это JavaScript, и не факт, что удастся его генерировать. Хотя это понятно, что любые артефакты веба можно генерировать, как и любые другие артефакты. Мне представляется интересной мысль про объединение проекта текущего комментируемого поста (про исполняющую среду системной информатики, поддерживающую также AI-суфлёра со стороны машины и нейро со стороны пользователя) и проекта по адаптивное обучение информатики, с последующим выходом в другие языки. Я когда-то придумал слово "КуМир" как название для мегамоделера с языками, где разные viewpoints определяли разные миры, и КуМир расшифровывался как "Комплект Учебных МИРов". Миры управлялись Ершолом как языком (правда, не консоль-REPL, а нуль-компилятор -- компилирование за время ноль и с комментариями по поводу ошибок на полях), и их было сделано штук пять-шесть. Ежели взять пост http://ailev.livejournal.com/1275421.html и продолжить эту линию с некоторого разнообразия языков программирования для многолетнего курса алгоритмики, а потом добавить аналогичные курсы математики, физики и всего прочего по тому же принципу, да ещё иметь там AI+нейро -- то это всё будет "усиленная AI и нейро среда для адаптивного группового обучения разнообразным предметам". Системная информатика, плюс нейросетки, плюс нейрофизиология, плюс опыт адаптивного обучения сначала алгоритмике, а потом и всего остального, плюс поддержка групповой синхронной и асинхронной работы (группа или даже группы учеников, плюс учитель или даже группа учителей, или даже большой веб-ресурс). Подходит по описанию под http://openmeta.livejournal.com/237572.html ))) Хотя я и скептичен по этому поводу, но почему бы не помечтать! ;)

Кстати, есть ещё и такие интересные штуки (и там интересные ещё технологии вокруг пробегают): https://code.visualstudio.com/blogs

JavaScript давно генерируют из всего. Для каких-нибудь TypeScript, CoffeeScript, Dart это основной таргет, для языков вроде Scala или Clojure побочный, ещё можно из Java, или из Python, а из C/C++ через emscripten такой ядрёный код получается, что быстрее любых вариантов "ручного" JS. Что же касается разных проектов (про среду, про нейро, про обучение, ...), то общего между ними на уровне "а в ворде потом можно "Войну и мир" написать". Не совмещается такое в едином жизнеспособном проекте, хотя и помещается в одной мечталке.

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

А ещё вот: https://github.com/eclipse/che

По опенсорсу тоже выручка хорошая бывает. Ну очень хорошая. Например, https://vc.ru/n/mozilla-yahoo А так, разделение труда. Как при "золотой лихорадке" - одни золото ищут, другие инструменты поставляют, etc.

Ну, на рынке движков для игр есть и другие печальные примеры. Нет золота -- некуда поставлять инструменты )))