Платформа Microsoft. NET з точки зору її творців, HTML, XML, DHTML, Інтернет-технології, статті

Однією з найбільш модних тем, що обговорюються зараз розробниками програмного забезпечення, є, безумовно, платформа Microsoft. NET,. NET Framework, а також очікуване в найближчому майбутньому засіб розробки Visual Studio. NET. (Ми теж неодноразово писали про це в нашому журналі і ще не раз повернемося до цієї теми.) Саме про платформу. NET, Visual Studio. NET і про нову мову програмування C #, що увійшло до складу Visual Studio. NET, піде мова в інтерв’ю з Андерсом Хейлсбергом – керівником проекту створення і розвитку мови програмування C # і основним учасником розробки Microsoft. NET Framework – Яке він люб’язно погодився дати відповідальному редактору КомпьютерПресс Наталії Єлманової.


КомпьютерПресс: Що ви можете розповісти про мету створення мови C #? Яка аудиторія його користувачів?


Андерс Хейлсберг: Коли ми створювали мову C #, у нас було кілька цілей. Перш за все – створити перший компонентно-орієнтована мова з сімейства C / С + +. Якщо згадати, як проводилася розробка додатків п’ять і навіть десять років тому, ми побачимо, що багато розробників вже тоді створювали спеціальне оточення для того, щоб організувати запуск програми на вимогу, виконання ним певної задачі і його зупинку. З появою феномена Web і архітектури «клієнт-сервер» природа програм змінилася. Зараз нерідко створюється набір компонентів, що виконуються під управлінням того чи іншого процесу, – бізнес-об’єктів для додатків середньої ланки, збережених процедур в серверах баз даних, і саме сукупність таких компонентів зараз називається додатком.


Крім того, ми мали на увазі і те, яким чином розробники зараз проектують і створюють програмне забезпечення. Сучасний підхід до проектування програм (у тому числі і HTML-сторінок, і бізнес-об’єктів) зазвичай має на увазі використання концепції властивостей, подій і методів компонентів або об’єктів, а також інспектора властивостей для їх зміни. Але якщо подивитися на С + + і Java, то стане зрозуміло, що вони не повністю підтримують ключові концепції компонентів. Такі елементи, як властивості і події, не існують в явному вигляді в цих двох мовах. Замість цього використовуються методи Get_ …, Set_ …, викликані для читання властивостей або їх зміни. Нерідко при застосуванні цих мов для реалізації тієї чи іншої функціональності програми доводиться створювати і використовувати інтерфейси і інші складні адаптери. Звідси випливає, що для компонентно-орієнтованого програмування і для всієї індустрії в цілому надзвичайно важливо вбудувати в мови програмування підтримку концепції компонента. Це і була одна з ключових цілей створення С #.


Нашою метою було також створення більш продуктивної версії С + +. Відомо, що розробники люблять цю мову за його міць і практично необмежені можливості, але проблема застосування С + + полягає в тому, що його потужність використовується протягом 1% часу, а 99% часу йде на те, щоб зрозуміти, яку конструкцію мови застосувати для вирішення тієї чи іншої задачі. Ми вирішили створити спрощену версію С + +, щоб підвищити продуктивність праці розробників. Тому мова C # містить, зокрема, кошти збору сміття, обробки виключень, що робить створені з його допомогою програми більш стійкими і надійними. Слід також відзначити коректну роботу з версіями, обумовлену самою платформою. NET, що позбавляє розробників від проблем, пов’язаних з існуванням різних версій однієї і тієї ж DLL (DLL hell).


І ще одна особливість нової мови – його найкраща інтероперабельність у порівнянні з Java. Звичайно, Java – прекрасний інструмент, але інтероперабельні код, написаний на ньому, виявляється досить дорогим, чого не можна сказати про C #.


КП: Відомо про прагнення Microsoft зробити C # і саму платформу. NET Framework індустріальним стандартом. Як у результаті буде розвиватися ця мова і яким чином в нього будуть вноситися зміни?


А.Х.: Ми вже передали на розгляд ECMA1 всю специфікацію C #, і якщо ця мова стане індустріальним стандартом, то внесення змін до нього буде проводитися відповідним комітетом по стандартизації з урахуванням пропозицій і думок, що надходять від співтовариства розробників (як це робиться з С + +). Ми готові внести свій активний внесок у подальший розвиток С #.


КП: Ви зазначили, що Java – відмінний мова програмування. Але більш важливі не його особливості як мови, а те, що Java зараз – це не просто мова, а платформа для розробки додатків, у тому числі розподілених. Що ви думаєте про те, як відбуватиметься конкуренція між платформами. NET і Java?


А.Х.: Якщо говорити про Java як про платформу для розробки додатків, то вона орієнтована на один-єдина мова – Java. Що стосується платформи. NET, ми спочатку зробили її багатомовною. Створюючи програми для. NET, можна використовувати C + +, Visual Basic, JavaScript, Cobol, Fortran, інші мови програмування. Якщо розглядати. NET з позицій інтероперабельності та повернення інвестицій в створений код, явно видно її переваги – адже на ній можна використовувати раніше створений код.


Ще одна перевага. NET – це орієнтація на XML Web-сервіси, тобто на ту архітектуру розподілених обчислень, яка представляється нам найбільш перспективною. Використовуючи. NET, можна конвертувати об’єкти в XML і назад з нульовими трудовитратами. Оскільки Java як платформа з’явилася раніше, ніж XML, то, природно, можна використовувати XML з Java, але таке використання не буде настільки простим, як у випадку. NET.


Нарешті, я повинен сказати, що у Microsoft і Sun різні підходи до стандартизації. Компанія Sun двічі намагалася зробити стандартом Java, але їй не вдалося переконати комітет з стандартизації прийняти все, що було нею зроблено у цій мові. В даний момент Java не є стандартизованим мовою. Ми ж, зі свого боку, прагнемо до того, щоб зробити C # таким, як і саму платформу. NET.


КП: Якщо продовжити розмову про конкуренцію. NET і Java, чи можна говорити про швидке успіху платформи. NET на ринку корпоративних програм? Чи слід очікувати появи C #-аналогів Java 2 Enterprise Edition, Enterprise Java Beans, підтримки. NET виробниками серверів додатків?


А.Х.: Я абсолютно впевнений, що саме цього і слід очікувати. Ми змагаємося з Java на ринку корпоративних додатків і можемо протиставити цій платформі такі технології, як ASP. NET, корпоративні сервери для. NET (. NET Enterprise Servers).


КП: А що можна сказати про сторонніх виробників серверів додатків – IBM, BEA, Oracle, інших компаній? Адже їхні продукти зараз підтримують Java і CORBA, а не. NET. Чи слід, на ваш погляд, очікувати підтримки. NET в наступних версіях серверів додатків від цих фірм?


А.Х.: Це дійсно так: виробники серверів додатків зараз підтримують Java. Але потрібно розуміти, що це певною мірою ілюзія. Якщо говорити про специфікацію EJB, то це дуже невеликий документ, описує мінімум функціональності. І якщо об’єктивно порівняти EJB для різних серверів додатків, наприклад WebSphere і WebLogic, ми побачимо, що їх код не є стовідсотково стерпним між цими серверами – у кожного з цих серверів є свої особливості.


Очевидно також, що тріщина у взаєминах IBM і Sun зростає. IBM підтримує безліч технологій, включаючи Java. Я думаю, проблема полягає в тому, що Sun, схоже, не прагне передавати специфікацію Java в організації, що відповідають за стандарти. Тому тільки Sun визначає правила, за якими розвивається цю мову.


КП: Повернемося до Java як до мови програмування. Що ви можете сказати про підтримку Java в. NET? Чи означає стратегія JUMP to. NET2, оголошена Microsoft на початку цього року, що Microsoft таким чином прагне повністю позбавитися від Java як від мови?


А.Х.: Ні, зовсім не повністю! Насправді стратегія JUMP to. NET означає приблизно те ж, що і нинішнє наше обіцянку створити таку мову, як J #, – мова з синтаксисом Java для. NET. Зараз нам також потрібні всі аналоги бібліотек Java аж до версії 1.1.4 – це дійсно необхідно для підтримки існуючого Java-коду. Але повної реалізації J2EE для. NET не буде, оскільки це стало б не більше ніж дублюванням вже наявної функціональності.


КП: Що робить Microsoft для підтримки. NET в засобах розробки інших виробників? У Росії, наприклад, є чимала кількість користувачів засобів розробки Borland, і для них це питання досить важливий. Я маю на увазі не Pascal для Visual Studio. NET, а що-небудь типу Delphi. NET c власної середовищем розробки і, можливо, зі своїми бібліотеками класів або компонентів, тобто щось подібне. NET-версії Visual Component Library.


А.Х.: Я не беруся коментувати плани компанії Borland щодо подальшого розвитку її продуктів. Технічна можливість створення Delphi поверх. NET і CLR, безумовно, є. Можна також перенести VCL в. NET. Але вибір залишається за Borland.


КП: Наші читачі, особливо користувачі Delphi, були б раді почути від вас кілька слів про те, як створювався цей продукт, і дізнатися вашу думку з приводу його впливу на подальший розвиток індустрії засобів розробки.


А.Х.: Delphi був створений в лютому 1995 року. Якщо згадати про попередні продуктах Borland, потрібно відзначити, що Turbo Pascal був дуже успішний – продукти з інтегрованими середовищами розробки істотно підвищували продуктивність праці програмістів. Однак перша версія Turbo Pascal для Windows все ж не вирішувала найістотніші проблеми, з якими стикалися розробники Windows-додатків, і нам досить швидко стало ясно, що саме ми повинні зробити для вирішення цих проблем. Створення Windows-програм мало починатися з проектування користувальницького інтерфейсу, і це стало ключовою ідеєю нового продукту.


Коли ми випустили Delphi, він став першим засобом швидкої розробки додатків, заснованим на компільованих мов програмування, тоді як існував у той час Visual Basic міг лише створювати p-код і був, по суті, заснований на інтерпретаторі. Я можу сказати, що саме створення Delphi стимулювало появу компілятора в машинний код в наступних версіях Visual Basic.


КП: Чи слід очікувати більш тісної інтеграції. NET з серверами додатків сторонніх виробників, крім Web-сервісів, наприклад прямого доступу до EJB, підтримки CORBA?


А.Х.: Підтримка прямого доступу до EJB означає додавання Java поверх наявних бібліотек, що мені не видається доцільним. Я думаю, що стратегія, пов’язана з розвитком технології XML Web-сервісів, найбільш підходить для підтримки інтеграції з такими серверами додатків. Зазначимо, що IBM, як і інші великі гравці ринку програмного забезпечення, відносяться до зазначеної стратегії більш ніж серйозно і підтримують її. Саме тому я вважаю, що інтеграція на основі цієї технології – цілком реальне явище.


Особисто я вважаю, що технології, подібні CORBA, нeдостаточно масштабованих. У масштабі локальної мережі ці технології вирішують багато проблем, але, як тільки ми починаємо працювати в масштабі континенту, застосування таких технологій може створити цілий ряд проблем. Головна з них у тому, що метою даних технологій є повна ізоляція програміста від передачі даних. Не отримуючи відгуку від об’єктів, до яких ви звертаєтеся, ви не знаєте, що саме відбувається при передачі даних, і тому повинні щось змінювати в об’єктах, викликати їх знову і знову, щоб розібратися у цих заходах.


Навіть обмежена швидкість світла є проблемою, якщо масштаб програм такий, що ви охоплюєте і Європу, і США. Саме з цієї причини варто повернутися до технологій розподілених обчислень, заснованих на повідомленнях, таких як застосування Web-сервісів. Надійна передача повідомлень дає шанс забезпечити більшу масштабованість, тому ми так глибоко віримо в Web-сервіси.


КП: Велике спасибі за докладні і змістовні відповіді. Ми чекаємо від вас нових ідей і, звичайно, нових продуктів.


Редакція КомпьютерПресс дякує співробітників російського представництва Microsoft за організацію цього інтерв’ю.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*