Архивы: по дате | по разделам | по авторам

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

Архив
автор : Максим Отставнов   20.06.2000

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

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

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

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

Джонатан Свифт. "Путешествия Гулливера" [1]


Всем интересующимся развитием рынка инструментальных средств крайне рекомендую недавнюю статью Рона Петруши, интерпретирующую выступление Билла Гейтса на 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 (обратно к тексту) - Фредерик Брукс, автор самой известной книги о разработке программного обеспечения, пишет, что "был потрясен", когда в первый раз услышал о "построении", а не "написании" программ.



© ООО "Компьютерра-Онлайн", 1997-2019
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.