Да. Но при этом вы правы в том смысле, что в C bool — это действительно просто целочисленный тип, у которого допустимыми значениями является 0 и 1, а true и false — это всего лишь #define на них, а не полноценные ключевые слова-литералы, как в C++.
Я бы не назвал это мейнстримным языком. Мейнстрим — это C#, Java, JavaScript, PHP.
Впрочем, даже если опустить эту планку, суть аргумента не меняется — наиболее популярные языки-последователи этой темы не касались, при том, что была масса других нововведений.
AST там есть, начиная с VS 2010 — собственно, на нем работает текущий IntelliSense (который, наверное, был первым автозавершением для плюсов, которое реально работало на любом коде — помню, как в свое время меня глубоко поразило то, что оно смогло обработать полиморфный function object, созданный через Boost.Lambda), и подсветка типов и разных видов переменных в VS 2012. Просто к нему еще не успели прикрутить все то, что давно было для того же C#.
Как минимум, в студии 100% надежно (начиная с VS 2010) работает code completion для плюсов, в том числе для весьма зубодробительных случаев с хитровывернутыми шаблонами (вроде std::bind, например). Единственная известная мне IDE, которая умеет что-то хотя бы отдаленно похожее для плюсов — это KDevelop. В том же Qt Creator, например, не дополняются настолько тривиальные вещи, как работа с элементами std::vector<std::string>.
То же самое с подсветкой типов etc. По сравнению с каким-нибудь Notepad++, в VS есть огромное отличие — он подсвечивает именно типы (после разбора дерева, инстанциации шаблонов etc), а не просто матчит кусок кода по регекспу «это примерно похоже на тип в объявлении». Опять же, если вы знаете плюсы, то должны знать и то, что в общем случае даже просто отличить объявление переменной от выражения требует разворачивания всех задействованных в выражении шаблонов — т.е. это не просто парсинг.
Если вы видели стандарты языков Java и C++, то причина, по которой для последнего реализовать всякие рефакторинги, и даже, вроде бы, тривиальные вещи вроде перехода к определению, сложнее на порядок, должна быть очевидна.
Причина очевидна — в языке уже есть аж целых два идиоматических способа выразить бесконечный цикл; зачем добавлять сахар, который не делает код ни короче, ни понятней?
Кстати, заметьте, что ни один мэйнстримный ЯП с си-подобным синтаксисом не ввёл такой сахар — хотя в других областях понадобавляли много чего, вплоть до лямбд. Это как бы говорит нам о ценности данной фичи…
Если писать редактор на иммутабельных структурах данных, надо смотреть на zipper. Кстати, принцип во многом похож на gap buffer — эффективность копирования с изменением обеспечивается за счёт привязки зиппера к конкретной точке в тексте (обычно — место последнего изменения).
Мы одни все сделать не успеем, но на то она и экосистема (и выложенный нами в опенсорс код, который форкают многие авторы расширений для VS). PHP на сегодня занимаются ребята из DEVSENSE. Увы, не бесплатно — хотя стоимость лицензий сравнима с PHPStorm.
Но вообще вы не одиноки — нам уже приходили фичереквесты от пользователей на прикручивание к VS всего, что только можно: PHP, Perl, Ruby, Node.js, Java (?!) и Haskell (!!!).
Кстати, один из основателей DEVSENSE — Томаш Петричек, человек, достаточно известный в узких кругах любителей функционального программирования на платформах от MS вообще, и F# в частности. В частности, он был основным автором книги «Real-world Functional Programming». Мне в связи с этим иногда становится интересно, на что похожи их исходники :)
Так практически все стандарты, которые сегодня в HTML5 — это «изначально чье-то изобретение». WebGL, например, когда-то назывался Canvas 3D, когда это была еще экспериментальная фича в Мозилле.
Поэтому вы, разумеется, совершенно правы — первыми реализовавшими всегда являются те, кто продвигает новую фичу в стандарт. А все остальные подтягиваются уже потом, когда дизайн фичи довели до ума, пофиксили связанные с ним баги и дыры в безопасности (помните, не столь давно было время, когда через WebGL можно было эксплойтить драйвера видеокарт, и некоторые браузеры его отключали по умолчанию?).
Я в принципе согласен с вами в том, что с WebGL действительно тянули слишком долго, уже после того, как закрыли все дыры. Но уже то, что он есть в IE сегодня — это огромный прогресс по сравнению с наплевательским отношением к стандартам времен IE6, или черепашьей скоростью их реализации в IE7-8. Дальше будет лучше. Вот посмотрим еще, кто первый полностью реализует ES6 :)
А вы все-таки посмотрите. Со времен MFC и GridBagLayout многое изменилось :)
Ну и как вариант — если в те времена идеология была NIH + «все или ничего», то сейчас куда большая гибкость. Для примера, тот же Python Tools for VS — мы ведь не делаем свой питон, или свои библиотеки под него. Мы делаем из VS полноценную и удобную IDE, которая работает со стандартным питоном и популярными библиотеками под него. Или Azure — если вы хотите крутить на нем PHP вместо .NET, то это тоже замечательно; и даже если вы хотите PHP на Linux, то все равно welcome.
А это такой хитрый план. Если сделать так, чтобы «хомячки могли сбежать», то, чтобы их удержать, всей компании таки придется над этим работать, чтобы взять качеством и инновациями. Собственно, это уже имеет место быть практически везде; я не буду утверждать, что везде оно идеально получается, но, согласитесь, есть огромная разница между политикой компании сегодня и, скажем, времен Висты.
И что характерно — самой компании это тоже идет на пользу в том смысле, что почивание на лаврах имеет тенденцию к скатыванию в болото внутри, а динамичная конкуренция поддерживает в форме.
Понимаете, тут дело не в субъективном стиле, а во вполне объективных граблях. Вещи вроде using namespace в заголовочном файле, Create/Close вместо конструктора и деструктора (и ладно бы еще они коды ошибок возвращали — так они у вас void), использование идентификаторов вида _SCRIPT_H_ (FYI, идентификаторы, начинающиеся с подчеркивания, за которым следует заглавная буква — зарезервированы для компилятора и стандартной библиотеки, причем последняя в VC++ этим активно пользуется) и т.д. Это реально просто плохой C++, и когда такое подается в качестве туториала, пусть и не по плюсам — это плохо, потому что это будут читать новички, и учиться делать так же.
Из собственного опыта, после поддержки подобного велосипеда год-два, он постепенно обрастает свистелками и прочим до такой степени, что все равно получается полноценная VM. Только не в пример более забагованная, чем Lua.
Впрочем, даже если опустить эту планку, суть аргумента не меняется — наиболее популярные языки-последователи этой темы не касались, при том, что была масса других нововведений.
Просто тут надо сравнивать сравнимые вещи — т.е. C++ с C++, а не C++ с Java или там C#.
То же самое с подсветкой типов etc. По сравнению с каким-нибудь Notepad++, в VS есть огромное отличие — он подсвечивает именно типы (после разбора дерева, инстанциации шаблонов etc), а не просто матчит кусок кода по регекспу «это примерно похоже на тип в объявлении». Опять же, если вы знаете плюсы, то должны знать и то, что в общем случае даже просто отличить объявление переменной от выражения требует разворачивания всех задействованных в выражении шаблонов — т.е. это не просто парсинг.
Кстати, заметьте, что ни один мэйнстримный ЯП с си-подобным синтаксисом не ввёл такой сахар — хотя в других областях понадобавляли много чего, вплоть до лямбд. Это как бы говорит нам о ценности данной фичи…
Но эта проблема спокойно решается в библиотеке, без изменения языка.
Но вообще вы не одиноки — нам уже приходили фичереквесты от пользователей на прикручивание к VS всего, что только можно: PHP, Perl, Ruby, Node.js, Java (?!) и Haskell (!!!).
Кстати, один из основателей DEVSENSE — Томаш Петричек, человек, достаточно известный в узких кругах любителей функционального программирования на платформах от MS вообще, и F# в частности. В частности, он был основным автором книги «Real-world Functional Programming». Мне в связи с этим иногда становится интересно, на что похожи их исходники :)
Поэтому вы, разумеется, совершенно правы — первыми реализовавшими всегда являются те, кто продвигает новую фичу в стандарт. А все остальные подтягиваются уже потом, когда дизайн фичи довели до ума, пофиксили связанные с ним баги и дыры в безопасности (помните, не столь давно было время, когда через WebGL можно было эксплойтить драйвера видеокарт, и некоторые браузеры его отключали по умолчанию?).
Я в принципе согласен с вами в том, что с WebGL действительно тянули слишком долго, уже после того, как закрыли все дыры. Но уже то, что он есть в IE сегодня — это огромный прогресс по сравнению с наплевательским отношением к стандартам времен IE6, или черепашьей скоростью их реализации в IE7-8. Дальше будет лучше. Вот посмотрим еще, кто первый полностью реализует ES6 :)
Если вы имеете в виду WebM, то она уже давно есть, начиная с IE9 (сам кодек можно взять здесь).
Да, это не из коробки. Но, учитывая непонятки с патентами вокруг VP8, я думаю, вы можете понять, почему MS не хочет подставляться, если вдруг что.
>> А поддержка WebGL из коробки когда появится?
В IE11.
>> IE — до сих пор самый отсталый браузер.
Кстати, скажите, а когда в Chrome или Firefox появится CSS grid layout, например? ;)
Ну и как вариант — если в те времена идеология была NIH + «все или ничего», то сейчас куда большая гибкость. Для примера, тот же Python Tools for VS — мы ведь не делаем свой питон, или свои библиотеки под него. Мы делаем из VS полноценную и удобную IDE, которая работает со стандартным питоном и популярными библиотеками под него. Или Azure — если вы хотите крутить на нем PHP вместо .NET, то это тоже замечательно; и даже если вы хотите PHP на Linux, то все равно welcome.
И что характерно — самой компании это тоже идет на пользу в том смысле, что почивание на лаврах имеет тенденцию к скатыванию в болото внутри, а динамичная конкуренция поддерживает в форме.