WPF в Visual Studio 2010: причины

Здесь рассказали о причинах, по которым в Visual Studio 2010 был использован WPF. Если опускать всю воду, то получается следующий список (в порядке описания разработчиком Visual Studio):

1. надо было использовать WPF в каком-то известном приложении MS по маркетинговым причинам;
2. архитектура Visual Studio, продолжашая эволюционировать с Visual C++6, начала мешать добавлению новых возможностей в студию.

Если 2-ю причину я могу принять и понять - нужно отбрасывать старое и развязывать логику и пользовательский интерфейс, чтобы удобней было жить потом. То 1-я причина (использование студии для раскрутки WPF) вызывает некоторый дискомфорт в мозгах - "Юзают мой любимый инстумент для раскрутки какой-то технологии, которую я из c++ и попробовать-то не могу!". 

А дальнейшее разъяснение, что использование WPF в студии, так и не было доведено до конца, начинает уже ставить большие знаки вопроса - зачем браться и делать на условных "62%". 

В целом странные ощущения от студии 2010 - реализация части функционала из C++0x, унифицированая система сборки проектов, и в то же время странное решение о использовании WPF для IDE.

Статья Саттера об асинхронном API

Недавно вышла новая статья Herb Sutter'а "Prefer Futures to Baked-In "Async APIs" , в которой он анализирует различные варианты как предоставлять асинхронность операций API. В конце статьи Саттер приходит к выводу, что лучше такого не предоставлять отдельное асинхронное API, т.к. любая реализация будет мешать пользователю библиотеки, и тогда разработчик, который пользуется этой библиотекой, сможет сделать асинхронность так, как удобно именно ему, а не какому-то стороннему дяде (привет Adobe с их C++ PDF API), и только для тех функций, которые нужны ему в асинхронном виде. Как один из плюсов такого подхода, Саттер приводит остановку бессмысленного раздувания программных библиотек.

Вот интересно, а сам Саттер понимал, что его статья подтолкнёт программистов, которые используют сторонние библиотеки, к удобной им реализации асинхронности функций, даже в ущерб уже доступному асинхронному API? И зная Саттера с его стремлением к concurrent коду и эффективной реализации многопоточности, можно сказать, что он сознательно провоцирует на это.

Читайте Саттера, кто этого ещё не делает, и обдумывайте прочитанное - возможно самое вкусное вы пока не заметили.