Комментарии 53
Про Oracle Designer видимо никто не слышал.
Те же веб-страницы. Я никогда не понимал, как же их можно «писать», когда надо создавать графически! Но нет, css, html живут и здравствуют)
Но без кода пока никуда.
вот VP для домиков dynamobim.org
И очень странно в статье о визуальном программировании не упомянуть систему LabView, в которой этот подход реализован еще много лет назад и которая не просто экспериментальный язык, а промышленный стандарт разработки в своей нише уже много лет.
Точно так как для бытовых роботов лучший язык будет содержать одну команду «смотри я покажу»… Утрирую конечно. Но суть думаю ясна.
IDE должно понимать намерение программиста, и выбирать оптимальный способ его достичь. Желания людей просты. Сложными могут быть методы их реализации.
И это совсем не обязательно требует сильный ИИ. Многое можно сделать уже сегодня. Тот же компилятор уже сегодня многое «прячет под капот», разработки. Визуальные языки — еще один шаг, в том же направлении. Каким может быть следующий шаг, я писал уже давно:)
ЗЫ. В следующий раз буду все комментарии сразу дочитывать, прежде чем свой писать. =\
А вот с тем, что в каком-либо языке программирования что-то «логично и понятно», в отличие от любой скриптовой системы (даже не визуальной), созданной для ускорения разработки простых вещей — я бы поспорил.
Программирование вообще подходит только для людей особого склада ума.
В целом же, имхо, логичность языков программирования можно приравнять к логичности обычных языков (русский, английский). В них ты только тогда можешь различить логичные цепочки (кое-где), когда у тебя уже большая практика и ты видишь полную картину. В ином же случае ничего логичного в языках нет. Всё базируется на огромном количестве правил, условностей и, кое-где, схожих паттернах этих правил и условностей, но далеко не везде. Ты только тогда знаешь язык, когда знаешь все эти правила. Ну а пользоваться этим сможет (так как правил в программирования намного больше чем в обычных языках), далеко не каждый, как я уже писал.
Так что визуальное программирование (скриптование) имеет место быть. Просто цели такого программирования должны быть другими. А обычные языки программирования вообще далеки от идеала, так как зависят от базового языка, который тоже далёк от идеала. При этом сотни тысяч людей продолжают всё это использовать и задумываются о том, как написать настоящий ИИ на таких примитивных языках как сейчас (точно также как и игру на блюпринтах не сделать), вместо того чтобы улучшить базу.
Визуальное программирование — это улучшенная база для скриптования.
Если разработку изначально програмировать с учётом этого, то можно заметно оптимизировать весь процесс, где далекие от кода коллеги, будут иметь на «входе» нужные им данные и путём простеньких манипуляций над игрово логикой или картинкой, получать желаемые данные на выходе (шейдеры, тексты,
ветви сюжета и т.д.)
Почему то каким то менеджерам в голову пришло, что накидав блох схемы можно снизить порог вхождения не потеряв в качестве.
П.с. Почему UML не упомянули. шумели же — генерация кода по UML — вот он Грааль программирования.
хотя на всё это есть один простой термин — полнота «языка».
т.е. на С — можно реализовать 99.9% состояний нашей «машины тьюрига». и чем выше абстракция, тем этот процент ниже.
трудно даже представить, каков процент полноты у языка из статьи.
большие алгоритмы все равно выглядят странно и страшно
Но ведь в Blueprint есть функции. Что мешает разбить алгоритм по частям? По аналогии, вы же не будете писать реализацию A* целиком в main().
Не все алгоритмы можно упаковать в иерархии по подблокам.
Тем кто хочет попробовать без установки есть более простой Визуальный язык блок схем Дракон https://drakon-editor.com/ — онлайн версия
https://vk.com/drakon_yazuk — ВК Группа
Очень широко используется не программистами (юристами, врачами, бизнес-тренерами) для составление блок схем (этакий вариант MindMap для алгоритмов), от себя отмечу — очень удобен для разбора юридических договоров.
Единственным ВАЖНЫМ отличием от других редакторов блок-схем является:
- Блок-схемы составляются по специальным правилам, так чтобы мозгу было легко их понять и исключить задержки/ошибки в понимании (например запрет перекрещивания линий/связей, только вертикальные-горизонтальные связи)
- Рассово-чистым :) Дракон-Редактором НЕВОЗМОЖНО в принципе составить блок схему нарушающую эргономические правила из п. 1.
- Технология вполне рабочая, — на нём был написано ПО для Бурана (практически без логических ошибок!), сейчас пишется ПО для МБР Тополь, Синева, Лайнер.
- Меня удивило что на волне хайпа с Apple и MacBook никто из наших программистов не написал для него огламуренный аналог дракон-редактора для американских юристов менеджеров и врачей.
Что-то не упомянули про движок Quest3D от Act-3D, нынешний Lumion для архивиза.
quest3d.com
guest3d.ru/g3d
Который работал с блочным программированием за долго до UE4 и Unity.
Году этак 2007-2008 на нем курсовую работу пилил, без использования кода. Преподаватели были в шоке когда я им исходники показывал.
Сам движок думаю был на уровне unity тех лет. Каждый используемый блок можно было улучшить через lua скрипты. Основной жесткой проблемой был импорт 3d модели, под каждую часть геометрии создавался свой блок. Что создавало трудности при импорте больших проектов. В то время его вроде использовали для интерактивных презентаций, помню был еще какой-то большой проект по истории там еще пирамиды майя можно было смотреть.
А во всяких BPM системах как любят мантру «дешевый системный аналитик, не умеющий программировать, сможет создать бизнес-процесс без привлечения программиста».
По факту,
1) меньшая гибкость. Проблемы с подключением сторонних библиотек/сервисов. Правда, есть заплатки, что можно свои блоки создавать. Но тогда уже некая гибридная парадигма выходит, совмещаюшая недостатки обоих
2) неудобства с наследованием, абстракциями
3) даже с диффами и VCS, меньшая приспособленность к анализу изменений в проекте
Ps: может, если применить AI, и оставлять ему на откуп тривиальные операции вроде всяких биндингов, банальных преобразований, джойнов, а описывать схемой только желаемый вход и выход, то и будет толк
В сухих тестах UE4 Blueprints примерно в 200-300 раз медленне С++. По умолчанию Blueprints работают в виртуальной машине и «дёргают» от туда С++. Но можно включить их принудительную компиляцию в С++. Тогда они будут всего в 6-8 раз медленне.
Тут нужно понимать, что на современном железе эта разница в исполнении игровой логики не так критична, т.к. на первом плане стоит скорость рендера картинки.
Есть опенсорсная реализация подобной вещи на NodeJS. Разработана IBM, называется Node Red: https://nodered.org/
Для написания прототипов или создания ботов — самое оно.
Для меня эти ноды — это особый тип интерфейса, который позволяет удобно и элегантно решать множество задач в разных сферах (музыка, 3Д графика и т. д.), и все эти задачи можно объединить в одну категорию — "композиционные". Но программирование — это нечто гораздо более емкое, и я никогда бы не предпочел подобный интерфейс старому доброму коду. Этот "молоток" хорошо подходит только для своих определенных "гвоздей".
Visual Scripting: будущее уже наступило?