Письмо о стратегии 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 были невнятные таблицы, невнятный текстовый редактор, да и вообще немало было невнятного.
«Это все замечательно, папаша», скажете вы. «Но кого волнуют старые текстовые программы?»
Прошу вас немного потерпеть, потому что история повторяется в трех разных направлениях, и если все делать по уму, то надо быть к этому готовым.
[edit] Мало памяти и слабые процессоры
С начала времен и до, скажем, 1989 года, программистов крайне волновала эффективность. Тогда просто не было так много памяти и так много процессорных тактов.
В конце 90-х некоторые компании, включая Microsoft и Apple, заметили (просто немного раньше, чем все остальные), что закон Мура позволяет не очень сильно переживать из-за производительности и использования памяти... а просто создавать всякие клевые штуки, и ждать пока подоспеет железо. Microsoft выпустила первую версию Excel для Windows в то время, когда 80386-е были слишком дороги, но они набрались терпения. Через пару лет вышел 80386SX и любой, кто мог позволить себе потратиться на клон за 1500$ мог запускать Excel.
Как программист, благодаря копеечным ценам на память и удвоению скорости процессоров каждые два года, вы можете выбирать. Можете потратить шесть месяцев, переписывая внутренние циклы на Ассемблере, или потратить шесть месяцев играя барабанщиком в рок группе, и в обоих случаях ваша программа будет работать быстрее. У программистов на ассемблере нет фанаток.
Вобщем, больше мы не беспокоимся о производительности и оптимизации.
Кроме одного случая: браузерного JavaScript-а работающего в AJAX приложениях. А так как в этом направлении движется практически все программирование, тут есть над чем подумать.
Многие из сегодняшних AJAX приложений могут похвастаться мегабайтом с лишним клиентского кода. На этот раз ограничение не по памяти или тактам процессора, теперь это ширина канала и время компиляции. В любом случае, вам надо очень сильно постараться, чтобы заставить прилично работать сложные AJAX приложения.
Впрочем, история имеет свойство повторяться. Каналы становятся дешевле. Люди придумывают как прекомпилировать JavaScript.
Разработчики, которые вложили много труда в оптимизацию, заставляя приложения загружаться и работать быстро, однажды поймут, что все в какой-то мере было напрасно, или, в крайнем случае, можете сказать, что «это не принесло конкурентного преимущества в долгосрочной перспективе», если вы предпочитаете разговаривать как экономист.
Разработчики, которые проигнорировали производительность и рванули добавлять клевые фишки в свои приложения, получат в долгосрочной перспективе лучшие приложения.
[edit] Переносимый язык программирования
Язык программирования С был изобретен с явной целью - сделать перенос приложений с одного набора команд на другой проще. И он неплохо справился, правда не был 100% переносимым, поэтому мы получили Java, которая была еще более переносимой, чем С. Ммммммм.
Сейчас основная беда переносимости это – тада! - клиентский JavaScript, и особенно DOM в веб браузерах. Написание приложений, которые работают во всех браузерах, это сущий кошмар. Просто нет другого выхода, кроме полного тестирования на Firefox, IE6, IE7, Safari и Opera, и знаете что? У меня нет времени тестировать под Opera. Фигово быть Oper-ой. У начинающих браузеров нет ни единого шанса.
Что же должно произойти? Ну, вы можете умолять Microsoft и Firefox быть более совместимыми. Удачи. Можете пойти по пути p-code/Java и соорудить небольшую песочницу поверх базовой системы. Но песочницы это тормозильницы, они медленные и лажовые, поэтому Java апплеты сдохли, сдохли, сдохли. Создавая песочницу, вы не претендуете больше чем на одну десятую скорости базовой платформы, и никогда не сможете поддерживать все модные функции, которые есть на одной платформе, и нет на других. (Я все еще жду, когда мне покажут Java мидлет для телефона, который умеет работать со всеми функциями телефона, вроде камеры, адресной книги, SMS сообщений или GPS приемником).
Песочницы не работали тогда, не работают они и сейчас.
Что будет дальше? Те, кто посообразительней сделают то же, что уже сработало в Bell Labs в 1978: создадут переносимый и эффективный язык программирования наподобие С. Он будет компилироваться в «родной» код (родным в данном случае будет JavaScript и реализации DOM) с разными кодогенераторами для различных целевых платформ, которые вылизаны одержимыми производительностью фанатами для того, чтобы вам о ней больше не вспоминать. Он будет таким же производительным как обычный JavaScript с единым способом доступа ко всем возможностям, и он будет компилироваться в родной код для IE и родной код для Firefox автоматически и без проблем с переносимостью. Да, он доберется и до вашего CSS и сделает с ним что-то ужасное, каким-нибудь непотребным, но все же корректным способом, поэтому вам больше никогда не придется думать о несовместимости CSS. Никогда. Ах, что это будет за славный день.
[edit] Интерактивность и стандарты пользовательских интерфейсов
Мэйнфрейм IBM 360 использовал пользовательский интерфейс под названием CICS, который вы до сих пор можете увидеть в аэропорту, если перегнетесь через стойку регистратуры. Это экран с зелеными символами размером 80 на 24 знакоместа, который, разумеется, работает только в текстовом режиме. Мэйнфрейм отправляет форму «клиенту» (клиент это умный терминал 3270). Терминал умный потому, что он знает, как отобразить форму и позволяет вам вводить данные в форму, не обращаясь к мэйнфрейму вообще. Отчасти поэтому мэйнфреймы были гораздо мощнее, чем Unix, процессору не надо было управлять вашим вводом, за это отвечал умный терминал. (Если вы не могли себе позволить поставить всем умные терминалы, вы покупали миникомпьютер System/1, который подключался между терминалами и мэйнфреймом и управлял вводом).
Как бы то ни было, после того как вы заполнили форму, вы нажимали ОТПРАВИТЬ, и все ваши ответы отправлялись на сервер для обработки. Потом машина присылала другую форму. И так снова и снова.
Уродство. Ну и как вы сделаете в такой системе текстовый редактор? (Вообще-то никак. Для мэйнфреймов никогда не было нормального текстового редактора).
Это был первый этап. Это в точности то же самое, что и эпоха HTML в интернете. HTML это CICS со шрифтами.
Второй этап начался, когда все купили себе домой персональные компьютеры, и внезапно программисты получили возможность распихивать текст по всему экрану, где угодно, когда угодно, и могли даже считывать каждое нажатие клавиши, теперь можно было сделать симпатичное быстрое приложение, которому не надо будет ждать, когда вы нажмете на ОТПРАВИТЬ, чтобы подключить к работе процессор. Например, вы можете сделать текстовый редактор, который автоматически переносит слова на новую строку, когда текущая строка кончилась. Сразу же. О, боже мой. Вы уже можете?
Во время второго этапа была другая проблема – не было ясных стандартов для пользовательских интерфейсов... у программистов было слишком много свободы, поэтому все всё делали по-разному. Из-за этого зная как пользоваться программой Х, использовать программу 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 не теряет пользователей.
Но потом, пока вы сидите в googleкресле, стоящем в googleplex-е попивая googleчино, и чувствуете себя живее всех живых, выходят новые версии браузеров, которые поддерживают кэшированный скомпилированный 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 потерял власть над рынком электронных таблиц. И это случится снова, на сей раз в вебе, потому что все факторы и течения в силе. Единственное чего мы пока не знаем, это деталей происходящего, но это случится.
