Comments 53
Т.е. через условно N лет, я смогу нарисовать в специализированной нотации (вроде bpmn или idef) блок схему, например мобильного приложения, и с относительно небольшими проблемами получить более-менее рабочее приложение, так?
Про Oracle Designer видимо никто не слышал.
Как это будет выглядеть в будущем, пока не ясно. Ясно то, что упрощение методов разработки приложений — это глобальный тренд. За остальные средства не скажу, но в Qt последнее время интенсивно разивают это направление.
Было же уже. MS Access например имеет (имел) возможность «рисовать» запросы, однако это не убило SQL. Warcraft 3 WorldEdit имеет встроенный скриптовый редактор, который условно можно назвать графическим, однако все профи использовали текстовые jass скрипты, благодаря этому и появилась и развивалась dota как карта, кстати. Matlab simulink, всякие IDE для ПЛИС, все это есть и уже давно, но смерти текстового программирования мы навряд ли дождемся)
Те же веб-страницы. Я никогда не понимал, как же их можно «писать», когда надо создавать графически! Но нет, css, html живут и здравствуют)
Те же веб-страницы. Я никогда не понимал, как же их можно «писать», когда надо создавать графически! Но нет, css, html живут и здравствуют)
Ничего нового, точно так же спрашивали девелоперы и 30, 20 лет назад, были уже попытки
Но без кода пока никуда.
Но без кода пока никуда.
Нет, сможете нарисовать сразу само приложение. Код и блок-схемы останутся для оптимизаторов-«низкоуровневиков».
не работает, это как Excel vs Access — очень быстро наступает потолок, выше которого даже не стоит пытатся прыгнуть
вот VP для домиков dynamobim.org
вот VP для домиков dynamobim.org
мне понравилось визуальное проектирование, например
Выглядит слишком визуально перегружено даже на максимально простых алгоритмах.
Для начала, не стоит смешивать визуальное программирование (когда сам код пишется в виде графических блоков) и графические средства разработки интерфейсов, когда мы расставляем всякие окошки, кнопки и т.п. визуальные элементы и потом привязываем к ним стандартный код.
И очень странно в статье о визуальном программировании не упомянуть систему LabView, в которой этот подход реализован еще много лет назад и которая не просто экспериментальный язык, а промышленный стандарт разработки в своей нише уже много лет.
И очень странно в статье о визуальном программировании не упомянуть систему LabView, в которой этот подход реализован еще много лет назад и которая не просто экспериментальный язык, а промышленный стандарт разработки в своей нише уже много лет.
ИМХО, визуальные языки в играх «взлетят», когда появятся удобные инструменты для разработки игры находясь внутри игры…
Точно так как для бытовых роботов лучший язык будет содержать одну команду «смотри я покажу»… Утрирую конечно. Но суть думаю ясна.
IDE должно понимать намерение программиста, и выбирать оптимальный способ его достичь. Желания людей просты. Сложными могут быть методы их реализации.
И это совсем не обязательно требует сильный ИИ. Многое можно сделать уже сегодня. Тот же компилятор уже сегодня многое «прячет под капот», разработки. Визуальные языки — еще один шаг, в том же направлении. Каким может быть следующий шаг, я писал уже давно:)
Точно так как для бытовых роботов лучший язык будет содержать одну команду «смотри я покажу»… Утрирую конечно. Но суть думаю ясна.
IDE должно понимать намерение программиста, и выбирать оптимальный способ его достичь. Желания людей просты. Сложными могут быть методы их реализации.
И это совсем не обязательно требует сильный ИИ. Многое можно сделать уже сегодня. Тот же компилятор уже сегодня многое «прячет под капот», разработки. Визуальные языки — еще один шаг, в том же направлении. Каким может быть следующий шаг, я писал уже давно:)
UFO just landed and posted this here
Потому что Блюпринт для художников, а не программистов. А задача плюсовиков — разрабатывать более сложные и проектно-ориентированные ноды для блюпринта.
ЗЫ. В следующий раз буду все комментарии сразу дочитывать, прежде чем свой писать. =\
ЗЫ. В следующий раз буду все комментарии сразу дочитывать, прежде чем свой писать. =\
А сколько вы времени потратили на изучение С++?
Скриптование и программирование — разные вещи. В теме уже писали для чего может использоваться, но уж точно не для полноценного создания игры.
А вот с тем, что в каком-либо языке программирования что-то «логично и понятно», в отличие от любой скриптовой системы (даже не визуальной), созданной для ускорения разработки простых вещей — я бы поспорил.
Программирование вообще подходит только для людей особого склада ума.
В целом же, имхо, логичность языков программирования можно приравнять к логичности обычных языков (русский, английский). В них ты только тогда можешь различить логичные цепочки (кое-где), когда у тебя уже большая практика и ты видишь полную картину. В ином же случае ничего логичного в языках нет. Всё базируется на огромном количестве правил, условностей и, кое-где, схожих паттернах этих правил и условностей, но далеко не везде. Ты только тогда знаешь язык, когда знаешь все эти правила. Ну а пользоваться этим сможет (так как правил в программирования намного больше чем в обычных языках), далеко не каждый, как я уже писал.
Так что визуальное программирование (скриптование) имеет место быть. Просто цели такого программирования должны быть другими. А обычные языки программирования вообще далеки от идеала, так как зависят от базового языка, который тоже далёк от идеала. При этом сотни тысяч людей продолжают всё это использовать и задумываются о том, как написать настоящий ИИ на таких примитивных языках как сейчас (точно также как и игру на блюпринтах не сделать), вместо того чтобы улучшить базу.
Визуальное программирование — это улучшенная база для скриптования.
А вот с тем, что в каком-либо языке программирования что-то «логично и понятно», в отличие от любой скриптовой системы (даже не визуальной), созданной для ускорения разработки простых вещей — я бы поспорил.
Программирование вообще подходит только для людей особого склада ума.
В целом же, имхо, логичность языков программирования можно приравнять к логичности обычных языков (русский, английский). В них ты только тогда можешь различить логичные цепочки (кое-где), когда у тебя уже большая практика и ты видишь полную картину. В ином же случае ничего логичного в языках нет. Всё базируется на огромном количестве правил, условностей и, кое-где, схожих паттернах этих правил и условностей, но далеко не везде. Ты только тогда знаешь язык, когда знаешь все эти правила. Ну а пользоваться этим сможет (так как правил в программирования намного больше чем в обычных языках), далеко не каждый, как я уже писал.
Так что визуальное программирование (скриптование) имеет место быть. Просто цели такого программирования должны быть другими. А обычные языки программирования вообще далеки от идеала, так как зависят от базового языка, который тоже далёк от идеала. При этом сотни тысяч людей продолжают всё это использовать и задумываются о том, как написать настоящий ИИ на таких примитивных языках как сейчас (точно также как и игру на блюпринтах не сделать), вместо того чтобы улучшить базу.
Визуальное программирование — это улучшенная база для скриптования.
Unreal Blueprint делался прежде всего для той части команды разработчиков игры, которая не умеет программировать, но которой приходится вмешиваться в логику игры.
Если разработку изначально програмировать с учётом этого, то можно заметно оптимизировать весь процесс, где далекие от кода коллеги, будут иметь на «входе» нужные им данные и путём простеньких манипуляций над игрово логикой или картинкой, получать желаемые данные на выходе (шейдеры, тексты,
ветви сюжета и т.д.)
Если разработку изначально програмировать с учётом этого, то можно заметно оптимизировать весь процесс, где далекие от кода коллеги, будут иметь на «входе» нужные им данные и путём простеньких манипуляций над игрово логикой или картинкой, получать желаемые данные на выходе (шейдеры, тексты,
ветви сюжета и т.д.)
А если мне приятно левая картинка? тем более сравнение не правильное, слева кусочек инициализации пингпонга на sfml, а справа код какой то функции на blueprint
да, в конце 90х кричали — визуальное программирование в дельфях это лютый вин!.. годы идут, крик раздаётся, только языки и платформы меняются.
Почему то каким то менеджерам в голову пришло, что накидав блох схемы можно снизить порог вхождения не потеряв в качестве.
П.с. Почему UML не упомянули. шумели же — генерация кода по UML — вот он Грааль программирования.
хотя на всё это есть один простой термин — полнота «языка».
т.е. на С — можно реализовать 99.9% состояний нашей «машины тьюрига». и чем выше абстракция, тем этот процент ниже.
трудно даже представить, каков процент полноты у языка из статьи.
Почему то каким то менеджерам в голову пришло, что накидав блох схемы можно снизить порог вхождения не потеряв в качестве.
П.с. Почему UML не упомянули. шумели же — генерация кода по UML — вот он Грааль программирования.
хотя на всё это есть один простой термин — полнота «языка».
т.е. на С — можно реализовать 99.9% состояний нашей «машины тьюрига». и чем выше абстракция, тем этот процент ниже.
трудно даже представить, каков процент полноты у языка из статьи.
большие алгоритмы все равно выглядят странно и страшно
Но ведь в Blueprint есть функции. Что мешает разбить алгоритм по частям? По аналогии, вы же не будете писать реализацию A* целиком в main().
Довелось мне как-то видеть логику выбора двигателя ( 1 из 3 для равномерного распределения ресурса между резервными) на графическом языке программирования от сименс… Так вот это кошмар из разряда «работает — не трогай».
Не все алгоритмы можно упаковать в иерархии по подблокам.
Не все алгоритмы можно упаковать в иерархии по подблокам.
В main — конечно, нет. Но функцию, которая, собственно, делает A* (а заодно еще DFS, BFS и алгоритм Дейкстры) разбить на более мелкие блоки уже не получится.
Вот когда появится визуальный способ представления для УЖЕ написанного кода на обычном языке программирования (например C++), тогда это начнёт обретать некоторую популярность и полезность… Ведь по факту это всего лишь представление кода в другом виде, в визуальном виде. Никаких новых возможностей это не вносит, лишь упрощает чтение (хотя как видно не всегда) и восприятие уже написанного. Но вот менять типы представлений для кода, мне видится не плохим началом.
Выглядит очень похоже на вот этот проект. Возможно, правда, что какие-то фичи пока что не поддержаны, и, возможно, потребуется какой-то препроцессинг кода.
Тем кто хочет попробовать без установки есть более простой Визуальный язык блок схем Дракон 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 модели, под каждую часть геометрии создавался свой блок. Что создавало трудности при импорте больших проектов. В то время его вроде использовали для интерактивных презентаций, помню был еще какой-то большой проект по истории там еще пирамиды майя можно было смотреть.
Что-то не упомянули про движок Quest3D от Act-3D, нынешний Lumion для архивиза.
quest3d.com
guest3d.ru/g3d
Который работал с блочным программированием за долго до UE4 и Unity.
Году этак 2007-2008 на нем курсовую работу пилил, без использования кода. Преподаватели были в шоке когда я им исходники показывал.
Сам движок думаю был на уровне unity тех лет. Каждый используемый блок можно было улучшить через lua скрипты. Основной жесткой проблемой был импорт 3d модели, под каждую часть геометрии создавался свой блок. Что создавало трудности при импорте больших проектов. В то время его вроде использовали для интерактивных презентаций, помню был еще какой-то большой проект по истории там еще пирамиды майя можно было смотреть.
Уже писали (упоминание про LabView), что визуальное программирование ДАВНО используется для программирования промышленных контроллеров: FBD (Function Block Diagram) в STEP 7 от сименса, яркий пример такого языка высокого уровня.
UFO just landed and posted this here
В Delphi посредством BOLD была реализована MDA впервые в 6-ой версии (2000-2001 гг.) Вот там ровно тоже самое, что описал автор, только для баз данных. И это более 15 лет назад. Но увы, не взлетело. Если бы взлетело, возможно это был бы прорыв, по уровню такой же, как и появления самих дельфей. Кстати, по каким причинам не взлетело? Ровно по таким же: простые вещи делают очень быстро и просто, буквально можно накликать полностью базу. Вещи чуть по сложнее, не говоря о «кровавом интерпрайзе» решались настолько сложно и долго, что проще было вообще эту технологию не использовать. Ну и доков практически не было.
Возник тут интересный вопрос: а как это добро увязать с системами контроля версий? Не просто чтобы было, а так, чтобы прямо удобно смотрелось.
Чего только лоди не придумают, чтобы не учится программировать.
А во всяких BPM системах как любят мантру «дешевый системный аналитик, не умеющий программировать, сможет создать бизнес-процесс без привлечения программиста».
По факту,
1) меньшая гибкость. Проблемы с подключением сторонних библиотек/сервисов. Правда, есть заплатки, что можно свои блоки создавать. Но тогда уже некая гибридная парадигма выходит, совмещаюшая недостатки обоих
2) неудобства с наследованием, абстракциями
3) даже с диффами и VCS, меньшая приспособленность к анализу изменений в проекте
Ps: может, если применить AI, и оставлять ему на откуп тривиальные операции вроде всяких биндингов, банальных преобразований, джойнов, а описывать схемой только желаемый вход и выход, то и будет толк
А во всяких BPM системах как любят мантру «дешевый системный аналитик, не умеющий программировать, сможет создать бизнес-процесс без привлечения программиста».
По факту,
1) меньшая гибкость. Проблемы с подключением сторонних библиотек/сервисов. Правда, есть заплатки, что можно свои блоки создавать. Но тогда уже некая гибридная парадигма выходит, совмещаюшая недостатки обоих
2) неудобства с наследованием, абстракциями
3) даже с диффами и VCS, меньшая приспособленность к анализу изменений в проекте
Ps: может, если применить AI, и оставлять ему на откуп тривиальные операции вроде всяких биндингов, банальных преобразований, джойнов, а описывать схемой только желаемый вход и выход, то и будет толк
Вот мучает вопрос, а что мешает изучить основы яп? Ведь по сути, все что заменяет blueprint — учиться за неделю или месяц
Поюзал помнится blueprints из Unreal. окей, для мелочи жить можно. Но когда я порешил сгенерировать галактику не частицами, а на базе множества билбордов с вершинными шейдерами. чтобы прогонять в 1 draw call на C++, я захотел чего-нить сделать с авторами Unreal Engine с их собственной нотацией C++ на базе дефайнов, полностью забив на стилистику стандартной библиотеки и с убожеской документацией, которая отстаёт на несколько релизов и зачастую вообще неактуальна. Плюс по этим макросам IDE в принципе адекватно не работает, реалньные места ошибок найти не то что бы сложно, а вообще невозможно. То в рамках тогоже Unreal Engine вообще не хочется на C++ ничего делать. При этом знаю очень даже хорошо язык.
Кому интересно, habrahabr.ru/post/333750
Когда-то давным-давно, во времена моего детства, это называлось CASE-системами, и было жутко перспективным… я даже сам писал такие простенькие редакторы, которые транслировали нарисованные по правилам блок-схемы в код программ для своего крооохотного интерпретируемого языка. Visual Basic 6, Win98, было время. CASE-системы нынче почти вымерли, а идея… хм… до сих пор жутко перспективна :)
Это всё напоминает мне старенькую шутку про риббон — «Почему Microsoft не добавили риббон в VisualStudio? Потому что они ей пользуются.» Вот и тут хотелось бы увидеть Визуальный ЯП, для которого и компилятор и IDE написаны на этом ЯП.
Может кто то проводил тесты код который на писаный вручную и через Visual Scripting, какой быстрее будет работать?
Думаю любому понятно, что любая надстройка над нативным кодом, будет заметно медленне его самого.
В сухих тестах UE4 Blueprints примерно в 200-300 раз медленне С++. По умолчанию Blueprints работают в виртуальной машине и «дёргают» от туда С++. Но можно включить их принудительную компиляцию в С++. Тогда они будут всего в 6-8 раз медленне.
Тут нужно понимать, что на современном железе эта разница в исполнении игровой логики не так критична, т.к. на первом плане стоит скорость рендера картинки.
В сухих тестах UE4 Blueprints примерно в 200-300 раз медленне С++. По умолчанию Blueprints работают в виртуальной машине и «дёргают» от туда С++. Но можно включить их принудительную компиляцию в С++. Тогда они будут всего в 6-8 раз медленне.
Тут нужно понимать, что на современном железе эта разница в исполнении игровой логики не так критична, т.к. на первом плане стоит скорость рендера картинки.
Есть опенсорсная реализация подобной вещи на NodeJS. Разработана IBM, называется Node Red: https://nodered.org/
Для написания прототипов или создания ботов — самое оно.
Для меня эти ноды — это особый тип интерфейса, который позволяет удобно и элегантно решать множество задач в разных сферах (музыка, 3Д графика и т. д.), и все эти задачи можно объединить в одну категорию — "композиционные". Но программирование — это нечто гораздо более емкое, и я никогда бы не предпочел подобный интерфейс старому доброму коду. Этот "молоток" хорошо подходит только для своих определенных "гвоздей".
Sign up to leave a comment.
Visual Scripting: будущее уже наступило?