Не знаю, насколько это всё соответствует действительности (правда, zdnet для меня лично не совсем бульварная пресса ), но показалась интересной статья, где говорят, что МС готовят что-то аля Dynamic Language Runtime на конференции Mix '07, которая должна открыться в следующий понедельник. Если смотреть с маркетинговых позиций, то вполне даже нелпохой ход, но вот насколько это востребовано в реальной интересно. Я не призываю к очередным войнам динамик vs. статик, просто интересно было бы знать процент который готов перейти на динамику. Правда есть же вроде VB.Net, который включает динамику. Сама динамика не единственный фактор, есть ещё такой момент как фреймворки (Rails, Django), которые сейчас довольно на слуху.
От себя добавлю, что работая сейчас с Websphere, местами код на Java динамический по сути, но в рамках статического языка (аля someObject.getString("field1")), поэтому сильно многословный, и наличие опциональной динамики помогло бы. Правда это тоже спорно: может что-то аля Scala помогло бы тоже (надо будет поподробней исследовать этот вариант).
Здравствуйте, Курилка, Вы писали:
К>Не знаю, насколько это всё соответствует действительности (правда, zdnet для меня лично не совсем бульварная пресса ), но показалась интересной статья, где говорят, что МС готовят что-то аля Dynamic Language Runtime на конференции Mix '07, которая должна открыться в следующий понедельник.
Это не dynamic runtime, а dynamic layer for clr. До dynamic runtime'а ему еще далеко. Думаю, что все ограничивается поддержкой динамических методов. IMHO, полной поддержки динамических языков там и не светит, так как runtime изначально статический. Поэтому все реализации динамических языков под CLR немного ущербные.
> Если смотреть с маркетинговых позиций, то вполне даже нелпохой ход, но вот насколько это востребовано в реальной интересно. Я не призываю к очередным войнам динамик vs. статик, просто интересно было бы знать процент который готов перейти на динамику. Правда есть же вроде VB.Net, который включает динамику.
IronPython вот уже несколько лет существует. Ruby тоже вроде недавно появился. Кто хотел (а таких немного), давно уже их используют.
Здравствуйте, l33thaxor, Вы писали:
L>Здравствуйте, Курилка, Вы писали:
К>>Не знаю, насколько это всё соответствует действительности (правда, zdnet для меня лично не совсем бульварная пресса ), но показалась интересной статья, где говорят, что МС готовят что-то аля Dynamic Language Runtime на конференции Mix '07, которая должна открыться в следующий понедельник.
L>Это не dynamic runtime, а dynamic layer for clr. До dynamic runtime'а ему еще далеко. Думаю, что все ограничивается поддержкой динамических методов.
Ммм, ты видел спецификацию?
Хотя, наверное, ты прав.
Но это не мешает назвать это всё дело так, как захочется самому МС.
L> IMHO, полной поддержки динамических языков там и не светит, так как runtime изначально статический.
Что ты подразумеваешь под полоной поддержкой? На статических языках делают вполне динамические вещи, имхо порой надо не сильно много сахара и всё L>Поэтому все реализации динамических языков под CLR немного ущербные.
Можно тут поподробней, в чём конкретно разница?
L>IronPython вот уже несколько лет существует.
1.0 выпустили лишь в прошлом году. L>Ruby тоже вроде недавно появился.
Интерпретатор с очень слабой скоростью. Люди вон переходят на тот же питон по этой причине. L>Кто хотел (а таких немного), давно уже их используют.
С таким подходом вообще в мире бы врядли что новое появилось — ведь всё уже есть, зачем что-то делать?
А если конкретней — у большой части народа (программстского в том числе) есть инерционность и для того, чтобы её преодалеть нужен некий толчок, и МС способна его сделать. Правда, есть другой вопрос — а нужна ли динамика в мейнстриме? Я думаю да, чем больше идей проработано и доступно для применения, тем лучше.
Здравствуйте, Курилка, Вы писали:
К>Не знаю, насколько это всё соответствует действительности (правда, zdnet для меня лично не совсем бульварная пресса ), но показалась интересной статья, где говорят, что МС готовят что-то аля Dynamic Language Runtime на конференции Mix '07, которая должна открыться в следующий понедельник. Если смотреть с маркетинговых позиций, то вполне даже нелпохой ход, но вот насколько это востребовано в реальной интересно.
Пока в .NET не будут решены архитектурные проблемы с GC-сборкой сгенерированого кода — то у динамики всегда будут проблемы. Возможность сборки статических методов — явно недостаточно.
Здравствуйте, Cyberax, Вы писали:
C>Пока в .NET не будут решены архитектурные проблемы с GC-сборкой сгенерированого кода — то у динамики всегда будут проблемы. Возможность сборки статических методов — явно недостаточно.
Можно пояснить выделенное? Слова вроде знакомые, но, что конкретно имеется в виду, не могу понять
Здравствуйте, Курилка, Вы писали: К>Можно пояснить выделенное? Слова вроде знакомые, но, что конкретно имеется в виду, не могу понять
Имеется в виду LWCG — DynamicMethod. Возможность быстро сгенерировать метод без всей обязательной обвязки типа сборка/класс. В отличие от классического Emit, код такого метода собирается GC, став ненужным.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Имеется в виду LWCG — DynamicMethod. Возможность быстро сгенерировать метод без всей обязательной обвязки типа сборка/класс. В отличие от классического Emit, код такого метода собирается GC, став ненужным.
Выделенное есть корректная аббревиатура? А то гуглом чтот ничего вменяемого
Здравствуйте, Cyberax, Вы писали:
C>Пока в .NET не будут решены архитектурные проблемы с GC-сборкой сгенерированого кода — то у динамики всегда будут проблемы. Возможность сборки статических методов — явно недостаточно.
Проблема такая есть, но я не понимаю, почему именно она является препятствием для динамики.
Можете пояснить? Какой-нибудь характерный сценарий, где это проявляется...
Здравствуйте, nikov, Вы писали:
C>>Пока в .NET не будут решены архитектурные проблемы с GC-сборкой сгенерированого кода — то у динамики всегда будут проблемы. Возможность сборки статических методов — явно недостаточно. N>Проблема такая есть, но я не понимаю, почему именно она является препятствием для динамики. N>Можете пояснить? Какой-нибудь характерный сценарий, где это проявляется...
Все известные мне быстрые интерпретаторы на .NET/JVM занимаются выводом типов и генерацией байт-кода "на лету". При этом часто получается очень много кода, так как один участок динамического кода может перекомпилироваться много раз. Ну а у .NET как раз проблемы со сборкой JIT-кода.
Здравствуйте, nikov, Вы писали:
N>Проблема такая есть, но я не понимаю, почему именно она является препятствием для динамики. N>Можете пояснить? Какой-нибудь характерный сценарий, где это проявляется...
Например в ситуациях связанный с duck typing. При входе в функцию, динамический язык может проверить тип параметров и сгенерировать код функции именно для данного типа без внутренних проверок типов. Для другого вызова с другими типами параметров, может быть сгенерена другая процедура. Кол-во сгенеренных процедур при увеличении кол-ва параметров теоретически в худшем случае увеличивается в экспонент. прогрессии. Чтобы это обходить подобное, нужен либо GC, либо добавлять проверки типов, либо ограничивать duck typing. И неплохо бы учитывать, что существует понятие инкапсуляции класса поддерживаемое CLR. Вобщем проблемы при реализации динам. языков на Net есть. Достаточно взглянуть на IL от JScript.Net.
Здравствуйте, GlebZ, Вы писали:
GZ>При входе в функцию, динамический язык может проверить тип параметров и сгенерировать код функции именно для данного типа без внутренних проверок типов.
Гениально!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Все известные мне быстрые интерпретаторы на .NET/JVM занимаются выводом типов и генерацией байт-кода "на лету". При этом часто получается очень много кода, так как один участок динамического кода может перекомпилироваться много раз.
Почему один участок должен перекомпилироваться много раз?
Здравствуйте, VladD2, Вы писали: VD>Гениально!
Я думаю, он имеет в виду, что в некоторых случаях среда исполнения может вычислить, что тип является инвариантным (пример — сложение целых чисел в цикле), и устранить проверки типа из функции.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я думаю, он имеет в виду, что в некоторых случаях среда исполнения может вычислить, что тип является инвариантным (пример — сложение целых чисел в цикле), и устранить проверки типа из функции.
А я думаю, что он что имел то и ввел. Просто начитался Кибераксовских расказов о PyPy. PyPy, правда, дает весьма медленный код, но как религия он вполне себе ничего.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А я думаю, что он что имел то и ввел. Просто начитался Кибераксовских расказов о PyPy. PyPy, правда, дает весьма медленный код, но как религия он вполне себе ничего.
Вообще-то мне хватает и так что читать. Что касается адаптивной перекомпиляции, то тут действительно прогнал. Акромя допотопного SELF никто этого не делал. Хотя в действительности, никто и не мешает в динамике это делать.
Здравствуйте, GlebZ, Вы писали:
GZ>Вообще-то мне хватает и так что читать. Что касается адаптивной перекомпиляции, то тут действительно прогнал. Акромя допотопного SELF никто этого не делал. Хотя в действительности, никто и не мешает в динамике это делать.
Дело в том, что эти технологии хорошо выглядят только на словах. На мой взгляд, окромя вывода типов все остальные подходы создают больше проблем чем решаеют. Динамическая специализация обязательно приводит к созданию кода диспетчиризации который и сжирает весь выигрышь от компиляции. Так что результат получается так себе.
Насколько я знаю в новую версию Питона закладывают поддержку вывода типов. Расчет очень простой. В местах где действительно нужна скорость можно будет писать так чтобы типы выводились сами или анотировать их врнучную (или совмещать и то и другое). Это подход правильный и с ним можно достичь многого.
Вот только не ясно зачем это все. Ведь уже есть как минимум 3 языка с полным выоводм типов которые практически не пуступают динамическим языкам ни по выразительности, ни по гибкости. Точнее даже во многом их превосходят. Так что зачем эта возня я лично не понимаю.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Дело в том, что эти технологии хорошо выглядят только на словах. На мой взгляд, окромя вывода типов все остальные подходы создают больше проблем чем решаеют. Динамическая специализация обязательно приводит к созданию кода диспетчиризации который и сжирает весь выигрышь от компиляции. Так что результат получается так себе.
Так можно и JIT в CLR отменить, который частным случаем является этой динамической специализации.
Вообще же во всяких смоллтолках (особенно VisualWorks) и коммон лиспе это довольно все прилично работает вообще без вывода типов.
VD>Вот только не ясно зачем это все. Ведь уже есть как минимум 3 языка с полным выоводм типов которые практически не пуступают динамическим языкам ни по выразительности, ни по гибкости. Точнее даже во многом их превосходят. Так что зачем эта возня я лично не понимаю.
Ну на самом деле с полным выводом типов юзабельных языков пока что нет. И неизвестно когда будет, если вообще.
А с каким-то выводом их гораздо больше чем 3, в несколько раз. Или это только дотнет имелся в виду?
Но в любом случае, у динамических языков конечно свои преимущества и в некоторых случаях огромная выразительность. Рефлексию, кодогенерацию/модификацию в рантайме и даже просто eval можно конечно и в статических языках сделать, но это будет две большие разницы в простоте, удобстве и выразительности между ними и Smalltalk/CL/Tcl. В общем-то даже с питоном, хоть он и достаточно дубовый в этом плане.
прежде чем понять рекурсию, необходимо понять рекурсию.
Здравствуйте, граммофон, Вы писали:
Г>Так можно и JIT в CLR отменить, который частным случаем является этой динамической специализации.
JIT — как раз технология продуманная. Хотя лично я предпочел бы пре-JIT. Разговоры о крутости динамической перекомпиляции в основном только пустое сотрясение воздуха. Хорошие оптимизирвующие компиляторы все равно дают больше толку. А пре-JIT имеет все их приемущества плюс возможность оптимизации под конкретную машину.
Г>Вообще же во всяких смоллтолках (особенно VisualWorks) и коммон лиспе это довольно все прилично работает вообще без вывода типов.
Это безответственные и нечем не подкрепленные заявления. Тут вот где-то пробегала пенесометрия "АльфаБлэнд". Можешь воспроизвести на любом Смолтоке и убедиться, что он и рядом не лежал со строготипизированными языками (PyPy на нем слил очень показательно).
Г>Ну на самом деле с полным выводом типов юзабельных языков пока что нет.
Исключительно для тебя. Хаскель и ОКамл никто не отменял. Они может быть и не удобным для многих, но скорее из-за радикально иного синтаксиса. Смолток тоже явно в этом плане далек от мэйнстрима.
В прочем "полный" вывод и не нужен. На уровне типов и методов явная аннотация типов ни сколько не напрягает и даже наоборот приносит немалые дивиденды спасая от ошибко и обеспечивая поддержку интелисенса.
Г>А с каким-то выводом их гораздо больше чем 3, в несколько раз. Или это только дотнет имелся в виду?
Имеются в виду гибридные языки нового поколения на фоне которых Смотолк выглядит недоразумением.
Г>Но в любом случае, у динамических языков конечно свои преимущества и в некоторых случаях огромная выразительность.
Еще одно голословное утверждение не имеющее ничего общего с действительностью.
Г> Рефлексию, кодогенерацию/модификацию в рантайме и даже просто eval можно конечно и в статических языках сделать, но это будет две большие разницы в простоте, удобстве и выразительности между ними и Smalltalk/CL/Tcl. В общем-то даже с питоном, хоть он и достаточно дубовый в этом плане.
Откровенно говоря говорить с людьми не видившими ничего кроме скриптов просто не интересно. Этот форум кишит пдобными флэймами. Делай поиск и изучай. Мне обсуждения этой чущи порядком поднадоели.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Г>>Вообще же во всяких смоллтолках (особенно VisualWorks) и коммон лиспе это довольно все прилично работает вообще без вывода типов.
VD>Это безответственные и нечем не подкрепленные заявления. Тут вот где-то пробегала пенесометрия "АльфаБлэнд". Можешь воспроизвести на любом Смолтоке и убедиться, что он и рядом не лежал со строготипизированными языками (PyPy на нем слил очень показательно).
Ну вот, сразу Альфа Бленд. Разумеется, на числодробильне динамические языки не блещут. По причине ссылочности любых данных.
Речь-то изначально шла о динамической диспетчеризации и избавления от оверхеда на вызов функции. С этим-то у смоллтолка как раз все в порядке.
А со ссылочностью да, можно локально бороться с дополнительной аннотацией/выводом типов. Common Lisp и Dylan так и делают. Там и альфабленд не критично отстанет, полагаю.
Г>>Ну на самом деле с полным выводом типов юзабельных языков пока что нет.
VD>В прочем "полный" вывод и не нужен. На уровне типов и методов явная аннотация типов ни сколько не напрягает и даже наоборот приносит немалые дивиденды спасая от ошибко и обеспечивая поддержку интелисенса.
Г>>А с каким-то выводом их гораздо больше чем 3, в несколько раз. Или это только дотнет имелся в виду?
VD>Имеются в виду гибридные языки нового поколения на фоне которых Смотолк выглядит недоразумением.
Так уж и недоразумением? А по-моему, это как сказать, что суахили будет выглядеть недоразумением Смоллтолк — не совсем general purpose язык. У него довольно своеобразная область применения и вообще модель исполнения. И там он как выглядел, так по-моему и выглядит последние лет 30.
Г>>Но в любом случае, у динамических языков конечно свои преимущества и в некоторых случаях огромная выразительность.
VD>Еще одно голословное утверждение не имеющее ничего общего с действительностью.
Да как угодно. В конце концов действительность штука такая.
VD>Откровенно говоря говорить с людьми не видившими ничего кроме скриптов просто не интересно. Этот форум кишит пдобными флэймами. Делай поиск и изучай. Мне обсуждения этой чущи порядком поднадоели.
Кажется, меня записали в поклонники динамики и script kiddies и сами же обиделись на это
Да видел я что-то кроме скриптов, спасибо Действительно.
Хотя, впрочем, спорить сильно не буду. Ведь действительность — это вещь такая...
прежде чем понять рекурсию, необходимо понять рекурсию.
), но показалась интересной статья, где говорят, что МС готовят что-то аля Dynamic Language Runtime на конференции Mix '07, которая должна открыться в следующий понедельник. Если смотреть с маркетинговых позиций, то вполне даже нелпохой ход, но вот насколько это востребовано в реальной интересно. Я не призываю к очередным войнам динамик vs. статик, просто интересно было бы знать процент который готов перейти на динамику. Правда есть же вроде VB.Net, который включает динамику. Сама динамика не единственный фактор, есть ещё такой момент как фреймворки (Rails, Django), которые сейчас довольно на слуху.
