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

ГВ>>Зададим вопрос: есть ли Java на .Net, и наоборот — имеется ли C# для JVM?
WH>Сделать Java под .NET не проблема.

так есть же уже Visual J#

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

GZ>>Проблема, насколько я понимаю, не в коде операционки. Проблема в коде клиентов. Если разрешен неверифицируемый код в клиенте, то safe или unsafe ядро — проблема есть. Если запрещен, то независимо от того, какая операционка, и насколько она сингулярна — проблемы нет.
WH>На сколько мне извесно самые разрушительные черви ходит именно ерез дырки ОС. Так что верфифицировать нужно все что вобще возможно. Вобщем мое мнение чем меньше unsafe кода тем лучше.
Червяки можно разделить на две категории. Первые — внедряются с внешней стороны, вторые — выполняются внутри системы, но проводят действия на которые он не имеет прав. Для второго случая, важен обход апаратной защиты адресации памяти(что обычно делается с помощью дырок в OS). В случае с сингуларити — все несколько проще в смысле аппаратной защиты. Unsafe программа может легко работать в адресах на которые у него прав нет. Safe программа — нет.

WolfHound wrote:
> А как виртуальныя машина отменяет разнообразие языков? Единственное что
> правильная ВМ отменяет всякие низкоуровневые языки которые не
> контролируют то что делает программист. Но вот нужны ли такие языки?
Нужны.

Будущее за ОС с нестандартными архитектурами — микроядерными ОС,
например. К примеру, ядра QNX'ов предидущих версий — примерно 12Кб кода
на различных ассемблерах (под кучу платформ).

Только этот код исполняется в режиме ядра, остальной код работает в
контексте пользователя, так что система выживает даже если упадет
железка с драйвером. У HP есть такие же технологии (Tandem, теперь Non
Stop). Так что managed OS нафиг не нужна.

В качестве Fully Managed OS — уже сейчас у IBM есть AS/400, там как раз
ВЕСЬ код в виртуальной машине выполняется. Хотя там набор инструкций VM
больше напоминает классические процессорные команды и не является
"безопасным" (хотя AS/400 и гарантирует, что приложение не вырвется за
пределы логического раздела). Работает все это очень медленно.

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

C>Нужны.
Нет.

C>Будущее за ОС с нестандартными архитектурами — микроядерными ОС,
C>например. К примеру, ядра QNX'ов предидущих версий — примерно 12Кб кода
C>на различных ассемблерах (под кучу платформ).
Управляемые ОС микро ядро какбы не отрицают, а скорее наоборот.

C>Только этот код исполняется в режиме ядра, остальной код работает в
C>контексте пользователя, так что система выживает даже если упадет
C>железка с драйвером. У HP есть такие же технологии (Tandem, теперь Non
C>Stop). Так что managed OS нафиг не нужна.
Угу а приложение от самого себя кто защищать будет? Как ты думаешь почему так популярны всякие жабы и дотнеты?

C>В качестве Fully Managed OS — уже сейчас у IBM есть AS/400, там как раз
C>ВЕСЬ код в виртуальной машине выполняется. Хотя там набор инструкций VM
C>больше напоминает классические процессорные команды и не является
C>"безопасным" (хотя AS/400 и гарантирует, что приложение не вырвется за
C>пределы логического раздела). Работает все это очень медленно.
Значит они сделали что-то не так. Посмотри на отчет о сингулярити она работает плюс/минус с тойже скоростью что современные винда и линух. И это при том что сингулярити практически не оптимизировали.
Кроче проблемы со скоростью это то во что тебе хочется верить. Реально будет скорре наоборот.

Вобщем мы это все уже обсудили. Единственный минус что ты нашол это потеря 30% в очень специфических случаях из-за несовершенства современных оптимизаторов.

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

GZ>Червяки можно разделить на две категории. Первые — внедряются с внешней стороны, вторые — выполняются внутри системы, но проводят действия на которые он не имеет прав. Для второго случая, важен обход апаратной защиты адресации памяти(что обычно делается с помощью дырок в OS). В случае с сингуларити — все несколько проще в смысле аппаратной защиты. Unsafe программа может легко работать в адресах на которые у него прав нет. Safe программа — нет.
В том то и прикол что в сингулярити все включая драйверы safe. Так что червям развернутся просто негде.
А внедриться в unsafe часть ядра практически не реально.

WolfHound wrote:
> C>Только этот код исполняется в режиме ядра, остальной код работает в
> C>контексте пользователя, так что система выживает даже если упадет
> C>железка с драйвером. У HP есть такие же технологии (Tandem, теперь Non
> C>Stop). Так что managed OS нафиг не нужна.
> Угу а приложение от самого себя кто защищать будет?
Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой
супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным
это не мешало.

> Как ты думаешь почему так популярны всякие жабы и дотнеты?
Как ты думаешь, а почему они популярны там, где пофиг на объемы
сжираемой памяти и быстродействие?

> Значит они сделали что-то не так. Посмотри на отчет о сингулярити она
> работает плюс/минус с тойже скоростью что современные винда и линух. И
> это при том что сингулярити практически не оптимизировали.
Сингулярити не позволяет использовать нативный код.

> Кроче проблемы со скоростью это то во что тебе хочется верить. Реально
> будет скорре наоборот.
Мечты, мечты

> Вобщем мы это все уже обсудили. Единственный минус что ты нашол это
> потеря 30% в очень специфических случаях из-за несовершенства
> современных оптимизаторов.
ЕДИНСТВЕННЫЙ???? А как насчет многократного перерасхода памяти И
жуткого усложнения кода (чтобы хоть как-то памяти сэкономить)?

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

C>Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой
C>супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным
C>это не мешало.
Практика показывает что какбы программист этого не хотел у него это всеравно не получится. Ибо человек не может работать совсем без ошибок.

C>Как ты думаешь, а почему они популярны там, где пофиг на объемы
C>сжираемой памяти и быстродействие?
Памяти они действительно жрут несколько больше, а вот тормоза сильно преувеличины.

C>Сингулярити не позволяет использовать нативный код.
И правильно делает. На кой черт он нужен?

C>Мечты, мечты
Поживем увидим.

C>ЕДИНСТВЕННЫЙ???? А как насчет многократного перерасхода памяти И
C>жуткого усложнения кода (чтобы хоть как-то памяти сэкономить)?
Покачто ничто кроме твоих слов это не подтверждает. Кстати помнишь я сходу нашол способ сэкономить 33% процента памяти при этом упростив код и подняв производительность. И это без изменения архитектуры. К сожалению я не знаю задачу по этому я не смогу оптимизировать на архитектурном уровне.
Болие того обемы памяти будут продолжать рости им в отличии от мощности процессоров ничто не мешает.

WolfHound,

ГВ>>Зададим вопрос: есть ли Java на .Net, и наоборот — имеется ли C# для JVM?
WH>Сделать Java под .NET не проблема. Сделать C# под JVM труднее но тоже можно ибо JVM беднее CLR.

Некоторое подмножество отобразить можно и вполне успешно.
Grasshopper Visual MainWin for J2EE


WH>Хотя смысла в этом нет никакого.
Смысл всё-таки есть: переход между платформами, унаследованные решения, переход на Unix etc.

WolfHound wrote:
> C>Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой
> C>супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным
> C>это не мешало.
> Практика показывает что какбы программист этого не хотел у него это
> всеравно не получится. Ибо человек не может работать совсем без ошибок.
И? Мне текущие программы вполне нравятся. То что у меня будет
выскакивать красивый stacktrace вместо Access Violation — меня не особо
привлекает.

> C>Сингулярити не позволяет использовать нативный код.
> И правильно делает. На кой черт он нужен?
Мне нужен. Если кто-то не умеет нативный код использовать — его проблемы.

> C>ЕДИНСТВЕННЫЙ???? А как насчет *многократного* перерасхода памяти И
> C>жуткого усложнения кода (чтобы хоть как-то памяти сэкономить)?
> Покачто ничто кроме твоих слов это не подтверждает.
Подтверждает. Например, отсутствие .NET/Java программ на обычных десктопах.

> Кстати помнишь я сходу нашол способ сэкономить 33% процента памяти
> при этом упростив код и подняв производительность.
До варианта с указателями все равно как до Луны. Кстати, твой вариант
уже не пройдет — недавно пришлось примерно 100000 временных массивов
создать Так что потребуется уже два байта на индекс.

> Болие того обемы памяти будут продолжать рости им в отличии от мощности
> процессоров ничто не мешает.
Я предпочитаю использовать дополнительную память, чтобы приложения
работали быстрее (из-за большего кэша диска, например), а не для того,
чтобы их разработчикам было легче их писать.

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

C>И? Мне текущие программы вполне нравятся.
А мне нет.
C>То что у меня будет выскакивать красивый stacktrace вместо Access Violation — меня не особо привлекает.
Проблема в том что AV может и не выскочить, а программа будет делать что-то не то.
К томуже имея трассировку стека разработчики смогут быстрее исправить ошибку. Болие того до пользователей дейдет гораздо меньше ошибок ибо они будут отлавливаться на этапе тестирования.

C>Мне нужен. Если кто-то не умеет нативный код использовать — его проблемы.
Например я умею писать нативный код. Но вот зачем его писать всеравно не понимаю.

C>Подтверждает. Например, отсутствие .NET/Java программ на обычных десктопах.
У меня таких программ не мало.

C>До варианта с указателями все равно как до Луны. Кстати, твой вариант уже не пройдет —
Сколько заплатишь если я утрамбую эту программу в объем памяти близкий С++ версии?
C>недавно пришлось примерно 100000 временных массивов создать Так что потребуется уже два байта на индекс.
Опять плохо считаем... три...

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

WolfHound wrote:
> C>То что у меня будет выскакивать красивый stacktrace вместо Access
> Violation — меня не особо привлекает.
> Проблема в том что AV может и не выскочить, а программа будет делать
> что-то не то.
То же самое может замечательно и с .NET-программами случится.

Переписывать ВЕСЬ (причем абсолютно весь) софт ради крайне редких
случаев, в которых из-за наведенных ошибок портятся данные? Нафиг такое
надо.

> К томуже имея трассировку стека разработчики смогут быстрее исправить
> ошибку. Болие того до пользователей дейдет гораздо меньше ошибок ибо они
> будут отлавливаться на этапе тестирования.
Трассировка стека замечательно делается и без .NET, причем еще со времен
70-х годов (core dump'ы). На Винде есть:
http://www.codeproject.com/debug/XCrashReportPt4.asp

> C>Мне нужен. Если кто-то не умеет нативный код использовать — его проблемы.
> Например я умею писать нативный код. Но вот зачем его писать всеравно не
> понимаю.
Тогда не трогайте тех, кто понимает.

> C>Подтверждает. Например, отсутствие .NET/Java программ на обычных
> десктопах.
> У меня таких программ не мало.
У меня тоже. Но вот совсем нет:
1. Мелких утиллит (типа MP3-плеера, IM, менеджера закачек). Так как
иначе памяти бы не осталось.
2. Крупных десктопных приложений.
3. Мелких утиллит командной строки.

> C>До варианта с указателями все равно как до Луны. Кстати, твой вариант
> уже не пройдет —
> Сколько заплатишь если я утрамбую эту программу в объем памяти близкий
> С++ версии?
Не получится. Более сложно связанные структуры приходится держать в виде
объектов, и никак от этого не избавится.

> C>недавно пришлось примерно 100000 временных массивов создать Так что
> потребуется уже два байта на индекс.
> Опять плохо считаем... три...
Да, проглючил. Три байта — мы сейчас просто разделяем индекс на два
32-битных слова.

> C>Я предпочитаю использовать дополнительную память, чтобы приложения
> работали быстрее (из-за большего кэша диска, например), а не для того,
> чтобы их разработчикам было легче их писать.
> Те предпочитаешь получать худший результат за большие деньги?
Нет. Я предпочитаю пользоваться КАЧЕСТВЕННЫМ продктом, а не результатом
того, что Гашиш Кумары смогли начать писать софт.

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

C>То же самое может замечательно и с .NET-программами случится.
Вероятность гораздо ниже. К томуже исключены наведенки непонятно откуда.

C>Переписывать ВЕСЬ (причем абсолютно весь) софт ради крайне редких случаев, в которых из-за наведенных ошибок портятся данные? Нафиг такое надо.
Ну можно начать с серверов и банков. Там итак очень много софта написано на safe языках.
И если сделать ВМ по умному то на нее можно будет запускить и жабные и .НЕТные приложения как родные.
Далие делается версия операционки которая работает в симбиозе с другими ОС и начинается захват десктопов.
Процесс этот не быстрый но вполне реальный.
В любом случае от него в долгосрочной перспективе индустрия только выиграет.

C>Трассировка стека замечательно делается и без .NET, причем еще со времен 70-х годов (core dump'ы). На Винде есть:
C>http://www.codeproject.com/debug/XCrashReportPt4.asp


C>Тогда не трогайте тех, кто понимает.
Ну ты толком объясни зачем.

C>У меня тоже. Но вот совсем нет:
C>1. Мелких утиллит (типа MP3-плеера, IM, менеджера закачек).
У меня тоже. Но только по тому что меня текущие устраивают и менять окружение без особой необходимости я не стану.
C>Так как иначе памяти бы не осталось.
Про память уже был флейм. В конце концов Паша Дворкин начал уходить от вопросов, а потом вобще пропал.
C>2. Крупных десктопных приложений.
VS2005 мелкое приложение? Хоть и не 100% .НЕТ но там много управляемого кода.
C>3. Мелких утиллит командной строки.
Есть. В основном самописные... на C#...

C>Нет. Я предпочитаю пользоваться КАЧЕСТВЕННЫМ продктом, а не результатом того, что Гашиш Кумары смогли начать писать софт.
Я тоже. Но причем тут Гашиш Кумары?
Например я когда перешол на .НЕТ начал работать куда эффективние.

WolfHound wrote:
> C>То же самое может замечательно и с .NET-программами случится.
> Вероятность гораздо ниже. К томуже исключены наведенки непонятно откуда.
Я уже не помню, когда в моем софте была такая ошибка в последний раз.
Обычно результаты переполнений буфферов видны тут же.

> C>Переписывать ВЕСЬ (причем *абсолютно весь*) софт ради крайне редких
> случаев, в которых из-за наведенных ошибок портятся данные? Нафиг такое
> надо.
> Ну можно начать с серверов и банков. Там итак очень много софта написано
> на safe языках.
И пусть. Мне лично пофиг на какой версии COBOLа работает мой банк.

> И если сделать ВМ по умному то на нее можно будет запускить и жабные и
> .НЕТные приложения как родные.
Где же она эта по-умному сделанная система (Singularity — это не ОНО)?

> Далие делается версия операционки которая работает в симбиозе с другими
> ОС и начинается захват десктопов.
Возьмем VB6 — на нем достаточно сложно уронить систему и очень легко
писать. По нынешним меркам VB6-приложения работают тоже вполне быстро.

И где же это доминирование десктопов быстрыми и качественными
приложениями на VB?

> C>Тогда не трогайте тех, кто понимает.
> Ну ты толком объясни зачем.
Скорость, большие языковые возможности, возможности намерянных
хаков, совместимость с ГИГАНТСКИМИ объемами уже существующего кода.

> C>У меня тоже. Но вот совсем нет:
> C>1. Мелких утиллит (типа MP3-плеера, IM, менеджера закачек).
> У меня тоже. Но только по тому что меня текущие устраивают и менять
> окружение без особой необходимости я не стану.
Мне вот кроссплатформенный мультипротокольный IM нужен. Казалось бы,
лучшее место для Java, но нормальных IM-клиентов на Java нет — никого
обычно не интересует мелкая утилита, жрущая 60Мб памяти (хотя
корпоративные IMы на Java есть).

> C>Так как иначе памяти бы не осталось.
> Про память уже был флейм. В конце концов Паша Дворкин начал уходить от
> вопросов, а потом вобще пропал.
Можно новый затеять.

> C>2. Крупных десктопных приложений.
> VS2005 мелкое приложение? Хоть и не 100% .НЕТ но там много управляемого
> кода.
Это не end-user десктопное приложение (я их имел в виду). Из
end-user'ных знаю только OneNote (который мало кто использует).

> C>Нет. Я предпочитаю пользоваться КАЧЕСТВЕННЫМ продктом, а не
> результатом того, что Гашиш Кумары смогли начать писать софт.
> Я тоже. Но причем тут Гашиш Кумары?
> Например я когда перешол на .НЕТ начал работать куда эффективние.
Над теми же типами задач?

Я не спорю, веб-приложения и серверные системы сейчас идеально на
C#/Java писать.

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

ГВ>>>А фреймворки?

VD>>25!

ГВ>33!

-------------------------
Летят Василий Иванович и Петька на самолете...
Петька:
— Василий Ивановичь! Приборы!!!
— 25.
— Что 25?!!!
— А что приборы?

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

C>Я уже не помню, когда в моем софте была такая ошибка в последний раз.
C>Обычно результаты переполнений буфферов видны тут же.
Обычно и у тебя... Вот только основная масса софта глючит по черному.
Переход с x86 на x86-64 прешлось отложить до лучших времен ибо куча программ не пошла.
...

C>Где же она эта по-умному сделанная система (Singularity — это не ОНО)?
Давай отделим мух от котлет.
Сингулярити это очень правельный концеп управляемой ОС. Но сингулярити основана наслегка модифицированном CLR со всеми его просчетами и глупостями.
Те если взять архитектруру сингулярити и реализовать ее на правильной ВМ то получится ОС которая будет очень быстро вытеснять другие ОС с серверов.

C>Возьмем VB6 — на нем достаточно сложно уронить систему и очень легко писать. По нынешним меркам VB6-приложения работают тоже вполне быстро.
В десятки раз медленнее нативных. А управляемые медленней на проценты.
К томуже VB6 очень уродливый язык и писать на нем довольно трудно.

C>Скорость,
Что скорость? В реальных приложениях это миф. Да ты и сам это прекрасно знаешь. А есть приложения где управляемые среды еще и быстрее нативных. Например если нужна кодогенерация.
C>большие языковые возможности,
Вспомнить про немерле?
C>возможности намерянных хаков,
Зачем?
C>совместимость с ГИГАНТСКИМИ объемами уже существующего кода.
Единственное реальное преймущество. Вот только код постоянно обновляется и процент safe кода растет.

C>Мне вот кроссплатформенный мультипротокольный IM нужен. Казалось бы, лучшее место для Java, но нормальных IM-клиентов на Java нет — никого обычно не интересует мелкая утилита, жрущая 60Мб памяти (хотя корпоративные IMы на Java есть).
Блин да откуда ты берешь такие цифры? Дай угадаю с потолка верно?
У меня янус меньше занимает, а он тот еще обжора. И жрет там память в основном не .НЕТ...

C>Это не end-user десктопное приложение (я их имел в виду). Из end-user'ных знаю только OneNote (который мало кто использует).
Что жначит не end-user? Я вполне себе end-user этой самой студии.

C>Над теми же типами задач?
Да.

C>Я не спорю, веб-приложения и серверные системы сейчас идеально на C#/Java писать.
Под десктоп на них тоже можно неплохо писать.

WolfHound wrote:
> C>Я уже не помню, когда в моем софте была такая ошибка в последний раз.
> C>Обычно результаты переполнений буфферов видны тут же.
> Обычно и у тебя... Вот только основная масса софта глючит по черному.
Я использую в основном: Thunderbird (не помню когда падало), FireFox
(вполне стабилен), Apollo (ни разу не падал), Miranda (действительно
глюкодром, ищу замену), FAR (идеален), MSVS (достаточно стабильна).

Редкие падения меня ну абсолютно не напрягают.

> Переход с x86 на x86-64 прешлось отложить до лучших времен ибо куча
> программ не пошла.
Виндовых программ. При миграции Debian x86 -> Debian AMD64 не
возникло ни одной проблемы с приложениями.

Интересно, сколько программ сломались при миграции .NET 1.0 -> .NET 2.0?

А сколько сломаются при миграции с Singularity на суперсистему BigBang,
в которой будут автомагически проверятся race-condition'ы и неправильное
использование потоков?

> Сингулярити это очень правельный концеп управляемой ОС. Но сингулярити
> основана наслегка модифицированном CLR со всеми его просчетами и глупостями.
> Те если взять архитектруру сингулярити и реализовать ее на правильной ВМ
> то получится ОС которая будет очень быстро вытеснять другие ОС с серверов.
Понимаешь, даже самая правильная VM с "безопасным" кодом не даст мне
прямого управления памятью и указателей.

> C>Возьмем VB6 — на нем достаточно сложно уронить систему и очень легко
> писать. По нынешним меркам VB6-приложения работают тоже вполне быстро.
> В десятки раз медленнее нативных.
Решается более быстрым процессором. Какие проблемы? Если начать писать
проект длительностью в пять лет, то к концу проекта развитие компьютеров
и крутых компиляторов сделает софт таким же быстрым как и нативный в
начале проекта.

> К томуже VB6 очень уродливый язык и писать на нем довольно трудно.
s/VB6/C#.

> C>Скорость,
> Что скорость? В реальных приложениях это миф.
В моем случае — жестокая реальность. На производительность нескольких
критичных кусков влияло даже неправильное расположение звезд. Причем
влияло в разы (JIT иногда отказывался инлайнить циклы).

> Да ты и сам это прекрасно знаешь. А есть приложения где управляемые
> среды еще и быстрее нативных.
Есть. И пусть там и используются. Я что ли против?

Мне не нравится навязывание управляемых сред.

> Например если нужна кодогенерация.
???

> C>б*о*льшие языковые возможности,
> Вспомнить про немерле?
Для меня это "C# вид сбоку".

> C>возможности намерянных хаков,
> Зачем?
Бывает нужно.

> C>совместимость с ГИГАНТСКИМИ объемами уже существующего кода.
> Единственное реальное преймущество. Вот только код постоянно обновляется
> и процент safe кода растет.
Если и растет, то только за счет маргинальных проектов. Раньше рос объем
VB6-кода.

> C>Мне вот кроссплатформенный мультипротокольный IM нужен. Казалось бы,
> лучшее место для Java, но нормальных IM-клиентов на Java нет — никого
> обычно не интересует мелкая утилита, жрущая 60Мб памяти (хотя
> корпоративные IMы на Java есть).
> Блин да откуда ты берешь такие цифры? Дай угадаю с потолка верно?
Нет. Я в свое время сам писал видеоIM на Java (с использованием
DivX-сжатия, кстати).

Именно столько занимает корпоративный IM, который я смотрел.

> C>Это не end-user десктопное приложение (я их имел в виду). Из
> end-user'ных знаю только OneNote (который мало кто использует).
> Что жначит не end-user? Я вполне себе end-user этой самой студии.
Не для разработчиков, в общем.

> C>Я не спорю, веб-приложения и серверные системы сейчас идеально на
> C#/Java писать.
> Под десктоп на них тоже можно неплохо писать.
Только корпоративные приложения. Или достаточно крупные suite'ы.

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

C>Я использую в основном: Thunderbird (не помню когда падало), FireFox (вполне стабилен), Apollo (ни разу не падал),
Не использовал.
C>Miranda (действительно глюкодром, ищу замену),
Это точно.
C>FAR (идеален),
Если не увлекаться плагинами...
C>MSVS (достаточно стабильна).
Пока не пытаешься писать под нее расширения.

C>Редкие падения меня ну абсолютно не напрягают.
А меня напрягают. Особенно если упал outpost firewall эта сволоч падает редко но метко убивая винду.

C>Виндовых программ. При миграции Debian x86 -> Debian AMD64 не возникло ни одной проблемы с приложениями.
Ну значит повезло. А как там было с драйверами?

C>Интересно, сколько программ сломались при миграции .NET 1.0 -> .NET 2.0?
Нисколько.
Ибо если программа хочет первый фреймворк то она будет требовать первый, а не второй.
При портирование программы на второй нужно в нескольких местах изменить вызовы некоторых библиотек. Но это не из-за CLR, а из-за того что библиотеки изменились.

C>А сколько сломаются при миграции с Singularity на суперсистему BigBang, в которой будут автомагически проверятся race-condition'ы и неправильное использование потоков?
Те сколько незаметно глючевших программ станут глючить заметно?

C>Понимаешь, даже самая правильная VM с "безопасным" кодом не даст мне прямого управления памятью и указателей.
Зачем?

C>Решается более быстрым процессором. Какие проблемы? Если начать писать проект длительностью в пять лет, то к концу проекта развитие компьютеров и крутых компиляторов сделает софт таким же быстрым как и нативный в начале проекта.


C>В моем случае — жестокая реальность. На производительность нескольких критичных кусков влияло даже неправильное расположение звезд. Причем влияло в разы (JIT иногда отказывался инлайнить циклы).
Те опять несовершенство оптимизатора в современно JIT'е?

C>Есть. И пусть там и используются. Я что ли против?
C>Мне не нравится навязывание управляемых сред.
А мне ненравится тот глюкодром который есть сейчас. Применение управляемых сред позволит значительно снизить колличество глюков.

>> Например если нужна кодогенерация.
C>???
http://www.bltoolkit.net/

>> C>б*о*льшие языковые возможности,
>> Вспомнить про немерле?
C>Для меня это "C# вид сбоку".
Что ты тогда понимаешь под языковыми возможностями?

>> C>возможности намерянных хаков,
>> Зачем?
C>Бывает нужно.
На вопрос ответь.

C>Если и растет, то только за счет маргинальных проектов. Раньше рос объем VB6-кода.
Мда... вот так сразу записал кучу софта в маргиналы...

C>Именно столько занимает корпоративный IM, который я смотрел.
И что это значит? Как это доказывает что любой IM на управляемом языке будет жрать столько памяти?

C>Не для разработчиков, в общем.
C>Только корпоративные приложения. Или достаточно крупные suite'ы.
А какая разница? Чего ты хочешь доказать?

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

ГВ>>>>А фреймворки?
VD>>>25!
ГВ>>33!
VD>

-------------------------
VD>Летят Василий Иванович и Петька на самолете...
VD>Петька:
VD>- Василий Ивановичь! Приборы!!!
VD>- 25.
VD>- Что 25?!!!
VD>- А что приборы?

Пятница? Хм. Нет, вторник.

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

C>WolfHound wrote:
>> C>Только этот код исполняется в режиме ядра, остальной код работает в
>> C>контексте пользователя, так что система выживает даже если упадет
>> C>железка с драйвером. У HP есть такие же технологии (Tandem, теперь Non
>> C>Stop). Так что managed OS нафиг не нужна.
>> Угу а приложение от самого себя кто защищать будет?
C>Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой
C>супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным
C>это не мешало.
Ответил здесь

Автор: Андрей Хропов
Дата: 23.05.06

.

>> Как ты думаешь почему так популярны всякие жабы и дотнеты?
C>Как ты думаешь, а почему они популярны там, где пофиг на объемы
C>сжираемой памяти и быстродействие?
Почему же их все-таки используют если они так плохи?

А вообще есть классический пример: Re: Частые вычисления по неопределенной формуле!!!

Автор: VladD2
Дата: 07.05.04

.

>> Значит они сделали что-то не так. Посмотри на отчет о сингулярити она
>> работает плюс/минус с тойже скоростью что современные винда и линух. И
>> это при том что сингулярити практически не оптимизировали.
C>Сингулярити не позволяет использовать нативный код.
Какая разница?
Ну будет скомпилировано из MSIL JIT или AOT компилятором в тот же машинный код.

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

C>WolfHound wrote:
>> А как виртуальныя машина отменяет разнообразие языков? Единственное что
>> правильная ВМ отменяет всякие низкоуровневые языки которые не
>> контролируют то что делает программист. Но вот нужны ли такие языки?
C>Нужны.
Но для небольшого числа применений (в ядре ОС и драйверах).

C>В качестве Fully Managed OS — уже сейчас у IBM есть AS/400, там как раз
C>ВЕСЬ код в виртуальной машине выполняется. Хотя там набор инструкций VM
C>больше напоминает классические процессорные команды и не является
C>"безопасным" (хотя AS/400 и гарантирует, что приложение не вырвется за
C>пределы логического раздела). Работает все это очень медленно.
Так там наверное интерпретация, а не JIT.
В Java и .NET перешли на JIT модель.