LINUX.ORG.RU

Графическое представление структур данных (включая работу с ними)?

 


2

3

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

Но есть еще одна область, где визуальное представление востребовано - это структуры данных. Мы рисуем диаграмки из квадратиков и стрелочек на презентациях когда объясняем сложные структуры данных коллегам и студентам, смотрим на диаграмки в статьях про структуры данных и т.д. (спасибо @Siborgium - это он меня натолкнул на мысль;-)).

Есть два предельных случая.

  1. Программа минимум - хотелось бы иметь утилиту, способную построить в рантайм диаграмму отображающую существующую в программе структуру данных. Например для отладки. Наверное это должно быть что то вроде valgrind, но которая заданной точке трассы исполнения рисует объекты (квадратики) соединенные стрелочками (пойнтерами). Хотя возможна же косвенная адресация, когда используется не пойнтер а индекс в массиве… Но для отладки это было бы круто, мы делали такое для питона - выглядит феерично и местами очень наглядно. Соответственно вопрос - есть ли сейчаc такие утилиты? Я бы такую хотел (для плюсов).

  2. Программа максимум - именно программирование. То есть мы берем структуру данных (точнее ее фрагмент) и мышкой перебрасываем стрелочки. Что то подобное я делаю на доске когда объясняю студентам что такое список. Утилита в которой это делается запоминает историю переброса стрелочек и генерит на основе этой истории код какого то метода (например list::insert). Историю можно промотать туда/сюда и отредактировать. Наверное неплохо иметь возможность делать текстовые вставки в историю. Это чисто императивный стиль программирования. Не знаю кто как, а я когда велосипедю сложные структуры данных такую картинку в голове/на доске/на бумажке держу.

Пока что п.2 это чисто фантазии, в ближайшие полгода у меня до такого точно руки не дойдут, да и не очень пока понятно насколько оно вообще надо/удобно.

@hobbit, @abcq, @provaton зацените;-)

★★★★

Последнее исправление: AntonI (всего исправлений: 2)

Ответ на: удаленный комментарий

Я не хочу флейма, тем более что с ним говорить не о чем.

Вот из того что я бы стал делать первым джаст-фор-фан, это CAS с визивигом, что бы можно было мышкой символы и скобочки таскать. Я уже понял как делать фронтенд, хочешь поучаствовать?;-)

AntonI ★★★★
() автор топика
  1. А смысл их рисовать. Уже для пары сотен объектов количество стрелочек и размер рисунка будет неприемлем для восприятия. А если взять один объект, то гораздо лучше не стрелочками, а когда ссылка является узлом структуры и может быть развёрнута. Как в .

  2. Таким образом только последовательность действий можно сделать. Условие или цикл макросом не записать.

monk ★★★★★
()
Ответ на: комментарий от AntonI

Было бы интересно, но я пока не знаю, что у меня со временем. Давай в почте потом обсудим.

DELIRIUM ☆☆☆☆☆
()

Графические, или визуальные, языки программирования ©.

P.S. Но можно использовать любой ЯП, ежели нанять китайского программиста, умеющего «цанцзе», структурный метод ввода китайских иероглифов, отображающих структуры данных, и проблема решена :)

quickquest ★★★★★
()
Ответ на: комментарий от monk
  1. Все не надо, хватит одного объекта и тех кто с ним связан. Я подумываю такую штуку сделать, ломать глаза выглядывая совпадающие пойнтеры в отладочном выхлопе мне надоело.

  2. И условие не выйдет. А вот тело цикла/условия вполне.

AntonI ★★★★
() автор топика

метапроговирус? ТС в карантин, к программированию не подпускать, пока указатель не попросит.

Virtuos86 ★★★★★
()

Я на в своей программистской юности игрался с генерацией кода из UML. Как-то не хочется туда возвращаться.

Объяснение идей на маленьких диаграммках - это единственная область применения. Создать тулзы для такой цели вполне неплохая идея. Но когда доходит до продакшена, где все структуры данных разрастаются и раздуваются, то вся эта графика становится только обузой.

provaton ★★★★★
()
Последнее исправление: provaton (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Не всегда. Хорошо нарисованная картинка временами сильно способствует пониманию текста.

Siborgium ★★★★★
()

По структуре данных - посмотри не то-ли что ты ищещь представлено в ddd или gdbgui проектах.

Вообще, по-хорошему структуру данных, по крайней мере значимые её аспекты надо как бы на уровне проектирования держать а не смотреть на то, что получилось пост фактум.

pon4ik ★★★★★
()

https://marketplace.visualstudio.com/items?itemName=hediet.debug-visualizer вот такая есть штука это наверное +- подойдет для пояснения студентам да и самому приятно посмотреть (С++ поддержки там нет, зато есть golang и python, java, js, ts например). Для джавы еще есть jive, и визуализационный плагин для eclipse, ну и если погуглить (что я и делал) там много всякого разного есть даже я так понял у DDD есть какие-то способности в визуальное представление отладки + нашел какое-то количество авторов и букварей по теории визуализации, инструментарию и практикам, пошукайте, раз я нашел за 10 минут, то и вы найдете намного больше за полчасика.

abcq ★★
()
Последнее исправление: abcq (всего исправлений: 2)
Ответ на: комментарий от AntonI

ломать глаза выглядывая совпадающие пойнтеры

В Racket при выделении значения в отладчике все совпадающие цветом подсвечиваются.

тело цикла/условия вполне

Тело цикла обычно зависит от параметра. Графически показать использование переменной цикла я не представляю как.

monk ★★★★★
()
Ответ на: комментарий от monk

В случае for(auto I: container) это просто параметр цикла?

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

Вопрос скорее в том нужно ли это вообще.

AntonI ★★★★
() автор топика
Ответ на: комментарий от pon4ik

По структуре данных - посмотри не то-ли что ты ищещь представлено в ddd или gdbgui проектах.

Спасибо.

Вообще, по-хорошему структуру данных, по крайней мере значимые её аспекты надо как бы на уровне проектирования держать а не смотреть на то, что получилось пост фактум.

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

AntonI ★★★★
() автор топика

когда объясняю студентам что такое список

список это nil и голова|хвост. Все!! Своими указателями ты разрушаешь детский мозг.

Uncle_Bobby
()
Ответ на: комментарий от AntonI

Ошибка в том, что ты путаешь понятие общей формы и частной реализации.

Я на собеседовании любил задавать вопрос про список. И начиналось жалкое блеянье про указатели на ячейки памяти. Тогда я спрашивал «а как в java, списки есть, а указателей на ячейки памяти нет»?

Uncle_Bobby
()
Ответ на: комментарий от Uncle_Bobby

В исходном посте:

Хотя возможна же косвенная адресация, когда используется не пойнтер а индекс в массиве…

Можно ввести понятие «обобщенного пойнтера», это некие данные + методы чтения/записи (конвертации к указателю), и работать с ним как с пойнтером.

Как в джаве я вообще понятия не имею.

AntonI ★★★★
() автор топика
Ответ на: комментарий от AntonI

Само объяснение неправильно с методологической точки зрения. Список - объект с определенным на нем классом операций, как матрица или множество. Зачем объяснять это через то как это реализовано в С++? Попробуй объсянить что такое тензор через указатели. У тебя занятия по стуктурам данных или практикум по программированию на с++?

Uncle_Bobby
()
Ответ на: комментарий от DELIRIUM

Так тут обратная задача.

Задача обратная, но проблемы визуального представления никуда не деваются :/

provaton ★★★★★
()
Ответ на: комментарий от Uncle_Bobby

Спорно. Я слышал трактовки что дескать массив это тоже список, но все таки каноническое определение списка на нашей полянке завязано на структуру данных, которая в свою очередь так или иначе завязана на реализацию.

Операции реализованные над списком вполне себе реализованы и над массивом, у них только сложность другая. Ну так сложность это вообще отдельная история…

У тебя занятия по стуктурам данных или практикум по программированию на с++?

два в одном.

AntonI ★★★★
() автор топика
Ответ на: комментарий от provaton

Проблемы не деваются, вопрос в том можно ли скрыть проблемы и оставить преимущества.

AntonI ★★★★
() автор топика

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

смотрите UML, sysML, IDEF и все прочее

alysnix ★★★
()
Ответ на: комментарий от AntonI

В таком смысле и держать. Если структура не тривиальна, то поддерживать основные соображения по её архитектуре с в актуальном состоянии.

pon4ik ★★★★★
()
Ответ на: комментарий от AntonI

массив это тоже список

Определение массива включает в себя требование доступа к i-му элементу за константное время, в списке же оно (время) по определению линейное.

Студентам я бы объяснял в духе «структура данных» -> «возможная реализация этой структуры данных на языке С++».

Siborgium ★★★★★
()
Последнее исправление: Siborgium (всего исправлений: 1)

Упс - программа минимум есть в отладчиках. В gdb и тем паче во всяких студиях.

Реализовать как отдельный мега-софт : берёте соотв.библиотеки (libdwarf как по старому) и пердячете View по полученным данным

(благодарить не надо, если настаиваете могу назвать WMZ)

Программа максимум в принципе не нужна. На край - возьмите UML. Существуют генераторы по нему. UML хотя-бы показывает дисциплины доступа и взаимоотношений не заморачиваясь над внутренней требухой.

MKuznetsov ★★★★★
()

такое для питона - выглядит феерично

Скриншот?

thunar ★★★★★
()
Ответ на: комментарий от Uncle_Bobby

Попробуй объсянить что такое тензор

Всё просто: Тензор - это голова и хвост, между ними жирный рыжий кот.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от provaton

Но когда доходит до продакшена, где все структуры данных разрастаются и раздуваются, то вся эта графика становится только обузой.

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

gedisdone ★★★
()

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

shnnmnn
()
Ответ на: комментарий от gedisdone

На презентациях графика обычно уже сильно отвязана от кода. :)

provaton ★★★★★
()
Ответ на: комментарий от shnnmnn

На одной вообще не собираюсь. Можно говорить об отображении некоторых методов измерения струкутры данных, каждый метод это не одна картинка а серия картинок (история изменений).

AntonI ★★★★
() автор топика
Ответ на: комментарий от AntonI

можно ли скрыть проблемы

Thyrd © позволял скрыть проблемы «унутре» иерархии графических примитивов, порождаемых структурными абстракциями языка Forth — «Великого и Ужасного».

и оставить преимущества.

Суслика Thyrd видишь?
— Нет.
— А он есть :)

quickquest ★★★★★
()
Ответ на: комментарий от DELIRIUM

Тензор - это голова и хвост, между ними жирный рыжий кот без головы и хвоста

Давайте быть точными в определениях.

Nervous ★★★★★
()

Мы "пишем программу" для наземной обработки данных одного телескопа.

Заказывает и принимает её ESA. И заставили они нас рисовать flowchart диаграммы для всего процесса. Моя часть - это обработка изображений, калибровки и коррекция всяких артефактов, я рисовал ручками по готовому прототипу/из головы (прототип был тоже из головы). Нарисовал в самом грубом приближении - какие блоки существуют, откуда/куда вход и выход, что на каком этапе корректируем. В целом, могу сказать что если так и оставить достаточно грубое описание, то занятие не совсем бесполезное. Помогло проработать физическую модель, не забыть откуда и куда идут какие параметры.

А вот если начинать дальше детализировать, то КМК сложность рисунка всё загубит. Он станет человеконечитаемый и потому мало полезный.

Хотя если таковой будет рисоваться на автомате, то может и полезно.

sshestov
()

Вы все правильно говорите, коллега (и я ровно так как Вы говорите обычно и делаю), но я немножко не о том.

Иногда графика нужна для отладки некоторых ФРАГМЕНТОВ кода. И есть некоторые ФРАГМЕНТЫ которые таки (наверное, см. исходный пост) проще ввести из графики. Но упаси боже вводить ВСЕ из графики - это ужос-ужос-ужос.

AntonI ★★★★
() автор топика
Ответ на: комментарий от ls-h

Да, я этот проект нашел на диске, но он че то не заводится сейчас, надо разбираться.

Так все просто, рисовалке даешь питоний объект, она его анализирует и выкидывает в .dot для графвиза. Был даже режим когда она следила за изменениями объекта и показывала на одной картинке как он эволюционирует. Как то мы сунули туда просто запущенный интерпретатор (там модули загруженные, все дела) - это была простыня 2000+ квадратиков.

Я думал это будет удобно для отладки, но потом че то не прижилось заглохло… если дадите почту я пришлю.

AntonI ★★★★
() автор топика
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

я то в целом согласен ...

и если кто что предложит - с удовольствием посмотрю.

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

sshestov
()
Ответ на: я то в целом согласен ... от sshestov

Там выше старшие товарищи говорят что что то подобное в продвинутых отладчиках уже есть, вон даже ссылочку подогнали Графическое представление структур данных (включая работу с ними)? (комментарий)

Я к сожалению в отладчиках полный нуб, немножко в gdb палочкой иногда тыкаю из консоли, с этим надо разбираться. Но в принципе я знаю наверное как прикрутить вывод в .dot (и даже сборку pdf, можно даже с его открытием) фрагмента структуры данных из плюсов, это такой продвинутый вариант отладочной печати. Если в отладчиках готового не найду то в апреле займусь, сейчас два дедлайна на RSCD висит.

Вы случаем не из ИКИ?;-)

AntonI ★★★★
() автор топика
Ответ на: комментарий от quickquest

Thyrd … Forth…

Для меня это слишком сложно;-(

AntonI ★★★★
() автор топика
Ответ на: комментарий от Avial

Нет, но штука любопытная. Спасибо;-)

AntonI ★★★★
() автор топика

Если искать аналогии, то советую посмотреть на системы САПР для микросхем. Для любителей повозюкать мышкой есть графические редакторы, но серьезные модели только текстом через Verilog и VHDL.

Кстати, текст - это тоже визуальная система, если на то пошло.

dave ★★★★★
()
Ответ на: комментарий от dave

Я не хочу искать аналогии, спасибо. И я не призываю юзать ВП везде (я даже формулы и текст верстаю в техе) - я лишь нашел еще одну область где ВП может быть полезно. Таких на самом деле немного.

AntonI ★★★★
() автор топика
Ответ на: комментарий от AntonI

Ну, визуальщина распространена в имитационном моделировании, но тоже до задач определенной размерности. Как задачи пошли большие, то все, прощай, мышка!

dave ★★★★★
()
Ответ на: комментарий от dave

Как задачи пошли большие, то все, прощай, мышка!

Это бесспорно.

AntonI ★★★★
() автор топика
Ответ на: комментарий от AntonI

Вы случаем не из ИКИ?;-)

Нет. Но в прошлой жизни много раз мимокрокодил.

sshestov
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.