Доступно об АйТи: Почему не взлетели визуальные языки
Посмотрим на язык программирования Скрэтч. Ну красиво, не правда ли?
В начале 2000-х была мода на визуальный язык UML, сейчас его почти забыли. Попытаюсь рассказать всем не-айтишникам, почему такое не взлетает.
Вообще-то я слегка неправ — кое в каком виде визуальное программирование взлетает. Но все удачные решения делятся на две категории.
Там, где действительно клик выразительнее текста.
Чтобы как-то привлечь к программированию посторонних.
Клик выразительнее текста
Приведу две системы, где один клик делает столько же, сколько пара строчек текста.
Редактор форм типа Embarcadero Delphi и Qt Creator.
Внешний вид формы всегда проще задать визуально, чем запрограммировать текстом.
Любая реляционная СУБД (система управления базами данных традиционного типа с таблицами и ключами), где линиями удобно показывать взаимоотношения между таблицами.
Программирование для посторонних
Иногда удобно привлекать к программированию специалистов в своей сфере — трёхмерщиков, геймдизайнеров, экономистов. Пусть они плохо программируют, зато свои знания успешно применят. Вот, например, редактор материалов из Unreal.
А вот — редактор квестов из «Космических рейнджеров». Тут причины сразу две: и удобно разложить блок-схему квеста на доске, и программист не нужен.
А с профессионалами ответа два.
Вы просто не знаете, чем занимается программист.
Существует очень много специального ПО, ориентированного на текстовые файлы.
Так чем же занимается программист?
Многие из вас водили если не вживую, то на детских машинках, потому пусть будет аналогия с водителем. Он давно заучил, как переключать передачи, он не забывает смотреть в зеркало, ПДД понимает интуитивно. В голове водителя другое: каким путём подобраться к точке, как сэкономить топливо, и как проехать нехороший участок.
Точно так же программист: он, конечно, может ругаться на неудачный синтаксис языка, но думает более сложными абстракциями. Посмотрим снова на первую картинку с пингвином в пустыне и найдём пару мест, которые профессионалу не нравятся.
Программист разделит игру (на чужом движке) на две части: 1) Управление игровой физикой; 2) Общий цикл игры (скобку «forever»), который отвечает за условия выхода из игры, вызовы игровой физики и прорисовщика, ограничение кадровой частоты.
Почему скорость персонажа в 10 пикселей/кадр жёстко прописана? Не лучше ли указать где-то: СКОРОСТЬ_ПИНГВИНА = 10?
А если игра будет управляться и клавиатурой, и джойстиком — программист напишет (или сдерёт) общий «центр управления», а затем будет спрашивать у него: нажата ли кнопка «двигаться вправо»? А уж что это — клавиша →, или D, или ось X джойстика, или крестовина вправо — это дело того самого центра управления.
В тех же «Космических рейнджерах» нередко нарушается знаменитый программистский жупел — «не повторяйся». Например, в игре в кости первый раз результат разыгрывается как [2..12], а дальнейшие — [1..6]+[1..6]. Программист напишет так, чтобы первая и последующие партии управлялись одним и тем же кодом.
Чем хороши текстовые файлы?
Существует широкий набор утилит для работы с текстовыми файлами:
Их можно редактировать редакторами, причём довольно дикими способами — например, скопировать-вставить заголовок цикла и кусок тела, без закрывающей скобки.
В них можно искать файловыми менеджерами.
Работу нескольких человек можно объединять с помощью систем управления версиями.
И всё это нужно программистам. Даже XML снижает полезность этих инструментов.