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

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

Что мы видим, когда заходим на страницу сервисов, предлагающих создавать приложения при помощи блоков? Рекламу о том, что каждый не будучи программистом сможет создавать приложения. После этого открываем среду разработки и видим, что от нас требуется перетаскивать блоки и соединять их друг с другом, а всю проверку корректности наших действий с точки зрения синтаксиса и частично логики берёт на себя система. Удобно и просто? Да, если проект простой, а с ростом его сложности начинаешь понимать, что необходимой функциональности нет и нужно либо искать расширения, либо самому что-то придумать из кучи статичных блоков, которые могут выполнять только одну заложенную в них операцию. Как изменить размер шрифта для 30 кнопок? Последовательно и вручную для каждой кнопки. Пользователь никуда ведь не торопится и ему важнее простота и надёжность, а не практичность и гибкость. Нет? Тогда он может разучить использование циклов и блоков Any, которые частично помогут автоматизировать ручной труд.

Рассмотрим пример такого блока.

На первый взгляд всё просто восхитительно и его функциональность превосходит все самые смелые мечты! Сначала из выпадающего списка нужно выбрать тип компонента – List Viewer. После этого из выпадающего списка выбираем нужный компонент – List_Viewer1.  Затем из выпадающего списка выбираем действие – установить элементы списка, а в самом правом параметре указываем опции для списка через запятую. Ошибиться сложно, поскольку система не даст вызвать несуществующий метод для несуществующего компонента! Ошибку можно совершить только при вводе опций. Но уж это пользователь должен проверить сам.

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

Другой пример.

Блок позволяет программно создавать компоненты! Да, только заранее выбранного типа. Если нужно создать 20 компонентов разных типов, то придётся использовать 20 таких блоков. Представьте ситуацию, вы приходите в строительный магазин и просите молоток:

- Порекомендуйте молоток.
- Вам для каких гвоздей?
- Для соточки.
- Тогда вот этот.
- А для сороковки?
- Вот этот.
- А для десятки?
- Молодой человек, для забивания гвоздей разной длины предназначен свой молоток. Если вам нужно забивать гвозди разной длины, то рекомендую приобрести вот этот набор из 48 молотков.

Абсурд? Да, а как тогда называется показанное на рисунке выше? Защитой от дурака. Но пользователей-то всё устраивает! Большинству важен результат, а не путь, каким он достигается. Если пользователь видит, что для решения задачи ему нужно выложить на экране 700 повторяющихся блоков, то он их будет выкладывать часами, даже не задумываясь о том, что есть более короткие и простые пути её решения. Откуда покупатель узнает, что есть кроссовки Adidas, если вокруг всю жизнь предлагаю сапоги Скороход?

Недавно я решил сделать интерпретатор команд, для программного вызова разных методов разных компонентов. Для этого пришлось создать более 700 блоков, которые можно было бы заменить всего одним динамическим блоком, в котором все параметры задаются при помощи переменных. Конечно, я выбрал задачу, которая не придёт в голову 99% пользователей, но на практике постоянно возникают задачи, для решения которых пользователей заставляют использовать десятки “простых в использовании” блоков. Динамические блоки приведут к увеличению фатальных ошибок? Да, если в системе отсутствует код для корректной обработки ошибок. Если же приложение падает оттого, что вместо числового блока указал текстовой, то в таком случае действительно проще налепить статичных блоков, оправдывая это тем, что пользователи ничего не смыслят в программировании. Так не убирайте статичные блоки совсем, а добавьте динамических.

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

Помимо App Inventor существует с десяток аналогичных платформ, отличающихся друг от друга количеством компонентов и блоков. Но всех их объединяет одно - статичные блоки, которые можно настроить только на этапе разработки приложения. Разработчики сами пользуются гибкими возможностями программных технологий, но всеми силами стараются оградить пользователей от них, придумывая разные мифы. Между тем, если пользователь не понимает логику работы c  циклами, то для него никакой разницы не будет в том, как на экране показан цикл.

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

- Чего грустишь, Петрович?
- А, разочаровал меня двигатель V8.
- Как так?
- Поставил я его на трактор, а он даже "Запорожец" не смог обогнать. Только дорогу гуслями попортил.

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