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

Y> Я много где уже слышал со слов разработчиков команды CLR фразы типа "я не в курсе как это сделано в JVM, я не специалист по Java".

Ссылочку можно?

Посмотрел тут еще одно кино
Microsoft .NET Framework: CLR Futures
http://channel9.msdn.com/pdc2008/PC49/
И пришол мне в голову другой домысел, что шарп страшен не только снаружи но и внутри, и добавлять в него новые фичи становится все сложнее. Ведь по хорошему главному языку платформы можно было и синтаксически поддерживать новый фичи, кортежи и контракты.

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

Y>Еще раз, не обязательно быть курицей, чтобы спорить о вкусе яичницы.
Но нужно быть курицей, чтобы знать все нюансы, почему яйцо именно такой формы.
Ну либо изучить яйцо вдоль и поперёк.
Вот именно в этом я очень сильно сомневаюсь.
Зато рассуждений о том, как правильно, и почему никакой совместимости нет и не надо, этого тут дофига, да. Знатоки же.

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

EC>>Эта платформа должна интероперировать много с чем: COM, Plain C dlls, etc.
EC>>И артефакты этого дела много откуда торчат.
WH>Бу-га-га.
WH>Давай придумай куда к интеропу можно прицепить опкоды Add, Mul, Ldc_I4_0,...
Ты мне приписываешь то что сам говорил (про опкоды речь ты вёл, а не я)
и на этом основании делаешь выводы о моей квалификации
WH>Пока я вижу только непонимание азов проектирования программного обеспечения вобще и ВМ в частности.
что никому не интересно.
Скорее здесь уместнее говорить о том, что тебе бы не повредило читать сообщение на которое ты отвечаешь.

EC>>Вариант, что пацаны с рсдн лучше знают как проектировать языки и виртуальные машины мне видится ещё менее реалистичным.
WH>Что? Засчитываем слив сразу или таки найдешь хоть один технический аргумент?
Раз ты такой дока в этои вопросе, то тебе не составит труда прислать ссылки на ВМы и ЯПя реализованные тобой?

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

EC>Раз ты такой дока в этои вопросе, то тебе не составит труда прислать ссылки на ВМы и ЯПя реализованные тобой?
Технических аргументов нет.
Слив засчитан.

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

WH>Слив засчитан.
Хейльсбергу?
Не удалось его перед тобой отмазать?

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

EC>>Раз ты такой дока в этои вопросе, то тебе не составит труда прислать ссылки на ВМы и ЯПя реализованные тобой?
WH>Технических аргументов нет.
WH>Слив засчитан.

Разумеется нет. Их не может быть у нас, так как ВМ мы не писали. У тебя их тоже не может быть.
Всё, что ты приводишь — твои размышления о том, как можно было из имеющихся ингридиентов сделать стейк вкуснее для какой-то целевой аудитории.
Но вот только ты не повар, ингридиентов ты не знаешь и целевую аудиторию тоже.
Но считаешь себя правым лишь на том основании, что мы тоже не повары.
"Слив защитан" — это ты с каких сайтов понабрался?

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

VE>Разумеется нет. Их не может быть у нас, так как ВМ мы не писали.
Ну если для тебя нарушение правил:
1)Нет хардкоду в модели.
2)Отделяем модель от представления.
Не аргумент то разгаваривать с тобой ваще не о чем.
Ибо это простительно только совсем зеленым студентам.
И то после совершения подобного преступления перед архитектурой должна следовать лекция на тему почему так делать не надо.

VE>У тебя их тоже не может быть.
У меня их есть.

VE>Всё, что ты приводишь — твои размышления о том, как можно было из имеющихся ингридиентов сделать стейк вкуснее для какой-то целевой аудитории.
VE>Но вот только ты не повар, ингридиентов ты не знаешь и целевую аудиторию тоже.
VE>Но считаешь себя правым лишь на том основании, что мы тоже не повары.
Я считаю себя правым по тому что много чего изучил и проанализировал.
А так же по тому что ни один из моих опонентов так и не представил аргументы которые бы выдерживали критику.
А доказательства по аналогии применяй гденибудь в других местах. Тут тебя за такие приемы разве что в троли запишут.

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

WH>А доказательства по аналогии применяй гденибудь в других местах. Тут тебя за такие приемы разве что в троли запишут.

А куда нужно записывать за неумение отличать аналогию от аллегории, за подозревание в собеседниках троллей, за "аргументов так и не привели" и за "слив защитан"?
Спорить толку нет. Хейлсберг может и привёл бы тебе сто аргументов, но его тут нет, а у нас нету даже стольких же аргументов, сколько у тебя. В сей локальной баталии ты, конечно, прав.

Но если бы мы тут решили заниматься не демагогией, а говорить об изначальной теме, то никакие твои слова не могут служить доказательством того, что Хейлсберг 20 лет по сторонам не смотрел. Собсно, всё. А аргументы и соображения по этому поводу уже к делу имеют весьма косвенное отношение, потому яйца выеденного не стоят.

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

WH>Ну если для тебя нарушение правил:
WH>1)Нет хардкоду в модели.
WH>2)Отделяем модель от представления.
WH>Не аргумент то разгаваривать с тобой ваще не о чем.
WH>Ибо это простительно только совсем зеленым студентам.

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

WH>А доказательства по аналогии применяй гденибудь в других местах.

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

P.S. На всякий случай. Я не считаю, что нельзя обсуждать структуру ВМ, не написав перед этим собственную, но аргументация твоя, мягко говоря, некорректна.

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

AVK>Тут такое дело, считать что есть какие то абсолютные правила, которые никогда нельзя нарущать, это тоже простительно только не очень опытному разработчику.
А тут абсолютно не обоснованное нарушение правил нарушение которых всегда приводит к проблемам.
Например в данном случае из-за того что int и компания более равны чем все остальные типы аналог std::valarray сделать невозможно.

AVK>Любая программа — компромисс между кучей разных требований.
Давай хоть одно требование которое могло привести к появлению данных опкодов?

Ну и как насчет изобретения делегатов зная о существование функциональных типов?
Как на счет сравнения с образцом и алгебраических типов (вместо енумов)?
Как насчет того чтобы потырить из хаскеля (он на момент разработки .NET уже не один год был) классы типов (пусть и в ограниченном виде)?

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

WH>А тут абсолютно не обоснованное нарушение правил нарушение которых всегда приводит к проблемам.

Я бы поостерегся делать такие сильные заявления, не зная досконально реальные мотивы того или иного решения.

WH>Например в данном случае из-за того что int и компания более равны чем все остальные типы аналог std::valarray сделать невозможно.

Тем не менее, точно такая же (а точнее, еще более усугубленная) ситуация в другом промышленном JITе — JVM.

AVK>>Любая программа — компромисс между кучей разных требований.
WH>Давай хоть одно требование которое могло привести к появлению данных опкодов?

Я тоже не обладаю такой информацией. Слышал, что это вызвано требованиями оптимизатора.

WH>Ну и как насчет изобретения делегатов зная о существование функциональных типов?

Поддержка дизайнтайма?

WH>Как на счет сравнения с образцом и алгебраических типов (вместо енумов)?

Это задачи компилятора, а не джита, ИМХО.

WH>Как насчет того чтобы потырить из хаскеля (он на момент разработки .NET уже не один год был) классы типов (пусть и в ограниченном виде)?

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

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

WH>>Например в данном случае из-за того что int и компания более равны чем все остальные типы аналог std::valarray сделать невозможно.
AVK>Тем не менее, точно такая же (а точнее, еще более усугубленная) ситуация в другом промышленном JITе — JVM.
В JVM это обосновано тем что JVM проектировался как интерпритатор. Это понятно и глядя на первые реализации и на то что опкоды там типизированные.
В .NET JIT был изначально. Да и опкоды там не типизированные. Те нужен вывод типов, а это уже не клеится с интерпритацией. Те .NET проектировали под компиляцию.

AVK>Я тоже не обладаю такой информацией. Слышал, что это вызвано требованиями оптимизатора.
Не выдерживает критики.
Оптимизатору совершенно всеравно что знать в лицо. Опкод Add или функцию Add : int * int -> int.

WH>>Ну и как насчет изобретения делегатов зная о существование функциональных типов?
AVK>Поддержка дизайнтайма?
Не вижу разници.

WH>>Как на счет сравнения с образцом и алгебраических типов (вместо енумов)?
AVK>Это задачи компилятора, а не джита, ИМХО.
Я позволю себе не согласиться.
JIT может сделать все лучше и один раз, а не каждый раз в каждом компиляторе.
Оптимизировать алгебраические типы на уровне ВМ можно так мне просто лень расписывать.

WH>>Как насчет того чтобы потырить из хаскеля (он на момент разработки .NET уже не один год был) классы типов (пусть и в ограниченном виде)?
AVK>Не уверен, что их вот так просто можно взять и потырить.
Если ограничить реализацию класса типа сборками в которых описан либо тип либо класс типов то они не протеворячат компонентности и являются строгим надмножеством интерфейсов.

AVK>Побочные эффекты для той же верификации мне на вскидку не ясны.
Сугубо положительные. Например: http://en.wikipedia.org/wiki/Cat_programming_language
Модель .NET для верефикации по любому далеко не самая дружественная из возможных.

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

WH>В JVM это обосновано тем что JVM проектировался как интерпритатор. Это понятно и глядя на первые реализации и на то что опкоды там типизированные.

Ну вот а в дотнете пошли чуть дальше — типизацию арифметики немножко уменьшили, что дало возможность делать чуть больше оптимизаций. Где то на эту тему в MSDN статья попадалась. Почему не сделали совсем абстрактным? У меня ответа на этот вопрос нет. Возможно, какие то проблемы с оптимизацией или верификацией, может быть что то не клеилось в реализации CF, может какая то совместимость с C++/CLI и его оптимизатором. Тем и отличаются реальные большие продукты от демок и концептов, что факторов приходися учитывать намного больше.
Так что, не зная всех подробностей, переливать из пустого в порожнее смысла не много. Когда (если) мне понадобится делать свой собственный JIT, вот тогда я и буду думать, как и овец спасти, и волка накормить, и шерсть с овец настричь.
Вот если мы не готовый продукт видим, а концепт, вот тогда совершенно резонно потребовать от авторов обоснования большинства решений, потому что в том смысл концепта и состоит.

WH>В .NET JIT был изначально.

Ага, от MS JVM

WH> Да и опкоды там не типизированные. Те нужен вывод типов

Ну, назвать это выводом типов можно только с большой натяжкой. Просто некий JIT-time полиморфизм.

AVK>>Поддержка дизайнтайма?
WH>Не вижу разници.

Разница в том, что нужна некая сущность, метаданные которой подробнейшим образом будут содержаться в сборке. Да еще нужно, чтобы эта сущность была совместима с IConnectionPoint сотоварищи, механикой TP/RP и много чем еще. Опять же, все то же самое — ситуация крайне многофакторная, навскидку пытаться делать заявления в стиле suxx/rulezz я бы не взялся.

AVK>>Это задачи компилятора, а не джита, ИМХО.
WH>Я позволю себе не согласиться.
WH>JIT может сделать все лучше и один раз

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

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

А ты уверен, что оно не противоречит ни одному существующему механизму в экосистеме, и не приведет к потере совместимости?

WH>Модель .NET для верефикации по любому далеко не самая дружественная из возможных.

Уж какая есть. Делать совсем не так уже поздно.

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

AVK>Ну вот а в дотнете пошли чуть дальше — типизацию арифметики немножко уменьшили, что дало возможность делать чуть больше оптимизаций.
Что-то как-то сомнительно.
Скорее решили колличество опкодов уменьшить.

AVK>Где то на эту тему в MSDN статья попадалась.
Ссылку можно?

AVK>Почему не сделали совсем абстрактным? У меня ответа на этот вопрос нет.
Я думаю его и у комманды CLR нет.

AVK>Возможно, какие то проблемы с оптимизацией или верификацией,
Ваще критику не держит.

AVK>может быть что то не клеилось в реализации CF,
Отдельный JIT для CF как по мне вобще сюр.

AVK>может какая то совместимость с C++/CLI и его оптимизатором.
Ну не поверю я в то что C++/CLI настолько дубовый что не может вместо опкода Add сгенерить вызов функции Add : int * int -> int. Ибо его таки научили генерировать код для стековой, а не регистровой машины.

AVK>Тем и отличаются реальные большие продукты от демок и концептов, что факторов приходися учитывать намного больше.
Назови хоть один фактор который не выглядит смешным?

WH>>В .NET JIT был изначально.
AVK>Ага, от MS JVM
И че?
Научить его понимать что опкод AddIntInt и вызов функции Add : int * int -> int это одно и тоже как по мне задача тривиальная.

AVK>Ну, назвать это выводом типов можно только с большой натяжкой.
Очень простой, однопроходный вывод типов.

AVK>Разница в том, что нужна некая сущность, метаданные которой подробнейшим образом будут содержаться в сборке. Да еще нужно, чтобы эта сущность была совместима с IConnectionPoint сотоварищи, механикой TP/RP и много чем еще. Опять же, все то же самое — ситуация крайне многофакторная, навскидку пытаться делать заявления в стиле suxx/rulezz я бы не взялся.
Ну давай раскажи что такоего есть у делегата чего нет у функционального типа приминительно ко всему этому списку?

AVK>Мне кажется, текущий JIT слишком низкоуровневый для таких конструкций. Смешивание же разных уровней внутри него чревато усложнением как компиляторов, так и рантайма. Для поиска оптимума нужно провести довольно много экспериментов. Я таковых не проводил и в ближайшее время проводить не собираюсь.
А они разрабатывали ВМ с нуля и могли (я бы даже сказал обязаны) сделать эти эксперементы эксперементы.

AVK>А ты уверен, что оно не противоречит ни одному существующему механизму в экосистеме, и не приведет к потере совместимости?
Аргх. Еще раз: Проектирование ВМ с нуля. Какая к черту совместимость?

WH>>Модель .NET для верефикации по любому далеко не самая дружественная из возможных.
AVK>Уж какая есть. Делать совсем не так уже поздно.
Фразу не осилил.

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

WH>Что-то как-то сомнительно.

За что купил, за то продаю.

AVK>>Где то на эту тему в MSDN статья попадалась.
WH>Ссылку можно?

Нельзя, не сохранил.

AVK>>Почему не сделали совсем абстрактным? У меня ответа на этот вопрос нет.
WH>Я думаю его и у комманды CLR нет.

Ты их за кого вообще принимаешь? Да, что это за мода такая пошла, писать слово команда с двумя "м"?

AVK>>может быть что то не клеилось в реализации CF,
WH>Отдельный JIT для CF как по мне вобще сюр.

По тебе сюр, а по факту JIT там довольно специфичный.

AVK>>Тем и отличаются реальные большие продукты от демок и концептов, что факторов приходися учитывать намного больше.
WH>Назови хоть один фактор который не выглядит смешным?

Я не знаю, что для тебя выглядит смешным, а что нет.

WH>>>В .NET JIT был изначально.
AVK>>Ага, от MS JVM
WH>И че? Научить его понимать что опкод AddIntInt и вызов функции Add : int * int -> int это одно и тоже как по мне задача тривиальная.

А по мне, так твое мнение не стоит ничего, потому что информации о том, что было на руках у разработчиков ноль целых, ноль десятых. Такие дела.

WH>Ну давай раскажи что такоего есть у делегата чего нет у функционального типа приминительно ко всему этому списку?

Андрей, не надо разговаривать со мной таким тоном. Я тебе на это ответ уже давал — я не знаю, информации у меня нет. Но твое "шапками закидаем" выглядит не очень убедительно.

WH>А они разрабатывали ВМ с нуля

Я уже писал — они использовали свою JVM.

WH> и могли (я бы даже сказал обязаны) сделать эти эксперементы эксперементы.

Я не помню, рассказывал ли я тебе эту историю, так что не обессудь, если повторюсь.
В одной конторе решили как то создать новое поколение продукта. Создали под это дело команду крутых челов, которые, вот прям как ты, рассказывали какие существующие системы отстой, и какая новая система будет вся из себя правильная. Обозвали продукт "Контора 9" и работа пошла. Прошло полгода. И оказалось, что, как раз из-за того, что они во всем находили фатальный недостаток, у них в качестве того, что можно показать не оказалось ни-че-го. Результат предсказать несложно — орлов разогнали, проект закрыли.
Таких историй по всему миру море, в том числе и в МС. Так что ни один вменяемый менеджер, стоя перед задачей с такими грандиозными рисками, не решится еще и новый дивный джит писать.

AVK>>А ты уверен, что оно не противоречит ни одному существующему механизму в экосистеме, и не приведет к потере совместимости?
WH>Аргх. Еще раз: Проектирование ВМ с нуля. Какая к черту совместимость?

Еще раз — не с нуля.

WH>>>Модель .NET для верефикации по любому далеко не самая дружественная из возможных.
AVK>>Уж какая есть. Делать совсем не так — уже поздно.
WH>Фразу не осилил.

Тире для понимания поставил.

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

AVK>Ну вот а в дотнете пошли чуть дальше — типизацию арифметики немножко уменьшили, что дало возможность делать чуть больше оптимизаций.
Нет, им просто опкодов не хватало. А типизация арифметики всё равно строго выводится на этапе JIT-компиляции во время построения SSA-дерева. Так что никаких возможностей оптимизации онр не даёт.

H>>В .NET JIT был изначально.
AVK>Ага, от MS JVM
Примерно так. CLR совсем неприспособлен для интерпретации. Интерпретатор .NET примерно в разы медленнее аналогичного JVM-ного. Как раз из-за нетипизированной арифметики.

WH>>Модель .NET для верефикации по любому далеко не самая дружественная из возможных.
AVK>Уж какая есть. Делать совсем не так уже поздно.
Распонтованый Code Access Security в том же Silverlight уже упростили до минимума.

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

C>Распонтованый Code Access Security в том же Silverlight уже упростили до минимума.
Распонтованый Code Access Security ваще кривой костыль.
И при правильной модели ВМ не нужен.

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

AVK>>Ну вот а в дотнете пошли чуть дальше — типизацию арифметики немножко уменьшили, что дало возможность делать чуть больше оптимизаций.
C>Нет, им просто опкодов не хватало.

То же самое. Я конечно ценю твое мнение — но товарищам, которые это делали, я пока что больше доверяю.

C> А типизация арифметики всё равно строго выводится на этапе JIT-компиляции во время построения SSA-дерева. Так что никаких возможностей оптимизации онр не даёт.

Так, читаем внимательнее. Речь о том, что уменьшение типизации по сравнению с исходным JVM позволило делать более агрессивные оптимизации. Т.е. как раз та самая штука, которую в соседнем топике пытаются Дворкину объяснить.

C>Распонтованый Code Access Security в том же Silverlight уже упростили до минимума.

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

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

AVK>Так, читаем внимательнее. Речь о том, что уменьшение типизации по сравнению с исходным JVM позволило делать более агрессивные оптимизации. Т.е. как раз та самая штука, которую в соседнем топике пытаются Дворкину объяснить.
Вот тебе таблица типизации опкода Add
http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.add(VS.95).aspx
Те мы получаем типизированные опкоды.
Следовательно утверждение о том что это сделано для более агрессивной оптимизации идет лесом.

C>>Распонтованый Code Access Security в том же Silverlight уже упростили до минимума.
AVK>Ну, не очень оно пошло, что ж тут делать то.
Ну так костыль вот и не пошло.
Про то как сделать security без костылей я недавно писал в "арихмтектуре".