Sketchware: куда делся блок "add source directly"?
При помощи блока "add source directly" можно было добавлять в проекты код на Java, что открывало перед пользователями Sketchware просто огромные возможности, по сравнению с использованием альтернативных инструментов разработки. Поначалу казалось, что этот "бомбический" блок позволит пользователям обойти много ограничений блочного программирования, но в результате получилось то, к чему разработчики явно не были готовы.
Что же случилось? Как только пользователи увидели возможность использования Java в проектах, они отодвинули блоки в сторону и стали активно использовать код, выходя за рамки скромной базовой блочной функциональности Sketchware. Проекты стали падать чаще, а стабильность работы Sketchware ощутимо снизилась. Пользователи копировали проекты с кодом, но не могли разобраться ни с ним, ни с многочисленными проблемами его использования и, естественно, стали грузить сообщество вопросами. В результате этого очень сильно напряглась не только группа поддержки, но и разработчики, которые сами перестали понимать, чем эти блоки наполняют. Проще говоря, народ стал использовать визуальную среду блочного программирования для текстового программирования на Java и вся идея доступности и надёжности Sketchware для малознакомых с программированием пользователей вылетела в трубу. В оконцовке разработчики признались себе и нам в том, что было ошибкой добавление этого блока в среду разработки Sketchware и сказали, что его удаление позволит "вернуть красоту блочного программирования". Эта фраза, признаться, порядком меня повеселила. Я, наивный, полагал, что блочное программирование используют для простоты, а оказываются - для красоты!
Данная ситуация говорит о многом, и, в частности, о том, что вместо монстрообразной среды разработки Android Studio многие предпочли бы использовать более простые и понятные в работе инструменты, несмотря на всю сложность работы с ними в мобильной среде (на маленьких экранах и без аппаратной клавиатуры). AIDE? Нет, интерес к этому инструменту уже прошёл. Семейство подобных App Inventor сред? Нет, так как для работы с Java нужно вникать в особенности разработки расширений. Скриптовые движки типа DroidScript? Нет, потому что они требуют вникать в особенности использования JavaScript - Java моста. React Native, NativeScript? Нет, понравился Sketchware, в котором можно было быстро набросать интерфейс, а большую часть функциональности реализовать при помощи кода, что, естественно, получалось быстрее возни с блоками.
В связи с вышесказанным возникает вопрос, а насколько вообще реальна интеграция блочного программирования с нативным? Она реальна, но в определённом контексте. Визуальное программирование при помощи блоков ошибочно воспринимается как инструмент для коммерческой разработки. Можно ли на этом или том сделать промышленный продукт, спрашивают пользователи? Им, конечно, хотелось бы без изучения программирования создавать такие же качественные приложения, как и те, кто многие годы изучал языки программирования. Соединили пару десятков блоков, и получили ничем не хуже продукт? Это фантастика, но как хочется в неё верить!
Удалили блок "add source directly", ну и что? А то, что большая часть обучающих материалов по созданию приложений на Sketchware, в которых данный блок использовался, теперь стала попросту бесполезной. Либо пользователям придётся искать старые версии (с большим количеством багов) Sketchware, в которых этот блок ещё использовался.
Можно ли на автомобиле, предназначенном для обучения навыкам вождения, принимать участие в соревнованиях? Наверно, нет. Также и с визуальным программированием, которые изначально проектировались для обучения. Использование их за пределами данных рамок происходит на свой страх и риск, потому что в них изначально не был заложен небходимый для этого фундамент и инструменты. Этажность дома без фундамента можно увеличивать, но вскоре это приведёт к вполне прогнозируем последствиям, что как раз и получилось в случае Sketchware.
Рассмотрим характерный пример - Thunkable X - инструмент, который позиционируется для разработки под iOS и Android. Его движок пишется на React Native и пользователи получают (помимо всего прочего) следующий пирог ограничений и багов:
- от нативных языков
- от React Native
- от Thunkable X
Какое приложение будет работать более устойчиво и адекватно, написанное на нативном языке или с использованием слоёного пирога выше? На нативном! И в нативной разработке проблем хватает, а с увеличением количества надстроек над неё их становится ещё больше! Тот же App Inventor разрабатывается уже более 10 лет, но до сих пор находят баги, потому что изначально в нёго не закладывалась функциональность и надёжность инструментов для промышленной и коммерческой разработки. Значит ли это то, что подобные среды разработки бесперспективны? Нет, если рассматривать их в контексте обучения и персонального использования. Под персональным использованием я понимаю либо использование приложения только для себя на своём устройстве, либо среди относительно небольшой группы людей.
Разработчики инструментов визуального программирования и их небольшие сообщества не имеют возможности полномасштабного тестирования продукта. Инструменты разработки развиваются несколько лет, а на их официальные форумы ежедневно пестрят сообщениями о том, что на каком-то устройстве что-то не работает или работает не так, как должно работать. А вот гарантировать работоспособность приложения для себя и своих друзей (хотя бы и при помощи костылей) вполне реально. Надёжность средств визуальной разработки приложений является достаточной для персонального использования, но резко падает в случае их публичного использования, в отличие от профессиональных инструментов разработки.
Думаю, теперь вы готовы ответить на вопрос о перспективах интеграции визуально блочного и текстового программирования, публичного использования таких проектов, времени доведения их до более или менее функционалного и стабильного состояния, а также назвать причины самых разных ошибок в мобильных приложениях, опубликованных в официальных магазинах.