Коли у 1996 році легендарний розробник мов програмування Андерс Гейлсберг перейшов до Microsoft, за його плечима вже були Turbo Pascal і Delphi — інструменти, що задали стандарт інтегрованих середовищ розробки для ПК. У Redmond його покликали робити те саме, але для Java: очолити створення Visual J++, а згодом — допомогти компанії переосмислити всю стратегію керованих мов. Цей поворот, підсилений гучним судовим позовом Sun проти Microsoft, зрештою привів до появи C# і платформи .NET — однієї з найвпливовіших технологій у корпоративній розробці за останні два десятиліття.
Від Delphi до Java: навіщо Microsoft був потрібен Visual J++
До приходу в Microsoft Андерс Гейлсберг уже встиг змінити індустрію двічі. Turbo Pascal у 1983 році об’єднав компілятор, редактор, бібліотеку виконання та інтерактивне середовище в одному продукті, який продавався за $49,95, тоді як типові компілятори коштували близько $500. Turbo Pascal був швидким, компактним і інтерактивним — саме тому в назві з’явилося слово “Turbo”. Це був не просто компілятор, а цілісний досвід розробки.
Наступним кроком став Delphi — компільована, об’єктно-орієнтована альтернатива Visual Basic для створення Windows‑додатків і клієнт‑серверних систем. Delphi принесла в маси VCL (Visual Component Library) з наслідуваними компонентами та drag‑and‑drop‑дизайном форм. Саме на Delphi було написано оригінальний десктопний клієнт Skype для Windows, який залишався на цій технології до свого виведення з експлуатації.
Microsoft уважно спостерігала за цим успіхом. Компанії був потрібен хтось, хто вмів не просто проєктувати мови, а створювати цілі екосистеми розробки з інтегрованими інструментами. У середині 90‑х Java стрімко набирала обертів, і Microsoft прагнула зробити для Java на Windows те саме, що Delphi зробила для нативних додатків. Так у 1996 році Гейлсберг приєднався до компанії, щоб спроєктувати Java‑інструменти нового покоління — Visual J++.
Visual J++ мав стати відповіддю Microsoft на популярність Java: знайомий синтаксис, але глибока інтеграція з Windows, кращі інструменти та продуктивність, орієнтована на корпоративних розробників, які вже жили в екосистемі Microsoft.
Visual J++ 6.0: Delphi‑подібна продуктивність для Java на Windows
Кульмінацією цієї стратегії став Visual J++ 6.0. На відміну від “чистих” реалізацій Java, які суворо дотримувалися кросплатформеного бачення Sun, Microsoft робила ставку на те, що більшість її клієнтів будують саме Windows‑додатки. Тому Visual J++ 6.0 поєднав одразу кілька ключових ідей, які Гейлсберг відточив ще в Turbo Pascal і Delphi.
По‑перше, це була інтерактивна RAD‑модель (Rapid Application Development). Розробник працював не лише з компілятором, а з повним циклом: редагування, компіляція, запуск, налагодження — усе в одному середовищі, максимально інтерактивно. Це переносило досвід Delphi в світ Java: швидкі ітерації, миттєвий зворотний зв’язок, мінімум тертя між кодом і виконанням.
По‑друге, Visual J++ 6.0 отримав Windows Foundation Classes (WFC) — настільну бібліотеку класів для Windows, яка дозволяла будувати нативні GUI‑додатки на Java з тією ж продуктивністю розробки, що й у Delphi. WFC фактично ставала для Java на Windows тим, чим VCL була для Delphi: компонентною моделлю, заточеною під конкретну платформу, а не абстрактний “напишіть один раз — запустіть будь-де”.
Це був свідомий компроміс: менше кросплатформеності, зате більше продуктивності й глибшої інтеграції з Windows. Для Microsoft, яка заробляла на операційній системі та інструментах для неї, це виглядало логічно. Але саме тут і почався конфлікт із Sun.
Суд Sun проти Microsoft: кінець Visual J++ і початок переосмислення
Sun Microsystems контролювала бренд Java та його специфікацію. Ліцензія вимагала, щоб реалізації Java були сумісні з офіційними стандартами й не розмивали обіцянку кросплатформеності. Підхід Microsoft із Visual J++ і WFC — орієнтація на Windows, додаткові API, які не працювали на інших платформах, — Sun сприйняла як порушення цієї угоди.
Судовий позов Sun проти Microsoft щодо Java став поворотним моментом. У підсумку саме цей конфлікт фактично поставив хрест на Visual J++ як на довгостроковій платформі. Для Microsoft стало очевидно: будувати майбутнє розробки на технології, юридичний і технічний контроль над якою належить іншій компанії, — стратегічний ризик.
Втрата Visual J++ змусила Microsoft переосмислити всю стратегію керованих мов. Компанія вже бачила переваги віртуальних машин, байткоду, збирача сміття та винятків — усе це давала Java. Але тепер потрібно було створити власну платформу, яка б поєднувала ці ідеї з глибокою інтеграцією в екосистему Microsoft і не залежала від зовнішніх ліцензійних обмежень.
Так народилася концепція .NET — і разом із нею нова мова, яка мала стати центральною точкою тяжіння для розробників Microsoft.
.NET і C#: керований рантайм плюс мова як єдина платформа
На відміну від Java, де мова й віртуальна машина були жорстко пов’язані, Microsoft із самого початку задумувала .NET і C# як дві сторони однієї, але все ж таки розділеної системи.
.NET замислювався як керований рантайм із власним байткодом, збирачем сміття, системою винятків і бібліотеками, який міг би стати спільною основою для кількох мов. C# — як нова об’єктно-орієнтована мова, максимально природно “лягаюча” на цей рантайм і водночас здатна об’єднати два головні табори розробників Microsoft: тих, хто писав на Visual Basic, і тих, хто працював із C++.
Ідея полягала не лише в тому, щоб створити “ще одну мову”. C# і .NET мали стати платформою, яка:
поєднує простоту та швидкий вхідний поріг, знайомий користувачам Visual Basic, з потужністю й контролем, до яких звикли C++‑розробники;
надає єдину модель типів, винятків, пам’яті та компонентів для всіх мов, що працюють на рантаймі;
усуває фрагментацію інструментів і бібліотек, яка виникала, коли кожна мова мала власний стек.
Це був урок, винесений як із досвіду Delphi, так і з історії Visual J++: мова й інструменти мають проєктуватися разом із платформою виконання, а не поверх неї. .NET і C# із самого початку створювалися як єдиний задум — керований рантайм плюс мова, які підсилюють одне одного.
Мова‑агностичний рантайм: спільний байткод для VB, C++, C# та інших
Ключовою відмінністю .NET від попередніх платформ Microsoft стала принципова мовна незалежність рантайму. Якщо у світі Win32 кожна мова фактично компілювалася в нативний код і працювала з API на своїх умовах, то .NET пропонував спільний керований байткод і модель виконання.
Рантайм .NET був спроєктований так, щоб:
виконувати код, написаний на різних мовах, але скомпільований у спільний байткод;
забезпечувати єдину систему типів, яку розуміють усі мови, що працюють на платформі;
дозволяти Visual Basic, C++, C#, а також іншим мовам (включно з нішевими чи академічними) співіснувати в одному процесі, викликати одна одну й ділитися об’єктами без “клейового” коду.
Це була спроба вирішити давню проблему Microsoft: як підтримувати різні стилі програмування й різні спільноти розробників, не множачи при цьому платформи. Замість того щоб змушувати всіх переходити на одну мову, компанія створила спільний фундамент, на якому могли співіснувати різні синтаксиси й парадигми.
У цьому сенсі .NET став логічним продовженням ідей, які Гейлсберг відпрацьовував ще в Turbo Pascal і Delphi: не просто мова, а повний стек — від рантайму до інструментів — має бути узгодженим і цілісним. Тільки тепер цей стек був задуманий як багатомовний.
C#: об’єктно-орієнтована мова для керованого байткоду
На цьому спільному фундаменті C# мав стати “рідною” мовою .NET — тією, що найкраще відображає модель рантайму. Дизайн C# від самого початку був орієнтований на керований байткод, збирач сміття та винятки.
Мова будувалася як повністю об’єктно-орієнтована: класи, інтерфейси, наслідування, поліморфізм — усе це мало працювати максимально природно в межах керованого середовища. Водночас C# мав бути достатньо знайомим для розробників із досвідом у C і C++: фігурні дужки, вирази, оператори — усе виглядало очікувано, але з додатковими гарантіями безпеки й керованості.
Збирання сміття стало базовою частиною моделі: розробник більше не мусив вручну керувати пам’яттю, як у C++, але й не втрачав контроль повністю — можна було, наприклад, використовувати небезпечний код у спеціальних блоках, коли це було виправдано. Винятки стали стандартним механізмом обробки помилок, інтегрованим у саму мову й рантайм.
Це поєднання знайомого синтаксису, керованого виконання й об’єктної моделі дозволило C# стати природним “містком” між світом нативного C++ і світом керованих мов, які до того асоціювалися насамперед із Java.
Єдина об’єктна система: boxing, reflection і компоненти як громадяни першого класу
Однією з найважливіших інновацій C# стала уніфікована об’єктна система, тісно пов’язана з рантаймом .NET. Мова не просто додала класи й об’єкти — вона запропонувала цілісну модель, у якій навіть базові типи інтегрувалися в загальну систему.
По‑перше, C# запровадив чіткий поділ на типи значень і типи посилань, але при цьому дозволив “упаковувати” (boxing) значення в об’єкти. Це означало, що навіть примітивні типи могли поводитися як об’єкти, коли це було потрібно, наприклад, для роботи з колекціями, які оперують загальними посиланнями. Рантайм розумів цю модель і забезпечував прозоре перетворення між значеннями й об’єктами.
По‑друге, C# отримав потужну систему рефлексії на рівні рантайму. Програма могла досліджувати власні типи, методи, властивості та події під час виконання, створювати об’єкти динамічно, викликати методи за іменем. Це було критично важливо для побудови фреймворків, інструментів, ORM, серіалізаторів і, зрештою, для самого середовища розробки.
По‑третє, C# зробив властивості, методи й події громадянами першого класу в мові. Властивості дозволяли описувати доступ до стану об’єкта через get/set‑аксесори в єдиному синтаксичному блоці, який для споживача виглядав як звичайне поле. Події стали вбудованим механізмом публікації‑підписки, інтегрованим у типову систему.
Це було прямим продовженням компонентно-орієнтованого мислення, яке лежало в основі Delphi. У світі .NET компоненти — візуальні чи невізуальні — могли експортувати властивості, методи й події в стандартизований спосіб, який розуміли як рантайм, так і інструменти на кшталт Visual Studio. Інструменти могли відображати властивості в дизайнері, підключати обробники подій, генерувати код — усе завдяки тому, що ці конструкції були частиною самої мови, а не лише конвенцією.
Уніфікована об’єктна система C# таким чином стала фундаментом для компонентно-орієнтованої розробки на .NET, де мова, рантайм і інструменти працюють як єдине ціле.
Висновок: поразка Visual J++ як умова народження C# і .NET
Історія переходу Андерса Гейлсберга до Microsoft, злету й падіння Visual J++, а потім народження C# і .NET — це приклад того, як технологічні й юридичні обмеження можуть підштовхнути компанію до створення чогось принципово нового.
Visual J++ 6.0 показав, що Java на Windows може бути такою ж продуктивною й інтерактивною, як Delphi, якщо поєднати RAD‑підхід і спеціалізовану бібліотеку класів на кшталт WFC. Але судовий позов Sun проти Microsoft продемонстрував і зворотний бік залежності від чужої платформи: будь-яке відхилення від “чистої” специфікації може стати стратегічною пасткою.
Відмова від Java як основи для керованих мов змусила Microsoft створити власний стек: .NET як мовно-агностичний керований рантайм і C# як мову, спроєктовану спеціально під нього. Уніфікована об’єктна система, boxing, рефлексія, властивості й події як громадяни першого класу — усе це стало відповіддю на потребу в компонентно-орієнтованій, інструментозорієнтованій платформі, яка могла б об’єднати розробників Visual Basic і C++.
Сьогодні C# і .NET залишаються центральними технологіями для величезної кількості корпоративних систем, і їхні корені — у тих рішеннях, які приймалися в Microsoft наприкінці 90‑х, коли компанія змушена була відмовитися від Visual J++ і побудувати власну екосистему керованих мов із нуля.
Джерело
TypeScript, C# and Turbo Pascal with Anders Hejlsberg — The Pragmatic Engineer