Здравствуйте, 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>>
Мы уже победили, просто это еще не так заметно...
