Автор перевода писал(а):Это мой перевод чужой статьи, которая нужна для более глубокого понимания цикла статей, которые я собираюсь написать.
Автор оригинала: Scott Ferguson, один из создателей VB.
Оригинал находится здесь: http://www.forestmoon.com/birthofvb/birthofvb.html
Visual Basic был зачат, когда «Ruby» впервые повстречался с «Embedded Basic» в августе 1989. Ruby был «инструментом для построения пользовательских оболочек», изначально созданный Аланом Купером и его командой разработчиков и купленный Биллом Гейстом и Microsoft с первоначальным намерением включить его в состав Windows 3.0.
Embedded Basic (EB) был движком ЯП (языка программирования), который был разработан для включения в СУБД под кодовым названием «Omega». Я не был приближённым к процессу принятия решений или причинам, по которым Ruby был отвергнут командой разработки Windows. Описание этой истории смотрите в статье Алана Купера «Почему меня называют отцом Visual Basic'а». Билл Гейтс послал обращение к менеджменту группы разработки языков программирования для бизнеса с целью узнать, можем ли мы найти какой-нибудь способ подружить Ruby c EB. Джон Файн — старший менеджер программы на тот момент — был поставлен перед задачей дать ответ на это обращение, и я был привлечён к этому как разработчик EB с опытом разработки для Windows с целью технической консультации.
На тот момент группа разработки языков программирования для бизнеса (Business Languages group) была организована в составе подразделения Data Applications Business Unit (DABU) и сфокусирована на разработке продукта Omega, попутно занимаясь поддержкой QuickBasic'а и BASIC-компилятора. Но сильные кадры были задействованы в расширенном исследовании, проектируя новую, объектно-ориентированную, базирующуюся на Windows бейсиковую среду разработки будущего под кодовым названием «Silver» («Серебро»). Так что было, по понятным причинам, значительное сопротивление этим попыткам отвлечься на создание «проходного» продукта с тратой на это ценных ресурсов и порождением кошмара из проблем совместимости с тем, какое виденье будущего имеет группа.
Ни для кого не будет сюрпризом, что всегда проще продать идею нового продукта, когда существует иллюзия, что самая большая часть работы уже сделана; хотя я определённо не верю, что у Билла была такая иллюзия. Его стремление добиться, чтобы из этого что-то получилось нельзя было оставить без внимания, но можно было свести на нет, собрав команду из наименее ценных кадров. Хотя большинство было «зелёными» новичками как руководители в Microsoft, они всё-таки были высококвалифицированными личностями, жаждущими получить возможность проявить себя.
Скотт Фергюсон (это я) был зачислен в команду как руководитель разработки и архитектор проекта (впервые). Адам Раух, только что нанятый на работу, был привлечён в качестве менеджера программы (впервые). Вместе мы «рулили» представлением о том, каким должен быть VB, от этапа первоначальных сырых черновиков спецификации продукта и вплоть до релиза продукта. Крис Фралей, тоже только что нанятый, стал первым разработчиком VB и был особо незаменимым при проектировании и разработке архитектуры улучшенного (по сравнению с Ruby — прим. пер.) движка форм. Брайан Льюис был главным разработчиком команды EB, которая, главным образом концентрируясь на проекте Omega, могла выделить немного ресурсов и на VB-специфичные задачи, по крайне мере в самом начале. Рик Олсон был впервые нанят на роль главного тестировщика. Нэвет Баскер была впервые назначена менеджером продукта, а Брайан Оверленд был главным техническим писателем. Таким образом был рождён «Thunder».
Ruby использовал систему обмена сообщениями между контролами, основанную на строках (напоминающую мне HyperCard). Первые осторожные наброски идеи подразумевали простую замену непродуманного «строкового» языка программирования на Бейсик. Но эти сообщения были сделаны под основанную на графах модель пользовательских интерфейсов, сложность которой довольно плохо масштабировалась от конструктора оболочек до среды программирования общего назначения. Так что такие идеи стали вскоре считаться не стоящими того. Модель, основанная на событиях, разрабатывалась для проекта Omega, и могла быть доделана до унифицированной концепции, пригодной и для VB и для долгосрочных планов относительно ООП. Нам был нужен их (проекта Omega — прим. пер.) редактор кода, чтобы заставить её работать. Так что, хорошо это или плохо, но мы решили воспользоваться уже существующим кодом, портировав его из проекта Omega в проект VB. Учитывая то, насколько сильно этот код был завязан на сложную архитектуру Омеги, это было примерно эквивалентно тому, чтобы залезть в обезьяньи мозги и отщипнуть только те кусочки мозгового вещества, которые отвечают за зрение.
Так что получилось так, что VB состоял из трёх важных и примерно эквивалентных частей: движка языка программирования EB, состоящего по большей части из очень мудрёного ассемблерного кода, впервые портированного под Windows, движка форм, построенного поверх незнакомого нам кода Ruby, попавшего к нам из-за пределов Microsoft, и оболочки, включающей редактор и фундаметальные вещи от проекта Omega, наряду с кодом управления проектами и прочими UI-вещами, написанными с нуля нами.
Объединение этих разрозненных частей воедино было сложнейшей проблемой, широту которой было трудно объяснить в терминах планирования и сроков тем, кто сидел с убеждённостью, что соединение вместе этих «готовых к употреблению» кирпичиков должно быть проще простого. В частности, модель сообщений Ruby совершенно не соответствовала намеченной нами событийной модели VB с её понятиями о зоне видимости модулей и событиях уровня форм. EB тогда ещё не был таким пакетом, предполагающем лёгкое повторное использование, каким VBA станет впоследствии. Это был не тот случай, когда можно было поставить новую EB DLL и двигаться дальше. Все следы существовашего в Ruby языка программирования должны были быть вырезаны и обращения к EB поставлены на их место. Повторяющийся между всеми тремя компонентами и избыточный код нужно было выявить и унифицировать по мере того, как развивался общий базис проекта.
Расширение масштабов решаемой проблемы с конструктора оболочек до среды программирования общего назначения объясняет сдвиг сроков и пересмотр графика — с «проходняка» на 6 месяцев до 18-месячного полномасштабного проекта. Дополнения и расширения Ruby, точнее лишь малая часть из них, включают в себя:
- Множество новых контролов, свойств и событий.
- Поддержка графических конструкций из Бейсика (линии, окружности, эллипсы, масштабирование) была добавлена формам и новому элементу управления PictureBox, включая поддержку сохранения и перерисовки графики при переотрисовке окон.
- Функционал системных объектов для таких вещей, как буфер обмена, коллекция шрифтов.
- DDE (ныне архаичный способ установления связей между приложениями).
- Распечатка форм.
- Зацепки, чтобы сделать систему справки, локализацию и компьютерное обучение.
В конечном итоге движок форм эволюционировал в ответ на постепенно изменяющиеся требования до такой степени, что осталась лишь малая часть кода оригинального Ruby, которую вообще можно было распознать. Но по прежнему оставалась ключевая концепция его базовой архитектуры, которая служила центром кристаллизации, вокруг которого могла нарастать новая технология. Тогда как по окончании разработки мы стали экспертами по подводным камням разработки UI в Windows, в начале у нас были лишь поверхностные знания. К счастью, в первые переходные месяцы к нашим услугам был гуру-разработчик Ruby Майкл Гири для того, чтобы познакомить нас с внутренним устройством Ruby и научить нас хитрым путям обуздания Windows USER API в тех ситуациях, о которых большинство Windows-разработчиков вообще никогда не задумывалось и в которые не попадало, но которые довели бы их до нервного срыва при работе над VB.
Поддержка custom-контролов была, вне всякого сомнения, самой важной концепцией Ruby, перенятой от него VB, и возможностью, которая чаще всего упоминалась как ответственная за степень успеха VB. Сама по себе возможность custom-контролов долгое время была кандидатом на исключение из списка возможностей. Но как разработчики мы ухватились за неё и оставляли ей шанс на жизнь даже по мере того, как архитектура претерпевала значительные изменения, в надежде, что эту возможность «воскресят». Высокая цена, которую потребовала эта возможность, была обусловлена по большей части трудозатратами на её тестирование и документирование. Нужно было бы ещё приложить усилия, чтобы найти и скоординироваться со сторонними разработчиками, которые написали бы свои custom-контролы, которые бы шли в комплекте с новым VB; плюс ресурсы разработки на оказание содействия этим начинаниям. В какой-то момент отдел маркетинга даже намекнул нам, что если мы не выпустим продукт к Рождеству, мы не будем выпускать его вообще! К счастью, терпеливый гений Билла взял верх, и он настоял, чтобы мы подкорректировали график и отложили выпуск ради custom-контролов. Опять таки, осознание, что что-то «почти сделано», повлияло на решение добиться того, чтобы оно было сделано. И как результат этого — родилась целая новая «доморощенная» отрасль.
Никакой продукт не разрабатывается в полностью изолированных условиях, и в Microsoft особенно требовали поддерживать всевозможные «стратегические» технологии компании, такие как accessibility, неотступление от постоянно сменяющихся стандартов единого оформления пользовательских интерфейсов в Windows, спецификация только что появившейся и многообещающей технологии OLE (Object Linking and Embedding). Эта нагрузка на VB1, на самом деле, меркнет по сравнению с масштабом сегодняшних требований. Она также меркнет по сравнению с теми ограничениями, которые перед VB1 ставили проекты Omega и Silver. Оба они определённо давали преимущества за счёт дополнительных умов, раздумывающих над решением схожих (связанных) проблем и предлагавших решения, имевшие ценность и для VB. Оба они в то же время отнимали ресурсы, которые могли бы быть направлены непосредственно на VB, и утраивали количество работы по взаимокоординации и разрешению спорных моментов, необходимой, чтобы справиться с пересечением трёх спутанных друг с другом спецификаций продуктов. Судьба распорядилась так, что проект Omega выбросили на помойку (где-то в начале или середине 1990 года), и команда EB переключилась на работу почти целиком над VB. И в итоге, конечно, проект Silver со своим виденьем будущего вольётся в VB. Но не до того, как выйдет Thunder.
Дальнейшие подробности разработки VB1 будут определённо нудными. Я вспоминаю, как кто-то рассказывал мне, что около 70 человек из разных сфер деятельности были задействованы в проекте, включая значительный вклад со стороны отдела поддержки продуктов и наших талантливых практикантов из Ватерлоо. Мы всей командой полетели в Атнанту на конференцию «Мир Windows '91», на которой Visual Basic версия 1.0 была официально представлена миру. Позже в 1991 на «PC Magazine Technical Excellence Awards» в Лас-Вегасе Адам и я получили высокую награду за VB в номинации «Средства разработки».
Перед самым концом стадии разработки меня спросили, составляет ли оригинальный код Ruby хотя бы 15% или больше от кода всего продукта, чтобы определить, достойны ли создатели Ruby быть упомянуты среди создателей продукта. Учитывая то, что, грубо говоря, треть от всего продукта составлял движок форм, и оставшиеся различимые части Ruby были точно меньше половины от него, я мог бы сказать: «нет». Но я предложил, что справедливо будет округлить проценты в большую сторону, учитывая, что VB скорее всего вообще бы не состоялся, если бы не Ruby, «свалившийся» на нас.
Так что получилось, что истинная ценность Ruby была не в его коде или технологии, а в том, что он был той искрой, из которой разгорелось пламя VB. Поскольку титул «отец Visual Basic'а», похоже, уже занят, я, пожалуй, соглашусь на роль «матери» и разделю этот титул со всеми теми, кто в действительности перенёс муки работы над ним.
18 февраля 2016 мне была оказана большая честь и привилегия принять награду «D.I.C.E. Awards Technical Impact», присуждаемую Microsoft Visual Basic. Эта награда — признание влияния, которое оказал VB на индустрию компьютерных игр, и отражение заслуг не только команды VB версии 1 и версии 2, частью которой я был, но и всех, кто был после нас и сделал его одним из самых широко используемых языков программирования в мире. Я до глубины души тронут тем, что спустя почти 25 лет нашу работу всё ещё по достоинству оценивают. Видео вручения награды — здесь.
Это фотография руководителей команды VB, которая была в брошюре по поиску новых кадров, выпущенной после выхода VB1. «Приходите в Microsoft — и вы тоже сможете работать над крутыми проектами!». Фотограф решил, что ему нужны дополнительные люди для лучшей сбалансированности кадра, так что он позвал двух своих ассистентов в качестве «статистов».
А вот фотография меня с наградой «PC Magazine», взятая из той же брошюры. Клянусь, я никогда не носил галстук на работе. Фотограф настоял. (И рубашка тоже не моя!)
В январе 1989, задолго до того, как нас познакомили с Ruby, Джон Файн написал предложение о создании языка программирования под названием Visual BASIC. Это название вновь всплыло из ниоткуда и стало рассматриваться наряду со многими другими перед самым релизом Thunder'а, и нравилось, на самом деле, далеко не всем. Почти всем нравилось название «Thunder» (Гром) и его тогдашним слоганом “The Power to Crack Windows” («Мощь, которая заставляет дрожжать окна» или «Сила, раскрывающая Окна»).
Группа ЯП для бизнеса была всегда очень, ОЧЕНЬ дотошной, когда дело касалось обратной совместимости. Мой первый значительный вклад в общее дело на работе в Microsoft заключался в ускорении функций графического ядра BASIC-рантайма, чтобы мы могли посоревноваться c Borland'овским TurboBasic'ом. Мне удалось добиться значительных улучшений (примерно в два раза) в алгоритме отрисовки линий путём рисования всегда слева направо, чем был упрощён внутренний цикл отрисовки. Но это привело к накоплению ошибки в алгоритме Брезенхема с противоположного конца отрезка в половине испытываемых случаев. В итоге некоторые точки в составе линии могли оказаться смещёнными на один пиксел по сравнению с тем, как рисовала предыдущая реализация. Результат не был неправильным, он был просто другим. В общем, чтобы эту переделку одобрили, времени ушло почти столько же, сколько на саму переделку — и всё из-за опасений нарушить обратную совместимость.
Ни до, ни после я не видел продуктов, которым бы уделялась такая тщательность и тестирование качества. Используя мощь собственной программируемости VB для тестирования самого себя, наша команда тестировщиков добилась покрытия кода тестами на уровне около 95%. И, будучи вовлечёнными в разработку юнит-тестов и процесс сборки, они помогли обеспечить высокий уровень качества на всём протяжении разработки.
Расширение VBX, применённое для custom-контролов, было придумано разработчиком по имени Ли Актон, который в VB1 был ответственен за большую часть редактора, код управления проектами и общие моменты по пользовательскому интерфейсу.
Разработка VB началась до того, как Windows 3.0 упростила управление памятью, устранив 64-килобайтые лимиты, привносимые сегментированной моделью памяти. VB впоследствии выйдет через год после выхода Win 3.0, но всё ещё оставалось нежелание со стороны менеджмента и отдела маркетинга отказываться от поддержки старого «реального режима» и пользователей, чьи компьютеры могли не поддерживать новый и более продвинутый режим виртуальный памяти. Совещания по рассмотрению текущего состояния проекта с участием Билла Гейтса часто после своего завершения подвергались переосмыслению, когда разные подотделы выкручивали смысл сказанного Биллом Гейтсом так, как лично им было выгодно. Но его слова «к херам реальный режим» было сложно истолковать неправильно, как и недооценить, насколько они облегчили разработку.
Тим Патерсон — отец MS-DOS, был ключевым разработчиком в команде EB. Он умеет одновременно уместить в регистрах больше переменных, чем кто-либо другой, кого бы я знал! Зацените его статьи в разделе «Истоки DOS»