Программирование Drag-N-Drop - это полетело бы? [закрыто]

12

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

Лично я не верю, что это была бы такая хорошая идея, но я хотел бы услышать, что вы думаете.

gablin
источник
Никогда не говори никогда (ты сказал: «Я не верю, что это была бы такая хорошая идея») - может быть странная ситуация, когда самая странная идея может работать хорошо.
ern0
6
"Будет ли это летать?" Честно говоря, если бы я думал, что системы управления полетом на самолете, на котором я летел, были запрограммированы кем-то, кто занимается программированием с помощью Drag-n-drop, я мог бы не попасть на этот самолет. ; D
Гленатрон
Очень нравится этот вопрос, хотя хотелось бы, чтобы некоторые ответы были длиннее и глубже.
Николь
1
Ironman будет использовать его и летать! Но он не существует в реальном мире!
Маной Р
@glenatron - Так что путешествуйте на поезде ... Системы управления полетом - это, с одной стороны, конечные автоматы, которые построены графически, а с другой - инженерные системы управления, которые построены из базовых блоков и собраны в интерфейсах GUI. Остальное UML.
Mouviciel

Ответы:

23

Многие наряды сделали системы программирования перетаскивания.

National Instruments "Labview", пожалуй, самый известный и лучший.

Фундаментальная проблема, с которой они все сталкиваются, заключается в том, что не существует известного способа превратить Flying Code Monkey в опытного программиста и инженера. Как ОДИН пример, нет никакой разницы для Обезьяны летящего кода между процессом O (N ^ 2) или O (N ^ 3) и процессом O (N log N), что означает, что они должны быть снабжены постоянными процедурами для алгоритмы O (N log N), которые можно настраивать в соответствии с созданными ими быстрыми графическими кладжами.

Вторая проблема, с которой они все сталкиваются, заключается в том, что когда вы предоставляете блоки специального назначения, необходимые для первой проблемы, накладные расходы, связанные с перемещением данных между блоками, становятся дорогостоящими. Я работал с одной очень хорошей такой системой под названием Rippen. Когда я профилировал, чтобы увидеть, где мы страдаем от приложения обработки сенсора HIGH! -Required производительности, я был довольно обеспокоен тем, что около 20% моего процессорного времени уходит на перемещение данных. (Поскольку я выполнял обработку изображений LADAR, выполняя значительную часть обработки с плавающей запятой для каждого пикселя входного изображения, 20% ЦП было МНОГО накладных расходов на перемещение данных.)

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

Джон Р. Штром
источник
Теоретически вы можете использовать режим отладки и выпуска (оптимизированный).
Работа
15

Простой ответ - нет.

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

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

LabVIEW довольно графический.

С веб-сайта LabVIEW :

LabVIEW

Зик
источник
Да, это выглядит аккуратно. Сколько вы можете сделать с этим? Это специализировано только для одного вида "программирования", такого как физика, или вы можете использовать его для чего-нибудь?
Габлин
2
Да, есть профессионалы LabVIEW: lavag.org . Дискуссионные форумы: forums.ni.com . Erlang сравнение: bit.ly/2yC0Tn . Описание компилятора: bit.ly/c6quPK . Пример общего программирования: bit.ly/cSnt5D . Используйте в LHC: bit.ly/9Yp4oo . Это нишевый язык, используемый повсюду: ni.com/solutions . Это чертовски дорого, он пропускает абстракции влево и вправо, устанавливает массу необъяснимых сервисов и страдает от множества любопытных. Он кроссплатформенный, простой для распараллеливания и такой же легкий / сложный, как и любой другой язык.
Джо Z
2
Это работает роботы LEGO. ni.com/academic/mindstorms
rwong
1
@Zeke: Если ВП (эквивалент программы или функции LabVIEW) требует прокрутки в нескольких направлениях, значит, он написан неправильно.
oosterwal
1
@oosterwal: Ты прав, это обычное дело. Кроме того, язык довольно преднамеренно продается учёным и инженерам, так как его легко выучить. Хранится в небольших программах, это правда. Поскольку программы требуют большей сложности, код, как правило, выходит из-под контроля. (Изменить: Не из-за языка как такового, но из-за благих намерений пользователей. Полное раскрытие: я ученый несколько дней :)
Джо Z
6

Yahoo! Pipes - это, вероятно, прекрасный пример графического языка того типа, который вы описываете; вы перетаскиваете примитивы (все, от источников данных, с которыми вы работаете, до циклов и условных выражений) для создания потока информации через систему.

Это сильно зависит от предметной области, но это главное. Трубы ориентированы на данные, что делает визуализацию (а не выражение) первостепенной. Аналогично, учебные среды, такие как Scratch или Sprog! подчеркнуть визуализацию того, над чем вы работаете в качестве учебного пособия; эффективность ввода данных является гораздо более низким приоритетом в этой области.

радиоразведка
источник
Если бы больше разработчиков любительских веб-приложений знали о Pipes, мир стал бы лучше. +1
Спарр
3

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

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

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

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

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

glenatron
источник
Программирование - сложный, сложный и длительный процесс, требующий огромного труда инженера. Вот почему индустрия пытается сделать разработку приложений доступной для непрограммистов: снизить затраты на разработку, оптимизировать использование человеческих ресурсов. Кроме того, как программист, я могу сказать, что есть много задач, которые должны выполнять непрограммисты, но у них нет инструментов для этих задач, поэтому это должны делать программисты, которые 1. ненавидят делать такие задачи 2. дороги 3. не лучшие люди для этого. Итак, я горячо приветствую любую идею, которая указывает на это, например, визуальное программирование.
ern0
1
Я знаю, почему индустрия пытается это сделать. Но я хочу сказать, что если вы умеете программировать, вы программист, и люди, которые не умеют программировать, не смогут сделать это лучше, потому что существуют визуальные инструменты для выполнения тех же задач, которые в противном случае им пришлось бы писать код. за. Инструменты не проблема, проблема в том, что вы должны делать с ними.
Гленатрон
Я имею в виду программирование более либеральным. Это также программирование, когда вы указываете своей стиральной машине запустить стирку в течение 5 минут, сушить в течение 10 минут. Кто-то должен дать разные названия для разных программных «слоев». Программирование потока данных? Это создание электронных таблиц (без макросов)? Да, они есть, но также отличаются от так называемых программистов. Как бы то ни было, есть серьезные различия в том, что программисты делают, я имею в виду, перетаскивание модулей в SuperIDE12 ++ с помощью плагинов против кодирования ассемблера. Кроме того, это просто большая разница, если ваша платформа имеет GC. Или: скрипт VS компилятора. «Программирование» - слишком распространенный термин.
ern0
3

Лучшая система программирования с использованием перетаскивания, которую я видел, предназначена для роботов Lego Mindstorms NXT.

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

Однако в какой-то момент он выходит из строя, и вам необходимо вернуться к другой системе.
Смотрите эту статью: http://www.wired.com/geekdad/2007/11/the-best-progra/

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

Bravax
источник
Люблю Mindstorms (которая возникла из Lego Dacta, у которой было более традиционное кодирование [язык, похожий на Logo / Lisp]), изучал его в школе 15 лет назад. Отличный подарок для программиста, чтобы получить своих детей, если они есть.
Orbling
1
На самом деле NXT - это LabVIEW. Ну, LV, который был немного урезан: ni.com/academic/mindstorms
Джо Z
Я никогда не знал этого, спасибо! Я очень впечатлен этим.
Bravax
2

Программирование потока данных (или программирование на основе потоков) может быть своего рода. Хотя программирование потока данных не является полным по Тьюрингу.

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

Вот хороший пример, когда даже мышь не использовалась для создания приложения для синтезатора, а голые руки и маленькие кубики: http://www.youtube.com/watch?v=0h-RhyopUmc

Статьи Википедии - хорошая отправная точка: http://en.wikipedia.org/wiki/Flow-based_programming http://en.wikipedia.org/wiki/Dataflow_programming

Генерация звука является типичной областью программирования потоков данных. Существует несколько систем с открытым исходным кодом: http://www.synthedit.com/ http://alsamodular.sourceforge.net/

Если у вас Mac, у вас может быть предварительно установленный на заводе Quartz Composer: http://developer.apple.com/graphicsimaging/quartz/quartzcomposer.html

Я также сделал систему DF с моим другом, но у нас нет никакого визуального редактора еще , только скрипт визуализатора.

ern0
источник
3
Почему вы считаете, что программирование потока данных не является полным по Тьюрингу?
oosterwal
Игра с коробочными соединениями не завершена. Написание компонентов завершено по Тьюрингу (обычно нет никаких ограничений, только структура DF, которая должна использоваться для связи с другими компонентами).
ern0
1
Основное аппаратное обеспечение любого процессора - это в основном поток данных. Как эта полная конструкция Тьюринга может привести к полной системе Тьюринга?
Mouviciel
@mouviciel Моей первой реакцией было «нет, процессор - это не поток данных», но это так. В любом случае, это плохой пример для систем потока данных; плохой дизайн. Существует только один исходный компонент (внешние / внутренние часы), который запускает компонент ЦП для обработки следующей инструкции. Даже если мы считаем другие компоненты, например аудио, видеокарту, систему DMA и т. Д., Компонентами, это все же плохой дизайн: компоненты слишком большие и слишком специализированные. Но идея хороша, может быть, это способ повысить производительность / универсальность, создать компьютеры с небольшими блоками и соединить такие компоненты, как компоненты потока данных? Пахнет как патент :)
ern0
2

Программная система MIT Scratch практически полностью перетаскивается.

Google App Inventor, похоже, похож (и приписывает Scratch).

Я бы не хотел кодировать что-либо большое в себе, но для обучения «мышлению программистов» Scratch превосходен. Это реальное программирование, но благодаря мгновенному визуальному удовлетворению и блокам, объединяемым воедино, можно избежать многих неприятностей, связанных с «синтаксической ошибкой», которые отталкивают новичков (вид, который я вижу в этой статье ). Попытка увлечь маленьких детей командной строкой python в наши дни не сработает.

timday
источник
1

Это уже существует, хотя, возможно, не в той форме, о которой вы думаете. Два примера - это Симулинк и Алиса.

Simulink - это графическое средство построения динамических систем моделирования. Хотя большинство конструкций более сложны, чем то, о чем вы обычно думаете, как о программировании, такие вещи, как for и if, все еще могут быть построены графически. Simulink представляет собой большую проблему в аэрокосмических приложениях, поскольку правительство и многие крупные компании делают свои первоначальные проекты в Simulink, а затем применяют те или иные средства проверки теорем к «коду» Simulink.

Алиса, инструмент для обучения программированию для детей. Это позволяет детям получать удовольствие от создания историй, перетаскивая действия и объекты на своего рода программную доску.

Джон Берриман
источник
1

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

жестяной человек
источник
Не могли бы вы немного рассказать о том, что есть у каждого из этих ресурсов, и почему вы рекомендуете их как ответ на заданный вопрос? «Ответы только на ссылки» не очень приветствуются на Stack Exchange
gnat
0

Существует довольно много визуальных языков программирования. Телефонная система, которой я управлял для большого центра обработки вызовов, была запрограммирована с использованием модулей перетаскивания. Мой дядя разработал систему Just-In-Time для проектирования производственных линий, которая была полностью перетаскиваемой, и это было 20 лет назад.

Я даже играл в боевую игру роботов на PS1, в которой использовался язык перетаскивания.


источник
Carnage Heart, была классная игра.
Обезьяна
Это тот, я не мог вспомнить имя. Мне понравилась эта игра. Очень умный дизайн.
-1

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

user9196
источник
2
Здесь я бы категорически не согласился: сложность многих реальных программ слишком высока, чтобы их можно было полностью представить графически. Все люди, которых я знаю, кто (1) знал, как программировать и (2) использовал LabView для более крупного проекта, обнаружил, что графическое представление слишком тяжелое для продуктивной работы над более крупными проектами. Конечно, LabView очень удобен, когда ваша программа помещается на одном экране; но когда ваша программа начинает выходить за пределы одного экрана, LabView становится трудно использовать эффективно (простой текстовый поиск не нужен, перестановка блоков болезненна…).
Эрик О Лебиго