Войти
ПрограммированиеФорумГрафика

Визуализация программирования. (2 стр)

Страницы: 1 2 3 4 Следующая »
#15
20:06, 14 янв. 2019

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


#16
23:33, 14 янв. 2019

san
> Еще раз - я говорю не об интерфейсе для программиста.
А о чем тогда? Тебе нужен способ реализовать кодинг в виде кликов и перетаскиваний?
А нужно ли такое программирование? Например блочное, где одно слово кода занимает 100500 пикселей, нагруженных визуальной составляющей, и еще кучей визуальных связей по экрану. Этого хватает только чтобы сделать маленький скрипт, но делать что-то большое в таком виде нереально.

#17
0:02, 15 янв. 2019

Жора Монтировка

> А нужно ли такое программирование?

Многие АСУТПшники по привычке таким страдают, в своё время других языков кроме LD и FBD не завезли :)

#18
(Правка: 2:49) 2:47, 15 янв. 2019

Жора Монтировка
> А нужно ли такое программирование?
Рекомендую почитать всю ветку, я достаточно подробно обьясняю зачем это нужно.

#19
4:09, 15 янв. 2019

san
Если прям совсем совсем нужно просто, то я предложу сделать конвейер, как на фабрике, только тут по "транспортерной ленте" движется переменная, каждый станок на пути меняет её, имея переключатель пути, можно сделать циклы.

#20
9:53, 15 янв. 2019

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

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

простейший пример, сорри формат С не знаю

Writeln('1');
Writeln('2');
Writeln('3');

For I:=1 To 3 do Writeln(IntToStr(I));

Если человек не знает, что есть блок For, то есть несколько путей решения
- Делать как знаешь
- Поискать как еще можно сделать и упростить

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

Если человек пошел по второму варианту, то как бы не было визуализировано, все равно человек будет знать что такое цикл.

Если пошел по первому варианту, то будь блок хоть 100 раз понятный он его не сможет применить.

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

p.s.
А как же wile, repeate?

#21
18:44, 15 янв. 2019

Предлагаю нанизывать объекты на нитку.
В этом случае цикл — это петля с объектами, в месте перекрестия надо разместить специальный объект, задающий число повторений.

#22
(Правка: 6:12) 5:40, 16 янв. 2019

FourGen
> пока человек не будет понимать назначение цикла, он не найдет его применения,

В моем случае человек может не иметь никакого понятия о цикле или алгоритме в целом. Для него это просто кубики или сферы расположенные в некотором порядке. Я назвал свою программу "Фрактальный Алхимик", именно исходя из того, что работа идет методом тыка, т.е это алхимия а не наука.
Дело в том, что никакой теории 3Д фракталов не существует и невозможно писать код заранее представляя себе результат - фрактальный мир получается практически непредсказуемым и зачастую зависит от малейшего изменения параметров.
Т.е. по идее юзер может вообще не видеть цикл как таковой, это может быть просто еще один предмет с параметром. Но тут есть один нюанс - все же мне надо как-то превратить набор предметов в код, а там важно знать, какие функции входят в цикл. Кроме того, мне часто надо иметь доступ к конкретному элементу цикла, я имею ввиду что-то вроде:
for (i=0; i<5; i++)
{
  a();
  b();
  if(i==2) c();
}

Значит я все же должен видеть весь цикл. Пока я думаю разворачивать циклы в двумерные таблицы. Ничего другое в голову не приходит. Тогда приведенный код можно представить как:
A . B .
A . B .
A . B С (вместо точки и торчит вверх)
A . B .
A . B .
Точка это узел к которому можно прицепить еще один обьект (функцию). Если их несколько, то они будут расположены на координате Z. Т.е линейный алгоритм представлен линией, цикл - плоскостью, а условие - размещается на третьей координате. Как то так.

>А как же wile, repeate?
Никак. Я же сразу сказал, что не замахиваюсь на визуальный С++ или HLSL. Задача намного скромнее.

#23
(Правка: 18:46) 14:40, 16 янв. 2019

>san
Эта задача совсем отличная от первоначальной постановка задачи, на мой взгляд.

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

Но если вопрос ставится в виде алхимии или типа того типа... мешай что хочешь...

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

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

(пока как выглядят элементы неважно)
и далее представляю себе комнату в VR:

- кидаю шарик цикл
- далее вопрос вообще все элементы можно на него применить?
- кидаю в него шарик условие
- допустим все проверки есть все неправильное игнорируется
- запускаю ок
- с этим все понятно
- что еще можно кинуть на шарик?
- можно кинуть элемент начала
- можно кинуть шаг
- можно кинуть конечный элемент
- можно ли элемент шаг применить к любому элементу? (например к переменной если да то тчто будет делать)
- задали все необходимые значения
- Человеку ПОФИГ что получится он не знает программирования
- (шарик условия закинутый в цикл пока не используется)
- допустим шарик цикл поменял свою форму и из него че-то отросло в виде каких нить шипов
- каждый шип это получается итерация цикла, но пока без данных
- закидываем во внутрь шарика цикл значения в шарик условие
- 1 то то
- 2 то то
- запускаем
- на шипе появился новый шарик или новый шип в сторону, в зависимости от того что за результат условия... (или выполнение новой команды, то шарик, если результат шип в сторону)
- соединяем этот боковой шип с новым шариком и тд

Напридумывать можно много но вот вопрос вложенности и сложности.
Что-то мне эти шарики нейронную сеть напомнили...

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

Ключевой момент: ЧЕЛОВЕК НЕ ЗНАЕТ ЧТО ТАКОЕ СТЕПЕНЬ :)

Дополню:
Если человек не знает что такое степень, но знает то что нужно получить.

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

Получится структура что то типа:

+ Показать

Только более разнообразная и разноцветная

Вчитался еще раз в последний пост:

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

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

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

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

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

#24
0:39, 17 янв. 2019

Была такая игра, где нужно составить программу для робота, чтобы провести его к выходу.
Программа набиралась из кубиков.
Каждый кубик означал простейшую операцию робота: сделать шаг, повернуться, толкнуть блок (активировать, повернуть выключатель).
Можно набор команд выделить в подпрограмму и закрепить за своей командой.
Так эмулируются циклы. Причём допустима рекурсия.

Ссылка с кратким описанием: http://skachat-besplatno.ru/games2/best-flash/programmiruem-robota.html

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

#25
7:05, 17 янв. 2019

san
Боюсь разочаровать, но в проекте системы виртуальной реальности были уже лет 50 как назад, а техническая реализация(в виде шлемов виртуальной реальности) как раз около 30 лет назад начала появляться.

#26
7:19, 17 янв. 2019

san
> Просто представьте что вы в виртуальной реальности и у вас нет клавиатуры, но
> надо написать программу. Причем любые библиотечные функции вам потенциально
> доступны ввиде 3Д обьектов. Вы можете двигать руками, у вас есть "лазерная
> указка" в каждой руке и на ней курок и джойстик (две степени свободы). Далее
> включайте воображение.
Ну вот. А не в виртуальной реальности, а в реальной - всё это реализовано через материю. То есть, чтобы в жизни написать программу, позволяющую листу бумаги планировать - нужно сложить его в бумажный самолётик и запустить. А дальше движок уже подхватит :)

#27
14:42, 17 янв. 2019

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

#28
19:02, 17 янв. 2019

DjeeZ
Это весьма нестандартный подход. Интересно.

#29
(Правка: 19:42) 19:41, 17 янв. 2019

san
> Например как визуализировать что-то вроде:
> for(i=0;i<10;i++)

Очевидно, исходя из:

Пусть набор охраняемых команд с построенной для него конструкцией выбора IF и предикат Р таковы, что


(Р and ВВ) ==> wp(IF, Р)

справедливо для всех состояний. Тогда для соответствующей конструкции повторения DO можно вывести, что

(Р and wp(DO, T)) ==> wp(DO, Р and non BB)

для всех состояний.

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумГрафика