Здравствуйте, Константин Л., Вы писали:
LC>>Следующим барьером является Garbage Collector. .NET навязывает всем свой GC. Хотя на самом деле, GC по сути является частностью реализации. И у каждой среды, свой GC наиболее подходящий под их задачи. Например, GC у JS и GC .NET'а это два очень разных по внутренней реализации механизма.
КЛ>а что, GC у JS хороший?
Тут дело не в том, хороший он у него или плохой. Дело в том, что он у него свой. Кроме JS есть еще куча разных сред с еще более специфичными GC. Если мы возьмем .NET в качестве базы для нового API, то он должен реализовать все эти специфичные GC для каждой из этих сред. Должен будет предоставить отдельную реализацию GC для JS, отдельную реализацию GC для ...
LC>>И наконец, производительность. Что бы не говорили адепты управляемых сред, каким бы эффективным и производительным ни был GC, у него все равно есть задержки, какими бы маленькими и не заметными для пользователей они не были. Все равно есть класс приложений и задач, где это недопустимо и необходимо всегда детерминированное время отклика. Соответственно, среда должна позволять ручное управление памятью, там, где это нужно. Сам сейчас работаю в такой области и это действительно важный фактор.
КЛ>c++/cli
C++/CLI работает поверх CLR, соответсвенно, она тоже является managed средой. Да и вообще, задумана она была изначально как промежуточный этап в портировании проектов на C++ под .NET.
КЛ>COM это в общем-то hell на текущий 2012 год.
Так ты предложи альтернативу. Причем альтернативу обкатанную, проверенную временем. Для Windows это почти единственный логично-верный шаг. Вон, Apple сколько лет обкатывали и контрибьютили в LLVM пока полностью туда не пересели.
Здравствуйте, iLikeCookies, Вы писали:
LC>Здравствуйте, Константин Л., Вы писали:
LC>>>Следующим барьером является Garbage Collector. .NET навязывает всем свой GC. Хотя на самом деле, GC по сути является частностью реализации. И у каждой среды, свой GC наиболее подходящий под их задачи. Например, GC у JS и GC .NET'а это два очень разных по внутренней реализации механизма.
КЛ>>а что, GC у JS хороший?
LC>Тут дело не в том, хороший он у него или плохой. Дело в том, что он у него свой. Кроме JS есть еще куча разных сред с еще более специфичными GC. Если мы возьмем .NET в качестве базы для нового API, то он должен реализовать все эти специфичные GC для каждой из этих сред. Должен будет предоставить отдельную реализацию GC для JS, отдельную реализацию GC для ...
удивительно, но эта проблема решена в c++/cli. я не понимаю, зачем вот это выделенное.
LC>>>И наконец, производительность. Что бы не говорили адепты управляемых сред, каким бы эффективным и производительным ни был GC, у него все равно есть задержки, какими бы маленькими и не заметными для пользователей они не были. Все равно есть класс приложений и задач, где это недопустимо и необходимо всегда детерминированное время отклика. Соответственно, среда должна позволять ручное управление памятью, там, где это нужно. Сам сейчас работаю в такой области и это действительно важный фактор.
КЛ>>c++/cli
LC>C++/CLI работает поверх CLR, соответсвенно, она тоже является managed средой. Да и вообще, задумана она была изначально как промежуточный этап в портировании проектов на C++ под .NET.
она является одновременно и managed и unmanaged. а ты рассказываешь что это невозможно.
КЛ>>COM это в общем-то hell на текущий 2012 год.
LC>Так ты предложи альтернативу. Причем альтернативу обкатанную, проверенную временем. Для Windows это почти единственный логично-верный шаг. Вон, Apple сколько лет обкатывали и контрибьютили в LLVM пока полностью туда не пересели.
палка обкатана и проверена многими поколениями неандертальцев, прости за аналогию.
COM в текущем виде — единственно верный фейл, с ним никто не захочет иметь дело.
Здравствуйте, Константин Л., Вы писали:
КЛ>COM в текущем виде — единственно верный фейл, с ним никто не захочет иметь дело.
Никакого фейла. 3D игры уже хрен знает сколько лет пишут с использованием COM, и никто особенно не жалуется. Тот факт, что ты его не асилил, говорит о тебе, а не о технологии
Здравствуйте, Константин Л., Вы писали:
LC>>Тут дело не в том, хороший он у него или плохой. Дело в том, что он у него свой. Кроме JS есть еще куча разных сред с еще более специфичными GC. Если мы возьмем .NET в качестве базы для нового API, то он должен реализовать все эти специфичные GC для каждой из этих сред. Должен будет предоставить отдельную реализацию GC для JS, отдельную реализацию GC для ...
КЛ>удивительно, но эта проблема решена в c++/cli. я не понимаю, зачем вот это выделенное.
Во первых, давайте уточним, о какой проблеме Вы говорите? Что именно Вам не понятно? Зачем Вы мне все время предлагаете C++/CLI, это инструмент совершенно для иных задач.
LC>>C++/CLI работает поверх CLR, соответсвенно, она тоже является managed средой. Да и вообще, задумана она была изначально как промежуточный этап в портировании проектов на C++ под .NET.
КЛ>она является одновременно и managed и unmanaged. а ты рассказываешь что это невозможно.
Она является неким склеивающим промежуточным этапом между Managed and Unmanaged средами. Для облегчения портирования C++ проектов под .NET. Сам провел кошмарные два года занимаясь Managed C++, а затем C++/CLI проектами, бессмысленная и не нужная трата времени
КЛ>палка обкатана и проверена многими поколениями неандертальцев, прости за аналогию.
И ты прости, суть твоей аналогии не уловил.
КЛ>COM в текущем виде — единственно верный фейл, с ним никто не захочет иметь дело.
Дело в том, что с ним уже имеют дело, более двадцати лет.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Константин Л., Вы писали:
КЛ>>COM в текущем виде — единственно верный фейл, с ним никто не захочет иметь дело.
K>Никакого фейла. 3D игры уже хрен знает сколько лет пишут с использованием COM, и никто особенно не жалуется. Тот факт, что ты его не асилил, говорит о тебе, а не о технологии
во-первых, свои догадки оставь при себе. во-вторых, я так говорю, потому что как раз осилил. и те игры, что я видел, "на COM" не писались, так что не надо.
Здравствуйте, Константин Л., Вы писали:
КЛ>во-первых, свои догадки оставь при себе. во-вторых, я так говорю, потому что как раз осилил. и те игры, что я видел, "на COM" не писались, так что не надо.
Здрассьте — а как же весь насквозь COMовский DirectX, на котором пишут бОльшую часть современных игр?
Здравствуйте, iLikeCookies, Вы писали:
LC>Здравствуйте, Константин Л., Вы писали:
LC>>>Тут дело не в том, хороший он у него или плохой. Дело в том, что он у него свой. Кроме JS есть еще куча разных сред с еще более специфичными GC. Если мы возьмем .NET в качестве базы для нового API, то он должен реализовать все эти специфичные GC для каждой из этих сред. Должен будет предоставить отдельную реализацию GC для JS, отдельную реализацию GC для ...
КЛ>>удивительно, но эта проблема решена в c++/cli. я не понимаю, зачем вот это выделенное.
LC>Во первых, давайте уточним, о какой проблеме Вы говорите? Что именно Вам не понятно? Зачем Вы мне все время предлагаете C++/CLI, это инструмент совершенно для иных задач.
мне не понятно, почему в c++/cli смогли решить проблемы и гетерогенной системы типов, и разных моделей управления памятью и проч, а в новом winapi — нет.
LC>>>C++/CLI работает поверх CLR, соответсвенно, она тоже является managed средой. Да и вообще, задумана она была изначально как промежуточный этап в портировании проектов на C++ под .NET.
КЛ>>она является одновременно и managed и unmanaged. а ты рассказываешь что это невозможно.
LC>Она является неким склеивающим промежуточным этапом между Managed and Unmanaged средами. Для облегчения портирования C++ проектов под .NET. Сам провел кошмарные два года занимаясь Managed C++, а затем C++/CLI проектами, бессмысленная и не нужная трата времени
что именно трата?
КЛ>>палка обкатана и проверена многими поколениями неандертальцев, прости за аналогию.
LC>И ты прости, суть твоей аналогии не уловил.
суть такова, что все уже давно кроме палки знают другие инструменты
КЛ>>COM в текущем виде — единственно верный фейл, с ним никто не захочет иметь дело.
LC>Дело в том, что с ним уже имеют дело, более двадцати лет.
вопрос в том, кто с ним имеет дело. сейчас COM мало кто знает/помнит, а вспоминать тем более не захотят
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Константин Л., Вы писали:
КЛ>>во-первых, свои догадки оставь при себе. во-вторых, я так говорю, потому что как раз осилил. и те игры, что я видел, "на COM" не писались, так что не надо.
K>Здрассьте — а как же весь насквозь COMовский DirectX, на котором пишут бОльшую часть современных игр?
ок, я в геймдеве не рулю, видел только пару игр на opengl. но что это, в общем-то, доказывает? что есть узкая ниша, где все вынуждены юзать COM?
Здравствуйте, iLikeCookies, Вы писали:
LC>Она является неким склеивающим промежуточным этапом между Managed and Unmanaged средами. Для облегчения портирования C++ проектов под .NET. Сам провел кошмарные два года занимаясь Managed C++, а затем C++/CLI проектами, бессмысленная и не нужная трата времени
Не согласен. На C++/CLI удобно писать высокопроизводительный код в виде C++ классов, внутри которых много Win32 API вызовов.
Здравствуйте, edton, Вы писали:
E>Не согласен. На C++/CLI удобно писать высокопроизводительный код в виде C++ классов, внутри которых много Win32 API вызовов.
И этот код потеряет свойство портабельности. Ладно, допустим и этого нам не надо. Что мешает этот высокопроизводительный код написать на голом C++ и воспользоваться P/Invoke? Что мешает обернуть наш код в COM, и затем его уже дергать из .NET'а?
Другое дело, C++/CLI нужен тогда, когда вам нужно из проекта на C++ воспользоваться возможностями платформы .NET.
PS: Не обращайте сильного внимания на мою особую не любовь к C++/CLI, это моя старая юношеская душевная травма, до сих пор дает о себе знать
PPS: И да, я считаю, что C++/CLI получился ужасным монстриком, эдаким Франкенштейном
Здравствуйте, Константин Л., Вы писали:
КЛ>мне не понятно, почему в c++/cli смогли решить проблемы и гетерогенной системы типов, и разных моделей управления памятью и проч, а в новом winapi — нет.
Не смогли они ничего решить. А в новом WinRT такой проблемы и нет вовсе. В этом одно из их ключевых отличий.
КЛ>вопрос в том, кто с ним имеет дело. сейчас COM мало кто знает/помнит, а вспоминать тем более не захотят
Вот WinRT и позволяет поверх себя реализовать любые среды и на любой вкус. Там даже на HTML/CSS/JS можно уже полноценно писать приложения под Windows!
LC>И этот код потеряет свойство портабельности. Ладно, допустим и этого нам не надо. Что мешает этот высокопроизводительный код написать на голом C++ и воспользоваться P/Invoke?
P/Invoke для классов? Можно конечно, но только если через P/Invoke передавать COM интерфейсы, что еще не удобнее чем C++/CLI
Здравствуйте, Константин Л., Вы писали:
КЛ>>>во-первых, свои догадки оставь при себе. во-вторых, я так говорю, потому что как раз осилил. и те игры, что я видел, "на COM" не писались, так что не надо. K>>Здрассьте — а как же весь насквозь COMовский DirectX, на котором пишут бОльшую часть современных игр? КЛ>ок, я в геймдеве не рулю, видел только пару игр на opengl. но что это, в общем-то, доказывает? что есть узкая ниша, где все вынуждены юзать COM?
DirectX — это не только игры(не такая, кстати, и узкая ниша), а графика вообще. 3D моделлеры, CAD-ы, скетчеры и прочее.
Здравствуйте, michae1, Вы писали:
M>ну хз, с MTA практически не сталкивался — не было необходимости, все время юзаю STA и там все прозрачно. Было бы интересно узнать что не так с MTA?
Для этого надо попробовать. COM на примере STA как то несерьёзно.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Что-то у меня складывается обратное впечатление, что он чуть ли не единственный адекватный руководитель в MS:
Ты просто не владеешь информацией в полном объеме. Синовский превосходный тактик, проблема не в этом вовсе. А в том, что со стратегией у него плохо и с умением воспринимать чужие идеи. Для второго человека в МС это фатальный недостаток.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Сдаётся мне, что как раз представлениями о прекрасном руководствуются именно дотнетчики. Так что, всё разумно, все занимаются своим делом: одни продолжают представлять прекрасное, другие — doing things done. Области ортогональные, не пересекающиеся.
"doing things done" недостаточно для должности такого уровня.
НС>>Истории с Реем Оззии или совсем свежая с Гатри — ты как, считаешь что это нормально, такое поведение со стороны второго человека в компании?
ГВ>А что за истории?
В гугле есть, сорри.
ГВ>ИМХО, конечно, но Product Vision должны формировать маркетологи, но уж никак не руководитель отдела разработки и уж точно — не голубоглазые мечтатели.
Стив Джобс, для примера — он кто из этих по твоему?
