Главная » Хабрахабр » [Перевод] Визуальное программирование — почему это плохая идея

[Перевод] Визуальное программирование — почему это плохая идея

image

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

Язык визуального программирования — это такой язык, который позволяет программисту создавать программы, манипулируя графическими элементами, а не печатая текстовые команды. Известным примером является Scratch, язык визуального программирования родом из MIT, который используется для обучения детей. Его преимущества заключаются в том, что он делает программирование более доступным для новичков и не-программистов.

Это связано с концепцией «round tripping» («туда и обратно»), где система может быть смоделирована визуально, программный код будет генерироваться из полученных моделей, а любые изменения кода могут быть возвращены обратно в модель. В 1990-х годах было очень популярное движение по внедрению визуального программирования в корпоративную среду с помощью так называемых CASE-инструментов, где корпоративные системы можно было бы определять с помощью UML и генерировать [их код] без необходимости в привлечении обученных разработчиков программного обеспечения. Увы, подобные инструменты так и не смогли выполнить свою миссию, и большинство из экспериментов [по их внедрению] в настоящее время в значительной степени заброшены.
image

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

  • Языки текстового программирования запутывают то, что по существу является простым процессом.
  • Абстракция и декупликация (decoupling, уменьшение связности) играют небольшую периферийную роль в программировании.
  • Инструменты, которые были разработаны для помощи программированию, не важны.

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

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

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

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

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

Между визуальным «кодом» и текстовым кодом существует рассогласование импеданса (набор концептуальных и технических трудностей), и программисту приходится перемещаться по интерфейсу между ними, часто затрачивая больше усилий на усовершенствование самого графического инструмента программирования, чем на решение изначальной задачи [по написанию программы].

image

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

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

По сути разница между хорошим и плохим кодом в основном и заключается в том, насколько программисту удалось это сделать. Большинство профессиональных программистов будут постоянно абстрагировать и декуплицировать код. У инструментов визуального программирования очень редко есть эффективные механизмы для таких вещей, в результате «визуальный» разработчик оказывается в ловушке доступных возможностей, эквивалентной BASIC'у 1970-х годов.

image

Взгляните на длительную эволюцию редакторов кода и сред IDE. Последнее заблуждение состоит в том, что визуальные программисты якобы могут обойтись без всех инструментов поддержки программирования, которые были разработаны на протяжении десятилетий. Отсутствие хорошего контроля над версиями — еще один серьезный недостаток большинства инструментов визуального программирования. Например, Visual Studio поддерживает эффективный инструмент intellisense, позволяющий подсматривать тысячи API-интерфейсов, доступных в одной только в библиотеке базового класса.

Очень трудно сделать 'blame' (найти коммит и ответственного за изменения конкретной строки) в большой глыбе XML или JSON. Даже если они сохраняют свой макет в текстовом формате, «диффы» не имеют никакого или почти никакого смысла. Вещи, которые не имеют никакого значения для функционального исполнения программы, такие как положение и размер графических элементов, при этом постоянно приводят к изменениям в метаданных, что делает «дифф» еще более сложным для синтаксического анализа.

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

Апдейт

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

Я согласен, что они могут быть очень полезными. Другим контр-примером, приведенным в Reddit, были инструменты статической структуры, такие как дизайнеры пользовательского интерфейса, дизайнеры схем баз данных или дизайнеры классов. Но их никогда не бывает достаточно. Все, что помогает визуализировать структуру данных или масштабную структуру программы, является бонусом. Об этом свидетельствует полный провал инструментов из 90-х, таких как Power Builder, которые базировались на графических визуализациях для создания среды разработки без необходимости работать с кодом.

Я Майк Хэдлоу, проповедующий разработчик. Об авторе:
Заметки, мысли вслух, обучение у всех на виду, недоразумения, ошибки, неразбавленные мнения. Я живу недалеко от Брайтона на южном побережье Англии.

Перевод выполнен при поддержке компании EDISON Software, которая профессионально занимается разработкой и тестированием софта.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Иди-ка ты на !@# со своей «токсичностью»

IT — не детский садик. Это место для взрослых, руководствующихся логикой и здравым смыслом. Их не надо опекать, не надо следить за словами, не надо переживать, что у них сформируются комплексы. Если человек некомпетентен, надо дать ему об этом явно ...

nomoregoogle.com — свежий сборник альтернатив сервисам технологического гиганта

Доминация Google в ряде сегментов совокупно с политикой компании стали вызывать так много вопросов в последние годы, что практически на всех тематических форумах и площадках пользователи начали активно делиться своим «Google-free» опытом — информацией о попытках частично или полностью избавиться ...