Лапутянский интерфейс

Архив

Всем интересующимся развитием рынка инструментальных средств крайне рекомендую недавнюю статью Рона Петруши, интерпретирующую выступление Билла Гейтса на TechEd...

Всем интересующимся развитием рынка инструментальных средств крайне рекомендую недавнюю статью Рона Петруши, интерпретирующую выступление Билла Гейтса на TechEd, о будущем Visual Basic [2]. Не смейтесь, она не про "бейсик", и я не сошел с ума.

Образцом добросовестности статью Петруши я назвать, к сожалению, не могу. Чего стоит одно только неупоминание в тексте про - 1) RAD, 2) визуальное программирование да еще в связи с 3) платформами от Microsoft - продуктов Borland (ныне Inprise), сыгравшей ключевую роль в популяризации как первого и второго, так и (на свою голову) третьего [3]?!

Однако она меньше набита агитпропом, чем оригинальное выступление главы Microsoft, и смысл из нее выудить легче: основное противоречие инструментальной политики компании, по Гейтсу с Петрушей, в том, что VB был создан как визуальное средство быстрой разработки приложений (rapid application development - RAD), но приложения сегодня - это Internet, а разработчикам для Internet VB сегодня предлагает лишь старое доброе написание текстов программ, безо всякого намека на "визуальность".

Преодолеть это противоречие в Microsoft планируют уже к выпуску следующей версии Visual Studio (7.0) [4].

Анализа рыночного контекста, в который попадет VB после такого перепозиционирования, и Гейтс, и Петруша избегают, предпочитая общие фразы о "цифровой экономике" и т. п.

Можно ерничать сколько угодно по поводу уже продемонстрированной пригодности VB для быстрой разработки сетевых вирусов (и макровирусы, и недавний ILOVEYOU), но гораздо интереснее понять, "против кого" в Microsoft хотят подружить Internet с визуальной разработкой приложений.

Возможно, что все это можно рассматривать как всего лишь очередной выпад против Java (и тогда не случайно выступление Гейтса пришлось как раз к открытию дней JavaOne), но если в Microsoft все это серьезно, то они, фактически, претендуют на место, занятое сегодня открытыми средствами, прежде всего, Perl [5] - совершенно невизуальным инструментом RAD для Internet.

Проблема (и для Misrosoft, и для других) с Perl - в том, что это открытое средство. В качестве "очевидного" примера успехов открытого софта в персональном компьютинге чаще всего называют Linux, однако Linux - это всего несколько десятков миллионов пользователей, а Apache и Perl "используют" все пользователи Internet, хотя бы на серверной стороне своих приложений [6].

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

Проще буквально на порядок, чем любым другим известным мне способом [7]. Конечно, за счет производительности (клей-код [glue code] будет интерпретироваться) и безопасности (если машинка в сети, механизм ограничения прав доступа, реализованный Web-сервером, станет критичным для безопасности данных), но именно на эти жертвы мы заранее готовы пойти, если решаем задачу методами RAD.

Web как концепция и Apache с Perl как инструменты, ее реализующие, давно "съели" 90% "интерфейсных" проблем, а мы этого и не заметили.

Но смешнее всего не это, а дальнейший анализ. Средства RAD призваны решать задачи двух классов. Во-первых, это создание короткоживущих приложений (чаще всего, предназначенных для утилизации данных, унаследованных от выводимых из эксплуатации программных средств) [8].

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

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

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

С точки зрения теоретика системного проектирования, это ужасно. Однако, если посмотреть на вычислительную среду как экосистему (перейдя от метафоры "построения" софта [9] к метафоре его "выращивания"), вроде бы, все нормально.

Стоит ли пытаться решить задачу "осеменения" территории Web большим количеством проектов (из которых выживут - каламбур - самые живучие) за счет привлечения лапутянским интерфейсом с яркими картинками большой массы неграмотных "программистов", я не знаю. С удовольствием посмотрю, как в Microsoft будут это делать. В любом случае, принцип Шоу ("Создай систему, которой сможет пользоваться идиот, и только идиоты будут ей пользоваться") очерчивает огромный сегмент рынка.

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

---

1 (обратно к тексту) - Пер. с англ. под ред. А. Франковского. - М.: "Московский рабочий", 1958, с.213.

2 (обратно к тексту) - Ron Petrusha. Visual Basic (and Microsoft) Face the Future, vb.oreilly.com/news/teched_day1.html.

3 (обратно к тексту) - Все равно что текст про Октябрьскую революцию без упоминания Лео Троцкого... впрочем, все мы читали такие учебники в школе.

4 (обратно к тексту) - Точнее, "альфа-релиз - этим летом, бета-релиз - осенью, а финальный релиз - когда будет готово" (там же).

5 (обратно к тексту) - И отчасти другими открытыми языками - Tcl, Python и пятком-десятком более эзотерических и специализированных средств.

6 (обратно к тексту) - Вопреки распространенному мнению Perl может очень эффективно использоваться и на клиентской стороне; есть даже книга трехлетней давности, в которой это "разжевывается" очень подробно: Clinton Wong. Web Client Programming with Perl. Automating Tasks on the Web. - O'Reilly, 1997, ее текст доступен на www.oreilly.com/openbook.

7 (обратно к тексту) - Включая использование Delphi - самого эффективного из известных мне специализированных средств RAD. Если Inprise перетащит-таки Delphi на современные платформы, это ничего не изменит.

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

9 (обратно к тексту) - Фредерик Брукс, автор самой известной книги о разработке программного обеспечения, пишет, что "был потрясен", когда в первый раз услышал о "построении", а не "написании" программ.