Меня заинтересовала последняя часть видео (где-то 40-вая минута и далее) где они начали рассуждать о совсем дальнем будущем C# (о 5-ой версии).
Там прозвучало не мало слов из которых можно сделать не мало выводов.
Пойду по порядку перечислять то что меня заинтересовало (задело).
1. C# — это императивный язык. Собственно означает ли это, что развитие C# в сторону ФП (функционального программирования) завершилось добавлением лямбд?
2. МП (метапрограммирование) — это никак не слишком большая пушка, а очень хорошо и мы (т.е. они) будем это поддерживать. Вот, собственно, "компилятор как сервис".
3. Макросы — это плохо так как нетипизированно и вообще текстово. Отсюда можно сделать вывод, что макросы ими понимаются не так как это понимается в Лиспе или Немерле, а как аналог препроцессора C. Не ясно почему их друг Дон (который Бокс) не убедил их в обратно.
4. Работа на уровне AST и запуск пользовательского кода из компилятора... а как все это отлаживать — задается вопросом Хейльсберг. Отсюда видим, что Дон и правда ничего не рассказал о Лиспе. Хотя слово Лисп он знает, так как упоминал. Ну, да я тоже такое слово знаю .
Меж тем отлаживать "это" весьма не сложно. Достаточно сгенерировать текст по AST и правильно расставить location-ы (сопоставить местоположение). Далее можно отлаживать генерируемый код обычным отладчиком. Код же самих макросов и так отлаживается с пол пинка, так как это просто код плагина к компилятору.
5. Компилятор как сервис — это по всей видимости не более чем возможность скомпилировать код из текстовой строчки в рантайме. Так что IT был прав.
6. Отсюда о пользовательских EDSL (встроенных в универсальный язык языков предметной области) до 6-ой версии можно не говорить. А возможно и вообще говорить бессмысленно.
7. Сопоставление с образцом (оно же ПМ — Паттерн-Матчинг) — это всего лишь другой взгляд на наследование и полиморфизм. При этом этот "взгляд" хуже исходного, так как он открывает внутренности объектов которые раньше были черным ящиком. Короче, нарушает принципы инкапсуляции. Индусы могут сломать ноготь. А безопасность труда — это святое. Неясно только как бедные индусы публичные поля пережили...
8. Вот мультиметоды (ММ) — это круть! Множественная диспечерезация (МД), т.е. по нескольким типам, а не по одному this, да еще с динамическим расширением это здорово... Это, кстати, сказал Меер, который судя по словам сказанным о нем в Википедии является серьезным функциональщиком и работал раньше над Хасклем. Может, что-то с Хасклем не так?
Что-то я тут не понимаю. Может это был стеб, так как улыбка у него была в этот момент до ушей, но как человек значащий что такое ПМ может серьезно сравнивать их с ММ и МД? Да, несомненно, ПМ позволяет с легкостью организовать локальный (не расширяемый динамически) МД, но обратно не верно. ПМ — это возможность распознавать сложнейшие паттерны, а не только динамический тип нескольких объектов. Уверен, что ММ буду востребованы гораздо реже нежели ПМ.
Что касается инкапусляции, то тоже не ясно. Что мешает реализовать МП только по публичному интерфейсу или по внутренним членам внутри типа? По крайней мере ПМ по объектам реализован во всех ведущих гибридных языках (Scala, F#, Nemerle).
9. Поддержка параллелизма очень нужно. Но как ее реализовать мы (они) не знаем. Точно будет PLinq. Можно было бы конечно еще добавить в CLR что-то вроде авторов (из Скалы и Эрланга), но ведь хрен знает что из этого этого получится. А, ведь это серьезное основание чтобы даже не пробовать. И то правда. Ведь все мощные расширения (дженерики, лямбды) были добавлены ребятами пришедшими из МС Ресерч. И видимо, раз уж ты попал в группу компиляторов МС, то исследованиями тебе заниматься не с руки. Надо ждать когда кто-то еще из МС Ресерч сделает что-то хорошее. Хочется верить, что таковые найдутся и они что-то сделают. А та 2-3 года на "продуктивзацию" решения и золотой ключик у нас в кармане.
10. МП, МП и многое другое противоречит принципам ООП, а значит оно нам не нужно. Где-то я это слышал. Где? А, точно. 10 лет назад Хейльсберг предложил добавить в Яву события и делегаты, а злые и консервативные Саншики (или Саночники?) сказали ему свое твердое сфотовое "нет" объяснив попутно, что это не объектно-ориентированное решение, и что намного лучше будет добавить вложенные и анонимные классы которые упростили бы реализацию интерфейсов и паттерна Слушатель, и в то же время не изменили бы чистоты ОО-крнцепций Явы. Видимо, через 10 лет новатор Хейльсберг понял, что они были правы. В прочем события и делегаты и правда были не сам лучшим изобретением. Вот только не потому, что они не ООП, а потому что они не до ФП.
Итого, у меня сложилось впечатление, что C# созрел и развивать его уже нет смысла (ну, если конечно не найдется орел из ресерча который сделает это сам). Так что в ближайших версиях мы вряд ли увидим, что-то радикально новое. Разве что мультиметоды или что-то их заменяющее вроде упрощения реализации паттерна Посетитель.
Я что-то не так понял, или все же прав был Черчилль говоривший: «Кто в молодости не был радикалом — у того нет сердца. Кто в зрелости не консерватор — у того нет головы». Или говоря другими словами — старость не радость .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Будущее C#, или почему C# ходит вокруг да около Nemerle
Disclaimer — все ниже сказанное является исключительно моими домыслами.
VD>Меня заинтересовала последняя часть видео (где-то 40-вая минута и далее) где они начали рассуждать о совсем дальнем будущем C# (о 5-ой версии).
Для Хейлсберга это не "совсем дальнее будущее", а то, чем он сейчас занимается.
VD>1. C# — это императивный язык.
Скорее ОО язык.
VD> Собственно означает ли это, что развитие C# в сторону ФП (функционального программирования) завершилось добавлением лямбд?
Судя по тому что я слышал — нет, не закончилось. Но превращения C# в совсем функциональный язык не будет. На то есть F#.
VD>2. МП (метапрограммирование) — это никак не слишком большая пушка, а очень хорошо и мы (т.е. они) будем это поддерживать. Вот, собственно, "компилятор как сервис".
Compiler as a service это немножко не то, это инструментальные средства, а не МП в стиле Nemerle.
VD>3. Макросы — это плохо так как нетипизированно и вообще текстово. Отсюда можно сделать вывод, что макросы ими понимаются не так как это понимается в Лиспе или Немерле, а как аналог препроцессора C. Не ясно почему их друг Дон (который Бокс) не убедил их в обратно.
Тут все очень просто — то что называется макросами в Немерле они макросами не называют.
VD>5. Компилятор как сервис — это по всей видимости не более чем возможность скомпилировать код из текстовой строчки в рантайме. Так что IT был прав.
И прав и не прав. CaaS конечно же не МП, но это не значит что МП не будет. Вот чего скорее всего не будет (по крайней мере по утверждению Мэдса), так это возможности изменять синтаксис.
VD>6. Отсюда о пользовательских EDSL (встроенных в универсальный язык языков предметной области) до 6-ой версии можно не говорить.
Да и нет. Т.е. в рамках компилятора C# точно да. А вот в рамках инструментальных средств, как раз таки, начинает играть рояль CaaS. Плюс, наверное, Oslo.
VD>7. Сопоставление с образцом (оно же ПМ — Паттерн-Матчинг) — это всего лишь другой взгляд на наследование и полиморфизм.
Да. Но это т.з. исключительно Хейлсберга. В 2 марта была интересная дисскуссия с C# team после того, как я про ПМ спросил. И это, судя по всему, как раз отголоски той дисскуссии.
VD>8. Вот мультиметоды (ММ) — это круть! Множественная диспечерезация (МД), т.е. по нескольким типам, а не по одному this, да еще с динамическим расширением это здорово... Это, кстати, сказал Меер, который судя по словам сказанным о нем в Википедии является серьезным функциональщиком и работал раньше над Хасклем. Может, что-то с Хасклем не так?
Ой, там столько вариаций на эту тему понапридумано уже. Собственно, Хейлсберг в той дисскуссии предложил в ответ парочку решений. Но это NDA
VD>9. Поддержка параллелизма очень нужно
Угу. Судя по всему, одна из killer features С# 5.
VD>. Но как ее реализовать мы (они) не знаем. Точно будет PLinq.
Точнее ParallelFX. И будет уже в 4.0. Прямо в mscorlib.
Блин, пусть меня расстреляют. Вобщем, http://channel9.msdn.com/posts/Charles/Jeffrey-Richter-and-his-AsyncEnumerator/
А Синклер, если захочет, расскажет забавную историю в тему.
VD> А, ведь это серьезное основание чтобы даже не пробовать. И то правда. Ведь все мощные расширения (дженерики, лямбды) были добавлены ребятами пришедшими из МС Ресерч. И видимо, раз уж ты попал в группу компиляторов МС, то исследованиями тебе заниматься не с руки. Надо ждать когда кто-то еще из МС Ресерч сделает что-то хорошее.
У тебя неверное представление о взаимодействии MSR и compiler team. MSR может работать не только по собственной инициативе, но и в рамках задач compiler team. Сейчас ряд таких исследований для C# 5 уже ведутся.
VD>Итого, у меня сложилось впечатление, что C# созрел и развивать его уже нет смысла (ну, если конечно не найдется орел из ресерча который сделает это сам). Так что в ближайших версиях мы вряд ли увидим, что-то радикально новое.
Кое что новое в 5 шарпе таки будет.
VD> Разве что мультиметоды
Очень вряд ли.
VD> или что-то их заменяющее вроде упрощения реализации паттерна Посетитель.
А вот это возможно.
VD>Я что-то не так понял, или все же прав был Черчилль говоривший: «Кто в молодости не был радикалом — у того нет сердца. Кто в зрелости не консерватор — у того нет головы». Или говоря другими словами — старость не радость .
Помимо Хейлсберга есть еще Мэдс и Эрик (который Липперт).
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
VD>8. Вот мультиметоды (ММ) — это круть! Множественная диспечерезация (МД), т.е. по нескольким типам, а не по одному this, да еще с динамическим расширением это здорово... Это, кстати, сказал Меер, который судя по словам сказанным о нем в Википедии является серьезным функциональщиком и работал раньше над Хасклем. Может, что-то с Хасклем не так?
Да, Meijer один из отцов-основателей Haskell, автор знаменитой "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire". Возможно, чтобы понять его новое мировоззрение стоит прочитать: Erik Meijer, Confessions Of A Used Programming Language Salesman. Еще он называет сабя: "типоголик в завязке"
VD>Что-то я тут не понимаю. Может это был стеб, так как улыбка у него была в этот момент до ушей, но как человек значащий что такое ПМ может серьезно сравнивать их с ММ и МД? Да, несомненно, ПМ позволяет с легкостью организовать локальный (не расширяемый динамически) МД, но обратно не верно. ПМ — это возможность распознавать сложнейшие паттерны, а не только динамический тип нескольких объектов. Уверен, что ММ буду востребованы гораздо реже нежели ПМ.
Вообще, среди академиков-практиков, типа Брахи, назревает некий реваншизм по отношению к ООП — С++, Java, C# сделали все неправильно — а вот если сделать как в Smalltalk или в CLOS только лучше — будет самое оно. Мультиметоды — это оттуда. Кстати, Scala — тоже в некотором роде об этом.
VD>9. Поддержка параллелизма очень нужно. Но как ее реализовать мы (они) не знаем. Точно будет PLinq. Можно было бы конечно еще добавить в CLR что-то вроде авторов (из Скалы и Эрланга), но ведь хрен знает что из этого этого получится.
Кстати, акторы в Scala — библиотека.
VD> А, ведь это серьезное основание чтобы даже не пробовать. И то правда. Ведь все мощные расширения (дженерики, лямбды) были добавлены ребятами пришедшими из МС Ресерч.
В статье выше про это немного есть.
VD>Я что-то не так понял, или все же прав был Черчилль говоривший: «Кто в молодости не был радикалом — у того нет сердца. Кто в зрелости не консерватор — у того нет головы». Или говоря другими словами — старость не радость .
Черчилль был умный мужик
Re[2]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, AndrewVK, Вы писали:
AVK>Судя по тому что я слышал — нет, не закончилось. Но превращения C# в совсем функциональный язык не будет. На то есть F#.
F# не менее императивен нежели C#. Но он на 5 поддерживает и ФП. Не думаю, что язык станет хуже если он получит возможность кроме циклов и иф-ов писать и в функциональном стиле.
AVK>Да и нет. Т.е. в рамках компилятора C# точно да. А вот в рамках инструментальных средств, как раз таки, начинает играть рояль CaaS. Плюс, наверное, Oslo.
Не вижу как компилятор в виде объекта поможет в области встраивания ДСЛ-ей.
Что до Осло, то это внешние СДЛ-и. Плюс это оверкил, на мой взгляд. В общем, еще одна мервороженная технология судьба которой быть инструментом для тех кто делает разные визуальные навороты и генераторы.
И вообще, что за подход такой "в рамках инструментальных средств"? Внешние ДСЛ-и? Если, да то у них очень ограниченная область применения и очень высокая стоимость создания (даже с Ослами и прочими СаКлаудами).
VD>>7. Сопоставление с образцом (оно же ПМ — Паттерн-Матчинг) — это всего лишь другой взгляд на наследование и полиморфизм.
AVK>Да. Но это т.з. исключительно Хейлсберга. В 2 марта была интересная дисскуссия с C# team
Где была? С кем? Это доступно в сети или это какой-то офлайн-междусобойчик?
AVK>после того, как я про ПМ спросил. И это, судя по всему, как раз отголоски той дисскуссии.
Это сказал Меер. Какое, кстати, он имеет отношение к Хаскелю?
А вообще он слишком уж подъигрывает Хейльсбергу. Иногда возникает ощущение, что он стебается над его словами, но делает это тонко, чтобы не посвященные не понимали, что же происходит.
VD>>8. Вот мультиметоды (ММ) — это круть! Множественная диспечерезация (МД), т.е. по нескольким типам, а не по одному this, да еще с динамическим расширением это здорово... Это, кстати, сказал Меер, который судя по словам сказанным о нем в Википедии является серьезным функциональщиком и работал раньше над Хасклем. Может, что-то с Хасклем не так?
AVK>Ой, там столько вариаций на эту тему понапридумано уже. Собственно, Хейлсберг в той дисскуссии предложил в ответ парочку решений. Но это NDA
Все его решения лет так 20 назад придуманы (минимум), так что не думаю, что их озвучка может подпадать под NDA. Можешь высказать их как свои идеи.
VD>>9. Поддержка параллелизма очень нужно
AVK>Угу. Судя по всему, одна из killer features С# 5.
Как бы он сам себя не убил. Реально поддержку нужно в CLR встраивать. По крайней мере поддержку акторов о которых говорил Хейльсберг точно нужно встраивать во фрэймворк, так как она сильно завязана на стоимость переключения контекста и на изоляцию виртуальных процессов.
Видимо — это один из страшных секретов .
AVK>А Синклер, если захочет, расскажет забавную историю в тему.
Синклер. Ау...
VD>> А, ведь это серьезное основание чтобы даже не пробовать. И то правда. Ведь все мощные расширения (дженерики, лямбды) были добавлены ребятами пришедшими из МС Ресерч. И видимо, раз уж ты попал в группу компиляторов МС, то исследованиями тебе заниматься не с руки. Надо ждать когда кто-то еще из МС Ресерч сделает что-то хорошее.
AVK>У тебя неверное представление о взаимодействии MSR и compiler team. MSR может работать не только по собственной инициативе, но и в рамках задач compiler team. Сейчас ряд таких исследований для C# 5 уже ведутся.
Возможно. Но слова "а ведь это может не удаться" меня позабавили до глубины души. Сделайте, попробуйте... Выкинете если что. Не те деньги. Тем более, что Эриксон со своим Эрлангом уже отлично доказал, что идея рабочая. А значит риск не велик.
VD>>Итого, у меня сложилось впечатление, что C# созрел и развивать его уже нет смысла (ну, если конечно не найдется орел из ресерча который сделает это сам). Так что в ближайших версиях мы вряд ли увидим, что-то радикально новое.
AVK>Кое что новое в 5 шарпе таки будет.
Я говорю о впечатлениях. Уж больно много скепсиса в их речах.
VD>> Разве что мультиметоды
AVK>Очень вряд ли.
Меер с таким удовольствием о них рассуждал (когда они хаили паттерн-матчинг), что показалось, что это чуть ли не замена всему на свете. Правда снова лыбился, так что не ясно не стеб ли это был.
Эта американская улыбка постоянно висящая на лице не дает понять когда люди стебаются, а когда серьезно говорят.
VD>> или что-то их заменяющее вроде упрощения реализации паттерна Посетитель.
AVK>А вот это возможно.
Вот это будет провал. Хотя поживем — увидим.
VD>>Я что-то не так понял, или все же прав был Черчилль говоривший: «Кто в молодости не был радикалом — у того нет сердца. Кто в зрелости не консерватор — у того нет головы». Или говоря другими словами — старость не радость .
AVK>Помимо Хейлсберга есть еще Мэдс и Эрик (который Липперт).
Что-то Меер пел ему в унисон. Боюсь, что авторитет дядьки Хельберга задавит кого хочешь.
ЗЫ
Вообще, не ясно зачем такие вот "разговоры на людях". С оной стороны что-то там говорят расплывчатое, но с другой никакой конкретики. "Компилятор как сервис" — звучит красиво, а что за этим словами?
Рассуждения же порой просто граничат с ламом. Если бы не знал кто это такие подумал бы какие-то приколисты или люди далекие от темы.
AST-макросы им видите ли не ясно как отлаживать. А у Бокса спросить? 50 лет их в Лиспе отлаживали.
Паттер-матчинг другой взгляд на полиморфизм. Ну, другой, ну и что? Если он в некоторых задачах мощнее в сто раз, что тогда делать? Обосраться и умереть, но отстаивать позиции ООП? Не Хейльсберг ли придя в МС начал копать под этот самый ОО вводя события и делегаты в "чистую Яву"?
Что за нарушение инкапсуляции? Ну, сделайте хотя бы ПМ по публичному интерфейсу.
Потом поглядите на тот же экспрешон-три. Там ведь ОО попирают во все дыры. Посетитель их на половину на switch-е реализован. Так не лучше ли дать людям хороший синтаксис для задач анализа, а не отстаивать принципы ООП любой ценой?
Макросы им не нравятся. Синтаксис они меняют. Мало ли у кого что там меняет. Сделайте по первой хотя бы без изменения синтаксиса. Так чтобы было можно его в виде функции оформить и в виде атрибута. Но чтобы можно было во время компиляции код сгенерить вместо них. И чтобы можно было прочитать код переданный в виде параметров этих макросов или просто находящийся в некотором методе (классе и т.п.).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, z00n, Вы писали:
Z>Да, Meijer один из отцов-основателей Haskell, автор знаменитой "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire". Возможно, чтобы понять его новое мировоззрение стоит прочитать: Erik Meijer, Confessions Of A Used Programming Language Salesman. Еще он называет сабя: "типоголик в завязке"
Так он религию сменил (вместе с местом работы) или это он так стебается?
Z>Вообще, среди академиков-практиков, типа Брахи, назревает некий реваншизм по отношению к ООП — С++, Java, C# сделали все неправильно — а вот если сделать как в Smalltalk или в CLOS только лучше — будет самое оно. Мультиметоды — это оттуда. Кстати, Scala — тоже в некотором роде об этом.
Скала то тут причем?
VD>>9. Поддержка параллелизма очень нужно. Но как ее реализовать мы (они) не знаем. Точно будет PLinq. Можно было бы конечно еще добавить в CLR что-то вроде авторов (из Скалы и Эрланга), но ведь хрен знает что из этого этого получится. Z>Кстати, акторы в Scala — библиотека.
Я знаю. Только эффективность на уровне плинтуса. Только относительно вычислительно-емкие подпроцессы можно выделять. В отличии от Эрланга где вроде как миллионы процессов можно создать.
VD>> А, ведь это серьезное основание чтобы даже не пробовать. И то правда. Ведь все мощные расширения (дженерики, лямбды) были добавлены ребятами пришедшими из МС Ресерч. Z>В статье выше про это немного есть.
А можно цитату. А то все читать времени пока нет.
VD>>Я что-то не так понял, или все же прав был Черчилль говоривший: «Кто в молодости не был радикалом — у того нет сердца. Кто в зрелости не консерватор — у того нет головы». Или говоря другими словами — старость не радость . Z>Черчилль был умный мужик
+1 Но сволочь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, VladD2, Вы писали:
Z>>Кстати, акторы в Scala — библиотека.
VD>Я знаю. Только эффективность на уровне плинтуса. Только относительно вычислительно-емкие подпроцессы можно выделять. В отличии от Эрланга где вроде как миллионы процессов можно создать.
Акторы в скале есть двух видов — вторых (Thread-less) можно создавать много.
Thread-blocking operations can be avoided by using react to wait for new messages (the event-based pendant of receive). However, there is a (usually small) price to pay: react never returns. In practice, this means that at the end of a reaction to a message, one has to call some function that contains the rest of the actor's computation.
VD>>> А, ведь это серьезное основание чтобы даже не пробовать. И то правда. Ведь все мощные расширения (дженерики, лямбды) были добавлены ребятами пришедшими из МС Ресерч. Z>>В статье выше про это немного есть.
VD>А можно цитату. А то все читать времени пока нет.
My main reason to join Microsoft as the company to infuse
mainstream programming languages with monads and other
functional programming features was that I believed the
quickest road to success would be to work on adding support
for exotic language features to the new Common Language
Runtime [74].
Пролистните по диагонали — она забавная.
Re[4]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, z00n, Вы писали:
Z>Акторы в скале есть двух видов — вторых (Thread-less) можно создавать много. Z>
Z>Thread-blocking operations can be avoided by using react to wait for new messages (the event-based pendant of receive). However, there is a (usually small) price to pay: react never returns. In practice, this means that at the end of a reaction to a message, one has to call some function that contains the rest of the actor's computation.
Они используют явовские примитивы которые не очень то шустрые. К тому же понятие "много" растяжимое.
Где то были сравнения с Эрлангом. Когда количество процессов было малым, то скорость была выше у Скалы (компилятор все же). А на большом количестве Эрланг резко вырывался вперед.
Z>
Z>My main reason to join Microsoft as the company to infuse
Z>mainstream programming languages with monads and other
Z>functional programming features was that I believed the
Z>quickest road to success would be to work on adding support
Z>for exotic language features to the new Common Language
Z>Runtime [74].
Похвальное рвение. Тогда, похоже, что его слова в этом авишнике — это стеб.
Z>Пролистните по диагонали — она забавная.
ОК
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, VladD2, Вы писали:
VD>F# не менее императивен нежели C#. Но он на 5 поддерживает и ФП. Не думаю, что язык станет хуже если он получит возможность кроме циклов и иф-ов писать и в функциональном стиле.
Все дело в приоритетах.
AVK>>Да и нет. Т.е. в рамках компилятора C# точно да. А вот в рамках инструментальных средств, как раз таки, начинает играть рояль CaaS. Плюс, наверное, Oslo.
VD>Не вижу как компилятор в виде объекта поможет в области встраивания ДСЛ-ей.
Будет сравнительно легко самостоятельно делать что то вроде asp.net.
AVK>>Да. Но это т.з. исключительно Хейлсберга. В 2 марта была интересная дисскуссия с C# team
VD>Где была? С кем? Это доступно в сети или это какой-то офлайн-междусобойчик?
Второе.
AVK>>после того, как я про ПМ спросил. И это, судя по всему, как раз отголоски той дисскуссии.
VD>Это сказал Меер. Какое, кстати, он имеет отношение к Хаскелю?
Никакого.
AVK>>Угу. Судя по всему, одна из killer features С# 5.
VD>Как бы он сам себя не убил. Реально поддержку нужно в CLR встраивать.
И это тоже.
AVK>>У тебя неверное представление о взаимодействии MSR и compiler team. MSR может работать не только по собственной инициативе, но и в рамках задач compiler team. Сейчас ряд таких исследований для C# 5 уже ведутся.
VD>Возможно. Но слова "а ведь это может не удаться" меня позабавили до глубины души. Сделайте, попробуйте... Выкинете если что.
Так и происходит.
AVK>>Помимо Хейлсберга есть еще Мэдс и Эрик (который Липперт).
VD>Что-то Меер пел ему в унисон.
При чем тут Меер? Он вообще не из compiler team.
VD>Вообще, не ясно зачем такие вот "разговоры на людях". С оной стороны что-то там говорят расплывчатое, но с другой никакой конкретики.
А по 5 шарпу никакой конкретики пока и нет. Они сейчас как раз и заняты определением того, что там будет.
VD> "Компилятор как сервис" — звучит красиво, а что за этим словами?
За этим словами вполне конкретная и детально проработанная технология. Только, еще раз повторяю, это не МП, это инструментальное средство, прежде всего упрощающее ряд задач по созданию расширений для VS.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
AVK>Блин, пусть меня расстреляют. Вобщем, http://channel9.msdn.com/posts/Charles/Jeffrey-Richter-and-his-AsyncEnumerator/ AVK>А Синклер, если захочет, расскажет забавную историю в тему.
Да, получилось на редкость забавно. Там началось всё с того, что мы (то есть AVK) отловили Мэдса в коридорах и докопались с вопросом "Hi Mads, how about the c#4 specification"?
Я бы на его месте на такое, да еще и в 8:30 утра, ответил "Who's the ...k are you?", но Мэдс был на редкость приветлив и начал достаточно интересную дискуссию.
Потихоньку перешли к параллельности и асинхронности, причем Мэдс упирал на то, что в рядах товарищей согласья нет, и есть куча потребностей, и все типа работают по разному.
Ну, я со своим корявым английским стал заяснять, что вот вроде есть библиотечка некоего Рихтера, так вот она — почти то что нужно, но с корявостями. Тут дяденька, который сидел рядом со мной напротив Мэдса, стал встревать в разговор с вопросами типа "корявостями? какими корявостями?". Я сбивчиво попытался объяснить, что, дескать, ее в принципе можно улучшить, но не слишком, потому что ограничения языка. Минуты через полторы разговора в стиле "да нет, вряд ли ты ее улучшишь — да нет, улучшу, там только много грязной работы — да вот лучше чем этот парень улучшил уже вряд ли улучшишь" Мэдс таки сказал этому дяденьке "Джеффри, хватит стебаться, покажи бэджик". Так я и выяснил, что на глазах изумленной публики спорил с Джеффри Рихтером на тему ажно Power Threading Library:
Я как-то этого не ожидал, именно поэтому у меня такое охреневшее выражение лица.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, z00n, Вы писали:
Z>Вообще, среди академиков-практиков, типа Брахи, назревает некий реваншизм по отношению к ООП — С++, Java, C# сделали все неправильно — а вот если сделать как в Smalltalk или в CLOS только лучше — будет самое оно. Мультиметоды — это оттуда. Кстати, Scala — тоже в некотором роде об этом.
Что значит "назревает", когда в С++ мультиметоды уже тыщу лет обсуждаются (зуб не дам, но помнится, что я читал про возможную реализацию чуть ли не в древнем ARM-e)
А вот тут хорошая обзорная статья с вариантами реализации (и с упоминанием других языков, в частности, того же CLOS)
Open Multi-Methods for C++: http://research.att.com/~bs/multimethods.pdf
Здравствуйте, AndrewVK, Вы писали:
AVK>>>после того, как я про ПМ спросил. И это, судя по всему, как раз отголоски той дисскуссии.
VD>>Это сказал Меер. Какое, кстати, он имеет отношение к Хаскелю?
AVK>Никакого.
Гы. Оказалось, что он один из его создателей.
Так что его слова — это на половину стеб.
AVK>>>Угу. Судя по всему, одна из killer features С# 5. VD>>Как бы он сам себя не убил. Реально поддержку нужно в CLR встраивать. AVK>И это тоже.
Это предположение или уже слухи?
VD>>Возможно. Но слова "а ведь это может не удаться" меня позабавили до глубины души. Сделайте, попробуйте... Выкинете если что.
AVK>Так и происходит.
Как-то не заметно. Тот же линк и дженерики имели прототипы в виде ресерчевских проектов.
Кстати, именно Меер оказывается создал СиОмера и вдохновил Линк.
Так что на него главная надежда. Его идея протащить лучшее из ФП в мэйнстрим мне очень нравится. Можно сказать мы занимаемся одним делом .
AVK>>>Помимо Хейлсберга есть еще Мэдс и Эрик (который Липперт).
VD>>Что-то Меер пел ему в унисон.
AVK>При чем тут Меер? Он вообще не из compiler team.
Ну, как бы Меер — это Линк и ФП фичи 3-его шарпа. Если уж и он поддерживает консерватизм Хейльсберга, то дело швах. В прочем, все больше склоняюсь к тому, что он стебался. Не даром они все ржали когда он говорил.
Если слова "я вообще-то не функциональщик" вообще прелесть.
AVK>А по 5 шарпу никакой конкретики пока и нет. Они сейчас как раз и заняты определением того, что там будет.
Дык как раз время обратиться к общественности.
Хейльсберг вас (МВПов) там в суе поминал. Мол сейчас придут и будут просить паттерн-матчинг и макросы .
VD>> "Компилятор как сервис" — звучит красиво, а что за этим словами?
AVK>За этим словами вполне конкретная и детально проработанная технология. Только, еще раз повторяю, это не МП, это инструментальное средство, прежде всего упрощающее ряд задач по созданию расширений для VS.
Компилить код с исходника и раньше можно было. Не уж то это за новую технологию пройдет?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, z00n, Вы писали:
Z>Да, Meijer один из отцов-основателей Haskell, автор знаменитой "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire". Возможно, чтобы понять его новое мировоззрение стоит прочитать: Erik Meijer, Confessions Of A Used Programming Language Salesman. Еще он называет сабя: "типоголик в завязке"
Статья и правда очень интересная. Значит он все же стебался большую часть времени.
Вообще надо понимать, что тебя будут смотреть в основном люди мало понимающие кто ты такой, так что такой стеб — это перебор.
Его слова "я вообще-то не функциональщик..." прозвучали весьма искренне, если бы не дружное ржание за кадром...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, jazzer, Вы писали:
J>Что значит "назревает", когда в С++ мультиметоды уже тыщу лет обсуждаются (зуб не дам, но помнится, что я читал про возможную реализацию чуть ли не в древнем ARM-e)
С++ — это язык в котором все обсуждается. Но так как основная концепция языка — все положить в библиотеку, то ничего в язык не добавляют и получается полная задница.
J>А вот тут хорошая обзорная статья с вариантами реализации (и с упоминанием других языков, в частности, того же CLOS)
CLOS — это не язык. CLOS — это макро-бибилотека для лиспа.
Собственно Лисп — это единственный язык где на сегодня эти самые мультиметоды штатно поддерживаются... и то через макросы.
J>Open Multi-Methods for C++: http://research.att.com/~bs/multimethods.pdf
Это все не более чем треп.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, IT, Вы писали: IT>А мне Ваня с АВК
Нда. Интересно было бы послушать эту историю в изложении, к примеру, Миши Купаева. Оценить, тскать, искажения в канале.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Будущее C#, или почему C# ходит вокруг да около Nemer
Не совсем. Там только о 10-ой части рассказано. Самые важные вещи — это средства декомпозиции и склеивания кода. О них он и не заикался. Потом деревья выражений доступны только в рантайме, что упрощает их реализацию, но уменьшает их актуальность. АСТ Немерла доступно во время компиляции.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, IT, Вы писали: IT>>А мне Ваня с АВК S>Нда. Интересно было бы послушать эту историю в изложении, к примеру, Миши Купаева. Оценить, тскать, искажения в канале.
Ну, в общем, дело с утра происходило, а утро — трудное время суток. Наверное, от того поймал Sinclair какого-то мужика, схватил за пуговицу — и давай его по-всякому низводить. И не умеет он ничего, и не может, и вообще куда ему там Рихтеровскую библиотечку переписать. Тот уж от него и так, и сяк — но от Sinclair-а разве вырвешься? Тем более с утра. Так что пуговицы в разные стороны шрапнелью летели, и через полчаса мужик уж на все был готов, и библиотечку переписать под личным руководством Sinclair-а, и всю вообще синхронность в асинхронность перефигачить, в мировом масштабе. Но тут, на его буржуинское счастье, объяснили Sinclair-у, что это сам Рихтер и есть. Тогда Sinclair преисполнился пиетета и последнюю пуговицу на куртке у мужика отрывать не стал. Да она к тому времени одна и оставалась-то, на правом рукаве...
ЗЫ И похоже, так оно и было — нет пуговиц-то у Рихера на куртке.
ЗЗЫ На самом деле примерно так и рассказывали, как ты изложил.
Re[7]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, Sinclair, Вы писали:
IT>>А мне Ваня с АВК S>Нда. Интересно было бы послушать эту историю в изложении, к примеру, Миши Купаева. Оценить, тскать, искажения в канале.
Ну, на самом деле, толи ты что-то скрываешь, толи они что-то преукрашивают, толи я додумал. Так что у Мишу действительно будет интересно послушать
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, VladD2, Вы писали:
VD>Они используют явовские примитивы которые не очень то шустрые. К тому же понятие "много" растяжимое. VD>Где то были сравнения с Эрлангом. Когда количество процессов было малым, то скорость была выше у Скалы (компилятор все же). А на большом количестве Эрланг резко вырывался вперед.
1) В Скале используются не самые быстрые возможные примитивы. Там местами надо их переписать.
2) Я пробовал threadless-актёры для асинхронной модели без блокировок. Работает сильно быстрее.
Sapienti sat!
Re[3]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, VladD2, Вы писали:
VD>Не совсем. Там только о 10-ой части рассказано.
Это PExpr и компания.
Something I personally would like to see more of in C# in the future is greater homoiconicity. We could extend expression trees to statement trees, declaration trees, program trees, and so on. This series of steps would enable increasingly powerful and interesting metaprogramming scenarios.
VD>Самые важные вещи — это средства декомпозиции и склеивания кода. О них он и не заикался.
Это детали реализации.
Да без них все плохо но жить можно не хуже чем они живут сейчас.
VD>Потом деревья выражений доступны только в рантайме, что упрощает их реализацию, но уменьшает их актуальность. АСТ Немерла доступно во время компиляции.
См выделеное.
C# suffers from the lack of a metalanguage. We absolutely do not want to go towards the horrible and primitive metaprogramming language exemplified by the C preprocessor language. We already have a great language, C#, so why not use C# as a metalanguage? Wouldn’t it be nice to make C# its own metalanguage? And once we do that, then we get into some truly strange loops, where we could use those data structures in the compiler implementation itself!
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, WolfHound, Вы писали:
VD>>Самые важные вещи — это средства декомпозиции и склеивания кода. О них он и не заикался. WH>Это детали реализации.
Черт кроется в деталях. В данном деле детали более важны чем какие-то там мечтания.
Я в своер время когда это понял бросил развитие R#-а.
WH>Да без них все плохо но жить можно не хуже чем они живут сейчас.
Без них жить нельзя. Это мука, а не жизнь. Тогла уж лучеше в стрингбилдере код генерировать и компилятором командной строки компилировать.
VD>>Потом деревья выражений доступны только в рантайме, что упрощает их реализацию, но уменьшает их актуальность. АСТ Немерла доступно во время компиляции. WH>См выделеное. WH>
WH>C# suffers from the lack of a metalanguage. We absolutely do not want to go towards the horrible and primitive metaprogramming language exemplified by the C preprocessor language. We already have a great language, C#, so why not use C# as a metalanguage? Wouldn’t it be nice to make C# its own metalanguage? And once we do that, then we get into some truly strange loops, where we could use those data structures in the compiler implementation itself!
Это не олее чем слова брошенные в воздух. Реально дерево выражений или иего аналоги не могут быть использованы внутри компилятора (в качестве АСТ) хотя бы потому, что типв в них описываются с помощью System.Type, а в компиляторе для этого используются совсем другие примитивы (типов еще не создано).
Короче, просто дать АСТ людям не выйдет. Это обреченная на провал затея. Тут нужно продуманное, комплексное решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Sinclair, Вы писали:
IT>>>А мне Ваня с АВК S>>Нда. Интересно было бы послушать эту историю в изложении, к примеру, Миши Купаева. Оценить, тскать, искажения в канале.
IT>Ну, на самом деле, толи ты что-то скрываешь, толи они что-то преукрашивают, толи я додумал. Так что у Мишу действительно будет интересно послушать
Игорь, практика показывает, что эпическую сагу можно сотворить из любого события. Особенно легко и хорошо это удается, если сагосказителя не связывают такие мелочи, как личные впечатления.
Re[3]: Будущее C#, или почему C# ходит вокруг да около Nemer
VladD2 пишет:
> CLOS — это не язык. CLOS — это макро-бибилотека для лиспа. > Собственно Лисп — это единственный язык где на сегодня эти самые > мультиметоды штатно поддерживаются... и то через макросы.
Я бы попросил поточнее. CLOS — это не макро библиотека, а важнейшая
составляющая языка Common Lisp. CLOS прописан в стандарте, и не
является надстройкой над языком, а, наоборот, это -- одна из
центральных концепций языка, без которой ни одна из реализаций
лиспа работать не может в принципе.
А что возможно большая часть конструкций CLOS-а -- это макросы,
так, извините, в Comon LISP вообще большая часть конструкций
всего языка — это макросы.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, MasterZiv, Вы писали:
MZ>Я бы попросил поточнее. CLOS — это не макро библиотека, а важнейшая MZ>составляющая языка Common Lisp. CLOS прописан в стандарте, и не MZ>является надстройкой над языком, а, наоборот, это -- одна из MZ>центральных концепций языка, без которой ни одна из реализаций MZ>лиспа работать не может в принципе.
Главное, что я хотел сказать — нет такого языка "CLOS". В лучшем случае — это EDSL.
Ну, а то что CLOS стандартизован в рамках CL не значит, что это не надстройка. Стандартные библиотеки описаны в стандартах языка. Но тем не менее они не язык.
MZ>А что возможно большая часть конструкций CLOS-а -- это макросы,
Ну, да. Остальное просто функции .
MZ>так, извините, в Comon LISP вообще большая часть конструкций MZ>всего языка — это макросы.
Тем не менее есть исполняемое ядро которое позволяет все остальное реализовать в виде библиотек и макросов. А такие вещи как CLOS — это уже библиотеки мощь (или немощь) которых определяется свойствами базового языка.
Возможно меня превратно поняли. Я не считаю — это плохим решением. Наоборот я считаю, что это очень круто (не сам CLOS, а то как он реализован).
Я вообще говорил о другом. Меня просто порадовали слова z00n и jazzer рассуждавших так как будто есть какой-то отдельный язык CLOS и делавших вид, что есть море реально используемых языков поддерживающих мультиметоды. Меж тем это не так. Я даже ни разу не видел ни одного внятного описания практического использования мультиметодов.
Указанные описания мультиметодов для С++ не более чем мечтания и научные изыски воплошенные только в тестовых проектах и неиспользуемые на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будущее C#, или почему C# ходит вокруг да около Nemer
VladD2 пишет:
> Главное, что я хотел сказать — нет такого языка "CLOS". В лучшем случае > — это EDSL.
Это — да. Языка такого нет. CLOSS — это фича common lisp-а.
> Ну, а то что CLOS стандартизован в рамках CL не значит, что это не > надстройка. Стандартные библиотеки описаны в стандартах языка. Но тем не > менее они не язык.
Я бы поспорил. Но CLOSS является неотъемлимой частью языка потому, что
без него ничего не может работать.
> Тем не менее есть исполняемое ядро которое позволяет все остальное > реализовать в виде библиотек и макросов. А такие вещи как CLOS — это уже > библиотеки мощь (или немощь) которых определяется свойствами базового языка.
Одно из базовых понятий, печатное представление любого объекта, реализуется
через CLOSS. Если его не будет, лисп просто не будет работать. Например,
REPL не будет работать. Ты можешь не использовать CLOSS в своих программах.
Но не использовать CLOSS в Common Lisp, на сколько я знаю, нельзя.
> Я вообще говорил о другом. Меня просто порадовали слова z00n и jazzer > рассуждавших так как будто есть какой-то отдельный язык CLOS и делавших > вид, что есть море реально используемых языков поддерживающих > мультиметоды. Меж тем это не так. Я даже ни разу не видел ни одного > внятного описания практического использования мультиметодов.
Соню Кин почитай. Grey streams посмотри. Они должны использовать именно
мультиметоды.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, VladD2, Вы писали:
VD> Я даже ни разу не видел ни одного внятного описания практического использования мультиметодов.
Вне контекста это мало о чем говорит. К примеру, итераторы в C# 2 использовались совсем нечасто, а вот в C# 3 используются немало, хотя сами итераторы в нем не изменились. Так и с мультиметодами — если это будет единственный вариант встроенной в язык динамическо/статической диспетчеризации по типам, то использоваться они будут.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
Здравствуйте, MasterZiv, Вы писали:
MZ>Это — да. Языка такого нет. CLOSS — это фича common lisp-а.
О том я и говорил.
MZ>Я бы поспорил. Но CLOSS является неотъемлимой частью языка потому, что MZ>без него ничего не может работать.
Является, является. Только не обязательна к использованию.
Скажем WPF, WCF и WWF в .NET 3.5 тоже являются его частью. Но лично мне они пока что не были нужны.
MZ>Одно из базовых понятий, печатное представление любого объекта, реализуется MZ>через CLOSS. Если его не будет, лисп просто не будет работать. Например, MZ>REPL не будет работать. Ты можешь не использовать CLOSS в своих программах. MZ>Но не использовать CLOSS в Common Lisp, на сколько я знаю, нельзя.
Это проблемы реализаций конкретных версий. Нигде не сказано, что конвертация объектов в строку обязана быть реализована через КЛОС.
MZ>Соню Кин почитай. Grey streams посмотри. Они должны использовать именно MZ>мультиметоды.
Ну, то есть использование такой крутой фишки приходится искать днем с огнем? Вот это и странно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, AndrewVK, Вы писали:
AVK>Вне контекста это мало о чем говорит. К примеру, итераторы в C# 2 использовались совсем нечасто, а вот в C# 3 используются немало, хотя сами итераторы в нем не изменились. Так и с мультиметодами — если это будет единственный вариант встроенной в язык динамическо/статической диспетчеризации по типам, то использоваться они будут.
Кем? Я видил их использование еще когда не слышал о 3.0.
Кстати, характерно. Сколько там этим итератором? Их применение можно найти на каждом углу. А вот мультиметоды в CL уже много лет, а найти их применение не так просто.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, VladD2, Вы писали:
VD>Кем? Я видил их использование еще когда не слышал о 3.0.
Я тоже. Но с появлением C# 3 они стали применяться намного чаще.
VD>Кстати, характерно. Сколько там этим итератором? Их применение можно найти на каждом углу. А вот мультиметоды в CL уже много лет, а найти их применение не так просто.
А если кроме них не будет других аналогов?
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
VladD2 пишет: > Это проблемы реализаций конкретных версий. Нигде не сказано, что > конвертация объектов в строку обязана быть реализована через КЛОС. >
Здравствуйте, Sinclair, Вы писали:
S>Нда. Интересно было бы послушать эту историю в изложении, к примеру, Миши Купаева. Оценить, тскать, искажения в канале.
Тоха, мы ничего не придумывали, рассказывали все как было на самом деле.. =) ну разьве что чуть-чуть..
Мэдс потом еще ехидно улыбался, когда я мимо проходил.. )
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[8]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, IB, Вы писали: IB>Мэдс потом еще ехидно улыбался, когда я мимо проходил.. )
Да-да. А AVK потом еще меня азартно тыкал локтем в бок и говорил: "Вон, смотри, у тебя есть еще один шанс не узнать Рихтера!"
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Будущее C#, или почему C# ходит вокруг да около Nemer
Здравствуйте, AndrewVK, Вы писали:
VD>>Кем? Я видил их использование еще когда не слышал о 3.0.
AVK>Я тоже. Но с появлением C# 3 они стали применяться намного чаще.
С чего бы это?
Кстати, от нас постоянно просят добавить в Немерле возможность реализовывать итераторы в рамках локальных функций. Думаю, в Шарпе тоже резко увеличилось бы количество применений итераторов если бы их можно было реализовывать по месту (как в Скале). Предложил бы это когда в следующий раз увидишь разработчиков шарпа.
VD>>Кстати, характерно. Сколько там этим итератором? Их применение можно найти на каждом углу. А вот мультиметоды в CL уже много лет, а найти их применение не так просто.
AVK>А если кроме них не будет других аналогов?
А других и нет. В Лиспе паттерн-матчигна нет. Есть неофициальные разработки на базе макросов, но они еще реже применяются.
Тут видом дело в том, что Лисп с одной стороны динамически типизированный язык. А с другой на нем обычно пишу в функциональном или процедурном стиле, а не используют ООП. А раз нет ООП, то и смысла в методах (пусть даже "мулти") особого нет.
Думаю, в Шарпе конечно их бы применяли бы чаще. Но мултиметоды несколько противоречат компонентному подходу если их делать не расширяемыми динамически, и могут привести к багам и проблемам с защитой если они будут динамически расширяемыми (расширения могут добавляться при подгрузке внешней сборки).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Будущее C#, или почему C# ходит вокруг да около Nemer
Я не спец в Лиспе, но сдается мне что PRINT-OBJECT это именно что КЛССовский метод.
Он умеет выводить информацию о встроенных типах (атомах, S-варажениях)?
>> Ну, то есть использование такой крутой фишки приходится искать днем с >> огнем? Вот это и странно.
MZ>Да нет же, достаточно распространено. Ну не знаю, как это доказать....
ОК. Сам Лисп на сегодня применяется настолько не часто, что говорить о статистике применения КЛОССа просто бессмысленно. Будем считать, что в лиспе мультиметоды периодически применяются (других то нету ).
MZ>Но на счёт других языков программирования -- тут ты прав на все 100%.
О том и речь. Причем если в ФЯ обычно имеются более мощный аналог — сопоставление с образцом, то в ООЯ есть только жалкая пародия — паттерн Посетитель и тот является частным случаем (на два аргумента) и очень неудобен в использовании.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Будущее C#, или почему C# ходит вокруг да около Neme
VladD2 wrote: > Я не спец в Лиспе, но сдается мне что PRINT-OBJECT это именно что > КЛССовский метод.
да
> Он умеет выводить информацию о встроенных типах (атомах, S-варажениях)?
да
Но только по стандарту его нельзя вызывать явно.
(что я тут наглым образом сделал).
> О том и речь. Причем если в ФЯ обычно имеются более мощный аналог — > сопоставление с образцом, то в ООЯ есть только жалкая пародия — паттерн > Посетитель и тот является частным случаем (на два аргумента) и очень > неудобен в использовании.
По мне фичи "функциональное программирование" и "сопоставление с образцом"
глубоко ортогональны друг другу. Мультиметоды же -- отдельная и совершенно
самоценная фича. Например, можно было бы делать на ней полиморфное присваивание,
сравнение и т.п., чего традиционно не хватало в С++.
А не применяются мультиметоды только потому, что их нигде не реализовано,
кроме как в Common Lisp-е.
Кстати, в Java есть один оччень нужный метод, java.lang.Object.equals, который
очень бы выиграл, если бы был мультиметодом. А так ему приходится, по бедности
языка, это дело имитировать с помощью серии if-ов.
Posted via RSDN NNTP Server 2.1 beta
Re[10]: Будущее C#, или почему C# ходит вокруг да около Neme
VladD2 wrote:
> Тут видом дело в том, что Лисп с одной стороны динамически > типизированный язык. А с другой на нем обычно пишу в функциональном или > процедурном стиле, а не используют ООП. А раз нет ООП, то и смысла в > методах (пусть даже "мулти") особого нет.
Да с чего ты взял-то, что OOP в лиспе не используют ?
Надо — используют, и ещё как. Ты думаешь для чего вообще CLOSS-то
придумали ? Не надо было бы — не придумывали бы наверное, да ?
Кстати, ещё о мультиметодах и функциональном подходе.
Идея такая, что как раз в функиональном -то подходе кроме
мультиметодов реально ничего и не должно быть, поскольку
в мультиметоде в центре — метод, функция, а не её объекты-параметры.
Мультиметод не принадлежит ни к какому классу, а является просто
функцией по большому счёту.
Posted via RSDN NNTP Server 2.1 beta
Re[11]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, MasterZiv, Вы писали:
MZ>По мне фичи "функциональное программирование" и "сопоставление с образцом"
А кто сказал, что первое — это фича? Первое — это парадигма. И Лисп как бы ее родоначальник.
MZ>глубоко ортогональны друг другу. Мультиметоды же -- отдельная и совершенно MZ>самоценная фича. Например, можно было бы делать на ней полиморфное присваивание,
Мультиметоды — это множественная диспетчеризация завернутая в личину методов. Не больше, и не меньше.
MZ>сравнение и т.п., чего традиционно не хватало в С++. MZ>А не применяются мультиметоды только потому, что их нигде не реализовано, MZ>кроме как в Common Lisp-е.
Сопоставление с образцом объективно мощнее. Это, скажем так, распознование сложных образцов и в том числе множественная диспетчеризация, так как один из видов образцов — это выявление динамического типа нескольких значений.
Скажем в том же Немерле мы имеем возможность реализовать мультиметоды в виде макросов, но это никому не нужно.
MZ>Кстати, в Java есть один оччень нужный метод, java.lang.Object.equals, который MZ>очень бы выиграл, если бы был мультиметодом. А так ему приходится, по бедности MZ>языка, это дело имитировать с помощью серии if-ов.
Самое смешно, что и в Яве и в дотнете вызов метода через рефлексию осуществляется с использованием множественой динамической диспетчеризации, т.е. по факту действует как мульиметод. Только работает это очень медленно.
Еще смешнее, что VB поддерживает мультиметоды уже сейчас, так как он повзоляет описывать динамический вызовы которые точно так же диспетчиризируют управление на основании динамических типов аргументов.
Вот только опять же — медленно и почти никто не использует.
Аналогичная функциональность будет добавлена в C# 4.0. При этом она будет (теоретически) работать существенно быстрее, так как там будет производиться кэширование.
Так что если мультиметоды так круты, то почему ты не пишешь на VB? $)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, MasterZiv, Вы писали:
MZ>Да с чего ты взял-то, что OOP в лиспе не используют ?
С того, что кода на Лиспе выдел достаточно, а вот ООП раза два от силы.
MZ>Надо — используют, и ещё как. Ты думаешь для чего вообще CLOSS-то MZ>придумали ? Не надо было бы — не придумывали бы наверное, да ?
Многие вещи делаются вообще не ясно для чего.
Вот тот же КЛОСС и Смолток гордятся своей крутой ОО-подсистемой, а пишут все на Яве, Шарпе, Васике и С++ где все не так круто, но писать удобнее (а может проще).
MZ>Кстати, ещё о мультиметодах и функциональном подходе. MZ>Идея такая, что как раз в функиональном -то подходе кроме MZ>мультиметодов реально ничего и не должно быть, поскольку MZ>в мультиметоде в центре — метод, функция, а не её объекты-параметры.
Дык потому они и есть в Лиспе, которые по сути ФЯ к которому пришили все что нашлось.
MZ>Мультиметод не принадлежит ни к какому классу, а является просто MZ>функцией по большому счёту.
Ага. Но хорошо ли это? ООП был придуман, чтобы упростить эмуляцию объектов "реального" мира. В реальном мире мультиметодов нет. Зато есть свойства объектов и функции которые они могут выполнять. В общем, люди в массе свей думают по другому.
Думаю, что Лисп не пошел в массы именно потому, что он заставляет думать так как надо ему, а не так как это обычно делают люди. Вся эта байда со скобками, польской записью, мультиметодами (в отсутствии обычных) приводит к тому, что люди его не принимают. Они не хотят перестраиваться под язык. Они хотят иметь язык подстроенный под них.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, jazzer, Вы писали:
J>Да что вы все как один заладили, что мультиметоды только в CLOS есть... J>Вот вам ссылка для изучения: http://en.wikipedia.org/wiki/Multiple_dispatch J>Есть даже для Перла реализация
Ну, так изучи ее и увидишь сам, что если отбросить эксперементы и скрипты в которых любой вызов динамически диспетчерезуется, то не сложно заметить, что Лисп останется в гордом одиночистве. Вот список языков из этой статьти:
* Common Lisp (via the Common Lisp Object System) [1]
* Dylan[2]
* Nice[3][original research?]
* Slate[4]
* Cecil[5]
* R[6]
* Groovy[7]
* Perl 6 [8]
* Clojure[9]
А на перле вы сами пишите.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, VladD2, Вы писали:
AVK>>Я тоже. Но с появлением C# 3 они стали применяться намного чаще.
VD>С чего бы это?
С появления линка.
VD>Кстати, от нас постоянно просят добавить в Немерле возможность реализовывать итераторы в рамках локальных функций. Думаю, в Шарпе тоже резко увеличилось бы количество применений итераторов если бы их можно было реализовывать по месту
Возможно.
VD> (как в Скале). Предложил бы это когда в следующий раз увидишь разработчиков шарпа.
Для этого видеть не обязательно, есть рассылка. Но для начала надо этот вопрос исследовать самостоятельно.
AVK>>А если кроме них не будет других аналогов?
VD>А других и нет. В Лиспе паттерн-матчигна нет.
В Лиспе все что нужно можно сделатьсамостоятельно, так что лисп не показатель.
VD>Думаю, в Шарпе конечно их бы применяли бы чаще. Но мултиметоды несколько противоречат компонентному подходу если их делать не расширяемыми динамически
А если делать расширяемыми, то толку в них, по сравнению с рефлекшен+LWCG, не дофига. А в C# 4 с его динамикой все это и синтаксически можно сделать прилично. Нужен именно полустатический вариант, чтобы визиторы не плодить. И мультиметоды, конечно, не лучший вариант из того что могло бы быть, но всяко лучше того, что уже есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
Здравствуйте, Gajdalager, Вы писали:
G>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, jazzer, Вы писали:
VD>>А на перле вы сами пишите.
G>Оффтоп в защиту перла — это шестой перл, не тот, которым детей пугают
в шестой перл это встроено в язык, а в пятом это библиотека
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Да что вы все как один заладили, что мультиметоды только в CLOS есть... J>>Вот вам ссылка для изучения: http://en.wikipedia.org/wiki/Multiple_dispatch J>>Есть даже для Перла реализация
VD>Ну, так изучи ее и увидишь сам, что если отбросить эксперементы и скрипты в которых любой вызов динамически диспетчерезуется, то не сложно заметить, что Лисп останется в гордом одиночистве. Вот список языков из этой статьти:
Не понял, зачем отбрасывать скрипты? В чем проблема с ними?
Тебе шашечки или ехать?
VD>А на перле вы сами пишите.
А я и пишу, с большим удовольствием
Но ты сам, думаю, понимаешь, что "перл мне не нравится, поэтому в разговоре о мультиметодах ему места нет" — это несерьезный аргумент.
Кстати, раз уж речь была о сроках, то реализация ММ в перле — 1998 год: http://search.cpan.org/~dconway/Class-Multimethods/lib/Class/Multimethods.pod
VladD2 пишет: > Ага. Но хорошо ли это? ООП был придуман, чтобы упростить эмуляцию > объектов "реального" мира. В реальном мире мультиметодов нет. Зато есть
Ты знаешь, в реальном мире и программ нет.
Но вот если надо описывать поведение при взаимодействии двух и более
объектов, а это не так уж и редко, то мультиметоды — самое то, самый
логичный подход.
> Думаю, что Лисп не пошел в массы именно потому, что он заставляет думать > так как надо ему, а не так как это обычно делают люди. Вся эта байда со > скобками, польской записью, мультиметодами (в отсутствии обычных) > приводит к тому, что люди его не принимают. Они не хотят перестраиваться > под язык. Они хотят иметь язык подстроенный под них.
Да просто они тупые в массе. Говори уж прямо.
Posted via RSDN NNTP Server 2.1 beta
Re[12]: Будущее C#, или почему C# ходит вокруг да около Neme
jazzer пишет:
> Да что вы все как один заладили, что мультиметоды только в CLOS есть... > Вот вам ссылка для изучения: http://en.wikipedia.org/wiki/Multiple_dispatch > Есть даже для Перла реализация
Ну вот, если в стольких языках это реализуют, хотя бы в виде библиотек,
значит этого не хватает, значит это кому-то зачем-то нужно ...
А также ещё одна (не новая) мысл, что все design patterns — это костыли
для недоязыков, и что лучше их иметь встроенными в язык, пусть даже
в виде декорейшенов, как в двух реализациях в питоне.
Posted via RSDN NNTP Server 2.1 beta
Re[11]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Я тоже. Но с появлением C# 3 они стали применяться намного чаще. VD>>С чего бы это? AVK>С появления линка.
Этому есть реальные доказательства, или это твои впечатления?
VD>> (как в Скале). Предложил бы это когда в следующий раз увидишь разработчиков шарпа.
AVK>Для этого видеть не обязательно, есть рассылка. Но для начала надо этот вопрос исследовать самостоятельно.
Ну, напиши туда. Простые смертные им явно по барабану.
AVK>В Лиспе все что нужно можно сделатьсамостоятельно, так что лисп не показатель.
Это только если языком. А на практике все очень не просто. Да и сам язык для ПМ плохо подходит. Матчить АСТ с помощью АСТ же еще та развлекуха.
VD>>Думаю, в Шарпе конечно их бы применяли бы чаще. Но мултиметоды несколько противоречат компонентному подходу если их делать не расширяемыми динамически
AVK>А если делать расширяемыми, то толку в них, по сравнению с рефлекшен+LWCG, не дофига.
Весь толк в скорости. Если они будут работать хотя бы раз 5 медленнее чем статические методы, то толк будет. В прочем, культуру использования все равно годами еще создавать прийдется.
AVK>А в C# 4 с его динамикой все это и синтаксически можно сделать прилично. Нужен именно полустатический вариант, чтобы визиторы не плодить. И мультиметоды, конечно, не лучший вариант из того что могло бы быть, но всяко лучше того, что уже есть.
Вопрос только в скорости. Как тут уже показывали любители динамики в скриптах Посетители практически не нужны, так как любой вызов автоматом мультимеметод при наличии перегрузки.
Ну, а если делать закрытый список (не расширяемый в рантайме), то преимуществ супротив паттерн-матчинга не будет вовсе. Одни нидостатки, так как МП на порядок более мощный механизм.
В общем, мультиметоды в идеологическом плане весьма неоднозначная фича.
ЗЫ
Сдается мне Меер жестоко тебался и над мультиметодами, и над Хейльсбергом. Одна его фраза "я вообще-то не функциональщик" чего стоит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, MasterZiv, Вы писали:
MZ>Ну вот, если в стольких языках это реализуют, хотя бы в виде библиотек, MZ>значит этого не хватает, значит это кому-то зачем-то нужно ...
А кто-то пользуется?
Такие библиотеки делают из принципа — шоб у нас було. Приходят товарищи (обычно лисперы) и говорят — а у вас нет Зингельшухера (с)...
MZ>А также ещё одна (не новая) мысл, что все design patterns — это костыли MZ>для недоязыков, и что лучше их иметь встроенными в язык, пусть даже MZ>в виде декорейшенов, как в двух реализациях в питоне.
Для динамики мультиметоды — это вообще не ясно что. Ведь если у тебя типы аргументов всегда вычисляются в рантайме, то почти любой вызов фукнции у которой более одного параметра — это мультиметод.
Что до паттернов, то только языки поддерживающие метапрограммирование могут автоматизировать решение большинства из них. И то есть паттерны вроде MVC которые настолько широки и общи, что создать универсальную их реализацию невозможно. На то они и дизайн-паттерны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, VladD2, Вы писали:
AVK>>С появления линка. VD>Этому есть реальные доказательства, или это твои впечатления?
Даже и не знаю что ответить. Разумеется, я не собирал подробную статистику (как, впрочем, и ты), но применения итераторов после выхода линка я вижу в на порядок больше, причем не только я. А так да, мои впечатления конечно.
AVK>>Для этого видеть не обязательно, есть рассылка. Но для начала надо этот вопрос исследовать самостоятельно.
VD>Ну, напиши туда. Простые смертные им явно по барабану.
Ну, я не хочу пока туда писать что то, в чем я сам не уверен.
AVK>>А если делать расширяемыми, то толку в них, по сравнению с рефлекшен+LWCG, не дофига.
VD>Весь толк в скорости.
Это мне в данном контексте малоинтересно. И LWCG ты все равно не обгонишь
AVK>>А в C# 4 с его динамикой все это и синтаксически можно сделать прилично. Нужен именно полустатический вариант, чтобы визиторы не плодить. И мультиметоды, конечно, не лучший вариант из того что могло бы быть, но всяко лучше того, что уже есть.
VD>Вопрос только в скорости.
У полустатического варианта в виде того же визитора или алгебраических типов в Немерле скорость соответствует скорости вызова виртуального метода, а у динамики — ET прекрасно компилируется на ходу.
VD>Сдается мне Меер жестоко тебался и над мультиметодами
Сдается мне, ты ошибаешься.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
Здравствуйте, VladD2, Вы писали:
VD>В общем, мультиметоды в идеологическом плане весьма неоднозначная фича.
Чтобы не было недопонимания — мультиметоды мне не нравятся, слишком они громоздкие. Те варианты, что предлагал Хейлсберг, хоть они и тоже ограничены, нравятся мне куда больше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
Здравствуйте, jazzer, Вы писали:
J>Не понял, зачем отбрасывать скрипты? В чем проблема с ними? J>Тебе шашечки или ехать?
Ну, потому что их скорости уже ничего не повредит. Тогда давай говорить, что VB тоже мультиметоды поддерживает, так как в динамическом режиме он вполне себе динамическую диспетчерезацию обеспечивает.
Шарп, кстати, тоже может через рефлекшон (совсем не сложно) динамически методы вызывать.
Ну, и какой от этого толк? В реальном коде это использовать нельзя.
VD>>А на перле вы сами пишите.
J>А я и пишу, с большим удовольствием
Ну, и продолжай .
J>Но ты сам, думаю, понимаешь, что "перл мне не нравится, поэтому в разговоре о мультиметодах ему места нет" — это несерьезный аргумент.
Честно сказать, я только от тебя услышал что в 6-ом Перле реализовали мультиметоды. Может они там даже быстро сделаны. Перл ведь компилируется вроде
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, MasterZiv, Вы писали:
MZ>Тошнит потому что часто на клавиатуру ...
А чё? Не хуже других .
Если серьезно, то значит не так уж важны для тебя мультиметоды, чтобы ради них выбирать язык. Я бы вот тоже ради них не выбрал бы ни Перл, ни Васик, ни даже Лисп. Хотя по поводу лиспа еще подумал бы, так как там не только мультиметоды реализованы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, AndrewVK, Вы писали:
AVK>Даже и не знаю что ответить. Разумеется, я не собирал подробную статистику (как, впрочем, и ты), но применения итераторов после выхода линка я вижу в на порядок больше, причем не только я. А так да, мои впечатления конечно.
А я как-то и раньше не особо много видел, и сейчас тоже не очень много.
AVK>>>А если делать расширяемыми, то толку в них, по сравнению с рефлекшен+LWCG, не дофига. VD>>Весь толк в скорости. AVK>Это мне в данном контексте малоинтересно. И LWCG ты все равно не обгонишь
Кто такой LWCG? И зачем мне его обгонять?
AVK>У полустатического варианта в виде того же визитора или алгебраических типов в Немерле скорость соответствует скорости вызова виртуального метода, а у динамики — ET прекрасно компилируется на ходу.
Да, нет конечно. По меньше будет. Раза в 2.5. В прочем это еще приемлемо. Алгеброические типы тут правда не причем. Это с любыми типами можно делать. Есть такой паттерн "| (x is SomeType1, y is SomeType2, ...)".
Вот только посетители больше двойной диспетчеризации реализовать не могут.
VD>>Сдается мне Меер жестоко тебался и над мультиметодами
AVK>Сдается мне, ты ошибаешься.
Не. Почитав о его деятельности моя уверенность немного укрепилась... примерно до ста процентов .
Человек был одним и создателей Хаскеля. Разбил себе лоб проталкивая Хаскель в массы. Создал даже упрощенный Хаскель который не приняли даже хаскелисты. Потом пошел "в народ". Нанялся в МС и сделал СиОмегу. Далее ты знаешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, VladD2, Вы писали:
AVK>>Это мне в данном контексте малоинтересно. И LWCG ты все равно не обгонишь
VD>Кто такой LWCG?
lightweight codegeneration
VD> И зачем мне его обгонять?
Ты скорости хотел
VD>Человек был одним и создателей Хаскеля. Разбил себе лоб проталкивая Хаскель в массы. Создал даже упрощенный Хаскель который не приняли даже хаскелисты. Потом пошел "в народ". Нанялся в МС и сделал СиОмегу. Далее ты знаешь.
Ну, мое мнение по поводу СиОмеги ты знаешь
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Чтобы не было недопонимания — мультиметоды мне не нравятся, слишком они громоздкие. Те варианты, что предлагал Хейлсберг, хоть они и тоже ограничены, нравятся мне куда больше.
Что значит громоздкие? Мультиметоды это что-то вроде перегрузки по нескольким параметрам. Может выглядеть, например, так:
class A
{
public static abstract MultiMethod(object x, D d, F f);
}
class B : A
{
public static override MultiMethod(string x, D d, G f); // 1public static override MultiMethod(int x, X d, Y f); // 2
}
class F { }
class G : F { }
class D { }
class X : D { }
class Y : G { }
...
A.MultiMethod((object)1, (D)new X(), (F)new G());
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Это мне в данном контексте малоинтересно. И LWCG ты все равно не обгонишь VD>>Кто такой LWCG? AVK>lightweight codegeneration
И каким боком это тут?
Речь кажется была о языке.
VD>> И зачем мне его обгонять? AVK>Ты скорости хотел
Скорости работы стандартного языкового механизма. А не хрен знает чего с боку бантик.
AVK>Ну, мое мнение по поводу СиОмеги ты знаешь
Дык. Все что не СиШарп, то...
Линк — это его рук дело. И в СиОмега он был отработан на языках с близкой к шпрповской системой типов (расширенной, правда).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, AndrewVK, Вы писали:
AVK>C# 4 обеспечит тебе синтаксис, а реализация будет работать через кодогенерацию.
Что-то я не вижу как это можно сделать. Что тут даст кодогенерация? Диспетчеризация же будет делаться средствами DLR.
AVK>Пруфлинк? VD>> И в СиОмега он был отработан на языках с близкой к шпрповской системой типов (расширенной, правда). AVK>Сиомега и линк это две большие разницы.
Здравствуйте, VladD2, Вы писали:
AVK>>C# 4 обеспечит тебе синтаксис, а реализация будет работать через кодогенерацию.
VD>Что-то я не вижу как это можно сделать. Что тут даст кодогенерация? Диспетчеризация же будет делаться средствами DLR.
На вход биндера придет ET с вызовом. А что уж с ним делать — интерпретировать или сгенерить в рантайме IL, это уже дело самого биндера.
VD>Разницы не разницы, но инспирировал все Меер.
Скажем так, он, безусловно, сильно повлиял на то, что получилось в итоге. Но это не значит, что конечный дизайн линка на 100% его заслуга.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
AVK>На вход биндера придет ET с вызовом. А что уж с ним делать — интерпретировать или сгенерить в рантайме IL, это уже дело самого биндера.
Что за ET?
Ну, а тормозить может сам механизм рантайм-идентификации типов. Как я понимаю, там предполагается вызвать у каждого объекта .GetType() и уже на его основании лезть в кэш. О проверках на null я вообще молчу.
В итоге это может оказаться в десятки раз медленнее обычного виртуального метода. И при этом каждый дополнительный параметр будет умножать тормоза.
VD>>Разницы не разницы, но инспирировал все Меер.
AVK>Скажем так, он, безусловно, сильно повлиял на то, что получилось в итоге. Но это не значит, что конечный дизайн линка на 100% его заслуга.
Скажем, так не было бы его, не было бы и линка. Но, то что не он один то что получилось спроектировал — это езжу понятно. Иначе получился бы Хаскель .
Меня просто его слова в этом авишнике несколько удивили. Особенно на фоне дружного ржания за кадром. Я сразу подумал, что это похоже на стеб. Но зная про то, что в Америке все очень любят улыбаться (какую бы гадость не делали, или какую бы глупость не говорили) я подумал, что может это и не стеб. Но когда прочел файлик по ссылке, то сразу понял, что не стебом это быть не могло.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали: VD>>Что за ET? AVK>Expression Tree
Ты бы сокращения вводил бы что ли. Это пока что не общепринятое сокращение.
VD>>Ну, а тормозить может сам механизм рантайм-идентификации типов.
AVK>В смысле? Полиморфный вызов что ли?
Там техника такая. Компилятор вмондячивает вызов делегата. Тот нацелен на код который получает динамическую информацию о типах параметров (видимо для тех из них, что заданы как dynamic). Затем лезет в кэш, если в кэше что-то есть, то дергает его (тут я не понял, вроде как там Expression Tree и лежит, но это же бред!). Если нет, то пытается запросить интерфейс IDynamicObject или биндер (если IDynamicObject не реализован). И только биндер уже может отплюнуть что-то. Похоже тоже Expression Tree, хотя тоже не ясно почему бы не просто делегат?
VD>> Как я понимаю, там предполагается вызвать у каждого объекта .GetType()
AVK>Где там? Биндер ты можешь реализовать самостоятельно как тебе угодно.
А что толку? Там до вызова того, что биндер возвратит еще тонна кода будет отрабатывать.
Для сравнения код типа:
match (x, y)
{
| (x is X, y is Y) => ...
}
Будет переписан в аналог шарповских if-ов и is/as-ов. Разницу в скорости можешь сам себе представить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Будущее C#, или почему C# ходит вокруг да около Neme
VladD2 пишет:
> Если серьезно, то значит не так уж важны для тебя мультиметоды, чтобы > ради них выбирать язык. Я бы вот тоже ради них не выбрал бы ни Перл, ни
Безусловно, это не решающий фактор.
> Васик, ни даже Лисп. Хотя по поводу лиспа еще подумал бы, так как там не > только мультиметоды реализованы.
Ну вот, сам же всё знаешь....
Posted via RSDN NNTP Server 2.1 beta
Re[14]: Будущее C#, или почему C# ходит вокруг да около Neme
VladD2 пишет:
> MZ>Ну вот, если в стольких языках это реализуют, хотя бы в виде библиотек, > MZ>значит этого не хватает, значит это кому-то зачем-то нужно ... > > А кто-то пользуется?
VladD, я не знаю. Я не фанат мультиметодов. Есть — замечательно. Нет — ну
и ладно, можно и без них жить. Но если люди так старательно их встраивают
или имитируют в языках, где их нет, то значит они им зачем-то очень нужны,
причём имитация в виде Visitor-а их почему-то не устраивает.
Вот у этих людей и спрашивай, зачем они им нужны.
> Такие библиотеки делают из принципа — шоб у нас було. Приходят товарищи > (обычно лисперы) и говорят — а у вас нет Зингельшухера (с)...
ага, делать им нечего...
В питоне, как я понял, аж три раза подряд делать нечего было.
Posted via RSDN NNTP Server 2.1 beta
Re[14]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gajdalager, Вы писали:
G>>Оффтоп в защиту перла — это шестой перл, не тот, которым детей пугают
VD>То есть — это уже фильм ужасов для взрослых?
Да, примерно как Немерле — вложенные языки, вложенные грамматики, определяемые пользователем, макросы (A Perl 6 macro ... can operate on unparsed strings, an AST representing pre-parsed code, or a combination of the two), ленивости (0..Inf), параллельности и прочие радости, как раз то, что тебе нравится
VladD2 wrote:
> Здравствуйте, MasterZiv, Вы писали: > > MZ>Тошнит потому что часто на клавиатуру ... > > А чё? Не хуже других . > > Если серьезно, то значит не так уж важны для тебя мультиметоды, чтобы ради > них выбирать язык. Я бы вот тоже ради них не выбрал бы ни Перл, ни Васик, > ни даже Лисп. Хотя по поводу лиспа еще подумал бы, так как там не только > мультиметоды реализованы.
мультиметоды в перле? О_о
Posted via RSDN NNTP Server 2.1 beta
Re[15]: Будущее C#, или почему C# ходит вокруг да около Neme
Здравствуйте, swined, Вы писали:
>> Если серьезно, то значит не так уж важны для тебя мультиметоды, чтобы ради >> них выбирать язык. Я бы вот тоже ради них не выбрал бы ни Перл, ни Васик, >> ни даже Лисп. Хотя по поводу лиспа еще подумал бы, так как там не только >> мультиметоды реализованы.
S>мультиметоды в перле? О_о http://search.cpan.org/~dconway/Class-Multimethods/lib/Class/Multimethods.pod
Здравствуйте, MasterZiv, Вы писали:
MZ>причём имитация в виде Visitor-а их почему-то не устраивает.
Визитор это не имитация мультиметодов, это другой способ решить ту же задачу. И далеко не во всем мультиметоды лучше визитора. Визитор, к примеру, контроллирует наличие всех классов в интерфейсе, а вот мультиметоды наличие всех нужных методов — нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.1.7000.0>>
.
)
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
