Обсуждение

Девяносто процентов так называемых программистов не может разобраться в обычном коде. Сложность связей погребёт их. Так и вижу программиста, увлечённо копипейстящего в пене из пяти десятков пузырей.

рабочие гуи, конечно, надо развивать а то со времен турбо-паскаля принципы работы с кодом остаюцца неизменными есть же возможности визуализации структур данных, параллельности и других концепций

ZUI не панацея. Там есть проблема с созданием идеомоторных паттернов, из-за чего работа в них всегда будет медленнее, чем в традиционных интерфейсах. Следующими вероятно будут гибридные решения, где ZUI-визуализация может быть объединена с более быстрыми метафорами навигации. А уж традиционное сейчас сочетание языков медленной разработки с ускоряющими IDE... :) Вообще, среды по линии Smalltalk пока интереснее - как Squeak и работы VPRI, так и Newspeak/Hopscotch (http://www.langnetsymposium.com/2009/talks.aspx) Последнее так и хочется сделать для ... пока хотя бы для Python, с добавлением браузерной метафоры Tree Style Tab.

Визуальных языков - море. И все - не рабочие.

Записался на бету. Попробую как оно в деле, если дадут.

Мне кажется, что для онтологий это немного не удобно. Простой пример. Если нам нужно собрать некоторую аналитическую записку на основе собранных данных, их классов, источников и областей применимости, вариантов использования и частных примеров, иллюстрирующих общие закономерности, часть данных при этом является результатом собственных расчетов - то как быть? Строить граф из разнотипных связей, как например в MindManager? В приведенном примере про сути речь идет про однотипную иерархию классов (безусловно удобную для программистов, но вот удобную ли для других направлений, связанных с обработкой данных - большой вопрос), которую можно размещать на плоском экране, ну и использовать обычное 2D пространство на манер обычного рабочего стола. А как быть, если нужно изменить классификацию, например, переключиться от поиска наследников в системе - обобщение/пример, к поиску наследников в системе целое/часть или причина/следствие? Даже поверхностный анализ дает с десяток сущетсвенных при построении любой онтологии срезов, которые нужно не только перемещать по плоскому столу, но и как-то вертеть в трехмерном пространстве, а может быть, и трех измерений мало. Все-таки олаповская модель (гиперкубик) куда собираются только те свойства, градации и иерархии, которые нужны, а потом это как-то отображается, лично мне кажется более удобной. И попробовать ее визуализировать так, чтобы в нужные стороны удобно (т.е. на бесконечном поле, с зумом и в нужные стороны) торчало то, что помогает понять, о чем идет речь с помощью онтологий - вот это было бы здорово. Другой вопрос - может стоит попробовать скрестить ежа с ужом, например, добавить метрику в этот рабочий стол, чтобы его можно было стеной наружу так сказать вывернуть?

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

Мы пробовали работать с 3D, ничего хорошего пока с этим не выходит. Самое интересное при работе с данными пока все-таки происходит в 2D.

Вот-вот. Верстка нужна, а не линейность. Метафора листа бумаги, где куда положил, там и лежит -- а не метафора гибкой wrap строки...

Это Java-то не рабочий язык, пардон?

15" мне не хватало никогда. "Хватает" — это когда практически всё поле зрения занято экраном. Два 21" экрана дат почти нужный эффект, и даже один 20" резко повышает (мою) производительность.

Притом практически бесконечного в любую сторону листа бумаги.

Это ява - визуальный, пардон? http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

Мне как-то поставили два монитора 19 дюймовых, но я второй держал выключенным :). Поскольку я привык программировать на бумажке, мне 19ти дюймов многовато. Хотя для работы с графикой, конечно дюймы не лишние. Впрочем и тут есть мнение, что больше 26 дюймов уже тяжело охватить взглядом, надо головой много вертеть.

Вы ведь внимательно смотрели флэшку, ссылка на которую стоит в исходном посте? Там IDE именно для явы.

Возможно оффтоп, но может и интересно: http://cartmendum.livejournal.com/42894.html :)

Нет, не оффтоп, даже и не к этой теме (как представлять сложную информацию). Тем не менее, представление информации [якобы ситуационной] инженерии методов на http://www.cmmi.de -- лучше, чем в бумаге, но много хуже, чем можно было бы сделать. Фактически, они сделали аутлайн к текстовому документу. Никакого языка представления, никакой метамодели. С другой стороны, и исходный текст предназначен больше для текстовых редакторов, нежели для других форм представления. И, главное, это не IDE: стуационности вообще не предусмотрено, текст дан и потребляется as is, никакой доработки-экземпляризации.

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

Кстати, классический цикл реализации проекта по ISO 15 926 в принципе трехмерен. Например, если взять классическую V-диаграмму вначале детализации, а потом верификации при сборке, то будет видно, что большая часть данных в процессе декомпозиции соотносится между различными компонентами 2D схем (ну а когда доходим до 3D чертежей, то все становится четырехмерным, но ключевые проекции, в которых видны ключевые инженерные и компоновочные идеи, все равно остаются). Как следствие, если вначале нарисовать общую логику технико-экономической концепции, потом дать реестры требований, сгруппированных по дальнейшему использованию, потом каждый набор требований превратить в набор принципиальных (схематических) решений, и все это разложить, как блины на тарелке, то вертикальные связи между 2D блинами разной детализации позволят более удобно производить dril-down, zoom, а может быть, даже даст осмысленный 2D скроллинг, что ИМХО играет важнейшее значение при сборке, верификации и подтверждении качества. Хотя не исключаю, что для этого не обязателен 3D.

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