Обсуждение

При таких ценах на рабочее место, действительно задумаешься, а не организовать ли написание. Может дешевле получиться. Если найти еще двух-трех заказчиков, которым нужна работа с большими графами (очевидная задача - анализ control flow в крупных программных проектах). На самом деле все еще хуже. Некоторое время назад кто-то в моей френдленте построил в GraphViz граф control flow или dependencies чего-то типа samba, экспортировал его в PNG, получил картинку 30000xсколько-то там, и долго искал просмотрщик растровой графики, который позволял бы её нормально масштабировать и панорамировать. (Ага, в 1993-1997 мы с растрами такого размера под DOS работали). И в fido7.ru.unix недавно кто-то высказывался по поводу того, что многие современные текстовые редакторы не умеют работать с текстами размером больше оперативной памяти (да, сейчас это значит "тексты в десятки гигабайт", но иногда и с таким приходится иметь дело).

Если и писать что-то, то уж точно не общеграфовое. Писать нужно редактор семантической сети, поддерживающий к ней запросы. И языком представления/запросов как раз делать Gellish. Мы когда-то с Акопянцем сделали пару версий Аквизитора (а Акопянц с Лазаревым потом сделал третью) -- это ровно такой софт, разве что не было графического представления, а только представление квазидеревянного (по основным типам отношений) "гипертекста". Использовалась эта штука как раз в экспертном САПР газосварки. Выбор Gellish дает уверенность в том, что разработка не будет прокинута промышленными интеграторами. То, что любые control flow вполне выразимы семантической сеткой, очевидно. Но это не было бы главным применением (хотя значительное количество графовых браузеров как раз на такое применение нацелены, этому применению в GraphViz посвящен целый раздел). Меня как раз интересует, нельзя ли обойтись настройкой какого-либо общеприменимого софта, чтобы не затевать разработки. Пока выходит, что нельзя.

Э, я тут ставлю совсем более другую задачу - создать школу программистов, способную быстро и эффективно такие задачи решать. Пока еще живы люди, которые работали в условиях жестких ограничений на ресурсы, и они еще не забыли как закладывать в архитектуру проекта масштабируемость. Причем имено на уровне десктопных приложений, а не серверов. Вот тут vvagr недавно Шерстюка поминал. Шерстюк ведь был велик в частности именно этим.

Я вот тоже подумываю не наваять ли мне Гелиш редактор. На нем удобно модели для генерации тестов задавать. Единственное, что work/control flow надо придумать как задавать, но это решаемо, хотя можнт лучше специализированный язык применить.

work/control flow хорошо описывается отношениями (это ведь тоже граф!), так что это не вопрос. Как именно синтаксически отображать отношения -- для начала можно все единообразно, затем вводить синтаксический сахар (например, для разных типов отношений разного типа стрелки плюс автоматическое отображение по какому-то из графовых алгоритмов рисования с приоритетом относительно какого-то типа стрелок -- но это особая область, рисование графов, тут все пока довольно плохо с алгоритмами "разводки").

Проблема в том, какой из возможных вариантов нотации/отображения выбрать :). Я вот присмотрел пока YAWL у него есть полезное свойство анализируемости.

Я тут недавно у финнов из Xtract Oy видел пример софта, который отрисовывает графы из десятков миллионов точек (утверждают, что граф из связей 33 млн. абонентов немецкой T-Mobile обсчитывается 9 часов всего). Там и визуальный браузер в комплекте имеется. Ребята почти взяли GSMA Mobile Innovations Award за это решение в этом году, кстати - проиграли только молодцам, разработавшим сотовые вышки с ветряками. "Зелёная" темы нынче в моде...