Програмування перетягування з перетягуванням - воно літатиме? [зачинено]

Усі мови програмування, які я знаю, написані - тобто вводяться так чи інакше як довжини тексту. Але мені цікаво, чи є мова програмування, де можна просто перетягнути всю програму; щоб отримати цикл, ви вибираєте це поле тут і перетягуєте його до того розділу "коду" там і так далі. І якби подібного немає, він би летів, якби його винайшли?

Особисто я не вірю, що це була б така гарна ідея, але я хотів би почути, що ви думаєте.

Багато нарядів зробили системи програмування перетягування.

Національні інструменти "Labview" - це, мабуть, найвідоміший і найкращий.

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

Друга проблема, з якою вони стикаються, полягає в тому, що, коли ви постачаєте блоки спеціального призначення, необхідні першою проблемою, накладні витрати, переміщені між блоками, починають дорожчати. Я працював з однією дуже приємною такою системою під назвою Rippen. Коли я профайлював, щоб побачити, куди ми болимо на високошвидкісному додатку для обробки сенсора, я був дуже занепокоєний, побачивши, що приблизно 20% мого процесорного часу збирається на переміщення даних. (Оскільки я займався обробкою зображень LADAR, роблячи неабиякий фрагмент обробки з плаваючою комою на кожному пікселі вхідного зображення, 20% процесора було ВЕЛИКОБОГО руху даних, що рухаються.)

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

Проста відповідь - ні.

Що стосується програмування, то текстове введення значно перевищує з точки зору визначеної інформації, ніж її візуальну частину лічильника.

LabVIEW досить графічний.

З веб-сайту LabVIEW :

Yahoo! Труби - це, мабуть, прекрасний приклад графічної мови типу, який ви описуєте; ви перетягуєте примітиви (все від джерел даних, на які ви дієте, до циклів і умов), щоб створювати потік інформації через систему.

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

Раз у раз хтось придумує мову програмування або інструмент для перетягування або проектування, який збирається "покласти край програмуванню так, як ми це знаємо", і зробить усіх, хто використовує його, програмістом.

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

Реальні дисципліни програмування - це стільки про те, як знати, як вирішувати проблеми, розуміти, як моделювати процеси та організовувати дані для використання. Навіть розуміння того, що взагалі можливо з комп’ютером.

Є докази (якщо суперечливі), що дозволяють припустити, що деяких людей не можна навчити мислити таким чином, що приводить мене до пари цікавих і релевантних думок. Для початку, якщо ви не можете так подумати, то навколо є багато програмістів, тож ви завжди можете найняти когось, щоб реалізувати ідею, якщо у вас є така, і ви думаєте, що за це варто заплатити. Якщо ви можете досить добре працювати з логікою програмування, то ви можете навчитися справжній мові, а не возитися з відносно простим середовищем перетягування.

Я тут думаю про загальне програмування. Те ж саме не обов'язково застосовується у більш обмеженому сценарії типу DSL, де перетягування може бути дійсно корисним користувачам процесу, який є спеціалістами в цьому домені, а не ІТ-спеціалістами.

Найкраща система програмування перетягування, яку я бачив, - це для роботів Lego Mindstorms NXT.

Це дозволяє робити деякі досить дивовижні речі, контролюючи деякі досить складні функції.

Однак у якийсь момент вона виходить з ладу, і вам потрібно повернутися до іншої системи.
Дивіться цю статтю: http://www.wired.com/geekdad/2007/11/the-best-progra/

Цілком можливо, що якби це було вдосконалено, і в різних сценаріях, де було б задоволено, потреба в цьому стане все менше і менше.

Програмування потоків даних (також програмування на основі потоку) може бути своєрідним. Хоча програмування потоку даних не завершено Тьюрінга.

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

Ось прекрасний приклад, коли навіть миша не використовувалась для створення програми synth, а голими руками та маленькими кубиками: 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 з моїм другом, але у нас немає ніякого візуального редактора ще , тільки скрипт визуализатора.

Система програмування MIT Scratch майже повністю перетягується.

Схоже, схожий (і зараховує Scratch) програму Google Inventor Google .

Я б не хотів кодувати щось велике ні в собі, але для навчання "програмістському мисленню", Scratch чудовий. Це справжнє програмування, але з миттєвим візуальним задоволенням і блокуванням з'єднань уникнути великої кількості розладів "синтаксичної помилки", які відтягують новачків (погляд, який я бачу, перегукується в цій статті ). Намагання захоплювати маленьких дітей командним рядком python не припиняє цього дня.

Це вже існує, хоч можливо і не у формі, про яку ви думаєте. Два приклади - Сімулінк та Аліса.

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

Аліса, це інструмент для навчання програмуванню для дітей. Це дозволяє дітям отримувати задоволення від створення історій, перетягуючи дії та предмети на якусь дошку історії програмування.

Програф був класною мовою, яка все перетягувала. Також у Вікіпедії є стаття з переліком візуальних мов із хорошим розміром .

Існує досить багато мов візуального програмування. Телефонна система, якою я керував у великому телефонному центрі, була запрограмована за допомогою модулів перетягування. Мій дядько розробив систему Just-In-Time для проектування виробничих ліній, яка була повністю перетягнута, і це було 20 років тому.

Я навіть грав у бойову гру роботів на PS1, яка використовувала мову програмування перетягування.

Текстове програмування пройшло 50 років, але інженерія програмного забезпечення повинна перейти в графічну сферу, щоб вирішити наступний рівень складності. Наприклад, поява багатьохкорових процесорів та виклики паралельного програмування підштовхують модель нитки до своєї межі. Відверто кажучи, я вважаю, що програмне забезпечення просто зарозуміло, думаючи, що є щось принципово інше і особливе в програмуванні, яке не піддавалося б візуалізації, як і всі інші домени. Як і телефонні оператори та багато інших професій, правильна технологія автоматизації дозволить доменним експертам незабаром співпрацювати в багатих просторах моделювання систем, заснованих на знаннях. Програма програмного забезпечення давно назріла для зміни парадигми.