Здравствуйте, VladD2, Вы писали:
VD>Вот практические тесты показали, что только компилирующие варианты Лиспа с полной аннотацией типов могут соревнаваться с С++-ным тестом.
Кто мешает использовать? (а, я сам знаю — большинству кодеров — скобочки! )
VD>А при этом код превращется в жутик по чище С++-ного.
Это субъективно и "определяется только привычками"
VD> ... все эти споры сводятся к разсуждениям о предпочтениях.
...и ты никак не устанешь рассказывать нам о своих предпочтениях. Иногда это начинает походить на навязывание единственно верного мнения. Но мы же понимаем, что ты не будешь заниматься таким бесполезным и бесперспективным делом
VD>На мой взгляд использование скриптов определяется только привычками и никим уровнем реализаций большинства статически типизированных языков. Развитие идет по спирали, и на каждом ее витке динамические языки снова всплывают начиная новый круг борбы с ними.
shell + web (+ сейчас xml с отпрысками вообще в каждой второй дырке, если не чаще) — те области, которые будут источниками подобных поползновений ещё очень долго.
VD>Вывод типов, метапрограммирование, сопоставление с образцом, автоматические теорем-пруверы должны снова откинуть динамику в нибытие до нового витка.
Должны? Ха-ха, Вы слишком оптимистичны. Могут — да. Если языки а-ля один всем здесь известный получат должную поддержку, распространение и развитие (в чём я очень сомневаюсь). Что касается такого как "Вывод типов, метапрограммирование, сопоставление с образцом, автоматические теорем-пруверы" — есть Qi (http://www.lambdassociates.org/). Да, его можно обозвать "академической поделкой", но в той-же степени что и... Ну, я надеюсь, меня все поняли
VD>Потом динамика возможно снова вылезет и будет новый виток борьбы с ней. И так до бесконечности.
Динамика никуда не денется и, соответственно, ей не надо ни откуда выползать. Пока код будут писать люди. Разные люди. Быстрее "динамику" может "закрыть" реализация большинства "динамических возможностей" (используемых по требованию) в мультипарадигменных языках, что мы уже частично наблюдаем. Только это будет концом и для "статики", которая в "чистом виде" нужна как "чисто функциональное программирование".
Здравствуйте, граммофон, Вы писали:
Г>Так можно и JIT в CLR отменить, который частным случаем является этой динамической специализации.
JIT — как раз технология продуманная. Хотя лично я предпочел бы пре-JIT. Разговоры о крутости динамической перекомпиляции в основном только пустое сотрясение воздуха. Хорошие оптимизирвующие компиляторы все равно дают больше толку. А пре-JIT имеет все их приемущества плюс возможность оптимизации под конкретную машину.
Г>Вообще же во всяких смоллтолках (особенно VisualWorks) и коммон лиспе это довольно все прилично работает вообще без вывода типов.
Это безответственные и нечем не подкрепленные заявления. Тут вот где-то пробегала пенесометрия "АльфаБлэнд". Можешь воспроизвести на любом Смолтоке и убедиться, что он и рядом не лежал со строготипизированными языками (PyPy на нем слил очень показательно).
Г>Ну на самом деле с полным выводом типов юзабельных языков пока что нет.
Исключительно для тебя. Хаскель и ОКамл никто не отменял. Они может быть и не удобным для многих, но скорее из-за радикально иного синтаксиса. Смолток тоже явно в этом плане далек от мэйнстрима.
В прочем "полный" вывод и не нужен. На уровне типов и методов явная аннотация типов ни сколько не напрягает и даже наоборот приносит немалые дивиденды спасая от ошибко и обеспечивая поддержку интелисенса.
Г>А с каким-то выводом их гораздо больше чем 3, в несколько раз. Или это только дотнет имелся в виду?
Имеются в виду гибридные языки нового поколения на фоне которых Смотолк выглядит недоразумением.
Г>Но в любом случае, у динамических языков конечно свои преимущества и в некоторых случаях огромная выразительность.
Еще одно голословное утверждение не имеющее ничего общего с действительностью.
Г> Рефлексию, кодогенерацию/модификацию в рантайме и даже просто eval можно конечно и в статических языках сделать, но это будет две большие разницы в простоте, удобстве и выразительности между ними и Smalltalk/CL/Tcl. В общем-то даже с питоном, хоть он и достаточно дубовый в этом плане.
Откровенно говоря говорить с людьми не видившими ничего кроме скриптов просто не интересно. Этот форум кишит пдобными флэймами. Делай поиск и изучай. Мне обсуждения этой чущи порядком поднадоели.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали: К>Можно пояснить выделенное? Слова вроде знакомые, но, что конкретно имеется в виду, не могу понять
Имеется в виду LWCG — DynamicMethod. Возможность быстро сгенерировать метод без всей обязательной обвязки типа сборка/класс. В отличие от классического Emit, код такого метода собирается GC, став ненужным.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Курилка, Вы писали:
К>Не знаю, насколько это всё соответствует действительности (правда, zdnet для меня лично не совсем бульварная пресса ), но показалась интересной статья, где говорят, что МС готовят что-то аля Dynamic Language Runtime на конференции Mix '07, которая должна открыться в следующий понедельник. Если смотреть с маркетинговых позиций, то вполне даже нелпохой ход, но вот насколько это востребовано в реальной интересно.
Пока в .NET не будут решены архитектурные проблемы с GC-сборкой сгенерированого кода — то у динамики всегда будут проблемы. Возможность сборки статических методов — явно недостаточно.
Здравствуйте, Cyberax, Вы писали:
C>Пока в .NET не будут решены архитектурные проблемы с GC-сборкой сгенерированого кода — то у динамики всегда будут проблемы. Возможность сборки статических методов — явно недостаточно.
Проблема такая есть, но я не понимаю, почему именно она является препятствием для динамики.
Можете пояснить? Какой-нибудь характерный сценарий, где это проявляется...
Здравствуйте, nikov, Вы писали:
C>>Пока в .NET не будут решены архитектурные проблемы с GC-сборкой сгенерированого кода — то у динамики всегда будут проблемы. Возможность сборки статических методов — явно недостаточно. N>Проблема такая есть, но я не понимаю, почему именно она является препятствием для динамики. N>Можете пояснить? Какой-нибудь характерный сценарий, где это проявляется...
Все известные мне быстрые интерпретаторы на .NET/JVM занимаются выводом типов и генерацией байт-кода "на лету". При этом часто получается очень много кода, так как один участок динамического кода может перекомпилироваться много раз. Ну а у .NET как раз проблемы со сборкой JIT-кода.
Здравствуйте, GlebZ, Вы писали:
GZ>При входе в функцию, динамический язык может проверить тип параметров и сгенерировать код функции именно для данного типа без внутренних проверок типов.
Гениально!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Вообще-то мне хватает и так что читать. Что касается адаптивной перекомпиляции, то тут действительно прогнал. Акромя допотопного SELF никто этого не делал. Хотя в действительности, никто и не мешает в динамике это делать.
Дело в том, что эти технологии хорошо выглядят только на словах. На мой взгляд, окромя вывода типов все остальные подходы создают больше проблем чем решаеют. Динамическая специализация обязательно приводит к созданию кода диспетчиризации который и сжирает весь выигрышь от компиляции. Так что результат получается так себе.
Насколько я знаю в новую версию Питона закладывают поддержку вывода типов. Расчет очень простой. В местах где действительно нужна скорость можно будет писать так чтобы типы выводились сами или анотировать их врнучную (или совмещать и то и другое). Это подход правильный и с ним можно достичь многого.
Вот только не ясно зачем это все. Ведь уже есть как минимум 3 языка с полным выоводм типов которые практически не пуступают динамическим языкам ни по выразительности, ни по гибкости. Точнее даже во многом их превосходят. Так что зачем эта возня я лично не понимаю.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не знаю, насколько это всё соответствует действительности (правда, 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>Кто хотел (а таких немного), давно уже их используют.
С таким подходом вообще в мире бы врядли что новое появилось — ведь всё уже есть, зачем что-то делать?
А если конкретней — у большой части народа (программстского в том числе) есть инерционность и для того, чтобы её преодалеть нужен некий толчок, и МС способна его сделать. Правда, есть другой вопрос — а нужна ли динамика в мейнстриме? Я думаю да, чем больше идей проработано и доступно для применения, тем лучше.
Здравствуйте, Cyberax, Вы писали:
C>Пока в .NET не будут решены архитектурные проблемы с GC-сборкой сгенерированого кода — то у динамики всегда будут проблемы. Возможность сборки статических методов — явно недостаточно.
Можно пояснить выделенное? Слова вроде знакомые, но, что конкретно имеется в виду, не могу понять
Здравствуйте, Sinclair, Вы писали:
S>Имеется в виду LWCG — DynamicMethod. Возможность быстро сгенерировать метод без всей обязательной обвязки типа сборка/класс. В отличие от классического Emit, код такого метода собирается GC, став ненужным.
Выделенное есть корректная аббревиатура? А то гуглом чтот ничего вменяемого
Здравствуйте, nikov, Вы писали:
N>Проблема такая есть, но я не понимаю, почему именно она является препятствием для динамики. N>Можете пояснить? Какой-нибудь характерный сценарий, где это проявляется...
Например в ситуациях связанный с duck typing. При входе в функцию, динамический язык может проверить тип параметров и сгенерировать код функции именно для данного типа без внутренних проверок типов. Для другого вызова с другими типами параметров, может быть сгенерена другая процедура. Кол-во сгенеренных процедур при увеличении кол-ва параметров теоретически в худшем случае увеличивается в экспонент. прогрессии. Чтобы это обходить подобное, нужен либо GC, либо добавлять проверки типов, либо ограничивать duck typing. И неплохо бы учитывать, что существует понятие инкапсуляции класса поддерживаемое CLR. Вобщем проблемы при реализации динам. языков на Net есть. Достаточно взглянуть на IL от JScript.Net.
Здравствуйте, 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 никто этого не делал. Хотя в действительности, никто и не мешает в динамике это делать.
Здравствуйте, VladD2, Вы писали:
VD>Дело в том, что эти технологии хорошо выглядят только на словах. На мой взгляд, окромя вывода типов все остальные подходы создают больше проблем чем решаеют. Динамическая специализация обязательно приводит к созданию кода диспетчиризации который и сжирает весь выигрышь от компиляции. Так что результат получается так себе.
Так можно и JIT в CLR отменить, который частным случаем является этой динамической специализации.
Вообще же во всяких смоллтолках (особенно VisualWorks) и коммон лиспе это довольно все прилично работает вообще без вывода типов.
VD>Вот только не ясно зачем это все. Ведь уже есть как минимум 3 языка с полным выоводм типов которые практически не пуступают динамическим языкам ни по выразительности, ни по гибкости. Точнее даже во многом их превосходят. Так что зачем эта возня я лично не понимаю.
Ну на самом деле с полным выводом типов юзабельных языков пока что нет. И неизвестно когда будет, если вообще.
А с каким-то выводом их гораздо больше чем 3, в несколько раз. Или это только дотнет имелся в виду?
Но в любом случае, у динамических языков конечно свои преимущества и в некоторых случаях огромная выразительность. Рефлексию, кодогенерацию/модификацию в рантайме и даже просто eval можно конечно и в статических языках сделать, но это будет две большие разницы в простоте, удобстве и выразительности между ними и Smalltalk/CL/Tcl. В общем-то даже с питоном, хоть он и достаточно дубовый в этом плане.
прежде чем понять рекурсию, необходимо понять рекурсию.
Г>>Вообще же во всяких смоллтолках (особенно VisualWorks) и коммон лиспе это довольно все прилично работает вообще без вывода типов.
VD>Это безответственные и нечем не подкрепленные заявления. Тут вот где-то пробегала пенесометрия "АльфаБлэнд". Можешь воспроизвести на любом Смолтоке и убедиться, что он и рядом не лежал со строготипизированными языками (PyPy на нем слил очень показательно).
Ну вот, сразу Альфа Бленд. Разумеется, на числодробильне динамические языки не блещут. По причине ссылочности любых данных.
Речь-то изначально шла о динамической диспетчеризации и избавления от оверхеда на вызов функции. С этим-то у смоллтолка как раз все в порядке.
А со ссылочностью да, можно локально бороться с дополнительной аннотацией/выводом типов. Common Lisp и Dylan так и делают. Там и альфабленд не критично отстанет, полагаю.
Г>>Ну на самом деле с полным выводом типов юзабельных языков пока что нет.
VD>В прочем "полный" вывод и не нужен. На уровне типов и методов явная аннотация типов ни сколько не напрягает и даже наоборот приносит немалые дивиденды спасая от ошибко и обеспечивая поддержку интелисенса.
Г>>А с каким-то выводом их гораздо больше чем 3, в несколько раз. Или это только дотнет имелся в виду?
VD>Имеются в виду гибридные языки нового поколения на фоне которых Смотолк выглядит недоразумением.
Так уж и недоразумением? А по-моему, это как сказать, что суахили будет выглядеть недоразумением Смоллтолк — не совсем general purpose язык. У него довольно своеобразная область применения и вообще модель исполнения. И там он как выглядел, так по-моему и выглядит последние лет 30.
Г>>Но в любом случае, у динамических языков конечно свои преимущества и в некоторых случаях огромная выразительность.
VD>Еще одно голословное утверждение не имеющее ничего общего с действительностью.
Да как угодно. В конце концов действительность штука такая.
VD>Откровенно говоря говорить с людьми не видившими ничего кроме скриптов просто не интересно. Этот форум кишит пдобными флэймами. Делай поиск и изучай. Мне обсуждения этой чущи порядком поднадоели.
Кажется, меня записали в поклонники динамики и script kiddies и сами же обиделись на это
Да видел я что-то кроме скриптов, спасибо Действительно.
Хотя, впрочем, спорить сильно не буду. Ведь действительность — это вещь такая...
прежде чем понять рекурсию, необходимо понять рекурсию.
Здравствуйте, граммофон, Вы писали:
Г>Ну вот, сразу Альфа Бленд. Разумеется, на числодробильне динамические языки не блещут. По причине ссылочности любых данных. Г>Речь-то изначально шла о динамической диспетчеризации и избавления от оверхеда на вызов функции. С этим-то у смоллтолка как раз все в порядке.
Речь изначально шла о производительности кода. Бесспорно, что всегда найдутся задачи которые на современном железе могут быть решены даже на очень тормозных средствах. Но это не делает тормоз быстрым. Это всего лишь говорит, что и тормоз можно применять при некоторых условиях.
Г>А со ссылочностью да, можно локально бороться с дополнительной аннотацией/выводом типов. Common Lisp и Dylan так и делают. Там и альфабленд не критично отстанет, полагаю.
Вот практические тесты показали, что только компилирующие варианты Лиспа с полной аннотацией типов могут соревнаваться с С++-ным тестом. А при этом код превращется в жутик по чище С++-ного.
Г>Так уж и недоразумением?
Полнейшим. В прочем, естественно, только тем кто хорошо знаком с новыми языками.
Г> А по-моему, это как сказать, что суахили будет выглядеть недоразумением Смоллтолк — не совсем general purpose язык.
Я бы сказал "совсем не". Но это только минус для него, а не оправдание.
Г> У него довольно своеобразная область применения и вообще модель исполнения. И там он как выглядел, так по-моему и выглядит последние лет 30.
Откровенно говоря я вообще не вижу его примененеия (только слова о нем). Даже IBM (души в нем не чаявшая) в итоге выбрала Яву (кторая и сейчас в некоторых аспектах уступает Смолтоку).
Г>Кажется, меня записали в поклонники динамики и script kiddies и сами же обиделись на это
А куда записывать людей далющий такие утверждения? Проблема, в том, что доказывать по сотому разу одно и тоже со временем надоедает. Как я уже сказал, тут море флэймво на эту тему. Можно поднимать любой и читать аргументы месяцами. Открывать еще один спор, да еще снова на уровне голых утверждений очень неохота.
Г>Да видел я что-то кроме скриптов, спасибо Действительно.
Боюсь, что в лучшем случае это "что-то" было каким-нить С++.
Г>Хотя, впрочем, спорить сильно не буду. Ведь действительность — это вещь такая...
Ведь действительно "такая". Люди привыкшие к скриптам начинаю низводить их недостатки до незначительных, и выпячивать гибкость как решающее приемущество. Проблема в том, что гибкими могут быт и не динамические языки. Но все это пустые слова, так как все эти споры сводятся к разсуждениям о предпочтениях.
На мой взгляд использование скриптов определяется только привычками и никим уровнем реализаций большинства статически типизированных языков. Развитие идет по спирали, и на каждом ее витке динамические языки снова всплывают начиная новый круг борбы с ними. Вывод типов, метапрограммирование, сопоставление с образцом, автоматические теорем-пруверы должны снова откинуть динамику в нибытие до нового витка. Потом динамика возможно снова вылезет и будет новый виток борьбы с ней. И так до бесконечности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Исключительно для тебя. Хаскель и ОКамл никто не отменял.
В Хаскеле сплошь и рядом необходимы аннотации типов, чтобы программа компилировалась. Да и в Окамле, если использовать его систему типов на всю катушку, с объектами и полиморфными вариантами.
)
