Здравствуйте, Cyberax, Вы писали:

C>>>Это объясняется тем, что Option'ы могут быть вложены друг в друга (абсолютно теоретическая вещь, на практике используется крайне изредка), так что авторазвёртывание Option'ов не стали делать.
VD>>Не нужно никакое авторазвертывание.
C>Почему же? Авторазвёртывание вполне определено и удобно, с семантикой как в SQL'е. В Kotlin'е сделали всё правильно.

C>А ошибку компиляции здесь сделать трудно, так как equals() обязан работать с объектами разного типа.

Почему трудно ?
Достаточно запретить автоматическое преобразование в object:

http://ideone.com/TZ6SN
http://ideone.com/gOier

Здравствуйте, _nn_, Вы писали:

C>>А ошибку компиляции здесь сделать трудно, так как equals() обязан работать с объектами разного типа.
__>Почему трудно ?
__>Достаточно запретить автоматическое преобразование в object:
Каким образом? Метод equals() определён у класса Object, так что можно сделать только хаком для специального случая.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, _nn_, Вы писали:

C>>>А ошибку компиляции здесь сделать трудно, так как equals() обязан работать с объектами разного типа.
__>>Почему трудно ?
__>>Достаточно запретить автоматическое преобразование в object:
C>Каким образом? Метод equals() определён у класса Object, так что можно сделать только хаком для специального случая.

Если явно привести тип к object, то уже ничего не поделаешь. Вызовется equals, как и хотел автор.
Только при явном указании вызовется equals с object.
Однако если не приводить типы то компилятор выдаст ошибку:

class A {}
class B : A {}

def a = A();
def b = B();

def c = a == b; // Не компилируется в Nemerle, но компилируется в C#
def d = a : object == b; // Компилируется

В Nemerle это как раз позволяет сэкономить ошибки, где в C# на них легко наступить.
Чем такой вариант не устраивает ?

Здравствуйте, Курилка, Вы писали:

К>>>Влад, откуда ты взял про интерпретацию? "hello world".size must be equalTo(11) — это вполне себе компилируемый кусок кода, а строка выше это описание тесткейса.

VD>>Большинство интерпретаторов — это вполне себе компилируемые программы. Только от этого гни интерпретаторами быть не перестают.

К>[cut]

К>По-моему ты на не на мой вопрос отвечаешь, задам тогда попроще: Scala — интерпретатор? (Specs, код для которой был приведён — библиотека на Scala, если что)

Да нет, на твой. Просто ты не понимаешь. Скала то компилятор. Вот только подобные ДСЛ-и выливаются в нтерпретацию. В Скале нет средств сгенерировать по описанию эффективный код.

Простой пример. На скале наверно можно описать регулярные выражения. Но превратить их в эффективный конечный автомат, и тем более сгенерировать switch-реализацию для этого автомата, не удастся.

Здравствуйте, Cyberax, Вы писали:

VD>>Не нужно никакое авторазвертывание.
C>Почему же?

Я тебе написал почему, но ты поскипал.

VD>Авторазвёртывание вполне определено и удобно, с семантикой как в SQL'е. В Kotlin'е сделали всё правильно.

Ничего там не сделано. Там явные гуарды надо писать. И это правлиьно. Все что там сделано — это вместо match используется if.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Курилка, Вы писали:

К>>>>Влад, откуда ты взял про интерпретацию? "hello world".size must be equalTo(11) — это вполне себе компилируемый кусок кода, а строка выше это описание тесткейса.

VD>>>Большинство интерпретаторов — это вполне себе компилируемые программы. Только от этого гни интерпретаторами быть не перестают.

К>>[cut]

К>>По-моему ты на не на мой вопрос отвечаешь, задам тогда попроще: Scala — интерпретатор? (Specs, код для которой был приведён — библиотека на Scala, если что)

VD>Да нет, на твой. Просто ты не понимаешь. Скала то компилятор. Вот только подобные ДСЛ-и выливаются в нтерпретацию. В Скале нет средств сгенерировать по описанию эффективный код.

Тебе привели вполне себе компилируемый пример (который по сути есть тупо последовательность вызовов довольно простых методов), но ты приводишь какие-то несколько отчуждённые измышления о вариантах DSL, которые нормальным образом на скалу не ложатся (в отличие от приведённого Cyberax примера):

VD>Простой пример. На скале наверно можно описать регулярные выражения. Но превратить их в эффективный конечный автомат, и тем более сгенерировать switch-реализацию для этого автомата, не удастся.

Спорить о том, что не все юзкейсы для DSL можно нормально на скале выразить по-моему довольно глупо

Здравствуйте, Курилка, Вы писали:

К>Тебе привели вполне себе компилируемый пример

Мне привели какую-то фигню. Коня вакуумного.

К>(который по сути есть тупо последовательность вызовов довольно простых методов), но ты приводишь какие-то несколько отчуждённые измышления о вариантах DSL, которые нормальным образом на скалу не ложатся (в отличие от приведённого Cyberax примера):

VD>>Простой пример. На скале наверно можно описать регулярные выражения. Но превратить их в эффективный конечный автомат, и тем более сгенерировать switch-реализацию для этого автомата, не удастся.

К>Спорить о том, что не все юзкейсы для DSL можно нормально на скале выразить по-моему довольно глупо

А что тут спорить то? То что производительности не требует — пройдет. А то что требует — будет тормозить.

Здравствуйте, avpavlov, Вы писали:

VD>>Ошибочная мысль. Они же свою Идею на Яве пишут. Надоело им она. Вот и решили упростить себе и другим
VD>>жизнь.

A>Ну не знаю, не знаю. Я вот не в курсе к сожалению, Студию переписали на дотНет?

Причем тут студия? Я же говорю Idea. Это IDE для Явы от JetBrains. Одна из лучший.

A>Да и вообще, целиком переписать — долго.

Что касается студии (т.е. MS VS), то ее таки — да, переписывают по-тихоничку на дотнете. Почти весь GUI уже переписан. Система сборки — тоже (используется MSBuild). Уверен, что в ближайшие 5 лет из студии неуправляемый код исчезнет вовсе.

VD>>но не такой сложный как Скала и с отличной поддержкой ИДЕ (читай Идеи).

A>Сомневаюсь, что удержатся они на позициях простоты. Когда есть умения и желание и хочется их куда-то приложить, трудно удержаться

Есть такое. Но будем надеяться, что удержатся. Потом им простота нужна еще и для того чтобы IDE хорошо работала с этим языком.

Здравствуйте, hattab, Вы писали:

QL>> A>Студию переписали на дотНет?

QL>> Частично. Например, визуальная часть на WPF.

H>Частично

А что ты так нервно моргаешь то? Исходно студия была целиком анменеджед. С каждой версией все больше и больше кода переписывается в менеджед. Понятно что такой объем работы сразу проделать трудно. Ведь еще и о совместимости нужно заботиться.

Здравствуйте, hardcase, Вы писали:

H>Долго? Это гмм скорее вопрос написания конвертера исходников Java -> Kotlin.

А оно надо? Все в итоге в байткод преобурзауется. Будут писать новые модули на новом языке и все. Если старые нужно будет серьезно рефакторить, то тоже самое.

VD>Причем тут студия? Я же говорю Idea. Это IDE для Явы от JetBrains. Одна из лучший.

При том что выход .Net не привёл к переписыванию студии. А прошло уже 9 или 10 лет. Тоже будет и с ИДЕЕЙ — не будут они её брать и переписывать на Котле, как бы изначально не хорохорились на форумах. Просто тупо оценят объём работ и отступятся. Будут новые вещи дописывать, а старые оставят как есть.

Здравствуйте, VladD2, Вы писали:

VD> QL>> A>Студию переписали на дотНет?

VD> QL>> Частично. Например, визуальная часть на WPF.

VD> H>Частично

VD> А что ты так нервно моргаешь то?

Нервно? Это тебе почудилось

VD> Исходно студия была целиком анменеджед. С каждой версией все больше и больше кода переписывается в менеджед. Понятно что такой объем работы сразу проделать трудно. Ведь еще и о совместимости нужно заботиться.

Да я что, спорю что-ли Однако, того факта, что гуй там только частично на WPF (а тот что на WPF еще имеет вкрапления нативных контролов. Зачем кстати?) это не отменяет. Прикольно будет, если в дальнейшем они решат выкинуть весь WPF и запилят морду на каком нибудь нативном DirectUI

Здравствуйте, avpavlov, Вы писали:


VD>>Причем тут студия? Я же говорю Idea. Это IDE для Явы от JetBrains. Одна из лучший.

A>При том что выход .Net не привёл к переписыванию студии. А прошло уже 9 или 10 лет.

Ну, как же не привело, когда процентов 70 кода (по скромным оценкам) уже переписаны?

A>Тоже будет и с ИДЕЕЙ — не будут они её брать и переписывать на Котле, как бы изначально не хорохорились на форумах. Просто тупо оценят объём работ и отступятся. Будут новые вещи дописывать, а старые оставят как есть.

Дык, просто так код никто не переписывает. Переписывают код которые не удовлетворяет тем или иным потребностям. По этому, естественно, с выходом нового языка никто не побежит все переписывать. Но те части которые будут переписываться, будут переписываться уже на новом языке.

Здравствуйте, hattab, Вы писали:

H>Да я что, спорю что-ли

Похоже, что да.

H>Однако, того факта, что гуй там только частично на WPF (а тот что на WPF еще имеет вкрапления нативных контролов. Зачем кстати?) это не отменяет.

GUI там на 99.99 менеджед. Не весь, правда, WPF, но тем не менее менеджед. Единственное что там осталось анменеджед — это контрол с деревом. Говорят что по соображениям совместимости. А там черт его знает.

Но менеджед там далеко не только гуй. Там много всего менедед стало.

H>Прикольно будет, если в дальнейшем они решат выкинуть весь WPF и запилят морду на каком нибудь нативном DirectUI

Ты явно не понимаешь о чем говоришь. Такие объемы кода просто так не выкидываются. Один только редактор кода — это горы кода. Редактор, кстати, получился очень хороший (с точки зрения API).

А анменеджед и так есть. WPF основан на маленькой, но тем не менее нэйтивной библоотеке которая и занимается низкоуровневыми вопросами отрисовки.

Здравствуйте, hattab, Вы писали:

H>Прикольно будет, если в дальнейшем они решат выкинуть весь WPF и запилят морду на каком нибудь нативном DirectUI

Да, кстати, забыл упомянуть одну пикантную подробность. В VS 2010 пакет управленияе проектами С++ был переписан в мендедед виде (скорее всего на шарпе). А пакеты для Шарпа и Васика пока что остались нйэтивными. Вот такие вот казусы случаются.

Здравствуйте, avpavlov, Вы писали:


VD>>Причем тут студия? Я же говорю Idea. Это IDE для Явы от JetBrains. Одна из лучший.

A>При том что выход .Net не привёл к переписыванию студии. А прошло уже 9 или 10 лет. Тоже будет и с ИДЕЕЙ — не будут они её брать и переписывать на Котле, как бы изначально не хорохорились на форумах. Просто тупо оценят объём работ и отступятся. Будут новые вещи дописывать, а старые оставят как есть.

При чем тут полное переписывание? Я подозреваю, что разработка более интеллектуальных рефакторингов (а JetBrains явный мировой лидер в этом деле) тупо упирается в уровень сложности кода.

Всякие анализаторы кода и рефакторинги писать на яве это ужас. Я поражаюсь терпению разработчиков IDEA. При том, что эта среда уже поддерживает очень большой перечень языков и платформ.

Вот только для IDE часто важна еще и скорость. А высокоуровневые фичи в языке часто с ней несовместимы. Поэтому тут лучше подошел бы аналог немерла, где можно строить высокоуровневый DSL который генерит очень шустрый код. Но у них в руках компилятор, могут допиливать прямо его, пока не поймут, что метапрограммирование нужно иметь в шаговой доступности.

Здравствуйте, VladD2, Вы писали:

VD>Плюс к этому языку будет первоклассная IDE, от лучшего производителя IDE. Для Скалы, насколько мне известно, ничего качественного так и не было сделано.

И это не случайно. К сожалению даже JetBrains не может осилить нормальную поддержку скалы.

Здравствуйте, VladD2, Вы писали:

VD> H>Да я что, спорю что-ли

VD> Похоже, что да.

Это твое заблуждение. С тем, что студия переписывается под менеджед у меня и мыслей спорить небыло

VD> H>Однако, того факта, что гуй там только частично на WPF (а тот что на WPF еще имеет вкрапления нативных контролов. Зачем кстати?) это не отменяет.

VD> GUI там на 99.99 менеджед. Не весь, правда, WPF, но тем не менее менеджед. Единственное что там осталось анменеджед — это контрол с деревом. Говорят что по соображениям совместимости. А там черт его знает.

На 99.99% это сильно не тянет. Берешь Spy++ и находишь кучу нативных контролов ServerExplorer — дерево нативное, Solution Explorer — дерево нативное, Object browser — дерево нативное (у WPF'а, похоже, совсем туго с деревьями ), Properties — винформсовые оберточки Более того, открываешь диалог Options, а он вообще весь нативный Attach to process, Code snippets manager, Add-in manager, External tools это все полностью нативные диалоги. И это мне просто лень все проверять, т.ч. твои 99.99% это красивая фантазия и не более

VD> Но менеджед там далеко не только гуй. Там много всего менедед стало.

Чудно, но я как бы о гуе

VD> H>Прикольно будет, если в дальнейшем они решат выкинуть весь WPF и запилят морду на каком нибудь нативном DirectUI

VD> Ты явно не понимаешь о чем говоришь. Такие объемы кода просто так не выкидываются.

Нужно же будет куда-то применять DirectUI. WPF вот что-то не пошел совсем. Разгонят одних индусов, наберут других и спираль начнет новых виток

VD> Один только редактор кода — это горы кода. Редактор, кстати, получился очень хороший (с точки зрения API).

Как пользователю, мне чхать на красивое API. Как пользователь, я хочу отзывчивого гуя, а с приходом менеджед студия стала тормозом.

VD> А анменеджед и так есть. WPF основан на маленькой, но тем не менее нэйтивной библоотеке которая и занимается низкоуровневыми вопросами отрисовки.

Оно и понятно, куда без натива в нативной то среде

Здравствуйте, hattab, Вы писали:

H>На 99.99% это сильно не тянет. Берешь Spy++ и находишь кучу нативных контролов

Да ну?

H>ServerExplorer — дерево нативное, Solution Explorer — дерево нативное, Object browser — дерево нативное (у WPF'а, похоже, совсем туго с деревьями ),

Это все пример одного контрола — дерева. Скорее всего сделали обертку для него на С++ и используют в виде контрола.

H>Properties — винформсовые оберточки

Гы. А что винформс у нас уже нэйтивом стал? Ну-ну.

H> Более того, открываешь диалог Options, а он вообще весь нативный

Это контейнер. Что было старое осталось старым. Но есть там страницы и сделанные в медеджед кода. Это как раз таки новые странички. Открой, например, настройки форматирования для шарпа.

H>Attach to process, Code snippets manager, Add-in manager, External tools это все полностью нативные диалоги. И это мне просто лень все проверять, т.ч. твои 99.99% это красивая фантазия и не более

С диалогами — да. Но это не там много кода. Да и он не сложный. В студии код совершенно в других местах дислоцируется. Скажем огромная часть студии это msenv.dll. Вот там анменеджед-кода полно. И качество его, порой, ужасное. Обработка ошибок на грани фола. Тупо возвращают E_ЧтоТоТам, если что не так. И плевать на то как другие будут ошибки искать.

Что до гуи — то тут основное объем кода — это, как не странно, редатор кода и всякого рода дизайнеры.

Я же имел в виду сам интерфейс студии (окошки).


VD>> Но менеджед там далеко не только гуй. Там много всего менедед стало.

H>Чудно, но я как бы о гуе

Честно говоря не понимаю чем тебе гуй сдался.

VD>> Ты явно не понимаешь о чем говоришь. Такие объемы кода просто так не выкидываются.

H>Нужно же будет куда-то применять DirectUI. WPF вот что-то не пошел совсем. Разгонят одних индусов, наберут других и спираль начнет новых виток

Это у тебя ошибочная информация. В плане разработки студии объем менеджед-кода только увеличивается.

В ближайшем будущем, скорее всего, на менеджед код будет переведены сервисы интеграции шарпа и васика, а так же и компилятор шарпа. Ну, а там менедежед-код будет выкидываться еще больше.

И знаешь почему будет выкидываться менеджед код? Потому что он хреновый и очень плохой в поддержке.

Создавать модули интеграции других языков к студии, на сегодня, очень не просто. Анменеджед-интерфейсы — это черные ящики. Получить информацию по ним почти невозможно. Обработка ошибок в них требует море кодирования и потому частенько просто выливается в возврат E_INVALIDARG или чего-то подобного. Так что понять что ты сделал не так в не тривильных случаях почти невозможно. Учитывая, что исходники МС вряд ли откроет — единственный путь сделать студию более дружественной к внешним расширениям — это дальнейший перевод ее на менеджед-код.

В 2010 студии для этого сделано не мало. Новый формат расширений очень красив и позволяет вынести различные фичи интеграции в отдельные, независимые модули. Новый редактор кода имеет продуманное, мощное и хорошее АПИ.

Если все это выбросить и вернуться назад к COM-у и нэйтив-реализации, то это будет огромным шагом назад. Думаю, что на такой глупый шак в МС не пойдут.

Ну, а ГУЙ, особенно какие-то там диалоги настроек — это мелочь на которую лично я даже не обращал внимание. Не они делают погоду. Приделывать же нэйтив-гуй к менеджед-кишкам по меньшей мере странно.

VD>> Один только редактор кода — это горы кода. Редактор, кстати, получился очень хороший (с точки зрения API).

H>Как пользователю, мне чхать на красивое API.

Как недальновидному пользователю — да. А дальновидный пользователь понимает, что от качества АПИ редактора зависит качество и количество сервисов с ним интегриумых.

Например, новое АПИ позволяет подлкючать расширения редактора кода (вроде интеллисенса) отдельными модулями. При этом все расширения делаются через простой и хорош документированный АПИ, а не через жопу автогеном как это делалось 10 лет назад (в том же Томато, например).

Уже сейчас можно скачать кучу полезных расширений. А 2010-й студии еще нет и года. Сравни это с тем что было в прошлые времена.

H> Как пользователь, я хочу отзывчивого гуя, а с приходом менеджед студия стала тормозом.

Гуй как раз работает весьма шустренько. И это не смотря на навороты.

Слова "стала тормознутой" говорили про все версии студии. Только через год-два те же слова уже говорили про следующую версию, а текущая оказывалась шустрой и пушистой .

Понятно, что с ростом функционала растет и нагрузка на систему. Плюс много кода пишется откровенно хатлтурно. Но от от того на управляемом это языке делается или нет практически ничего не зависит.

H>Оно и понятно, куда без натива в нативной то среде

Естественно. Возможно сей факт как-то сгладит батхерт вызываемый у некторых товарищей тем фактом, что доля менеджед-кода в студии с каждым годом увеличивается .

Здравствуйте, VladD2, Вы писали:

VD> H>На 99.99% это сильно не тянет. Берешь Spy++ и находишь кучу нативных контролов

VD> Да ну?

Ну да

VD> H>ServerExplorer — дерево нативное, Solution Explorer — дерево нативное, Object browser — дерево нативное (у WPF'а, похоже, совсем туго с деревьями ),

VD> Это все пример одного контрола — дерева. Скорее всего сделали обертку для него на С++ и используют в виде контрола.

Прикол то в том, что почему то не WPF Неужто спустя столько лет у WPF нет достойного контрола — дерева Впрочем, там не только дерево засветилось, но и самый обычный ListView (открывай, скажем, Bookmarks), и тоже в нескольких местах.

VD> H>Properties — винформсовые оберточки

VD> Гы. А что винформс у нас уже нэйтивом стал? Ну-ну.

Я же не сказал, что винформсы нативные (хотя они суть оболочка над нативными контролами). Я о том, что почему то снова не WPF. Помнишь о чем разговор то?

Например, визуальная часть на WPF

На что я заметил, что она на WPF частично.

VD> H> Более того, открываешь диалог Options, а он вообще весь нативный

VD> Это контейнер. Что было старое осталось старым. Но есть там страницы и сделанные в медеджед кода. Это как раз таки новые странички. Открой, например, настройки форматирования для шарпа.

Я же не говорю, что менеджед страничек там нет, но и нативных там куча, с нативными контролами

VD> H>Attach to process, Code snippets manager, Add-in manager, External tools это все полностью нативные диалоги. И это мне просто лень все проверять, т.ч. твои 99.99% это красивая фантазия и не более

VD> С диалогами — да. Но это не там много кода. Да и он не сложный. В студии код совершенно в других местах дислоцируется. Скажем огромная часть студии это msenv.dll. Вот там анменеджед-кода полно. И качество его, порой, ужасное. Обработка ошибок на грани фола. Тупо возвращают E_ЧтоТоТам, если что не так. И плевать на то как другие будут ошибки искать.

А я не про код. Я про гуй, который не на WPF

VD> Что до гуи — то тут основное объем кода — это, как не странно, редатор кода и всякого рода дизайнеры.

VD> Я же имел в виду сам интерфейс студии (окошки).

Ну вот окошки доступные из View (как вышеупомянутое Bookmarks), относятся к тому, что ты имел ввиду? Если да, то и в них нативные контролы есть.

VD> H>Чудно, но я как бы о гуе

VD> Честно говоря не понимаю чем тебе гуй сдался.

Я указал выше, относительно какого тезиса (WPF-гуй) идет разговор.

VD> H>Нужно же будет куда-то применять DirectUI. WPF вот что-то не пошел совсем. Разгонят одних индусов, наберут других и спираль начнет новых виток

VD> Это у тебя ошибочная информация. В плане разработки студии объем менеджед-кода только увеличивается.

VD> В ближайшем будущем, скорее всего, на менеджед код будет переведены сервисы интеграции шарпа и васика, а так же и компилятор шарпа. Ну, а там менедежед-код будет выкидываться еще больше.

Это все конечно хорошо, но только какое отношение это имеет к WPF-гую? Почему бы им не выкинуть WPF и не заменить его менеджед обертками от DirectUI? Вполне себе вариант

VD> И знаешь почему будет выкидываться менеджед код? Потому что он хреновый и очень плохой в поддержке.

Ой, не надо военных песен. Менеджед не сделает код хорошим, вероятность скатывания в говнокод увеличится, это факт. Как это уже произошло с семерочными MMC-снапинами EventViewer и Scheduler.

VD> Создавать модули интеграции других языков к студии, на сегодня, очень не просто. Анменеджед-интерфейсы — это черные ящики. Получить информацию по ним почти невозможно. Обработка ошибок в них требует море кодирования и потому частенько просто выливается в возврат E_INVALIDARG или чего-то подобного. Так что понять что ты сделал не так в не тривильных случаях почти невозможно. Учитывая, что исходники МС вряд ли откроет — единственный путь сделать студию более дружественной к внешним расширениям — это дальнейший перевод ее на менеджед-код.

Ты хочешь сказать, что отсутствие документации по внутренним интерфейсам это проблема нативного кода? Я тебя правильно понял? Отчего же это не мешает ребятам из RemObjects, которые сделали интеграцию своего Oxygen в студию?

VD> В 2010 студии для этого сделано не мало. Новый формат расширений очень красив и позволяет вынести различные фичи интеграции в отдельные, независимые модули. Новый редактор кода имеет продуманное, мощное и хорошее АПИ.

Понимаешь, это ни коим образом не указывает на плюсы менеджед кода и отстойность нативного Это говорит лишь о том, что проектирование перед кодирование есть корошо

VD> H>Как пользователю, мне чхать на красивое API.

VD> Как недальновидному пользователю — да. А дальновидный пользователь понимает, что от качества АПИ редактора зависит качество и количество сервисов с ним интегриумых.

Пользователь вообще не в курсе этих ваших API. Для него существуют другие категории ценностей. Ему интеграцию немерлей к студии припиливать не нужно.

VD> Например, новое АПИ позволяет подлкючать расширения редактора кода (вроде интеллисенса) отдельными модулями. При этом все расширения делаются через простой и хорош документированный АПИ, а не через жопу автогеном как это делалось 10 лет назад (в том же Томато, например).

То есть в заслугу менеджед коду ты ставишь проработанность спроектированного API? Я тебя правильно понял?

VD> H> Как пользователь, я хочу отзывчивого гуя, а с приходом менеджед студия стала тормозом.

VD> Гуй как раз работает весьма шустренько. И это не смотря на навороты.

Мне так не кажется. Под виртуалкой студией пользоваться просто неприятно.

VD> Слова "стала тормознутой" говорили про все версии студии. Только через год-два те же слова уже говорили про следующую версию, а текущая оказывалась шустрой и пушистой .

Угу. Увеличивается количество менеджед кода — становится больше разговоров о тормозах студии. Прямое следствие.

VD> Понятно, что с ростом функционала растет и нагрузка на систему. Плюс много кода пишется откровенно хатлтурно. Но от от того на управляемом это языке делается или нет практически ничего не зависит.

Еще как зависит. Для примера возьми MMC-снапин EventViewer. Сделали его менеджед. Функционала не добавилось (просмотрщик, он и есть просмотрщик). Зато появились такие тормоза... И это на ровном месте. А ты говоришь...

VD> H>Оно и понятно, куда без натива в нативной то среде

VD> Естественно. Возможно сей факт как-то сгладит батхерт вызываемый у некторых товарищей тем фактом, что доля менеджед-кода в студии с каждым годом увеличивается .

Возможно у кого то действительно батхерт от сего факта, но лично я тут говорю о гуе, который на WPF лишь частично