17.07.2024 13:00
Bright_Translate 14 3800 Источник

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

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

▍ Контекст


Каждые несколько месяцев кто-нибудь да выпускает очередной красивый язык визуального программирования, который выглядит, например, так:



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

Показанный алгоритм заменяет следующий псевдокод1:

def merge_sort(a):
  if (length(a) == 2):
    if (a[0] < a[1])
      return a
    else
      return [a[1], a[0]]
  else:
    [x1, x2]  = split_in_half(a)
    sorted_x1 = merge_sort(x1)
    sorted_x2 = merge_sort(x2)
    return priority_merge(sorted_x1, sorted_x2)

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

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

=INDEX(A1:A4,SMALL(IF(Active[A1:A4]=E$1,ROW(A1:A4)-1),ROW(1:1)),2)

Я проигнорирую эту причину, потому что многие аналогичные инструменты явно предназначены для опытных разработчиков. Они предполагают, что вы будете устанавливать их через npm install или развернёте в AWS Lambda.

Почему визуальное программирование не заходит разработчикам?

Разработчики говорят, что хотят «визуальное программирование», и ты начинаешь думать «ага, давайте заменим if и for». Но никто никогда не создавал схему программы для чтения for (i in 0..10) if even?(i) print(i). Знакомые с кодом разработчики уже ценят и понимают текстовые представления для чтения и записи бизнес-логики2.

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

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

Вот некоторые примеры визуализации, которые я часто встречаю в серьёзных контекстах:

  • Различные способы визуализации базы кода в целом.
  • Схемы подключений компьютеров в сети.
  • Схемы размещения данных в памяти.
  • Схемы переходов конечных автоматов.
  • Swimlane-диаграммы для протоколов, работающих по принципу запрос/ответ.

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

Если вы скептично настроены в отношении подобных решений, позвольте спросить: «Вам известно, как в точности размещены данные в памяти вашей системы?» А ведь неудачное размещение данных в памяти является одной из основных проблем падения производительности. При этом очень трудно «увидеть», как именно конкретный элемент данных размещён, и сопоставить это с паттернами доступа в базе кода.

Или ещё вопрос: «Известны ли вам все внешние зависимости, которые задействует ваш код, отвечая на HTTP-запрос? Вы уверены? А вы не заметили, что Боб недавно добавил вызов в сервис ограничения скорости передачи в промежуточном ПО?» Не беспокойтесь, вы узнаете об этом при следующем сбое.

Для обоих вопросов ответом обычно будет: «Я думаю, что знаю» с затаившимся страхом, что, возможно, вы всё-таки упустили нечто, что не смогли увидеть.

К сожалению, большинство визуализаций:

  • Делаются наспех.
  • Составляются вручную на салфетке или с помощью Whimsical.
  • Редко интегрируются в стандартный рабочий поток.

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

  • Инспектор просмотра элементов DOM.
  • Flame-графики в профилировщиках.
  • Диаграммы SQL-таблиц.

Но всё это исключения, а не что-то распространённое. Разве не круто, когда вы можете выявить проблему производительности по flame-графику? И нам нужна эта возможность для всего.
Далее я расскажу о некоторых из этих визуализаций, чтобы вы могли рассмотреть их использование в своей текущей работе или даже интеграцию в существующие среды разработки.

▍ Визуализация базы кода


В этом прекрасном выступлении показано множество способов визуализации различных аспектов базы кода. Множество! Вот несколько интересных конкретно для меня:

  • Sourcetrail: иерархия классов и браузер зависимостей.
  • Treemap: статистический обзор файлов в базе кода.
  • Периодическое сохранение кода.

▍ Sourcetrail


Sourcetrail – это опенсорсный инструмент для визуализации баз кода (закрыт), написанный спикером из выступления выше. Вот прекрасный обзор того, как этот инструмент помогает перемещаться по базе кода. Выглядит он так:



Sourcetrail решает множество типичных проблем дизайна при визуализации кода:

  • Он показывает визуализацию рядом с кодом, при наведении на который подсвечивается соответствующая визуальная часть. И наоборот, при наведении на диаграмму, подсвечивается код. Клик по зависимости переводит вас к отвечающему за неё коду (например, когда одна функция вызывает другую, или один модуль требует другой).
  • Причём этот инструмент продуманным образом скрывает информацию. В базах кода зачастую присутствует слишком много связей для одновременной визуализации. Sourcetrail же изначально показывает только то, что вы, по его мнению, ищите, и для вывода дополнительной информации просит либо кликнуть, либо навести куда-либо. Его интерфейс построен так, чтобы подтягивать потоки, которые кажутся интересными, а не получать общий обзор всей базы кода. Этим он отличается от описанного далее Treemap, который сделан как раз для получения общего представления.

Однако, как показывает демо, Sourcetrail присущ ряд типичных проблем, связанных с подобным способом визуализации:

  • Нет очевидных указаний на то «когда этот инструмент может понадобиться». Выполняя профилирование, вы думаете: «Мне нужен flame-граф». А когда вам нужна эта визуализация?
  • Он не присутствует в тех инструментах, которые я хочу использовать. В демо показано, как пользователь переключается между Sourcetrail и Sublime. Этот тип визуализации кода и навигации по нему должен находиться внутри редактора.

▍ Treemap


В этих видео Джонатан Блоу реализует «карту дерева» для инспектирования различных аспектов кодовой базы. Исходя из видео (я его вьюер не использовал), последняя версия выглядит так:



  • Каждый квадрат здесь представляет файл кода.
  • Размер квадрата отражает размер файла.
  • Цвет квадрата представляет смесь метрик в каждом файле вроде глубины вложенных if, глубины вложенных циклов, количества глобальных считываний и так далее.

С помощью подобной визуализации можно отражать и прочие метрики (size, color) в отношении базы кода, например, (code_size, code_quality), (code_size, heap_access / code_size) и тому подобное.

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

packages/
  first_dependency/
    first_transitive_dep/
  second_dependency/
    second_transitive_dep/
  ...
src/
  bingo/
  papaya/
  lmnop/
  racoon/
  wingman/
  galactus/
  ...

Вы наверняка бегло просматривали такие. Я тоже так делал, когда устраивался в крупную компанию. Когда вы клонируете такой репозиторий и просто по нему пробегаетесь, то по факту не понимаете, что конкретно в нём находится, даже в общих чертах. В примере выше оказывается, что бо́льшая часть кода находится в сервисе racoon/ (3M строк кода) и second_transitive_dep/ (1M строк кода). Всё остальное занимает менее 300К строк и сопоставимо с ошибкой округления. Вы можете работать с такой базой кода годами, не понимая этих базовых фактов.

▍ Диаграмма сохранения кода


Работа Рича Хики «History of Closure» содержит несколько интересных визуализаций, которые помогают понять, как базы кода Clojure развивались со временем. Вот диаграмма сгорания задач, сгенерированная Hercules CLI:



  • Код, написанный в течение каждого конкретного года, представлен здесь своим цветом (например, для 2006 это красный).
  • Если какой-то код удаляется или заменяется на код следующего года, его участок удаляется.
  • Отслеживая цвета, можно видеть остаточный объём кода по годам. Например, код 2006 года (красный) был преимущественно удалён или заменён. А вот код 2011 года (зелёный) с момента своего написания остался практически нетронутым. То же касается почти всех лет3.

▍ Компьютерные сети и топологии сервисов


Если вы когда-нибудь начнёте использовать AWS, то заметите, что документация этой платформы полна диаграмм вроде следующей:



Думаю, эта диаграмма весьма наглядна. Она показывает все задействованные «сервисы» и их связи. В этом случае, если вы знаете, что каждый из них делает, то их взаимосвязанность будет очевидной. (Если же не знаете, придётся читать о каждой).

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

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

Вопрос: «Если вы используете определения сервисов gRPC, то можете ли генерировать на их основе диаграммы?»

▍ Схемы памяти


В этой теме Reddit участник задал вопрос, пытаясь понять схему распределения памяти указателей Rc<T>:

Привет! Хочу понять схему памяти при выполнении следующего фрагмента кода из стандартной библиотеки:

use std::rc::Rc;

let vec_var = vec![1.0, 2.0, 3.0];
let foo = Rc::new(vec_var);
let a = Rc::clone(&foo);
let b = Rc::clone(&foo);

Я представил себе примерно следующую картину её распределения. Верна ли она? Спасибо!




На это один из пользователей ответил такой схемой:



Заметьте, что изначальный код не изменился. Единственное, что указано в ответе – это скорректированная диаграмма. Дело в том, что для задавшего вопрос схема является более эффективной формой представления его мысленной модели, поэтому её корректировка влияет именно на эту модель, но не на сам код.

Завершается обсуждение так (выделение моё):

Здравствуйте! Благодарю за то, что пролили свет на мой вопрос.

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

В книге «Programming Rust» очень активно используются схемы распределения памяти:



Вопрос: «Можете ли вы сгенерировать эти диаграммы прямо из аннотаций типа struct?»

В этом языке есть ещё один способ «распределения памяти»: его модель владения. Независимо от формы и размера данных в памяти, различные ссылки «владеют» другими ссылками, формируя таким образом дерево. Принцип владения лучше всего описывается этой схемой из «Programming Rust»:



Вопрос: «Можете ли вы генерировать деревья владения на основе исходного кода Rust?»

▍ Конечные автоматы


Эти штуки довольно стандартны. В документации Idris с их помощью демонстрируют, о чём пойдёт речь, когда предстоит раскрыть тему новых принципов моделирования конечных автоматов в системе типов. Я считаю, что этот пример полезен на двух уровнях:

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



Вопрос: «Можете ли вы генерировать эти диаграммы напрямую из аннотаций типов Idris?»

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

PaymentIntent является основным объектом, который Stripe использует для представления выполняющегося платежа. С платежом может произойти очень многое, в связи с чем в этом инструменте реализован довольно сложный конечный автомат. Мы с Мишель Бу и Изабель Бенсусан в 2019 году составили для этого механизма вот такую диаграмму конечного автомата, которая показана ниже. Тогда это была одна из первых «диаграмм» в его документации.

Она отражает различные состояния, в которых может находиться PaymentIntent, сопровождая каждый своим UI:



Занятный пример конечных автоматов и их формализации показан в лекции Лесли Лампорта на тему коммита транзакций в TLA+.

▍ Swimlane-диаграммы для визуализации обмена запросами/ответами


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

Вот хороший пример из документации Stripe. В нём показаны все запросы/ответы, происходящие, когда клиент оформляет заказ, сохраняет выбранный способ оплаты и, собственно, платит:



Если вы такой ещё не видели:

  • В столбцах указан тот, кто выполняет запрос (компьютер или человек).
  • Каждая рамка – это действие, которое они могут выполнить.
  • Каждая стрелка – это запрос/ответ между ними.
  • Время, проходящее по мере выполнения запросов.

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

const r = await stripe.confirmPayment();

то можете найти соответствующий ему запрос и просмотреть контекст, в котором он происходит, даже если в окружающем коде этого контекста нет.

Адриенна Дрейфус усердно потрудилась, чтобы создать и стандартизировать эти диаграммы в документации Stripe.

Вопрос: «Можете ли вы генерировать эти диаграммы непосредственно из комплексных тестов, которые написали для своего сервиса?»

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

В Aphyr зачастую используют собственную версию swimlane-диаграмм, чтобы показать, как различные процессы рассматривают состояние в распределённой системе. Например, в анализе Jepsen VoltDB 6.3 они показывают, как различные узлы базы данных могут обмениваться сообщениями:



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

В той же статье показана интерактивная диаграмма по типу swimlane, визуализирующая результаты, полученные от инструмента Jepsen:



  • Теперь каждая «дорожка» является горизонтальным, пронумерованным рядом (10, 11, 18), представляющим процесс, который считывает или записывает данные.
  • В рамках отражены операции процессов, требующие время для своего завершения. Линии представляют логические связи между данными, которые процессы видят. Линии, которые нарушают линейность, отмечены недопустимыми и окрашены красным.

Ещё один крутой пример есть в документации алгоритма Double Rachet мессенджера Signal. Эти диаграммы отслеживают, что конкретно Элис и Бобу необходимо на каждом шаге работы протокола для шифрования и дешифровки очередного сообщения:



Этот протокол достаточно сложен, чтобы я мог воспринять его диаграммы как источник истины. Иными словами, если реализация алгоритма Double Rachet вдруг сделает что-либо, противоречащее диаграммам, то ошибка, скорее, окажется в коде, а не в них. Именно в перечисленных областях, на мой взгляд, визуальное программирование должно являться актуальным средством, но эта тема уже для другой статьи.

▍ Сноски


1. Я не знаю, верен ли код выше – таким я его вывел на основе диаграммы. ↩
2. Это стандартная критика систем визуального программирования, и, на мой взгляд, в этом случае толпа права. Но почему люди продолжают возвращаться к этой технологии? Что им следует делать вместо этого? ↩
3. У Рича также есть отличная презентация истории Clojure, где он рассказывает, почему эти диаграммы сгорания задач выглядят именно так: Clojure с целью сохранения стабильности кода старается избегать его переписывания, за исключением случаев исправления багов.↩

Telegram-канал со скидками, розыгрышами призов и новостями IT ?

Комментарии (14)


  1. markshevchenko
    17.07.2024 14:09
    #27053578

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

    В недалёком будущем, скажем, через 10-15-20 лет легко представить, что компьютер будет похож ни лист ватмана формата А4 или А3. Мы будем его сворачивать, носить с собой, раскладывать на столе, работать.

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

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

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

    Блок-схемы в этот список не попали: я никогда не считал их удобными или удачными.

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


    1. vtal007
      17.07.2024 14:09
      #27054666

      Простите, куда системные блоки сжимаются (причем аж даже стремительно)? они как были коробкой на литров 30-40-50. так и остались со времен IBM-PC (или даже раньше), ток раньше клали горизонтально, а теперь чаще вертикально (на столе, под столом)

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

      Как ни старайся, а 4090 (да хоть 4060) не особо сожмешь


      1. markshevchenko
        17.07.2024 14:09
        #27054686
        +1

        Почему тайваньцев и китайцев? Маломерные форм-факторы — это международные стандарты. Я видел мини-системники производства HP и Dell, не говоря уже об эппловских Mac mini.

        Мне кажется, вы хватаетесь за отдельные исключения, совершенно игнорируя то, что я написал — тенденцию. Не надо вам в футурологи.


      1. DarthVictor
        17.07.2024 14:09
        #27054930

        Было бы желание. Вот например 4090FE в корпусе 5л.

        Но это, конечно, для гиков. Обыватель наоборот будет использовать калорифер литров на сорок.


        1. vtal007
          17.07.2024 14:09
          #27054960

          ну это ж для фана. в массе своей в офисы и людям продают унылые черные коробки (кто-то домой покупает аквариумы. Во-первых это красиво светится)

          у меня самого было nr200, но это совсем не типовая история
          даже больше скажу, "сбор своего компа" это отдельное хобби (которое на пост-СССР живет из-за малых доходов + инженерная культура), для тех же американцев, можно просто купить готовый комп и не заморачиваться

          собственно и у нас можно, но считается "фу, как ты мог" :)

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

          вот кмк, начало популяризироваться SFF, китайцы наплодили неплохих корпусов. Но! внезапно, ITX материнки не дешевые (ну по крайне мере от а-брендов) и самое популярный формат mATX

          Но повторю, сам формат ITX существует довольно давно (ну наверно как сам стандарт АТХ). и скорее можно сказать, что е-атх по сути мертво, а вот и корпуса и материнки АТХ вполне себе существуют. И пока этот формат есть, говорить о трендах по стремительному уменьшению корпусов мягко скажем опрометчиво

          А те, маленькие коробки, с задушенными i3, конечно продаются, но что они реально меняют в плане трендов


  1. LordDarklight
    17.07.2024 14:09
    #27053738
    +9

    Визуальное программирование как полностью самостоятельное направление вряд ли когда-нибудь взлетит. На то есть несколько причин:

    1. Так уже исторически сложилось, что людям проще работать с текстами и под это активно затачивались все текстовые процессоры и IDE - читать и вводить буквы просто проще, как и выполнять разные операции над текстами. Да - визуализация как бы считается более лёгкой для восприятии - но об этом ниже. Да - можно попробовать создать удобную и очень продвинутую IDE и натаскать на неё человека - но уверен сложность такой среды будет куда выше чем у текстового процессора! Хотя, может и удастся с ней работать хорошо натасканному специалисту достаточно просто!

    2. Компьютерным алгоритмам так же куда проще работать именно с текстовым преставлением - и тут вообще ничего не изменится. Кроме того - роль автоматизированной обработки текстов с каждым десятилетием будет расти и расти!

    3. С текущими средствами ввода и манипулирования данными - человеку куда проще вводить данные (алгоритмы) с клавиатуры, чем, скажем, мышью. Вот когда разработают что-то более продвинутое для ввода - может что-то и изменится. Но даже силой мысли или в VR оперировать текстами, мне кажется, по-прежнему будет проще...

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

    5. Визуализация алгоритмов только может стать хорошим подспорьем в стандартных текстовых IDE как отдельный инструмент - либо для простых алгоритмов и новичков, либо как дополнительное средство анализа кода - например при поиске ошибок - т.к. позволяет эффективно визуализировать движение по коду в динамике, в т.ч. в виде активной схемы в реальном времени выполнения!

    6. Так же визуализация может быть удобна для ряд узких задач программирования или для представления данных: это нейросети и какой-либо кластерный анализ


  1. SadOcean
    17.07.2024 14:09
    #27053972
    +2

    Согласен в целом со статьей.
    В моей области (геймдев) есть много попыток использовать визуальное программирование, самое известное наверное Unreal Blueprints - визуальный язык для Unreal engine.
    Но все это считается несерьезным по целому ряду причин.
    Я думаю самая важная - быстро растущая комплексность делает эти диаграммы совершенно нечитаемыми паутинами, а средств организации кода, подобных модулям не придумали. Точнее что-то придумали, но использовать сложно, что противоречит идее "легкого входа". В итоге классический код становится хорошим компромиссным решением между сложностью написания, чтения и распознавания взаимосвязей.

    Но есть много специализированных областей, в которых это может быть оправданно:
    - Редакторы шейдеров. Их можно писать кодом, но в визуальном программировании можно получить визуализацию промежуточных результатов, что обеспечивает глубокое понимание и легкую отладку того, что ты делаешь
    - Редакторы анимаций (по сути машины состояний) - аналогично, даже большие деревья все еще доступны для понимания, все узлы более менее однообразны.
    - Часто делают редакторы квестов/диалогов в виде деревьев. Тут нужно упомянуть, что хотя это и распространенное решение, так же часто используются и DSL, где это описывается обычным текстом. Например многие чатботы содержат деревья с визуальным программированием для начинающих, но более продвинутые версии все равно описываются через DSL
    - Я делал даже небольшой ЯП для геймдизайнеров на объектах, хотя по структуре он был ближе к scratch - скорее там были последовательности команд списками, нежели деревья или визуальное программирование. На самом деле основной плюс такого языка был в том, что не нужно было знать синтаксис, только основные принципы. Команды и переменные выбирались из списка.

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


  1. inkelyad
    17.07.2024 14:09
    #27054124
    +3

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


  1. Fushigi
    17.07.2024 14:09
    #27054152
    +3

    В статье всё намешано. Заголовок про визуальное программирование, но говорим о визуализации кода и данных. Это так то разные вещи.

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

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


  1. NickDoom
    17.07.2024 14:09
    #27054188
    +1

    «Балет на льду и хоккей на траве» ®©™.

    С маниакальным упорством люди пытаются описать логические элементы текстом (VHDL), а алгоритм — диаграммами.

    Начните с визуального «программирования» ПЛИС, может, дальше-то и идти не придётся?


  1. user87644
    17.07.2024 14:09
    #27054302

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


  1. qbertych
    17.07.2024 14:09
    #27054430
    +1

    Рассуждения про бесполезное визуальное программирование без единого слова о Labview, у которого нехилая такая доля рынка промышленной автоматизации - ну такое.


  1. vk6677
    17.07.2024 14:09
    #27054894

    В ПЛК популярны диаграммы и функциональные блоки. Но сложные проекты лучше "текстом" писать.


  1. Format-X22
    17.07.2024 14:09
    #27055058

    Обратите внимание - этот комментарий, другие комментарии, эта статья, эта страница хабра… оно всё из текста. Да, в случае страницы есть интерфейс, а в статье даже есть картинки. Но всё же задумайтесь - сейчас вы читаете этот комментарий текстом. Почему же никто не пишет комментарии картинками? Вот то то и оно.

    Дело в том что мы все имеем опыт в тексте частенько лишь на лет 5 меньше нашего возраста. А самый удобный инструмент тот с которым ты уже давно успешно работаешь, а ещё с ним работают миллионы людей в рамках языка и миллиарды в рамках текста вообще. Если бы мы рисовали картинками слова… то получились бы иероглифы, которые используются также парой миллиардов людей. При этом они также упрощены до штрихов и простых символов. Даже в виде картинок это текст.

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

    Картинки конечно нужны. Но они как пояснение. Действительно - некоторые вещи лучше зарисовать. Не хватает языкам программирования дополнений в виде зарисовок либо крупно-архитектурных моментов, либо наоборот микро… с другой стороны рефакторить и усложнять такое по мере развития проекта - это боль. Потому зарисовать в документации это ок, а вот тащить в код - сомнительно. В конце концов сколько существует книг, поставляемых в формате текста без всего, и всё там прекрасно. Лишь некоторые вставляемые иллюстрации, например фотографии. Или опять же те же общие абстрактные схемы.

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