Comments 117
Все инструменты которые используют визуальное программирование обычно заканчивается на простых сценариях. Как только требуется что то сложнее пары if, всё — визуальное программирование заканчивается, начинается костылирование в виде всяких скриптов и прочей шняги. А контроль версий для визуального программирования это та еще муть.
сильно изменился? Я имею в виду принципиальную разницу между, скажем,
машиной ЭНИАК и современным компьютером у Вас на столе. Так ли серьезна
разница этих двух бинарных цифровых автоматов? Вот по этой причине, имхо,
ничего принципиально не меняется и измениться не может. Пока.
Возможно — потому что машины не изменились, у нас все та же архитектура, восходящая к Фон Нейману, уже десятки лет, не могу этого исключать. Возможно что пока — тоже не могу исключать. Но пока новых идей нет — нет никакого повода рассчитывать, что визуальное программирование или его очередное поколение «ближе чем кажется». С чего бы? На какой такой новое базе оно вдруг будет построено? Какие признаки на это указывают? На мой взгляд — никаких.
Но, естественно, программирует на уровне дворника.
Ну, чисто теоретически, некоторые формы записи алгоритмов, скажем, в виде графа, могли бы оказаться проще. Но именно могли бы, в сослагательном наклонении, потому что на практике это почти ни разу не взлетело. Есть редкие исключения из правила, не более того.
Но результат в том, что появился новый уровень абстракции, для лучшей передачи дизайнерской задумки вместе с какими либо динамическими элементами для последующей их разработки.
Теперь дизайн может включать в себя заложенную логику поведения сетки, лейаутов, готовых к копированию изингов и ассетов для разработчика.
Это расширение возможностей, а не замена одного на другое
Как только требуется что то сложнее пары if, всё — визуальное программирование заканчивается, начинается костылирование в виде всяких скриптов и прочей шняги.
Это сегодня такое состояние темы (акулий плавник.задний скат).
ЕМНИП, в 1996 году, а то и раньше, IBM выпустила VAC — Visual Age for C, который был доступен для IBM OS/2 3.x (Warp, Connect). Это было реально пионерское решение для визуального программирования графического пользовательского интерфейса любой мыслимой на тот момент сложности. В основе его лежала технология на основе слотов и сигналов — отдельные элементы которой спустя десять лет стала использовать Trolltech в своем фреймворке Qt.
На то время существовали разного рода утилиты для компоновки окон из базовых виджетов (в мире PC/AT и PS/2 это назвалось «controls»). В результате появлялись файлы, в которых эти контролы перечислялись, именовались, размещались и между ними устанавливались иерархические связи. Что-то типа нынешнего QT-дизайнера, разве только немного попроще, но по сути все то же самое.
VAC же помимо всего этого предлагал графический редактор, которой позволял как для отдельных контролов, так и для их иерархий назначить слоты и сигналы, развести сигналы по слотам как по умолчанию, так и кастомно, а также крайне гибко фильтровать сигналы в зависимости от состояния контролов. В результате формировался проект, все исходники которого были на 100% сгенерированы автоматически. Проект этот без каких-либо проблем собирался и запускался. Из полученной схемы можно было, ткнув мышкой в слот, сигнгал и прочий элемент, открыть нужные исходники в нужном месте, посмотреть и поработать руками, если не устраивало то, что предлагалось. Реально весь UI-функционал делался без явного кодирования. Работало такое приложение прямо поверх PM (Presentation Manager — аналог виндового gdi32) без каких либо промежуточных слоев, в связи с чем достигалась заявляемая IBM отзывчивость — менее 0.1 c на консольное событие.
Наверно нельзя говорить, что программирование "устарело", на мой взгляд это все равно что "математика устарела"
Для выполнения каких-то действий надо их описать. Компьютер же тупой :) Он выполняет программу. Да, программы погребены под все большем количеством абстракций призванных облегчить понимание человеком, но и только. Поэтому программирование будет всегда.
Декард совершил просто невероятную революцию.Позвольте, но Декарт.
у нас есть мат-аппарат, вычислительная мощность, новые подходы и специалисты, чтобы создать тулы.
Бизнесу нужно прямо сейчас выполнять свои задачи, как можно эффективнее (и по времени, и по расходам). Эти все новые подходы только в очень специфических областях приживаются понемногу, а в массе — слишком ново (= рискованно), слишком мало людей и слишком дорого внедрять…
Это как назвать все машины с ДВС устаревшими, потому что потихоньку начинают использовать электрокары. В отдельных сценариях — возможно, в полном смысле — всё ещё не устарели.
Я могу придумать только мат. доказательства для каждого алгоритма, что он безопасный и делает именно то, что нужно — но это звучит примерно как «а давайте расширим штат разработчиков в 5 раз, при этом все новые работники не буду ничего создавать, а только проверять уже написанное имеющимися», что подойдёт только особо-критичным областям.
TDD подразумевает YAGNI/KISS, что может аукнуться в перспективе. А ещё про тесты для тестов не забывать, да. И тесты тестов тестов (не призываю полностью отказываться, но 100%TDD проектов я ещё не встречал).
DSL в каждую задачу? Для каждой области деятельности свой специфичный язык? (опять таки проект из первого пункта).
Проверки в Rust не дают выстрелить в ногу явно, но от кривой логики это не спасает (банально забыть инвертировать значение проверки в важном условии). Прямо сейчас есть куча статических анализаторов, которые проверят то же самое в других языках.
Про «луковичную архитектуру» и «аспекты из ерланга» ничего не скажу, потому что не представляю их замысла.
И всё это не новые подходы, они уже довольно давно есть и могут применяться при наличии желания и возможности. И я всё же не соглашусь, что всё это должно быть везде.
И как визуализировать бизнес логику?
Про UML диаграммы слышали что-нибудь?
Я лично к визуальному программированию отношусь сугубо скептически, но что нельзя визуализировать бизнес-логику это перебор.
Поддерживаю. Реальный проект получается ну с очень огромными диаграммами. Тяжело поддерживать, тяжело разбираться. Обычно выпускается версия для старта и на этом все. Дальше ну очень редко используется цикл UML -> реальный код.
Еще раз, я против чтобы кодирование заменяли диаграммами. Но и утверждение про невозможность визуализировать бизнес-логику также неверно.
Тогда вопрос — как идет работа с системами контроля версий. Вот внесли два разработчика в двух разных ветках изменения в одну диаграмму. Пускай даже не конфликтующие (т.е. один — в одном углу, другой — в другом). Как происходит слияние веток?
Полностью вручную. Кто-то садиться и делает merg ручками, увы :(
И знаете, что смешно — что много лет назад этот инструмент все еще популярен среди тех, кто продолжает работать с той платформой для «визуального программирования». Потому что визуальный diff и merge так и не появился.
А такие как правило и пишут подобные тексты. То что визуально нарисовать UI проще, чем закодировать — это одно. Но путать это с логикой — как раз свойственно дизайнерам.
И как визуализировать бизнес логику?
А может показать фрагмент как это выглядит сейчас?
Но можно совершенствовать сами языки программирования и среды разработки.
Я уже писал, что для выразительности кода не хватает операторных символов (а их набор ограничен ASCII ввиду его общедоступности на любой клавиатуре мира). Это скорее всего уже нереально изменить.
А вот сам дизайн языков должен быть более похожий на «языки разметки», то есть такой, чтобы среды разработки могли максимально легко проводить парсинг «на лету» и трансформировать части кода в какие-то визуализации.
100%. Я когда начинал изучать ПЛИС, тоже по старинке все рисовал, как электронную схему. Пока не пришлось моделировать межсоединение 50 с чем-то блоков. Мало того что схема стала нечитабельна, так из-за того что выводы одного блока вливались в качестве шины в другой блок, стало просто не возможно уследить за битами и именами шин. А вот текстом просто пишем generate block, и все куда наглядние.
Вообщем за графикой осталось лиш топ схема (процессор, pll, i/o, sdram и тд).
Рассказ о визуальном программировании без упоминания LabVIEW (на котором написана куча промышленных систем, вплоть до системы управления Большим адронным коллайдером) и PLC. Сразу видно, что писал эксперт.
Рассказ о визуальном программировании без упоминания LabVIEW
От которого все нормальные программисты плюются
БАК не управляется с LabVIEW. Понятное дело что моделирование могло быть в чем угодно, но в железе там лабвью быть не может. И данные там тоже не матлабом обрабатывают.
Вообще лабвью не язык программирования, т.к. для решения всего спектра задач все равно надо расчехлять матлаб.
1. Похожая тематика — в автоматике широко применяются релейные схемы и языки программирования контроллеров LAD/FBD и — это, так или иначе, визуальное воплощение релейных схем
2. Условно низкий порог вхождения. Инженер, способный начертить схему запуска двигателя с самоподхватом на реле и контакторе + 2 кнопки Пуск и Стоп, вполне сможет эту схему написать и в контроллере на LAD, после небольшого обучения.
3. Относительная легкость отладки. Много где в автоматике применяются дискретные сигналы и их удобно отслеживать визуально в отладке — пробежался глазами по подсвеченной цепи и сразу увидел, какое реле не замкнулось, когда нужно, а какое — наоборот — замкнулось, когда не надо.
4. Это все актуально для несложной логики. Там где используются сложные алгоритмы, там, конечно, уже используются языки высокого уровня
В том же NodeRED казалось бы тоже куча визуальных компонентов. Но все равно, нет да нет приходится писать скрипты. Так как так проще, чем создавать волосатую тварь ))
Трудно победить программирование. Так как оно формальнее. При создании диаграмм больше отвлекаешься на эстетику пытаясь упорядочить все, что бы не превратилось в лабиринт. обычный код IDE научились форматировать, могут предсказывать, что тебе хочется и подставлять. Не говоря уже о том, что можно массово менять код в файлах и прочее.
Почему книги все еще пишут текстом? Давно надо было перейти на визуальные образы — пиктограммы. Вместо слова "человек" рисуем человечка. Сразу проявляется как минимум два огромных преимущества: во-первых, подобный "текст" может писать и читать человек, не умеющий читать и писать. Во-вторых, пропадает языковой барьер — повествование может написать японец, а русский сможет его читать без перевода.
Для обычного рукописного текста эволюция шла в противоположном направлении — сначала было пиктографическое письмо и только потом появилась классическая письменность. И никого не беспокоило, что ей надо учится.
Хотя мне жалко, что Дельфи-подобные среды, где интерфейс можно нарисовать мышкой, сейчас что-то маргинальное. В свое время было удобно — набросал контролов, описание формы сгенерировалось автоматически.
Qt Creator — вполне современная и часто используемая среда с редактором форм. В отличие от дельфей позволяет задавать layout, в котором контролы могут перемещаться автоматически и менять размеры при изменении размеров формы во время выполнения программы.
В дельфи же то же самое. Например в FGX
Дельфи-подобные среды, где интерфейс можно нарисовать мышкой, сейчас что-то маргинальноеТак кажется возможно потому, что почти весь десктоп уехал в веб. Но есть ещё мобилки, где этот подход живее всех живых.
Scratch++ ?
Преимущества графических интерфейсов перед текстовыми очевидны. С ними легко работать, они эффективны, красивы, и при этом способны дать пользователю все необходимые ему возможности.
Ну да, конечно.
16 мая 2007 Создан язык программирования для детей в возрасте 8 лет и старше. — Blockly, Build, Scratch ему понравился…
Ладно «нескучный» интерфейс накидать,
но потом они калькулятор 2*2 на electron «программируют».
Почему-то ждал про квантовые алгоритмы....
Я пробовал использовать Automate — приложение для Android для скриптования действий на телефоне, использующее графическую среду программирования, в которой рисуется блок-схема, а параметры каждого блока задаются в его свойствах.
Что можно сказать о сравнении такого программирования с традиционным:
1) традиционным способом программы пишутся гораздо быстрее. Гораздо быстрее набрать на клавиатуре if(x>y), чем выбрать пункт "добавить блок", потом открыть категорию "General", там блок "Expression true?", потом в свойствах, в разделе "input arguments" ввести x>y, потом ещё пририсовать оба выхода от этого блока…
2) на блок-схеме не видны все параметры функции, в отличие от текста программы. Нужно ходить по свойствам каждого блока. Текстовое представление программы более плотное.
Вывод: для профессионального программирования такие системы не годятся, только для обучения или для написания небольших программ (скрипты для мобильных телефонов, где заданы условия или события, и несколько действий в качестве реакции — как раз хороший пример такой среды). На мобильных устройствах это ещё может быть удобнее из-за интерфейса ввода в виде сенсорного экрана, на компьютерах же самый удобный интерфейс ввода — это клавиатура, ориентированная на ввод текста.
На мобилках программировать в принципе не удобно, а на десктопе доступны hot keys
У визуального программирования есть обманчивая простота. Создаётся впечатление, что раз это визуальная вещь, можно легко и непринуждённо с помощью одной мышки написать что угодно. По факту, приходится постоянно пролистывать огромное количество компонентов-элементов и их настройки и ещё приходится запоминать, в каком подразделе какого поддерева каталога элементов находится этот компонент, чтобы его вставить. А пока ты листаешь список компонентов, ты видишь названия других компонентов, неосознанно оцениваешь их, и у тебя мелькают мысли, как их можно использовать. Это, в итоге, рассеивает внимание и снижает продуктивность.
С чисто с когнитивной точки зрения, визуальное программирование хуже, чем кодинг, поэтому оно не станет новым поколением. Оно помогает только снизить требования по знаниям для входа в программирование вообще.
- Половина примеров из статью, когда визуальный процесс заменяет текстовое программирование — построение UI. Вообще-то уже очень давно интерфейсы и так можно мышкой накидывать.
- Визуально редактировать числа в коде — любопытный концепт. Жаль, что на создании каких-то визуализаций потенциал и заканчивается (потому что уже на подкручивании параметров условной substr начинаются проблемы) — и это не говоря о том, что даже строки так не поредактировать, тем более саму логику.
- Blueprints в UE4 и прочие аналогичные средства — не более чем Lego из готовых блоков, для очень конкретных областей. Если вдруг понадобится нечто, чего не позволяют готовые блоки — то придётся свои собственные либо так же создавать кодом, либо лепить макро-блоки из существующих (и далеко не везде это доступно), что та ещё боль.
- Создание запросов в БД — мало того, что очень специфичное «программирование», так ещё и выглядит как «нажми 50 раз мышкой и введи 50 символов» против «введи 100 символов»
Что же касается реальных случаев использования — ну вот, например Jira позволяет искать таски в «простом» условно-визуальном режиме (ввести или выбрать поле, а потом ввести или выбрать значение) или же в «продвинутом» только-текстовом режиме, с автодополнениями. Всё моё окружение, кто хоть насколько-то периодически пользуется поиском выбирают почему-то продвинутый.
Может быть это конкретная реализация так себе, а может просто так лучше.
Визуальное программирование взлетело во времена Delphi, который давал возможность быстро накидать интерфейс, задать свойства визуальных объектов, и добавить к ним код в виде событий. И это отличный баланс между визуальным и текстовым программированием.
А следующий этап будет, когда к текстовому и визуальному добавится аудиопрограммирование. Ведь что такое программа? Она задаёт некоторые данные и действия с ними. Вот для задания действий (отдачи команд) люди издавна использовали голосовые команды.
нет, delphi не имеет никакого отношения к визуальному программированию, т.к. визуально ничего не кодируется. Задаются свойства компонентов, но и только. Весь функционал пишется н обычно ООП.
Визуально задаётся графический интерфейс, а также дата-модули с описанием данных, сервера и клиенты TCP/IP и проч. компоненты, не относящиеся к графическому интерфейсу напрямую. Это немалая часть программного продукта. При желании всё это можно описать и инициировать в коде, что есть плюс для нестандартных ситуаций.
Но это было придумано давно. Я же пишу о действительно переломном этапе в программировании, который придёт, когда IDE начнёт распознавать голосовые команды, правильно интерпретировать и сохранять в виде программы.
И какой это перелом?
Голосовой ввод доступен везде, с нормальным уровнем качества. Вперёд.
Лично по мне, руками быстрее, точнее, удобнее. Да и горло луженое понадобится.
Или речь про команды типа "Сделай хорошо" или "Напиши мне сервер новой соцсети"?
Я имел ввиду нечто между простым надиктовыванием текста программы, и "Сделай хорошо". Т.е. чтобы у IDE были некие зачатки интеллекта, позволяющие правильно интерпретировать и накидать основу программы путём надиктовывания команд. Типа такого:
- создать новый проект для Win64.
- добавить модуль данных, СУБД используем MySQL. Добавить соединение с БД такой-то, расположенной там же, где и база предыдущего проекта.
- Создать форму идентификации пользователя по имени и паролю, данные хранить в таблице Users. Показывать эту форму при запуске программы.
- Добавить в проект REST-сервер…
Ну и т.д. IDE должно распознавать сотни и тысячи программных сущностей (модули, классы, методы), уметь их правильно инициировать, связывать между собой, как указывает программист. Помогать отлаживать и деплоить готовую программу. Должно запоминать ранее выполненные проекты, и брать оттуда готовые сущности по команде. Уметь редактировать, заменять и удалять программные сущности по команде… Вот такое я назвал бы следующим поколением в программировании.
Во-первых, «графический интерфейс пользователя» намекает на то, что с UI работает конечный пользователь-человек, который с помощью компьютера решает свою собственную проблему. Его не интересует, как эта чертова машина работает внутри, хоть там под капотом живут волшебные гномики и исполняют мои приказы. Упрощение UI для пользователя — это решение проблемы использования компьютера, а не программирования.
Во-вторых, из деятельности программирования можно вычленить огромное число этапов, которые не являются созданием алгоритмов. Тут и построение лейаутов, и прототипирование UI, и собственно дизайн, и визуализация данных, и многое другое. То, что из сложного программирования смогли вычленить гораздо более простые этапы и решить их более простыми способами с меньшими требованиями к работнику, это замечательно. Но собственно программирование при этом не перестало быть «текстовым».
В-третьих, есть большое число сторон программирования, которые бывает полезно визуализировать. У нас есть и UML-диаграммы разных видов, и флеймграфы, и doxygen с извлечением разнообразной информации из исходного кода. Но это всё суть производные программирования, дополнения и продолжения, а не замены. Они играют роль не замены программирования, а в некотором смысле моделирования, построения модели — мы берем сложный алгоритм, выделяем в нем какие-то важные для обсуждения вопросы (например, связи между классами или модулями), отбрасываем несущественные детали и работаем с моделью. Модель помогает думать о «реальности» (т.е. программе), но не заменяет собой реальность.
Будущее языков программирования я вижу так — каждое новое поколение языков больше похоже на человеческий
Например:
ассемблер более человеческий чем машинный код
си более человеческий чем ассемблер
питон более человеческий чем си
*следующее поколение* более человеческое чем питон
Думаю в будущем будут какие то трансляторы в высоко-уровневые языки с человеческого
что то вроде natural language shell
Будущее языков программирования я вижу так — каждое новое поколение языков больше похоже на человеческий
История языка описания математических формул как-то не дает уверенности в подобном развитии языков программирования.
Там как раз начинали с обычного человеческого, а дошли в итоге до совершенно "нечеловеческого" языка математических формул.
Так что разве что какой простенький язык для простых смертных, программирующих кухонную технику, станет человеческим.
А язык программирования для специалистов скорее станет совсем "нечеловеческим".
DSL должны уметь описывать вообще все возможные операцииВ одной какой-то области необходимых операций не так уж и много, но важно другое — все они понятны человеку, который является спецом в этой области и в то-же время не является программистом. То есть DSL это не синоним слова «простой», но синоним слова «понятный».
Кстати, при повсеместном использовании DSL вырастут пороги при переходе между разными областями разработкиКонечно, и это правильно. Как сейчас, например, порог при переходе между профессиями выше, чем 1000 лет назад.
Кстати пороги могут и не так сильно вырасти, если внутри всех DSL будет условно один и тот же ЯП.
Конечно, и это правильно. Как сейчас, например, порог при переходе между профессиями выше, чем 1000 лет назад.
Ну вы сказали.
Профессии же не просто так усложняются. Производство тоже сложнее.
Даже 50 лет назад связь в каждом кармане с всемирной библиотекой знаний (на самом деле, где подавляющее большинство — пустой трёп) — было фантастикой.
Когда-то у меня была мечта: описывать классы программы в графическом представлении.
Представьте, открываете программу, которую делал кто-то другой и которую делали вы сами, но позабыли. А в ней помимо текста программы и папок проекта обязательно есть несколько диаграмм, на которых разработчик разместил описания классов с комментариями как это работает, показал важные связи, раскрасил и сгруппировал на пространстве диаграмм классы по их назначению.
Начинаем работать, глаз быстро запоминает компоновку диаграмм. Допустим, нам нужно добавить некую новую фитчу — а глаз помнит, что этот функционал был где-то справа сверху основной диаграммы. Начинаем думать, что придется доработать — какие классы придется расширить, какие добавить. При этом перед глазами не один экран кода или дерево папок проекта а диаграмма. Доработали, классы изменились на диаграмме, подправляем диаграмму, поясняем как это теперь работает в комментариях на диаграмме.
Эти мои мечты не сбылись — достаточно удобного инструмента для подобного визуального программирования в IDE так и не появилось. Может быть все кто пытался его сделать (вроде VS Class Designer) убеждались, что это слишком сложно, нестандартно, непрактично и останавливались на половине пути.
Хотя, где-то в 2003-ом я пробовал рисовать диаграммы UML с автогенерацией кода C++ по ним, и мне показалось, что это почти работает.
В реальном проекти этих классов пара сотен и у каждого десяток-другой методов(если не больше). Да и вы к конкретному классу возращаетесь гдето… раз в год. А еще у вас проектов штук 5. Ничего вы не запомните таким методом.
А обычный текстовый поиск будет усложнен.
В реальном проекти этих классов пара сотен
Это и есть мелкий проект. В реальном проекте их их тысячи. Вот у меня под руками сейчас, если брать со всеми внешними библиотеками — так там сотни тысяч индивидуальных классов набирается.
Это все классно, пока вы работаете на супер-мелком проекте.Не совсем так. Во первых, любой крупный проект имеет логически разделенные модули. Не бывает пары сотен важных классов в одном модуле, скорее эту будут довольно однообразные классы, которые нет смысла рисовать на диаграммах. Диаграммы рисуем там, где нужно проиллюстрировать и пояснить дополнительно как устроен модуль, т.е. показать концепцию, если она не очевидна.
Во-вторых, то что я описывал хорошо для модулей, в которых алгоритмы достаточно сложные а классов не так много. Т.е. открываем модуль, в модуле скажем 20 000 строк, и он состоит из нескольких десятков классов, взаимодействующих друг с другом для решения задач.
Представьте себе, что вы имеете дело с кодом графического редактора или кодом некого сервиса, что-то моделирующего, возвращающего ответы, извещающего об изменениях. Есть много задач, для которых хочется нарисовать диаграмму в 2D пространстве а не разложить классы по папкам.
А еще у вас проектов штук 5.Тогда тем более диаграммы хорошо. Обращаясь к проекту надо вспомнить как в нем что работает. Диаграмма — самый подходящий способ освежить в памяти что там вообще творится. Если в проектах все однообразно и ничего особенного нет, тогда не нужны и диаграммы.
Любой кто сталкивался с блюпринтами в UE знает целую кучу их проблем по сравненисю с кодом.
А ведь там идеальная реализация визуального программирования, сложно придумать лучше! А уж если плагинов-улучшайзеров из маркета навесить…
Скорее программирование вообще пропадет как род деятельности, нежели визуальное программирование заменит код.
Был изобретен в СССР, использовался при разработке и испытаниях космических кораблей «Буранов».
ru.wikipedia.org/wiki/ДРАКОН
Интересовался я у него в связи с тем, что «дураконовцы» до тех пор не смогли создать нормальный транслятор, несмотря на «предоставлениеь пользователю языковых средств, которые заставляют человека мыслить продуктивно, облегченное межотраслевое и междисциплинарное общение между представителями разных организаций и
за счет использования когнитивно-эргономического подхода к проектированию»
собственно, и сейчас создаваемые этнтузиастами, хм, «продукты»… впрочем, посмотрите на них самостоятельно.
С ними легко работать, они эффективны, красивы, и при этом способны дать пользователю все необходимые ему возможности.
Но ведь все наоборот — GUI это совершенно неудобно. Т.е., когда ты лениво лежишь на диване и клацаешь вкладочки в браузере мышкой — это да, удобно. Но для сконцентрированной програмистской работы как раз таки текстовый интерфейс и шорткеи оказываются намного удобней. Ввести короткую команду в терминал или нажать шорткей намного быстрее чем елозить курсором по экрану выбирая нужную команду в нужном подразделе меню, или перетаскивать что-то там куда-то там.
Возить мышкой по слайдеру чтоб изменить значение переменной в коде? Это ужасно неэргономично.
Полностью визуальный редактор для игр Klik & Play появился еще в 1994 году. Логика описывается в виде списка "если-то", где условия и действия выбираются мышкой из выпадающих списков.
Концепция была довольно жизнеспособная: движок до сих пор развивается и имеет актуальную версию. В первой половине 2000х вокруг него было активное международное сообщество. Небольшая группа наиболее активных участников отпочковалась и сделала свой клон — Scirra Construct, работающий на том же принципе.
Основная проблема, как уже было сказано выше — нелинейный рост сложности. Делать банальные игры легко, а вот что-то более сложное — уже очень сложно, и механизмы движка вместо помощи начинают мешать.
З.Ы. Я уж думал про программирование с использованием ии, или хотя бы чуть по свежее тему чем визуальное программирование про то, что все пересядем на фреймворки расскажут. А тут только получил вьетнамские флэшбеки вспомнив про опыт workflow foundation.
З.З.Ы зашёл на оригинал статьи, автор разраб в стартапе, который впаривает революционный nocode тул для js, nuff said, как говориться. Я понимаю, что в корпоративный блог надо постить регулярно, но статей то не мало, можно же как-то не совсем мусор то переводить, за ваш труд перевода же тоже обидно.
Новый уровень программирования не в том, чтобы визуально что-то настраивать, а в том, что компьютер сам умел компоновать блоки кода друг с другом (с пониманием смысла, что они делают), этакая постоянная динамическая перегенерация и композиция (друг с другом) классов кода на основе каких-то базовых классов/шаблонов.
Write computer programs.
Derivation — early 17th century (in the sense ‘written notice’): via late Latin from Greek programma, from prographein ‘write publicly’, from pro ‘before’ + graphein ‘write’.
Программировать, написать коды и инструкции для машины, которые автоматизируют выполнение задачи.
Писать компьютерные программы.
Происхождение — ранний 17 век, от Латинского и Греческого programma, от prographein, «Писать для публики», от pro — «перед», graphein — «Писать».
Не вижу никаких проблем в том, чтобы писать то, что должно быть написано, а не намалёвано.
Теперь вернёмся в наши дни. Мы постоянно взаимодействуем с компьютерами, в общем-то забывая о том, что было время, когда не существовало графического пользовательского интерфейса. Можете себе представить работу с iPhone в условиях, когда вместо того, чтобы перемещаться по приложениям и взаимодействовать с ними, используя касания экрана и жесты, приходится вводить команды с клавиатуры?
Достаточно странно то, что программирование компьютеров до сих пор осуществляется именно так. В этом мы недалеко ушли от первого Altair 8800 и от телетайпа. Мы вводим команды в консоли и передаём структурированные текстовые инструкции компиляторам или интерпретаторам.
Буквально сегодня:
habr.com/ru/news/t/540260
«Пилот F-35 пожаловался, что тачскрины вызывают ошибки, физические тумблеры были надёжнее»
Если человек не является профессионалом — то тачскрин вполне хороший интерфейс.
Но он ограниченный.
Плюс у роботов разовьется тонкая механика, и «повторяй за мной» автоматизирует многие процессы.
Это не то что бы следующее поколение программирования, просто дополнение парадигмы
Следующее поколение программирования ближе, чем кажется