Письмо о стратегии VI
From The Joel on Software Translation Project
Автор: Джоэл Спольски
Переводчик: Евгений Виговский
В оригинале статья называлась Strategy Letter VI и была написана 18 сентября 2007
IBM только что выпустила офисный пакет с открытыми исходниками под названием IBM Lotus Symphony. Похоже на «Ещё один дистрибутив StarOffice». Но я подозреваю, что они хотят стереть из памяти людей настоящий Lotus Symphony, который в своё время объявили чуть ли не вторым пришествием, а он оказался совершенно никчёмным. Это был аналог Джильи из мира программ.
В конце 80-х в Lotus ломали голову, что же делать дальше с их флагманским табличным и графическим продуктом, Lotus 1-2-3. Возникло две очевидных мысли: во-первых они могли добавить функций. Например, встроить текстовый редактор. Получившийся продукт был назван Symphony. Другая мысль, которая тоже казалась очевидной, это создать трёхмерный редактор таблиц. Так получился 1-2-3 версии 3.0.
Обе задумки столкнулись с серьёзной проблемой — старым ограничением DOS на 640 Кбайт памяти. IBM уже начала поставлять несколько компьютеров с чипами 80286, которые могли адресовать больше памяти, но в Lotus решили, что найдётся не так много людей, готовых потратить на компьютер 10000 $. Поэтому они всё ужимали и ужимали. Потратив 18 месяцев на то, чтобы втиснуть 1-2-3 для DOS в 640 Кбайтов, они потеряли уйму времени и, в конце концов, отказались от трёхмерности, чтобы таки запихнуть всё в память. В случае же Symphony они просто резали функции направо и налево.
Ни один из путей не оказался верным. К тому времени как был выпущен 1-2-3 версии 3.0, у всех уже были 80386-е с двумя или четырьмя мегабайтами оперативной памяти. К тому же в Symphony были невнятные таблицы, невнятный текстовый редактор, и ещё несколько невнятных вещей.
«Это всё замечательно, папаша, — скажете вы. — Но кого волнуют старые программы для текстового режима?»
Потерпите меня ещё минуту, потому что история повторяется ещё в трёх случаях, и можно сделать выгодную ставку на то, что результаты будут такими же.
Мало памяти и слабые процессоры
С начала времён и до, скажем, 1989 года, программисты вынуждены были заботиться об эффективности. Тогда просто не было столько памяти и не было столько процессорных тактов.
В конце 90-х некоторые компании, включая Microsoft и Apple, заметили (просто немного раньше, чем все остальные), что закон Мура позволяет не очень сильно переживать из-за производительности и использования памяти, а просто создавать классные вещи и ждать, пока железо подоспеет. Microsoft выпустила первую версию Excel для Windows в то время, когда 80386-е были слишком дороги, но они были терпеливы. Через пару лет вышел 80386SX и любой, кто мог позволить себе 1500-долларовый клон, мог запускать Excel.
У вас, как у программиста, благодаря копеечным ценам на память и удвоению скорости процессоров каждые два года, есть выбор. Можете потратить шесть месяцев, переписывая внутренние циклы на ассемблере, или потратить шесть месяцев играя барабанщиком в рок-н-рольной группе, и в обоих случаях ваша программа будет работать быстрее. У программистов на ассемблере нет фанаток.
В общем, мы больше не беспокоимся о производительности и оптимизации.
Кроме одного случая: браузерного JavaScript'а, работающего в AJAX-приложениях. А так как в этом направлении движется практически всё программирование, тут есть над чем подумать.
Многие из сегодняшних AJAX-приложений имеют мегабайт с лишним клиентского кода. На этот раз это не ограничение по памяти или тактам процессора, теперь это ширина канала и время компиляции. В любом случае, вам надо очень сильно постараться, чтобы заставить прилично работать сложные AJAX-приложения.
Впрочем, история повторяться. Каналы становятся дешевле. Люди придумывают, как прекомпилировать JavaScript.
Разработчики, которые прикладывают много усилий в оптимизацию и делают компактные и быстрые программы, однажды проснутся и обнаружат, что усилия были потрачены зря в большей или меньшей степени. Или, в крайнем случае, можно сказать, что «это не дало конкурентного преимущества в долгосрочной перспективе», если вы человек, разговаривающий как экономист.
Разработчики, которые наплевали на производительность и ринулись добавлять классные функции в свои программы, получат в долгосрочной перспективе лучшие программы.
Переносимый язык программирования
Язык программирования С был изобретён с явной целью — упростить перенос программ с одного набора команд на другой. И он неплохо справился, правда не был на сто процентов переносимым, поэтому мы получили Java, которая была ещё более переносимой, чем С. Хм-м-м.
Сейчас основная беда переносимости это — та-да! — клиентский JavaScript, и особенно DOM в браузерах. Написание приложений, которые работают во всех браузерах, это сущий кошмар. Просто ничего не остаётся, кроме исчерпывающего тестирования под Файрфоксом, IE6, IE7, Сафари и Оперой, и знаете что? У меня нет времени тестировать под Оперой. Фигово быть Оперой. У начинающих браузеров нет ни единого шанса.
Что же должно произойти? Ну, вы можете умолять Microsoft и Файрфокс быть более совместимыми. Удачи. Можете пойти по пути p-code/Java и соорудить небольшую песочницу поверх базовой системы. Но песочницы это тормозильницы, они медленные и лажовые, вот почему Java-апплеты сдохли, сдохли, сдохли. Создавая песочницу, вы обречены на одну десятую скорости базовой платформы, и обречены никогда не поддерживать все классные функции, которые есть на одной из платформ, но нет на других. (Я всё ещё жду, когда мне покажут Java-апплет для телефона, который может работать со всеми функциями телефона, вроде камеры, адресной книги, SMS-сообщений и GPS-приёмника).
Песочницы не работали тогда, и они не работают сейчас.
Что же должно произойти? Победители сделают то же, что уже сработало в Bell Labs в 1978 году, — создадут язык программирования наподобие С, который будет переносимым и эффективным. Он будет компилироваться в «родной» код (родным в данном случае будет JavaScript и DOM) с разными кодогенераторами для различных целевых платформ, в которых помешанными на производительности будут программисты компиляторов, а не вы. Он будет таким же производительным как обычный JavaScript с полным доступом к DOM в едином стиле, и он будет компилироваться в родной код для IE или Файрфокса автоматически и без проблем с переносимостью. И, да, он залезет в ваш CSS и искромсает его отвратительным, но гарантированно корректным способом, чтобы вы никогда больше не думали о несовместимости CSS. Никогда. О, что за славный это будет день!
Интерактивность и стандарты пользовательских интерфейсов
Мэйнфрейм IBM 360 использовал пользовательский интерфейс под названием CICS, который вы до сих пор можете увидеть в аэропорту, если перегнётесь через стойку регистратуры. Это зелёный экран 80 на 24 символа, только текстовый режим, разумеется. Мэйнфрейм отправляет форму «клиенту» (клиент — это интеллектуальный терминал 3270). Терминал интеллектуальный, он знает, как отобразить вам форму и позволяет вам вводить в форму данные, не обращаясь к мэйнфрейму вообще. Это было ещё одной причиной, почему мэйнфреймы были настолько мощнее Unix’а: процессору не надо было заботится о редактировании строк, эта было свалено на интеллектуальный терминал. (Если вы не могли себе позволить поставить всем интеллектуальные терминалы, вы покупали миникомпьютер System/1, который подключался между терминалами и мэйнфреймом и управлял редактированием форм.)
В общем, после того как вы заполнили форму, вы нажимали «отправить», и все ваши ответы отправлялись на сервер для обработки. Потом машина присылала другую форму. И так снова и снова.
Ужас. Ну и как вы сделаете в такой системе текстовый редактор? (Вообще-то никак. Для мэйнфреймов никогда не было нормального текстового редактора.)
Это был первый этап. Это в точности соответствует эпохе HTML в интернете. HTML — это CICS со шрифтами.
Второй этап начался, когда все купили себе домой персональные компьютеры, и внезапно программисты получили возможность пихать текст по всему экрану, где захотят, когда захотят, и могли даже считывать каждое нажатие клавиши. Теперь вы могли сделать симпатичную быструю программку, которой не нужно было ждать, когда вы нажмёте ОТПРАВИТЬ, чтобы подключить к работе процессор. Например, вы могли сделать текстовый редактор, который автоматически переносил слово на новую строку, когда текущая строка заполнялась. Сразу же. О, боже мой! Вы можете делать такое?
Проблема со вторым этапом была в том, что не было ясных стандартов пользовательских интерфейсов… у программистов было слишком много свободы, поэтому все всё делали по-разному. Если вы умели пользоваться программой X, пользоваться программой Y вам было тяжело. WordPerfect и Lotus 1-2-3 имели совершенно разные системы меню, клавиатурные интерфейсы и структуры команд. О копировании данных между этими приложениями даже речи не шло.
И это в точности там, где сейчас мы с AJAX-разработками. О да, конечно, пользоваться ими намного удобнее, чем программами DOS первого поколения, так как с тех врёмен мы многому научились. Но AJAX приложения не целостны, и они очень плохо работают друг с другом: вы не можете вырезать и вставлять объекты из одного AJAX-приложения в другое, например, я не знаю, как перетащить картинку из Gmail во Flickr. Эй, ребята, копирование и вставка были изобретены четверть века назад!
Третий этап для персональных компьютеров это Macintosh и Windows. Стандартизированный, единообразный пользовательский интерфейс, с такими наворотами как окна и буфер обмена, которые были разработаны для того, чтобы приложения могли работать вместе. Из-за возросшего удобства использования новых интерфейсов произошёл взрыв популярности персональных компьютеров.
А так как история повторяется, можно ожидать некоторой стандартизации AJAX-овских пользовательских интерфейсов примерно в том же направлении, как в своё время было с Microsoft Windows. Кто-то напишет новый SDK, с помощью которого можно будет создавать мощные AJAX приложения с одинаковыми элементами пользовательского интерфейса, которые умеют работать вместе. И чей SDK сумеет завоевать больше умов разработчиков тот и получит такой же бастион в конкурентной борьбе как Microsoft с их Windows API.
Если вы сам веб-разработчик и не собираетесь поддерживать SDK, с которым работают все остальные, вскоре вы обнаружите, что пользователи не захотят использовать ваше веб-приложение, ведь оно не поддерживает, знаете ли, копирование и вставку, синхронизацию адресной книги и все те чудеса, которые мы будем принимать как данность к 2010 году.
Представьте себе, например, что вы Google с Gmail’ом, и очень довольны собой. Но затем кто-то, о ком вы никогда не слышали, наверное, какой-нибудь стартап Y Combinator’а, вызвал забавный интерес, продавая NewSDK, сочетающий отличный переносимый язык программирования, компилирующийся в JavaScript и, что ещё лучше, огромную AJAX-библиотеку, включающую в себя все функции для взаимодействия с другими программами. Не просто копирование и вставка — мощные сложные функции, вроде синхронизации и единого централизованного управления учётной записью (поэтому вам не нужно говорить Facebook и Twitter, что вы делаете, можно всё ввести в одном месте). А вы смеётесь над ними, потому что их NewSDK занимает целых 232 мегабайта… 232 мегабайта JavaScript’а, и чтобы загрузить страницу, требуется 76 секунд. Поэтому ваше приложение Gmail не теряет пользователей.
Но потом, пока вы сидите в гугл-кресле в гугл-комплесе, попивая гугл-чино и чувствуя глубокое удовлетворение, выходят новые версии браузеров, которые поддерживают кэшированный скомпилированный JavaScript. И внезапно NewSDK становится быстрым. А Пол Грэм даёт им ещё 6000 пачек доширака, чтобы они остались в бизнесе ещё на три года, совершенствуя его.
А ваши программисты, чётр возьми, распустили нюни: Gmail огромен, мы не можем перенести Gmail на этот дурацкий NewSDK. Нам придётся изменить каждую строчку кода. Блин, да это же будет полной переделкой, вся программная модель перевёрнута с ног на голову, она рекурсивна и в ней столько скобок, что даже Google не может их купить. Последняя строка почти каждой функции состоит из 3296 закрывающих скобок. Придётся купить специальный редактор, только чтобы их подсчитать.
А пишущие на NewSDK ребята выдают приличный текстовый редактор, приличный клиент для электронной почты и органайзер — убийцу Facebook и Twitter, которые синхронизируется с чем угодно, поэтому люди начинают ими пользоваться.
И пока вы не придаёте этому значения, все начинают использовать приложения на NewSDK, и они замечательны, и внезапно бизнесы хотят только NewSDK-программы, а все эти классические чистые AJAX-приложения выглядят жалкими, потому что они не умеют копировать и вставлять, и интегрироваться, и синхронизироватся, и играть вместе на барабанах. И Gmail становится устаревшим. WordPerfect электронной почты. И вы будете рассказывать своим детям, какой у вас был восторг от двухгигабайтного почтового ящика, а они будут смеяться над вами. У них в лаке для ногтей больше двух гигабайтов.
Безумная история? Подставьте вместо «Google Gmail» «Lotus 1-2-3». NewSDK будет вторым пришествием Microsoft Windows, именно так Lotus потерял власть над рынком электронных таблиц. И это случится снова, на сей раз в вебе, потому что все факторы и течения в силе. Единственное, чего мы пока не знаем, это деталей, но это случится.
