Информация

Дата основания
Местоположение
Россия
Сайт
ruvds.com
Численность
11–30 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 117

Все инструменты которые используют визуальное программирование обычно заканчивается на простых сценариях. Как только требуется что то сложнее пары if, всё — визуальное программирование заканчивается, начинается костылирование в виде всяких скриптов и прочей шняги. А контроль версий для визуального программирования это та еще муть.

Причем это уже много десятков лет так. И ничего принципиально не меняется — потому что новых идей в общем-то не появилось. Только новые статьи такого вот типа регулярно появляются…
Хорошо, программирование — это такая «субъектная» деятельность. А объект
сильно изменился? Я имею в виду принципиальную разницу между, скажем,
машиной ЭНИАК и современным компьютером у Вас на столе. Так ли серьезна
разница этих двух бинарных цифровых автоматов? Вот по этой причине, имхо,
ничего принципиально не меняется и измениться не может. Пока.
Я говорил не о программировании вообще, а о попытках заменить его «визуальным программированием». И в этом смысле никаких новых идей именно в области визуального программирования не появилось.

Возможно — потому что машины не изменились, у нас все та же архитектура, восходящая к Фон Нейману, уже десятки лет, не могу этого исключать. Возможно что пока — тоже не могу исключать. Но пока новых идей нет — нет никакого повода рассчитывать, что визуальное программирование или его очередное поколение «ближе чем кажется». С чего бы? На какой такой новое базе оно вдруг будет построено? Какие признаки на это указывают? На мой взгляд — никаких.
Почему? Вон GPT-3 появилося.
Но, естественно, программирует на уровне дворника.
А вы считаете, что оно все перевернет? И почему?
Врятли. Это пример «новой идеи».
Погодите, а разве GPT-3 это вообще про визуальное программирование? Ну в смысле, как новая идея в программировании вообще это вполне годный пример, обработка естественного языка на новых принципах. Но к визуальному программированию это вроде вообще отношения не имеет, или я чего упустил?
Более того, непонятно с какой радости визуальное программирование должно быть легче, чем, скажем так, текстовое. Сложность логики то от этого не меняется, всё равно нужно чётко её задать. Более высокие абстракции? Так и текстом уже давно абстракциями оперируем, эпоха ассемблера давно прошла. А синтаксис языка программирования, ИМХО (если это не с++, конечно) — это самое простое что есть в программировании. Поэтому вдвойне с вами согласен, что визуальщина — это чисто простые сценарии, или обучение.
>Более того, непонятно с какой радости визуальное программирование должно быть легче, чем, скажем так, текстовое.
Ну, чисто теоретически, некоторые формы записи алгоритмов, скажем, в виде графа, могли бы оказаться проще. Но именно могли бы, в сослагательном наклонении, потому что на практике это почти ни разу не взлетело. Есть редкие исключения из правила, не более того.
Мне кажется не правильно говорить о том что программирование идет в сторону визуализации, а скорее визуальные инструменты идут в сторону программирования.

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

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

Это расширение возможностей, а не замена одного на другое
Как только требуется что то сложнее пары 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 на консольное событие.
Тоже подумал сразу о Visual Age. Очень крутая среда была.
Тоже подумал сразу о Visual Age. Очень крутая среда была.

Современные аналоги — что?

И как визуализировать бизнес логику? Любую. Как визуализировать API?


Человек, который писал статью — дизайнер, а не программист.


Я согласен, что программирование устарело. Но по совершенно другим причинам.

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

Устарело именно потому, что у нас есть мат-аппарат, вычислительная мощность, новые подходы и специалисты, чтобы создать тулы.


Математика тоже бывает устаревшей. Ее форма записи. Что более точная аналогия с программированием. Декард совершил просто невероятную революцию. Большинство думают, что текущая форма записи математики была всегда.

Декард совершил просто невероятную революцию.
Позвольте, но Декарт.

виноват, но уже не исправлю.

у нас есть мат-аппарат, вычислительная мощность, новые подходы и специалисты, чтобы создать тулы.

Бизнесу нужно прямо сейчас выполнять свои задачи, как можно эффективнее (и по времени, и по расходам). Эти все новые подходы только в очень специфических областях приживаются понемногу, а в массе — слишком ново (= рискованно), слишком мало людей и слишком дорого внедрять…

вопрос не в "реалистичности" и "как быстро", а "устарела" или нет.

Пока используется в подавляющем большинстве случаев и нет однозначно лучшей альтернативы — не устарело. К сожалению/счастью, в большинстве повседневных сценариев разработки ПО классический подход выигрывает по ряду причин — поэтому и используется.
Это как назвать все машины с ДВС устаревшими, потому что потихоньку начинают использовать электрокары. В отдельных сценариях — возможно, в полном смысле — всё ещё не устарели.

Окей. Термин "устарело" неподходит, потому что мы вкладываем разное значение в него.


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


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

Можете привести примеры подобных вещей, которые действительно нужно внедрять повсеместно?
Я могу придумать только мат. доказательства для каждого алгоритма, что он безопасный и делает именно то, что нужно — но это звучит примерно как «а давайте расширим штат разработчиков в 5 раз, при этом все новые работники не буду ничего создавать, а только проверять уже написанное имеющимися», что подойдёт только особо-критичным областям.

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


Будем честны. Даже, настолько устоявшуюся и доказанную, практику писать тесты применяют не все. Значительная часть ИТ не применяет.

А вы продолжаете без конкретных аргументов гнуть свою линию, что какие-то мифические «новые подходы» придут и спасут унылый и серый мир программирования. Какие такие вещи накопились, что они настолько круты, что нужно внедрять повсеместно? Да так, что аж всю индустрию изменят?

DDD, TDD, луковичная архитектура, DSL, аспекты из ерланга, компиляторная проверка качества (типа раста, хотя лучше бы алгебраические типы)
Это из того, что уже доказало свою еффективность.


Это должно не только "быть вездне", но и быть соответствующий тулинг и сахар, чтобы все рабоало прозрачно.

DDD довольно специфичен и во многие области плохо ложится (вот у меня есть проект умной грядки на ардуинке, какие там данные? Влажность почвы и время суток? И как от этого толкать разработку?)
TDD подразумевает YAGNI/KISS, что может аукнуться в перспективе. А ещё про тесты для тестов не забывать, да. И тесты тестов тестов (не призываю полностью отказываться, но 100%TDD проектов я ещё не встречал).
DSL в каждую задачу? Для каждой области деятельности свой специфичный язык? (опять таки проект из первого пункта).
Проверки в Rust не дают выстрелить в ногу явно, но от кривой логики это не спасает (банально забыть инвертировать значение проверки в важном условии). Прямо сейчас есть куча статических анализаторов, которые проверят то же самое в других языках.
Про «луковичную архитектуру» и «аспекты из ерланга» ничего не скажу, потому что не представляю их замысла.

И всё это не новые подходы, они уже довольно давно есть и могут применяться при наличии желания и возможности. И я всё же не соглашусь, что всё это должно быть везде.
  • я опечатался. Я хотел написать BDD, а не TDD.

Я не согласен с каждым пунктом. Но каждый из них — разговор на отдельную ветку.


Эта ветка — про отсталость "как делают все" от "что мы уже можем сделать". Все эти аргументы были использованы против тестов в свое время. Кстати, некоторые из них применяли против ввода git'а.


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

ADT дают очень малую долю проверок.


А зачем TDD (если первое T для тестов) для случая, когда компилятор проверяет качество?

см выше


я опечатался. Я хотел написать BDD, а не TDD.

-


ADT дают очень малую долю проверок.

И да и нет. Когда они уже есть и буквально выбольдозирили пласт ошибок из работы — кажется, что они дают мало. Потому что эти ошибки уже не появляются. И команда переходит к более сложным ошибкам.


Но прчина ввода ADT, обычно в том, что такие ошибки занимают большую часть багтрекера.

Когда они уже есть и буквально выбольдозирили пласт ошибок из работы — кажется, что они дают мало.

Тут вы правы. Просто я сужу по опыту с каким-нибудь хаскелем, где ADT и даже GADT уже есть, а безопасности всё равно хочется ещё больше.

И как визуализировать бизнес логику?

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

Поддерживаю. Реальный проект получается ну с очень огромными диаграммами. Тяжело поддерживать, тяжело разбираться. Обычно выпускается версия для старта и на этом все. Дальше ну очень редко используется цикл UML -> реальный код.

Для этого есть, например, диаграммы последовательностей
Еще раз, я против чтобы кодирование заменяли диаграммами. Но и утверждение про невозможность визуализировать бизнес-логику также неверно.

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

Как раз слышал. За последние 2 года я отвечаю на проектах за документацию. Более того, есть неплохии тулы по вихуализации баз данных. Основное отличии от ЮИ — что ты визуализируешь только часть, только какой-то слой логики. Иначе оно становится нечитаймым лабиринтом связей.


Так вот. У нас нет именно инструментов чтобы автоматически выделять такие слои.

Тогда вопрос — как идет работа с системами контроля версий. Вот внесли два разработчика в двух разных ветках изменения в одну диаграмму. Пускай даже не конфликтующие (т.е. один — в одном углу, другой — в другом). Как происходит слияние веток?

я не дорос до уровня документации в репозитории.


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


В последний раз у меня в карьере, когда документацию писали несколько, там ее тоже держали отдельно. И писали вообще ДО написания кода. Большую ее часть.

Полностью вручную. Кто-то садиться и делает merg ручками, увы :(

Если мы про диаграммы — то как-то много лет назад я написал инструмент для импорта проекта из BPMN, где все в картинках, стрелочках и пр., в XML, где две версии проекта можно сравнить в виде текста (сравнить понятное дело криво, но ничего лучше там все равно не было).

И знаете, что смешно — что много лет назад этот инструмент все еще популярен среди тех, кто продолжает работать с той платформой для «визуального программирования». Потому что визуальный diff и merge так и не появился.
А мы можете показать бизнес-логику, написанную прямо и непосредственно на UML? Ну так, чтобы UML не был средством проиллюстрировать код, а был самим кодом? Потому что если это не так, то два представления (сам код и диаграммы) имеют свойство расходиться, и одно из них стремительно устаревает и перестает быть актуальным. И почему-то как правило этим кем-то бывает UML.
>Человек, который писал статью — дизайнер
А такие как правило и пишут подобные тексты. То что визуально нарисовать UI проще, чем закодировать — это одно. Но путать это с логикой — как раз свойственно дизайнерам.
И как визуализировать бизнес логику?

А может показать фрагмент как это выглядит сейчас?

Собственно визуальное программирование — утопия. Программы очень непохожи на электронные схемы, и приблизить их не получится ввиду принципиальной императивности кода. Возможно, для чисто функционального языка что-то и можно сделать…
Но можно совершенствовать сами языки программирования и среды разработки.
Я уже писал, что для выразительности кода не хватает операторных символов (а их набор ограничен ASCII ввиду его общедоступности на любой клавиатуре мира). Это скорее всего уже нереально изменить.
А вот сам дизайн языков должен быть более похожий на «языки разметки», то есть такой, чтобы среды разработки могли максимально легко проводить парсинг «на лету» и трансформировать части кода в какие-то визуализации.
НЛО прилетело и опубликовало эту надпись здесь

100%. Я когда начинал изучать ПЛИС, тоже по старинке все рисовал, как электронную схему. Пока не пришлось моделировать межсоединение 50 с чем-то блоков. Мало того что схема стала нечитабельна, так из-за того что выводы одного блока вливались в качестве шины в другой блок, стало просто не возможно уследить за битами и именами шин. А вот текстом просто пишем generate block, и все куда наглядние.
Вообщем за графикой осталось лиш топ схема (процессор, pll, i/o, sdram и тд).

Я уже писал, что для выразительности кода не хватает операторных символов (а их набор ограничен ASCII ввиду его общедоступности на любой клавиатуре мира). Это скорее всего уже нереально изменить.

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


У меня сейчас в коде совершенное буйство уникода, при этом чисто средствами редактора. Клавиатура обычная.

Рассказ о визуальном программировании без упоминания LabVIEW (на котором написана куча промышленных систем, вплоть до системы управления Большим адронным коллайдером) и PLC. Сразу видно, что писал эксперт.

Рассказ о визуальном программировании без упоминания LabVIEW

От которого все нормальные программисты плюются

Зря вы так. Сейчас в комментарии придет emmibox и расскажет, что все умные люди как раз пишут на LabView, а классические языки общего назначения — тупиковая ветвь и годятся только для элементарных поделок

БАК не управляется с LabVIEW. Понятное дело что моделирование могло быть в чем угодно, но в железе там лабвью быть не может. И данные там тоже не матлабом обрабатывают.
Вообще лабвью не язык программирования, т.к. для решения всего спектра задач все равно надо расчехлять матлаб.

С вашего дивана может быть и виднее, но почему-то NI (разработчик LabVIEW) и CERN с вами не согласны.

В автоматизации визуальное программирование неплохо прижилось:
1. Похожая тематика — в автоматике широко применяются релейные схемы и языки программирования контроллеров LAD/FBD и — это, так или иначе, визуальное воплощение релейных схем
2. Условно низкий порог вхождения. Инженер, способный начертить схему запуска двигателя с самоподхватом на реле и контакторе + 2 кнопки Пуск и Стоп, вполне сможет эту схему написать и в контроллере на LAD, после небольшого обучения.
3. Относительная легкость отладки. Много где в автоматике применяются дискретные сигналы и их удобно отслеживать визуально в отладке — пробежался глазами по подсвеченной цепи и сразу увидел, какое реле не замкнулось, когда нужно, а какое — наоборот — замкнулось, когда не надо.
4. Это все актуально для несложной логики. Там где используются сложные алгоритмы, там, конечно, уже используются языки высокого уровня
Я бы сказал, не столько для несложной, сколько для редко меняющейся. Т.е. скажем реализованной в железе. Потому что с версионированием у визуального программирования все обычно плохо, и изменения это боль определенного рода.

В том же NodeRED казалось бы тоже куча визуальных компонентов. Но все равно, нет да нет приходится писать скрипты. Так как так проще, чем создавать волосатую тварь ))


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

Почему книги все еще пишут текстом? Давно надо было перейти на визуальные образы — пиктограммы. Вместо слова "человек" рисуем человечка. Сразу проявляется как минимум два огромных преимущества: во-первых, подобный "текст" может писать и читать человек, не умеющий читать и писать. Во-вторых, пропадает языковой барьер — повествование может написать японец, а русский сможет его читать без перевода.


Для обычного рукописного текста эволюция шла в противоположном направлении — сначала было пиктографическое письмо и только потом появилась классическая письменность. И никого не беспокоило, что ей надо учится.


Хотя мне жалко, что Дельфи-подобные среды, где интерфейс можно нарисовать мышкой, сейчас что-то маргинальное. В свое время было удобно — набросал контролов, описание формы сгенерировалось автоматически.

Qt Creator — вполне современная и часто используемая среда с редактором форм. В отличие от дельфей позволяет задавать layout, в котором контролы могут перемещаться автоматически и менять размеры при изменении размеров формы во время выполнения программы.

В дельфи же то же самое. Например в FGX

К слову, визуальные редакторы именно формочек есть и для других языков/фреймворков: Visual Studio позволяет мышкой набрасывать компоненты Windows Forms, есть Glade для GTK…
В Делфи все тоже прекрасно перемещалось, если правильно пользоваться панелями и привязкой к границам.
Дельфи-подобные среды, где интерфейс можно нарисовать мышкой, сейчас что-то маргинальное
Так кажется возможно потому, что почти весь десктоп уехал в веб. Но есть ещё мобилки, где этот подход живее всех живых.
Преимущества графических интерфейсов перед текстовыми очевидны. С ними легко работать, они эффективны, красивы, и при этом способны дать пользователю все необходимые ему возможности.

Ну да, конечно.
Программирование происходит в голове, там узкое место, а не в пальцах.

Почему-то ждал про квантовые алгоритмы....

Я пробовал использовать Automate — приложение для Android для скриптования действий на телефоне, использующее графическую среду программирования, в которой рисуется блок-схема, а параметры каждого блока задаются в его свойствах.
Что можно сказать о сравнении такого программирования с традиционным:
1) традиционным способом программы пишутся гораздо быстрее. Гораздо быстрее набрать на клавиатуре if(x>y), чем выбрать пункт "добавить блок", потом открыть категорию "General", там блок "Expression true?", потом в свойствах, в разделе "input arguments" ввести x>y, потом ещё пририсовать оба выхода от этого блока…
2) на блок-схеме не видны все параметры функции, в отличие от текста программы. Нужно ходить по свойствам каждого блока. Текстовое представление программы более плотное.


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

На мобилках программировать в принципе не удобно, а на десктопе доступны hot keys

Это справедливо даже не только для программирования. У меня на компьютере натуральная файлопомойка, и, чтобы мне найти какой-то файл, использую мгновенный поисковик Everything — т.е. как в гугле ввожу название файла и он сразу же высвечивается. Чтобы мне тоже самое сделать в проводнике, мне нужно потратить кучу времени. Т.е. да, напечатать нужное на клавиатуре гораздо удобнее, чем сделать это в граф. интерфейсе, крайне странно, что данный принцип до сих пор не встроен в ОС. Тоже самое с телефоном, в адресной книге проще найти номер, печатая его. Искать номер, или софт (если его много), листая список, это дичь какая-то. Да и те же горячие клавиши гораздо удобнее нарисованных в интерфейсе кнопок
крайне странно, что данный принцип до сих пор не встроен в ОС.

Клавиша Windows и набор нужного названия — это не то?

Гораздо быстрее набрать на клавиатуре if(x>y), чем выбрать пункт «добавить блок», потом открыть категорию «General», там блок «Expression true?»

Зато это кардинально снижает порог вхождения. Представьте, что это не if(x>y), а какой-нито CreateDatabaseConnection(), который вам понадобился в первый раз, и вы так же будете делать «Documentation» — «Databases» — «Create connection» — «Parameters...» Или вобще в сорцы этой библиотеки придется лезть. А тут все сразу перед глазами — и документация и «код».
Кстати в этом же главное преимущество GUI над CLI.

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

Скольнибудь сложная логика на Blueprints в UE4 превращается в прямом смысле в спаггети-код. Да и текст читается быстрее, чем раскиданные узлы. Но собирать готовые компоненты с логикой — довольно удобно. Писать конкретные реализации — почти невозможно. Это скорее инструмент для геймдизайнеров, которым нужно чтобы «персонаж идет(туда)», «карта генерировалась(параметры)». Т.е абстрактная логика. Да и думаю, что революция уже произошла, прокаченные IDE, которые поправят наименования, опечатки, стиль кода, подсветят неиспользованный код и не возвращаемые ветви, с прикрученным дебагером, где можно размотать все что душе угодно. Не говоря уже о самом подходе, в котором мы пишем абстракции(ООП, ФП и т.д), а не машинные коды.

В ранних версиях БП было много косяков и ограничений и я тоже их хейтил. Но сегодня вполне можно всю игру делать на БП а в плюсы отправляться только за низким уровнем. Абсолютно не согласен насчет спагетти кода и невозможности конкретных реализаций. Наоборот, очень удобно иметь возможность прыгать по уровням абстракции как в IEC 61131.

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

У визуального программирования есть обманчивая простота. Создаётся впечатление, что раз это визуальная вещь, можно легко и непринуждённо с помощью одной мышки написать что угодно. По факту, приходится постоянно пролистывать огромное количество компонентов-элементов и их настройки и ещё приходится запоминать, в каком подразделе какого поддерева каталога элементов находится этот компонент, чтобы его вставить. А пока ты листаешь список компонентов, ты видишь названия других компонентов, неосознанно оцениваешь их, и у тебя мелькают мысли, как их можно использовать. Это, в итоге, рассеивает внимание и снижает продуктивность.

С чисто с когнитивной точки зрения, визуальное программирование хуже, чем кодинг, поэтому оно не станет новым поколением. Оно помогает только снизить требования по знаниям для входа в программирование вообще.
Очень слабая аргументация в статье:
  • Половина примеров из статью, когда визуальный процесс заменяет текстовое программирование — построение UI. Вообще-то уже очень давно интерфейсы и так можно мышкой накидывать.
  • Визуально редактировать числа в коде — любопытный концепт. Жаль, что на создании каких-то визуализаций потенциал и заканчивается (потому что уже на подкручивании параметров условной substr начинаются проблемы) — и это не говоря о том, что даже строки так не поредактировать, тем более саму логику.
  • Blueprints в UE4 и прочие аналогичные средства — не более чем Lego из готовых блоков, для очень конкретных областей. Если вдруг понадобится нечто, чего не позволяют готовые блоки — то придётся свои собственные либо так же создавать кодом, либо лепить макро-блоки из существующих (и далеко не везде это доступно), что та ещё боль.
  • Создание запросов в БД — мало того, что очень специфичное «программирование», так ещё и выглядит как «нажми 50 раз мышкой и введи 50 символов» против «введи 100 символов»


Что же касается реальных случаев использования — ну вот, например Jira позволяет искать таски в «простом» условно-визуальном режиме (ввести или выбрать поле, а потом ввести или выбрать значение) или же в «продвинутом» только-текстовом режиме, с автодополнениями. Всё моё окружение, кто хоть насколько-то периодически пользуется поиском выбирают почему-то продвинутый.
Может быть это конкретная реализация так себе, а может просто так лучше.
Я думаю, новое поколение программирования появится тогда, когда вместо монитора для погружения в виртуальный мир будет использоваться более продвинутое средство. Сейчас монитор серьезно ограничивает всю визуальщину, и лучше простого кода пока ничего не придумали. Но вот скажем если выстрелят и станут доступными технологии полного погружения с обратной связью на основе прямого коннекта к мозгу, типа нейролинка Илона Маска, тогда разработка ПО может превратиться в совершенно иное занятие, это конечно останется инженерной дисциплиной, но IDE с обратной связью в мозг будет давать в виде каких-то новых чувств (или даже виртуальных органов, специфичных для программистов — как у Лукьяненко, когда космический корабль становился физически ощущаемой частью тела пилота), а также возможность видеть не ограниченную рамку монитора а 360 градусов обзора и полностью интерактивную среду — пока трудно представить какими будут средства разработки в будущем, в визуальном плане возможно какая-то смесь газонокосильщика и джонни-мнемоника. До этого момента никаких серьезных продвижений в развитии программирования имхо не будет (надеюсь я в этом утверждении не уподобляюсь Биллу Гейтсу с его 640 кб памяти).

До этого вполне может быть нейросеть, которая более менее надёжно понимает нас и делает наши хотелки.
А про Гейтса — фейк, не стоит это распространять далее.

Визуальное программирование взлетело во времена Delphi, который давал возможность быстро накидать интерфейс, задать свойства визуальных объектов, и добавить к ним код в виде событий. И это отличный баланс между визуальным и текстовым программированием.


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

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

Визуально задаётся графический интерфейс, а также дата-модули с описанием данных, сервера и клиенты TCP/IP и проч. компоненты, не относящиеся к графическому интерфейсу напрямую. Это немалая часть программного продукта. При желании всё это можно описать и инициировать в коде, что есть плюс для нестандартных ситуаций.


Но это было придумано давно. Я же пишу о действительно переломном этапе в программировании, который придёт, когда IDE начнёт распознавать голосовые команды, правильно интерпретировать и сохранять в виде программы.

И какой это перелом?
Голосовой ввод доступен везде, с нормальным уровнем качества. Вперёд.
Лично по мне, руками быстрее, точнее, удобнее. Да и горло луженое понадобится.
Или речь про команды типа "Сделай хорошо" или "Напиши мне сервер новой соцсети"?

Я имел ввиду нечто между простым надиктовыванием текста программы, и "Сделай хорошо". Т.е. чтобы у IDE были некие зачатки интеллекта, позволяющие правильно интерпретировать и накидать основу программы путём надиктовывания команд. Типа такого:


  • создать новый проект для Win64.
  • добавить модуль данных, СУБД используем MySQL. Добавить соединение с БД такой-то, расположенной там же, где и база предыдущего проекта.
  • Создать форму идентификации пользователя по имени и паролю, данные хранить в таблице Users. Показывать эту форму при запуске программы.
  • Добавить в проект REST-сервер…
    Ну и т.д. IDE должно распознавать сотни и тысячи программных сущностей (модули, классы, методы), уметь их правильно инициировать, связывать между собой, как указывает программист. Помогать отлаживать и деплоить готовую программу. Должно запоминать ранее выполненные проекты, и брать оттуда готовые сущности по команде. Уметь редактировать, заменять и удалять программные сущности по команде… Вот такое я назвал бы следующим поколением в программировании.
В статье нечетко очерчен предмет обсуждения.

Во-первых, «графический интерфейс пользователя» намекает на то, что с UI работает конечный пользователь-человек, который с помощью компьютера решает свою собственную проблему. Его не интересует, как эта чертова машина работает внутри, хоть там под капотом живут волшебные гномики и исполняют мои приказы. Упрощение UI для пользователя — это решение проблемы использования компьютера, а не программирования.

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

В-третьих, есть большое число сторон программирования, которые бывает полезно визуализировать. У нас есть и UML-диаграммы разных видов, и флеймграфы, и doxygen с извлечением разнообразной информации из исходного кода. Но это всё суть производные программирования, дополнения и продолжения, а не замены. Они играют роль не замены программирования, а в некотором смысле моделирования, построения модели — мы берем сложный алгоритм, выделяем в нем какие-то важные для обсуждения вопросы (например, связи между классами или модулями), отбрасываем несущественные детали и работаем с моделью. Модель помогает думать о «реальности» (т.е. программе), но не заменяет собой реальность.
Так называемые no-code решения, это тупиковый путь если требуется разработка «не стандартных» решений, и я уверен что в любом проекте есть такая часть логики

Будущее языков программирования я вижу так — каждое новое поколение языков больше похоже на человеческий
Например:
ассемблер более человеческий чем машинный код
си более человеческий чем ассемблер
питон более человеческий чем си
*следующее поколение* более человеческое чем питон

Думаю в будущем будут какие то трансляторы в высоко-уровневые языки с человеческого
что то вроде natural language shell
Будущее языков программирования я вижу так — каждое новое поколение языков больше похоже на человеческий

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

мое мнение.


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


И такой тулинг нас сразу приводит к легкому и непринужденному использованию DSL. Как хочет Mainer5s. Или даже личных языков. Когда ты пишешь видешь код в своем любимом языка — а репозиторий и команда видит "командный" код и синтаксис. Хочешь писать код на JS, а прокт на Java — в соседнем окне будет джава.

Легче полнцоенно освоить язык программмирования или фреймворк, чем научиться пользоваться визуальным редактором как в UnrealEngine, Unity. Только на обучение таких крупных IDE уйдёт не мало времени.
НЛО прилетело и опубликовало эту надпись здесь
Нет, будущее программирования не за визуальным программированием, а за DSL-языками.
DSL должны уметь описывать вообще все возможные операции, иначе они будут примерно таким же решением, что и визуальщина: если есть готовое, то легко и приятно, а если нет — добро пожаловать в недра реализации. Кстати, при повсеместном использовании DSL вырастут пороги при переходе между разными областями разработки. Так, если я пишу на Си, например, веб-сервер, то я без особых проблем смогу перейти в разработку системных утилит или даже микроконтроллеров или WebAssembly. Да, там есть своя специфика, но язык и половина библиотек останутся такими же. С DSL в общем случае так не получится.
DSL должны уметь описывать вообще все возможные операции
В одной какой-то области необходимых операций не так уж и много, но важно другое — все они понятны человеку, который является спецом в этой области и в то-же время не является программистом. То есть DSL это не синоним слова «простой», но синоним слова «понятный».

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

Кстати пороги могут и не так сильно вырасти, если внутри всех DSL будет условно один и тот же ЯП.
Конечно, и это правильно. Как сейчас, например, порог при переходе между профессиями выше, чем 1000 лет назад.

Ну вы сказали.
Профессии же не просто так усложняются. Производство тоже сложнее.

Даже 50 лет назад связь в каждом кармане с всемирной библиотекой знаний (на самом деле, где подавляющее большинство — пустой трёп) — было фантастикой.
Единственный известный мне удачный пример использования визуального программирования — это древние библиотеки для шлепания экранных форм типа VСL (Delphi), .net Windows Forms и похожие.

Когда-то у меня была мечта: описывать классы программы в графическом представлении.
Представьте, открываете программу, которую делал кто-то другой и которую делали вы сами, но позабыли. А в ней помимо текста программы и папок проекта обязательно есть несколько диаграмм, на которых разработчик разместил описания классов с комментариями как это работает, показал важные связи, раскрасил и сгруппировал на пространстве диаграмм классы по их назначению.
Начинаем работать, глаз быстро запоминает компоновку диаграмм. Допустим, нам нужно добавить некую новую фитчу — а глаз помнит, что этот функционал был где-то справа сверху основной диаграммы. Начинаем думать, что придется доработать — какие классы придется расширить, какие добавить. При этом перед глазами не один экран кода или дерево папок проекта а диаграмма. Доработали, классы изменились на диаграмме, подправляем диаграмму, поясняем как это теперь работает в комментариях на диаграмме.
Эти мои мечты не сбылись — достаточно удобного инструмента для подобного визуального программирования в IDE так и не появилось. Может быть все кто пытался его сделать (вроде VS Class Designer) убеждались, что это слишком сложно, нестандартно, непрактично и останавливались на половине пути.
Хотя, где-то в 2003-ом я пробовал рисовать диаграммы UML с автогенерацией кода C++ по ним, и мне показалось, что это почти работает.
Описывать классы (или другие блоки) графически вполне удобно и сейчас, тот же UML для описания классов/блоков вполне годится. А вот реализовывать функционал таким способом удаётся либо совсем в примитивных сценариях, либо с заметными ограничениями и/или неудобствами.
Это все классно, пока вы работаете на супер-мелком проекте.
В реальном проекти этих классов пара сотен и у каждого десяток-другой методов(если не больше). Да и вы к конкретному классу возращаетесь гдето… раз в год. А еще у вас проектов штук 5. Ничего вы не запомните таким методом.
А обычный текстовый поиск будет усложнен.
В реальном проекти этих классов пара сотен

Это и есть мелкий проект. В реальном проекте их их тысячи. Вот у меня под руками сейчас, если брать со всеми внешними библиотеками — так там сотни тысяч индивидуальных классов набирается.

Это все классно, пока вы работаете на супер-мелком проекте.
Не совсем так. Во первых, любой крупный проект имеет логически разделенные модули. Не бывает пары сотен важных классов в одном модуле, скорее эту будут довольно однообразные классы, которые нет смысла рисовать на диаграммах. Диаграммы рисуем там, где нужно проиллюстрировать и пояснить дополнительно как устроен модуль, т.е. показать концепцию, если она не очевидна.
Во-вторых, то что я описывал хорошо для модулей, в которых алгоритмы достаточно сложные а классов не так много. Т.е. открываем модуль, в модуле скажем 20 000 строк, и он состоит из нескольких десятков классов, взаимодействующих друг с другом для решения задач.
Представьте себе, что вы имеете дело с кодом графического редактора или кодом некого сервиса, что-то моделирующего, возвращающего ответы, извещающего об изменениях. Есть много задач, для которых хочется нарисовать диаграмму в 2D пространстве а не разложить классы по папкам.
А еще у вас проектов штук 5.
Тогда тем более диаграммы хорошо. Обращаясь к проекту надо вспомнить как в нем что работает. Диаграмма — самый подходящий способ освежить в памяти что там вообще творится. Если в проектах все однообразно и ничего особенного нет, тогда не нужны и диаграммы.
которые нет смысла рисовать на диаграммах.

Я напоминаю контекст дискусии. Заменить код диаграммами.
Когда мы пишем код диаграммами нет возможности "пропустить". Потому тогда что не будет кода.


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

Несмотря на то, что блюпринты определенно заняли свою нишу и заняли её оправданно — заменой коду они врядли станут.
Любой кто сталкивался с блюпринтами в UE знает целую кучу их проблем по сравненисю с кодом.
А ведь там идеальная реализация визуального программирования, сложно придумать лучше! А уж если плагинов-улучшайзеров из маркета навесить…
Скорее программирование вообще пропадет как род деятельности, нежели визуальное программирование заменит код.
Визуальный алгоритмический язык программирования и моделирования ДРАКОН — «Дружелюбный русский алгоритмический язык, который обеспечивает наглядность»

Был изобретен в СССР, использовался при разработке и испытаниях космических кораблей «Буранов».

ru.wikipedia.org/wiki/ДРАКОН
Ага, только в нем в схемах использовался C как «дополнительный», причем большая часть кода была на «дополнительном» языке.
Не без этого) Но кмк это лучше, чем если бы они сделали собственную «стандартную библиотеку» :)
нет, там использовался не Си, а ПРОЛ — отечественный язык. хотя «использовался» — это сильно сказано. Когда я у Паронджанова поинтересовался технологией трансляции (это было где-то в 2012 году), то он ответил просто и незатейливо: «нарисовали, и отдали программистам на кодирование». Так что заслуга Дуракона в «разработке и испытании Буранов» не больше, чем заслуга изготовителя кастрюль для столовой НИИАПа…
Интересовался я у него в связи с тем, что «дураконовцы» до тех пор не смогли создать нормальный транслятор, несмотря на «предоставлениеь пользователю языковых средств, которые заставляют человека мыслить продуктивно, облегченное межотраслевое и междисциплинарное общение между представителями разных организаций и
за счет использования когнитивно-эргономического подхода к проектированию»
собственно, и сейчас создаваемые этнтузиастами, хм, «продукты»… впрочем, посмотрите на них самостоятельно.
С ними легко работать, они эффективны, красивы, и при этом способны дать пользователю все необходимые ему возможности.

Но ведь все наоборот — GUI это совершенно неудобно. Т.е., когда ты лениво лежишь на диване и клацаешь вкладочки в браузере мышкой — это да, удобно. Но для сконцентрированной програмистской работы как раз таки текстовый интерфейс и шорткеи оказываются намного удобней. Ввести короткую команду в терминал или нажать шорткей намного быстрее чем елозить курсором по экрану выбирая нужную команду в нужном подразделе меню, или перетаскивать что-то там куда-то там.
Возить мышкой по слайдеру чтоб изменить значение переменной в коде? Это ужасно неэргономично.
Интересно, мне одному показалось, что автор перепутал взаимодействие с программой и получение результата? Интересно, как бы он описывал визуальное создание продуктов, которые изначально не подразумевают визуальность, например СУБД?

Полностью визуальный редактор для игр Klik & Play появился еще в 1994 году. Логика описывается в виде списка "если-то", где условия и действия выбираются мышкой из выпадающих списков.


Концепция была довольно жизнеспособная: движок до сих пор развивается и имеет актуальную версию. В первой половине 2000х вокруг него было активное международное сообщество. Небольшая группа наиболее активных участников отпочковалась и сделала свой клон — Scirra Construct, работающий на том же принципе.


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

Оооо, да… Как там у вас в 80х? Мы вам тут из будущего пишем! Если коротко, то за 40 лет чёт так и не взлетело ещё.
З.Ы. Я уж думал про программирование с использованием ии, или хотя бы чуть по свежее тему чем визуальное программирование про то, что все пересядем на фреймворки расскажут. А тут только получил вьетнамские флэшбеки вспомнив про опыт workflow foundation.
З.З.Ы зашёл на оригинал статьи, автор разраб в стартапе, который впаривает революционный nocode тул для js, nuff said, как говориться. Я понимаю, что в корпоративный блог надо постить регулярно, но статей то не мало, можно же как-то не совсем мусор то переводить, за ваш труд перевода же тоже обидно.
Конечно, ошибка в источнике, но VisiCalc релизился в 1979, а не в 1977.

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

Program — provide (a computer or other machine) with coded instructions for the automatic performance of a task.

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 пожаловался, что тачскрины вызывают ошибки, физические тумблеры были надёжнее»

Если человек не является профессионалом — то тачскрин вполне хороший интерфейс.
Но он ограниченный.
Думаю, будут куча интерфейсов обучения нейронным сетям и прочим AI инструментам, которые будут генерить алгоритмы.

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

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