Обсуждение

> число программистов и сисадминов в "неайтишных" компаниях ну, сисадмины же не разрабатывают ничего, так что их и из айтишных компаний надо вычитать. а программисты в неайтишных не учитываются правильно - они же не делают ничего на продажу, поэтому на рынок софта не влияют. > пока неприметной language workbench MPS этой неприметной уже лет семь или восемь как минимум. если она так и не стала приметной, что-то неладно в королевстве.

Она неприметна только у венчурных капиталистов (потому что JetBrains позиционирует ее совсем по-другому, нежели ребята из Intentional Software). То, что ее обязательно приводят во всех обзорах language workbenches, показывает и доказывает как раз крайнюю ее заметность.

К вопросу о ворочении графами: пару лет назад какая-то израильская лавка сделала процессор именно под "ускорение искусственного интеллекта". Не помню, правда, не от тебя ли я это тогда слышал. Вот у них с графами все хорошо...

Статью википедии JetBrains MPS http://ru.wikipedia.org/wiki/JetBrains_MPS предлагают удалить из-за малого числа ссылок в поисковике на тему!

Мне не очень приятна их реализация. Но это единственный работающий и доступный продукт. Чем и выделяется из прочих. :)

В ИТ все стартапы-проекты основаны на кадрах. Хорошие кадры - хорошие проекты. Пока жили старым прошлым - кадры были хорошие. Сейчас с ИТ кадрами, в силу "объективных" реформенных дел в образовании ничего хорошего нет и не будет. Следовательно ИТ кадровый потенциал страны будет только снижаться. Быстро. Как и перспективы инвестиций в разработки. Не надо быть большим аналитиком, чтобы понимать это. Надо бежать другие в страны, которые озабочены образованием населения. В другие буквы БрИК, например.

Тут еще нужно отметить, что подобного сорта language workbenches и ранее упомянутые онтологические системы программирования (например, на базе ISO 15926) требуют какой-то адекватной аппаратной поддержки: центральный процессор медленно ворочает огромными графами, а графические ускорители называются так не от слова "граф", а от слова "графика". Для language workbenches специальной аппаратной поддержки не надо, мощи современных процов вполне хватит. Просто программеры не умеют достаточно хорошо и в нужные сроки писать хороший и быстрый одновременно код. Разработка спец аппаратуры, создание софта к нему и популяризация всего этого столько много времени займет, что расчитывать это как на решение проблемы не стоит - больно уж долго ждать придется.

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

Сейчас много команд, которые разворачиваются в этом направлении и продукты которых тоже доступны (например, более консервативная Whole Platform, о которой я несколько раз уже писал). Но у MPS, похоже, работоспособность и безглючность повыше, и интерфейс получше (ибо много решений утянуто с основных IDE, которые выпускает JetBrain). У нас вот выбор: затевать свою подобную разработку (которая пройдет более быстро, ибо понимаем, что делаем), или опереться на чью-то чужую (которых раз, два, и обчелся -- но "не очень приятна реализация", ибо они топтали целину, когда начинали думать о своей архитектуре). FONC начал вообще с разработки пакета идей, и далее радостно предлагает их для реализации в любом языке (в языке COLA в том числе, но не ограничиваясь этим языком). Мы пока идем тем же путём: собираем идеи, которые при их сборке в одном месте дадут скачок в уменьшении сложности на порядки.

Нужно просто набирать людей в проект не из своего города (или даже страны), а из глобуса. И сразу жизнь проще станет. Но ход про "побег" правильный, только для этого даже двигаться с места в эпоху интернета не нужно. У нас команда для .15926 подбирается из самых разных городов России -- Москвы, Питера, Урала, Юга. Один раз собрались очно (и то не все), а остальное -- через интернет...

Интел-то как раз таким заниматься не будет. Ему и на х86 хорошо. Он вот пытался сделать Larrabee, который бы кстати вполне для графов подошел, поскольку там обычные ядра а не специализированные, но как-то у него туго дела идут. Впрочем у него конкуренты мощные. А НВидиа сделала тоже ядра общего вида, а не специализированные, так что их тоже можно юзать для обработки графов. Кстати видел недавно новость про сервак с 512 процессорами Атом. В принципе, для многих графовых алгоритмов неплохо будет, если их параллелить уметь. А если еще Атом на АРМ заменить, то еще лучше будет.

По пп.4. Таким образом получается, что, допустим у Мегаплан (есть такой успешный SaaS), инвесторов не будет интересовать ни их софт, ни клиентская база а только умение продавать свою диковинку? И еще бы больше интересовало если бы у них был бы отдел внедрения, обучения и сопровождения корпоративный клиентов? Но ведь SaaS-ы тем и примечательны что внедрения-обучения там нужны в минимальных объемах... Получается, что инвестируют исключительно маркетинговый потенциал??

Когда имеет смысл делать на базе готового продукта: 1) Интеграция в пайплайн. Из практики - инструмент для специальной обработки текстур делается плагином к Photoshop - художники и так в нём работают, очень удобно. 2) Подходящие свойства продукта. Например, кому-то нужна реализация Java, с возможностью легко дописывать новые конструкции/макросы, и редактор к ней. Есть смысл посмотреть на MPS. 3) У команды нет знаний и опыта разработки редакторов, но нужна своя вьюха для хитрых данных в проекте, чтобы пользователи не редактировали XML руками. С дополнительными затратами времени, молотком и матом пишется вьюха для Eclipse. Однако, результат есть, а какие-то навыки по редакторам разработчики в процессе получили. Для данного случая я бы про существующие workbenches вообще не вспоминал. Очень далеки, хотя могут быть референсами для юзабилити решений. А вот первый вариант можно посмотреть. Если есть готовый пайплайн и достаточно открытый по архитектуре САПР в нём. Но в этом вы явно лучше знаете ситуацию.

С пайплайном очень трудно: мы ведь бьем как раз в точку, которая задает пайплайн там, где его до этого не было (у нас ведь описывается жизненный цикл!). В принципе, это разные PLM-системы, но такие системы весьма вендор-специфичны. ISO 15926 дает возможность немного отойти от этой вендор-специфичности и больше думать о задаче, а не о средствах ее решения. Проблема еще и в том, что все PLM настроены на описание workflow, а не жизненных циклов и их практик, как целимся мы. Нынешние PLM сидят все на крошечных участках общего ЖЦ, примеры более обширной интеграции очень редки. Мы движемся от обратного: хотим сделать "описание жизненного цикла для менеджеров и новых сотрудников", а потом его детализировать до уровня, когда возможно непосредственное исполнение в софте его частей. У нас есть примеры успешных таких разработок перед глазами (например, ОргМастер). Так что в данном случае у нас ближе к случаю 3 из вашего коммента. Мы, например, обсуждали вариант взять Simantics и сделать вьюху прямо к нему (он сам сидит над Eclipse, но у него онтологический движок и к нему все необходимые заморочки -- разве что онтология нестандартная, не ISO 15926). У меня понимание того, что я хотел бы иметь в реализации: -- интерфейс, больше похожий на САПР или любой дизайнерский софт, а не "традиционную IDE", абсолютно динамическое редактирование. Вы абсолютно верно указали это в вашем постинге. -- возможность добавлять языки (собственно, это и есть language workbench) -- при добавлении языков сразу указывать на связь с данными из других представлений, и иметь возможность экспортировать результаты (тут важно ISO 15926). В принципе, все современные САПР устроены таким образом (с точностью до различающихся онтологий, но структура этих онтологий близка к ISO 15926, а не к типам языков программирования или схемам баз данных -- она в терминах описания реальности, а не в терминах языков программирования). -- первым "языком=вокабуляром" должен быть ISO 24744 (потому что из него сразу видны выходы во все другие языки: описания продуктов, жизненных циклов, инструментов и т.д.). Увы, все рассматриваемые варианты реализации предполагают либо получение неподъемной громоздкой системы с кучей всего ненужного (типа того же Eclipse) на борту, и отсутствием нужных свойств, либо присутствие нужных свойств и заранее непонятное время программирования с невозможностью даже его оценить. Я думал, что интересное решение можно получить, например развивая Mapper и попутно интегрируясь в IDE Python. Но точно так же сейчас можно вздохнуть, и пересадить алгоритмы Mapper на MPS -- и дальше, сжав зубы, писать на Java. Тут есть еще существенный момент: людям очень не нравится думать о том, что системой типов языка является ISO 15926. Всем хочется писать в "традиционной системе типов языка", а затем мэппиться только в тот момент, когда нужно что-то куда-то передать или что-то откуда-то запросить. Типа как "сила предлагаемого решения в свободе рук программиста, а ISO 15926 -- это как английский, только для межнационального общения". Моя же мысль: а давайте попробуем писать сразу по-английски, какие это может решить наши проблемы? Разница в подходах: английский будут учить либо потом (после начала программирования), либо сначала (до начала программирования). А у меня гипотеза, что пишушие по-английски будут иметь вообще другой стиль программирования -- ибо у них сразу будет другая картина мира (ведь наш метафорический "английский" -- это онтология!). Много, много споров и развилок...

вы 2 дня там были ? Про : "инвестиции не на инвестфорумах ищут.1. Классическое венчурное инвестирование через инвестфонды -- это очень небольшой процент реальных сделок, которые идут на рынке. " А где их ищут собственно ? И если можно 2 ответа - в российских и американских условиях ? Вопрос для меня важный, собираюсь продвинуть несколько проектов до получения денег. Или может есть какой концептуальный референсный текст на эту тему ?

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

Simantics может быть (частично) вариант 2. Потому что вариант 3 это когда долго и дорого, основной ресурс уходит в преобразование (рост) команды. Когда есть такой приоритет. Я бы начинал с прототипа, в любом случае. Если standalone, то прототип на Python, затем перенос графа внутреннего представления, а также тяжёлого рендеринга внешнего в C++, с оставлением все логики UI в Python. Чтобы халявно менять и перезагружать не выходя из самого редактора. Если делать на Eclipse, то сначала поиск спеца с хорошим отношением к Java (сам такое трогать не люблю, несмотря на разработку JSR), а затем (тоже) прототип на Java. Халявным будет уже существующий UI Eclipse/Simantics/whatever. А вообще, оценку лучше начинать с требований. Табличка: 1. Должно быть в прототипе. 2. Должно быть в первой рабочей версии продукта. 3. Должно появиться при развитии продукта. 4. Рейтинг mature, фичи реализованы, можно полировать UI и выбирать дальнейшее развитие. И по каждому пункту: требования, сроки, доступные ресурсы.

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

Ассоциативная память используется сейчас в роутерах (обсуждение идет в hadware треде FONC -- прямо в эти дни). Так что эти необычные архитектуры (помним Erlang) продолжают вылезать в телекоммуникациях, там ведь нужно очень быстро и очень много, и на это есть деньги.

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