Pull to refresh
0
Инфопульс Украина
Creating Value, Delivering Excellence

Интервью с Джеффри Рихтером на конференции Microsoft SWIT 2014

Reading time 11 min
Views 11K


27-28 марта в Киеве прошла конференция Microsoft SWIT 2014. В течение двух дней разработчики и ИТ-менеджеры могли увидеть и услышать большое количество выступлений от докладчиков со всего мира.

Самое главное внимание, конечно же, привлекли доклады Джеффри Рихтера. Джеффри – большой авторитет для многих разработчиков, эксперт в технологии .NET и владелец компании Wintellect. У меня состоялось интервью с ним, часть вопросов в котором была задана читателями Хабра. Проговорили мы почти час, кому интересно — добро пожаловать под кат.

(Если вам кажется, что вы этот топик где-то уже видели раньше, то нет, то было одно интервью, а это — другое).

Здравствуйте, Джеффри. Мы большие фаны Ваших книг и презентаций, это большая честь для нас быть сейчас здесь и говорить с Вами.
Спасибо.

Меня зовут Владимир, я пишу на С++, а это мой коллега Александр — .NET-разработчик. Также мы ведём блог на сайте habrahabr.ru, возможно Вы не слышали об этом сообществе, но у нас оно достаточно популярно: около миллиона ИТ-специалистов из России, Украины и других стран. Неделю назад мы анонсировали Ваш приезд на конференцию Microsoft SWIT и предложили людям задавать вопросы. С Вашего позволения, я задам наиболее популярные вопросы читателей, а также несколько вопросов от себя.
Ок.

Давайте представим, что никакого языка C# и платформы .NET не существует и Вам, со всеми Вашими сегодняшними знаниями и опытом поставлена задача разработать их «с нуля». Создали бы Вы их в точности такими, какими они являются сейчас? Возможно, что-то в них изначально сделано плохо? Возможно, Вам бы хотелось добавить что-то важное?
Безусловно, в .NET и C# сегодня есть вещи, которые и Microsoft и лично я хотели бы реализовать иначе. 13 лет назад мир был другим. Сейчас мы сконцентрированы на мобильной разработке, 13 лет назад фокус был на веб-сервисах. Таким образом, что стоило бы сделать, так это создать .NET более «чистым», минималистичным, чтобы он не использовал так много памяти, как это происходит сейчас, не был столь «тяжелым».

Существует ведь .NET Micro Framework — разве он не для этого?
Есть несколько способов посмотреть на платформу .NET. В первую очередь, это набор стандартов, которые любая компания может взять и реализовать, и эти реализации будут совместимы до тех пор, пока они придерживаются стандартов. Сама компания Microsoft поддерживает несколько реализаций .NET:
1. Классическая версия, на которой работают все десктопные программы, сервера с ASP.NET, Silverlight и т.д.
2. .NET Compact Framework
3. .NET Micro Framework

Первой и самой важной реализацией, конечно, был обычный .NET, но потом мы подумали: «а как же на счёт телефонов или часов — устройств, у которых не так много памяти и не такие мощные процессоры?». Не было никакой возможности заставить .NET работать на них достаточно хорошо, именно поэтому и появились «урезанные» версии. Если сегодня всё это можно было написать «с нуля», я думаю, стоило бы выделить небольшое ядро всей платформы — систему CLR-типов и сборщик мусора. Это должна быть основа, а вот всё остальное уже могло бы подключаться к платформе чем-то вроде «плагинов». К примеру, Reflection — достаточно требовательная к ресурсам и медленная технология, при этом не так много программ действительно ею активно пользуются. Мы могли бы, к примеру, оставить Reflection в десктопной версии .NET и убрать из Micro и Compact версий. Таким образом, одно и то же ядро работало бы во всех версиях платформы, что дало бы большую гибкость. А уже команды разработчиков конкретной платформы могли бы добавлять остальной функционал, по модели «plug-and-play». Тебе нужна какая-то определённая функциональность? Ок, возьми и добавь её. Но .NET никогда не проектировался таким образом. Он изначально создавался, как цельная, монолитная платформа.

Но ведь при монолитном подходе мы можем написать приложение — и быть уверенными, что оно заработает везде. А как быть с предлагаемым вами «модульным» подходом?
Приложение может само заявлять, какие «модули» нужны ему для работы. В конце концов, мы и сегодня не можем написать одно приложение, которые бы реально работало на .NET, .NET Micro Framework и .NET Compact Framework. То, что я предлагаю, на самом деле увеличивает гибкость платформы.

Считаете ли Вы, что это было правильным решением Microsoft — выпустить и поддерживать .NET только под Windows? Что Вы думаете о Mono, Xamarin и вообще будущем .NET на платформах, отличных от Windows?
Это хороший вопрос. Определённо, это было политическим решением Microsoft. 13 лет назад Билл Гейтс, Стивен Баллмер и другие, стоявшие у истоков компании люди, решили, что Microsoft делает большие деньги на продаже операционной системы Windows и очень важно укреплять и поддерживать её всеми средствами. Выпуск .NET исключительно под Windows был сильным ходом для этих целей. Что касается сегодняшнего дня, Microsoft определённо уже осознала, что Windows имеет сильных конкурентов (как минимум Android и iOS) и они не представлены на этих платформах. Кроме того, и Билл Гейтс и Стив Баллмер уже ушли из компании, и я думаю, что современный Microsoft будет более открытой компанией. Верю ли я в Xamarin? Несомненно. Люди наконец-то могут писать программы (ну, как минимум их бизнес-логику) один раз и для всех платформ. Да, каждая платформа потребует доработки визуальной части приложения, но это не так страшно. В целом, я считаю, Xamarin очень хорошо продвигает платформу .NET вперёд.

Говоря о разных платформах, некоторые люди спрашивают: «Почему я должен писать код на .NET, получая приложение, способное работать только под Windows, когда я могу взять Qt или Java и создать продукт, который будет работать везде?». Что Вы можете ответить этим людям?
Каждая операционная система имеет свои особенности. Одной из важной особенностью операционной системы является её подход к интерфейсам, взаимодействию с пользователем, интуитивности и простоте работы. Windows в своих последних версиях предлагает собственное видение этих вещей — например, плиточный интерфейс, удобно отображающий «живые» иконки приложений. Мне достаточно открыть стартовый экран — и я уже вижу на плитках мои задачи в календаре, наличие писем в почте, сообщения от моих друзей. Использование этих уникальных для операционной системы элементов делает приложение дружественным, понятным пользователю, а это ведь то, к чему мы должны стремиться. Используя .NET и Windows Runtime такие интерфейсы строить проще, чем с помощью универсальных библиотек, так что Microsoft делает жизнь разработчика более приятной. Кроме того, если, к примеру, пользователь откроет стартовый экран Windows 8 и заметит, что плитка вашего приложения обновилась — это может вызвать у него желание открыть приложение и проверить, что же изменилось, а в этом месте вы можете предложить ему платную услугу или показать рекламу. И вот уже мы видим, как поддержка особенностей Windows-платформы повлияла на монетизацию приложения.
В плане поддержки новых возможностей ОС Windows мне очень нравится Windows Runtime. Это наиболее современный, «чистый» и простой API, который только можно себе представить. На нём писать значительно проще, чем, к примеру, на Objective-C под iOS. Вы можете возразить, что программирование под iOS может приносить больше прибыли сегодня, но Microsoft сегодня делает всё, чтобы завоевать мобильный рынок. Это большая битва и она только началась.

Что Вы думаете о платформе Windows Azure (которая кстати, на днях была переименована в Microsoft Azure)? Что Вы думаете о будущем этой платформы? Не планируете ли Вы написать книгу об Azure?
Да, я уже говорил о том, что напишу книгу об Azure. Вернее, о Microsoft Azure Storage. Когда Azure вышел, я, по правде говоря, не очень в него верил. Я считал, что не пришло ещё то время, когда компании готовы размещать свои данные и сервисы в чужих дата-центрах. Кроме того, Microsoft не имел большого опыта в публичных облачных продуктах — да, на то время уже существовали outlook.com, bing и некоторые другие продукты, но вот именно масштабных публичных облаков у Microsoft не было. Но у них получилось. Со времени появления Azure серьёзно повысилась его надёжность, функциональность, упали цены — и люди поверили в этот продукт. Мы слышим всё новые истории успеха от компаний, использующих Azure. Даже сайт моей компании сегодня работает на Azure, избавляя нас от необходимости думать о массе вещей, о которой нам не хотелось бы думать. Моей любимой частью Azure является Azure Storage. В каждом приложении самым важным является его состояние. Какие данные мы храним, что показываем пользователю. Всё это нужно где-то хранить — и эта задача заботит каждого разработчика. И когда я напишу книгу — она будет именно о том, как Azure Storage позволяет работать с данными, очередями, таблицами, как делать это эффективно, с минимальными затратами. Это большой объём информации, не всё можно найти в официальной документации и рекомендациях Microsoft, я думаю, что смогу осветить важные и интересные детали.

Как Вы считаете, нужно ли обычному разработчику понимать, как Microsoft Azure устроен внутри? Работая с локальными файлами и сервисами я всегда могу понять, почему та или иная операция заняла много времени или завершилась неудачно, у меня есть средства отладки, профилирования. При работе с Microsoft Azure если что-то пошло не так или заняло слишком много времени — я могу лишь догадываться о причинах.
Ну, сервисы Microsoft Azure работают через Интернет, а сеть Интернет, в общем, не имеет стандартов по гарантированной скорости доставки и обработки данных. Проблемы производительности могут быть связаны с вашим устройством, ПО, роутером, провайдером, сервером или его ПО. Я не думаю, что так важно концентрироваться на внутренностях Microsoft Azure. В конце концов, даже в локально работающем .NET-приложении есть много скрытого, неявного поведения, например — работа того же сборщика мусора. Тем ни менее, множество людей пользуются этим сборщиком мусора, получая приемлемые для них скорости работы приложения. Сама по себе операционная система тоже является «чёрным ящиком» — даже при простой операции чтения файла вызываются десятки функций, работает внутренний код ядра ОС, драйверов — вы не знаете детали реализации этих систем, но, пока они работают в устраивающей вас скоростью — вы ими пользуетесь. Так же и с Microsoft Azure: просто попробуйте, если скорость работы вас устроит — пользуйтесь, нет — ок, ищите что-то другое. Мне такой подход кажется нормальным. Люди строят всё более и более высокие уровни абстракции для решения всё более и более сложных задач.

Знакомы ли Вы с проектом Roslyn, предоставляющим API к компиляторам C# и VB.NET? Считаете ли Вы этот проект просто игрушкой, или по-настоящему мощным средством для расширения существующих языков, создания новых важных продуктов? Верите ли Вы в будущее этого проекта?
Да, я знаю этот проект. Его создание заняло весьма много времени, он до сих пор не включен в состав Visual Studio, но он будет становиться всё более и более значимым в ближайшие годы. Проект выполняет сразу несколько задач. Во-первых, он заставил разработчиков компилятора C# переписать его на C#. Поскольку теперь компилятор можно разрабатывать быстрее — скорость внедрения новых фич языка возрастёт. Во-вторых, теперь задача написать средство рефакторинга для C# стала намного проще. Microsoft ожидает появления большого количества таких продуктов, конкуренции между ними и повышения их качества. Кроме того, появилась возможность писать трансляторы кода с одного языка на другой.

Считаете ли Вы, что Roslyn в будущем всегда будет поддерживать последнюю версию компиляторов, со всеми актуальными возможностями языка C# ?
Да, конечно. При разработке Roslyn были реализованы все возможности актуальной на то время версии C#, затем вышла новая версия — C# 6, возможности которой также сейчас добавляются в Roslyn. Кроме того, разработка компилятора языка C# перешла от нативного кода, к коду на самом C#, что также будет способствовать более простой интеграции новых фич в Roslyn.

Как программиста на С++ меня интересует Ваше мнение о C++/CLI и C++/CX. Считаете ли Вы, что у этих проектов есть будущее, как отдельных, целостных языков или их судьба — быть просто мостиком между новыми технологиями Microsoft и старыми проектами с нативным кодом?
C++/CLI — никогда не имел особого успеха. Мне как-то предлагали адаптировать мою книгу по C# к C++/CLI. Проект не состоялся — мы не нашли никого, кто хотел бы и мог бы сделать это. Этот язык был странным начинанием Microsoft для… я даже не знаю… Я никогда не встречал ни одного человека, использующего C++/CLI в качестве основного языка программирования. Что касается C++/CX, его предназначение — упростить работу с COM. COM — технология, созданная ещё в 90-ых, вы сами знаете насколько она ужасна со всеми этим подсчётом ссылок, преобразованием интерфейсов и так далее. Одной из причин появления .NET было именно желание избавиться от этого наследия. Компоненты — это хорошо, а вот вопросами выделения и освобождения памяти пусть занимается CLR, а не программист. В Windows Runtime компания Microsoft вернулась к нативным компонентам, а С++/CX — это способ сделать работу с этими компонентами прозрачной, в стиле работы с компонентами .NET. Сам язык С++ остался прежним, расширение Component Extensions лишь избавляет нас от ужасов работы с COM.

Складывается интересная ситуация — сама Microsoft достаточно активно использует С++ для нативной разработки (тот же Windows Runtime в последних версиях Windows написан не на .NET, а в виде native-компонентов), при этом компания не поощряет сторонних разработчиков к использованию C++, а продвигает .NET и C#. Почему?
Не смотря на большой размер компании Microsoft, её ресурсы всё-таки являются ограниченными. Нельзя охватить всё, нельзя поддерживать все технологии. По каждой вещи принимаются конкретные решения: «Насколько много людей будет этим пользоваться? Каков потенциал развития? Сколько денег компания в итоге заработает?». Очевидно, что основной приоритет у Microsoft сейчас именно на .NET и управляемом коде. Конечно, и C++/CLI и C++/CX будут поддерживаться, баги исправляться, но на активное развитие этих продуктов ресурсов будет выделяться меньше.

Что Вы думаете о будущем текущего стека технологий Microsoft — .NET, C#, Windows Runtime? Можете ли Вы сказать, как они будут развиваться?
Я определённо люблю .NET и C#. И я в этом не одинок. После выхода Windows 8 был момент, когда эти технологии показались… я не скажу заброшенными, но несколько потерявшими позиции. Во-первых, вспомните историю Silverlight. Это подкосило веру в светлое будущее .NET. Кроме того, множество презентаций и примеров говорило о том, что программы для Win8 будут писаться преимущественно на Javascript. .NET программисты чувствовали себя обманутыми — неужели .NET уйдёт со сцены? К счастью, Microsoft вовремя одумалась. Многие люди, продвигавшие те решения, уже не у руля, а большинство приложений в Windows Store написаны на C#. Кроме того, на одной из последних конференций (я не помню точно, на какой), Microsoft продемонстрировала новую версию компилятора C#, способного напрямую генерировать нативный код, без привязки к виртуальной машине .NET, в точности такой код, какой получается на выходе С++ компилятора. Т.е. речь о производительности С# уже не упирается в то, что это не нативный код. Этот компилятор будет выпущен в ближайшие 1-2 года. Таким образом для меня С# остаётся лучшей технологией разработки на ближайшее будущее.

Что Вы думаете о функциональных языках и в частности о языке F#? Считаете ли Вы целесообразным применять эти языки в реальных проектах уже сегодня?
Функциональные языки — это, вообще, не мой профиль. Я совсем мало писал на F#, но знаю, что C# в последних версиях немало идей почерпнул в F# — лямбда-функции, методы-расширения. И вот эти, заимствованные фичи я действительно использую в своей работе каждый день. F#, определённо, не имеет такой поддержки, популярности, статей и книг, как C#. Мысль о его применении может появиться только тогда, когда всего богатства других (не функциональных) языков программирования уже не хватает. Но лично мне редко приходится попадать в такие ситуации, а когда и приходится — мне тяжело оценить, насколько ту или иную функциональность будет проще написать и поддерживать на F#. Программисты, как и люди других профессий, стараются применять на практике те инструменты, с которыми они уже хорошо знакомы. Чтобы перейти на что-то совершенно новые должны быть очень веские причины.

Я хотел бы задать вопрос по поводу Вашего сегодняшнего доклада. Вы рассказывали о модели процессов для приложений из Windows Store. Вы сказали, что каждое приложение находится в песочнице, что изолирует его от влияния остальных приложений и не даёт ему получить доступ к пользовательским данным или повредить систему.
Да, это так.

В то же время, эта песочница не столь совершенна, как, к примеру, песочница приложений в iOS. В операционной системе Windows могут работать не только приложения из Windows Store, но и обычные, десктопные приложения. И они могут получить доступ к процессам приложений из Windows Store — могут их убить, могут перехватить их вызовы, могут даже инжектнуть в них свой код, украв из них пользовательские данные или подделав информацию, которая отображается пользователю. Не считаете ли Вы такую модель небезопасной?
Действительно, процессы приложений из Windows Store живут в песочнице, а десктопные приложения — нет. Это одна из причин, почему Microsoft выпустила специальную версию своей ОС — Windows RT, где обычные приложения работать не могут. На сегодняшний день есть ряд устройств работающих на этой ОС и вот они действительно предоставляют честную, полностью изолированную песочницу. Это очень важно — впервые Microsoft может отказаться от груза поддержки и совместимости со всеми предыдущими своими операционными системами. Это позволяет сделать продукт действительно надёжным, безопасным и современным. Что в этом продукте плохо — это маркетинговая ошибка в наименованиях. У нас есть Win RT как операционная система, Win RT — как устройство на этой ОС, и ещё есть Windows Runtime, что тоже сокращают до Win RT. Однако, всё это совершенно разные вещи, люди немного путаются.
Tags:
Hubs:
+35
Comments 22
Comments Comments 22

Articles

Information

Website
www.infopulse.com
Registered
Founded
1992
Employees
1,001–5,000 employees
Location
Украина