P>>А что это значит??
G>В пылу дискуссии участники незаметно перешли с русского на Липс, так как он дает больше выразительных возможностей чем любой другой язык.
Здравствуйте, Cyberax, Вы писали:
>> Есть подозрение, что: >> 1. Преподаватель не захотел/не смог/не успел показать студентам, как >> правильно использовать Lisp.
C>Преподаватель учил Лисп вместо со студентами, стараясь все сделать как C>можно более красиво
Н-да... Звучит это довольно подозрительно. Если воспринимать буквально, то получается, что преподавателю надо было за время, отведенное на преподавание дисциплины (N часов в учебном плане), самому изучить язык. Однако IMHO времени на самостоятельное изучение языка (и тем более на подготовку к преподаванию) уходит гораздо больше, чем на восприятие нормального курса по этому языку, и N часов, выделенных на второе, запросто может не хватить на первое.
C>Лисп вообще давался в этом курсе для изучения C>функционального подхода. В следующем году будет либо Scheme, либо Clean.
Если интересно, могу рассказать/посоветовать одну книжку по Scheme (и не только).
>> В результате комбинации этих факторов Lisp воспринимался как >> незнакомый и неудобный аналог Паскаля — отсюда и низкое качество, и >> плевательство.
C>А это уже скорее недостаток Лиспа — он не побуждает думать по-другому, C>если человек уже не знает что такое функциональное программирование и с C>чем его едят.
А что, он должен заставлять? Multi-paradigm языки не имеют право на существование? Вон C++ тоже не заставляет использовать ООП программиста, который знаком с C.
>> P.P.S. А если бы студенты, привыкшие к ФЯ, пересели на C++ — они могли >> бы заюзать библиотеки, позволяющие писать в функциональном стиле! >> Представляете результат?
C>Я его не представляю, я его видел. После натыкания по разу на C>стандартные ляпсусы в С++ писали вполне нормальный код.
Уточняю: речь идет о вещах вроде FC++. Их действительно можно использовать без особого напряга, не имея приличного опыта с C++?
E>Помимо списков и символов, в Лисп есть отдельные типы данных для строк, массивов, хеш-таблиц, записей (структур), потоков ввода-вывода. Кроме того, стандарт Common Lisp включает в себя систему объектно-ориентированного программирования CLOS, далеко превосходящую по выразительным возможностям систему программирования C++. Для доказательства этого превосходства достаточно отметить, что есть возможность выбирать вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно определить четыре метода
E>(defmethod draw ((x sentence) (y screen)) (message-box x y)) ; для отображения сообщения на экране
E>(defmethod draw ((x sentence) (y paper)) (write x y)) ; нужно просто написать слова на бумаге
E>(defmethod draw ((x picture) (y screen)) (show-picture-in-a-box x y)) ; показываем картинку на экране
E>(defmethod draw ((x picture) (y screen)) (paint-picture-on-a-paper x y)) ; рисуем картинку на бумаге.
E>При вызове
>>(draw my-data my-device)
E>выбор одного из четырех определенных методов будет динамически осуществляться в момент вызова. Это невозможно в C++, где пришлось бы делать draw либо методом общего предка объектов screen и paper, либо методом общего предка sentence и picture, а выбор кода по типу второго аргумента осуществлять с помощью анализа этого типа в конструкции if.
Просто по ходу дела автор путается и ляпы допускает, хотя в его словах есть доля истины, просто здесь смысл не в параметрах, даж незнаю как это выразить, короче говоря — в CLOS изначально есть мультиметоды, т.е. перегрузка идёт не по 1 (неявному) параметру this, а по всем параметрам, т.е. получаем эдакую виртуальную матрицу вызовов. В плюсах для такого приходится извращаться, не зря много про двойную диспетчеризацию написано (не у Александреску ли была нехилая глава этому посвещена или у Мейерса?), ну а для множественной диспетчеризации надо ещё хитрей изгаляться...
Хотя, признаюсь, сам ещё особо с этими мультиметодами не разбирался, так что сильно не пинайте — не гуру лиспа далеко
Здравствуйте, Курилка, Вы писали:
К>Просто по ходу дела автор путается и ляпы допускает, хотя в его словах есть доля истины, просто здесь смысл не в параметрах, даж незнаю как это выразить, короче говоря — в CLOS изначально есть мультиметоды, т.е. перегрузка идёт не по 1 (неявному) параметру this, а по всем параметрам, т.е. получаем эдакую виртуальную матрицу вызовов. В плюсах для такого приходится извращаться, не зря много про двойную диспетчеризацию написано (не у Александреску ли была нехилая глава этому посвещена или у Мейерса?), ну а для множественной диспетчеризации надо ещё хитрей изгаляться...
Да я понял, что здесь речь идет о чем-то типа мультиметодов. Просто из-за таких явнях ляпов в знании C++ сама ценность такого сравнения сильно уменьшается, имхо.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Да я понял, что здесь речь идет о чем-то типа мультиметодов. Просто из-за таких явнях ляпов в знании C++ сама ценность такого сравнения сильно уменьшается, имхо.
Конечно, подобное можно видеть и тут на рсдн в лице всяких апологетов Оберона (возможно в чём-то стоящего язык).
К сожалению такого просто избежать невозможно, все когда-то были профанами, только вот, к сожалению, многие ими остаются...
Здравствуйте, eao197, Вы писали:
E>Там и еще было: E>
E>Помимо списков и символов, в Лисп есть отдельные типы данных для строк, массивов, хеш-таблиц, записей (структур), потоков ввода-вывода. Кроме того, стандарт Common Lisp включает в себя систему объектно-ориентированного программирования CLOS, далеко превосходящую по выразительным возможностям систему программирования C++. Для доказательства этого превосходства достаточно отметить, что есть возможность выбирать вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно определить четыре метода
E>(defmethod draw ((x sentence) (y screen)) (message-box x y)) ; для отображения сообщения на экране
E>[ skipped ]
E>При вызове
>>(draw my-data my-device)
E>выбор одного из четырех определенных методов будет динамически осуществляться в момент вызова. Это невозможно в C++, где пришлось бы делать draw либо методом общего предка объектов screen и paper, либо методом общего предка sentence и picture, а выбор кода по типу второго аргумента осуществлять с помощью анализа этого типа в конструкции if.
И что? Я так понимаю, имеются в виду мультиметоды (хотя, может, показано это не очень ясно), которых в C++ пока нет.
E>И еще пару перлов: E>
E>Например, легко ошибиться, написав (i==j || k==l) вместо ((i==j) || (k==l)), а в Лисп такая ошибка просто невозможна, потому что нужно будет написать (or (= i j) (= k l))
E>Т.е. запись (or (= i j) (= k l)) сразу понятнее, чем (i==j || k==l).
А что, там так и написано — что одно понятнее другого??
E> Кстати, насколько я знаю, обе приведенные записи в C++ эквивалентны (т.к. приоритет сравнения выше, чем приоритет логического ИЛИ).
Значит, ошибся человек... С кем не бывает.
E>А так же: E>
E>Например, оператор if в C не возвращает значения, и, чтобы это обойти, была придумана операция ( ? : ). Было бы удобно, если бы оператор switch в C мог также возвращать значение, которое можно присвоить переменной после завершения его выполнения. В Паскале и Бейсике даже присваивание является оператором и не возвращает значения, поэтому нельзя написать a=b=с. В Лиспе в этом плане все гораздо удобнее. if возвращает значение. Одну и ту же конструкцию if можно использовать для ветвления алгоритма и для выбора значения по условию. Также возвращает значение и cond (аналог switch), и setf (аналог присваивания). Да и вообще, в Лиспе значение возвращается всегда, где это имеет смысл.
E>Как будто в C++ подругому .
Таки по-другому. switch, if, for и т.п. — все не возвращают значение, хотя во многоих случаях это могло бы быть полезным.
С другой стороны, есть высказывание в духе "Лисп-программисты для всего на свете знают значение, но не цену" . (За точность не ручаюсь.)
CX>>Ссылка интересная, спасибо. Но вот один настораживающий момент: E>[...] CX>>автор никогда не слышал и оперирует он знаниями совсем древнего C++. А это есть минус статье, т.к. взялся сравнивать — разберись в вопросе.
E>Там и еще было: E>
вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно E>
Все написано правильно. Это называется "мультиметоды", и этого С++ не умеет. Как и Java. Как и C#. Как и Smalltalk. Перфразируя CrystalX, взялся чморить — разберись в вопросе.
Здравствуйте, Курилка, Вы писали:
К>Просто по ходу дела автор путается и ляпы допускает, хотя в его словах есть доля истины, просто здесь смысл не в параметрах, даж незнаю как это выразить, короче говоря — в CLOS изначально есть мультиметоды,
Текст далек от идеала, но этот момент, кажется, выражен ясно
выбор одного из четырех определенных методов будет динамически осуществляться в момент вызова.
Курилка,
К>Конечно, подобное можно видеть и тут на рсдн в лице всяких апологетов Оберона (возможно в чём-то стоящего язык).
Не всяких, а некоторых. Например, AVC вполне толково рассказывал про Оберон,
eao197,
E>>Да я понял, что здесь речь идет о чем-то типа мультиметодов. Просто из-за таких явнях ляпов в знании C++ сама ценность такого сравнения сильно уменьшается, имхо.
Аутор конечно как слон в посудной лавке. Тем не менее, хорошей реализации мультиметодов в C++ нет, каждая обладает какими-то недостатками, но все (известные реализации) — необходимостью в интеллектуальной работе руками при масштабировании. То есть здесь 1:0 в пользу Лиспа. Увы.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Gaperton, Вы писали:
P>>>А что это значит??
G>>В пылу дискуссии участники незаметно перешли с русского на Липс, так как он дает больше выразительных возможностей чем любой другой язык.
Т>Вы будете смеяться, но это был С++/
Буду . Мой пример с C++ и Clean отдыхает. Честно скажу — не знал, что запятая перегружается .
Здравствуйте, Gaperton, Вы писали:
G>вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно E>[/q]
G>Все написано правильно. Это называется "мультиметоды", и этого С++ не умеет.
Вот написал бы он мультиметоды -- я бы слова не сказал. А то, что было выделено жирным сильно смахивает на обычный overloading.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
pvgoran wrote:
> C>Преподаватель учил Лисп вместо со студентами, стараясь все сделать как > C>можно более красиво > Н-да... Звучит это довольно подозрительно. Если воспринимать > буквально, то получается, что преподавателю надо было за время, > отведенное на преподавание дисциплины (N часов в учебном плане), > самому изучить язык.
Кто говорит, что преподаватель изучал язык на парах??? Он его изучал
дома (и на работе), составляя и решая задания, которые только потом уже
давались студентам.
> C>Лисп вообще давался в этом курсе для изучения > C>функционального подхода. В следующем году будет либо Scheme, либо Clean. > Если интересно, могу рассказать/посоветовать одну книжку по Scheme (и > не только).
Мне-то не нужно. А вот студентам — пригодится, причем надо на русском языке.
> C>А это уже скорее недостаток Лиспа — он не побуждает думать по-другому, > C>если человек уже не знает что такое функциональное программирование и с > C>чем его едят. > А что, он должен заставлять? Multi-paradigm языки не имеют право на > существование? Вон C++ тоже не заставляет использовать ООП > программиста, который знаком с C.
Ну так в С++ главная парадигма — это императивное программирование. В
Лиспе — все же близкое к функциональному, но вот сам Лисп не особо
побуждает его использовать.
> C>Я его не представляю, я его видел. После натыкания по разу на > C>стандартные ляпсусы в С++ писали вполне нормальный код. > Уточняю: речь идет о вещах вроде FC++. Их действительно можно > использовать без особого напряга, не имея приличного опыта с C++?
STL они использовали совершенно нормально, а больше и не надо было.
Здравствуйте, eao197, Вы писали:
E>Да я понял, что здесь речь идет о чем-то типа мультиметодов. Просто из-за таких явнях ляпов в знании C++ сама ценность такого сравнения сильно уменьшается, имхо.
Камень в твой огород
People frightened by Lisp make up other reasons for not using it. The standard excuse, back when C was the default language, was that Lisp was too slow. Now that Lisp dialects are among the faster languages available, that excuse has gone away. Now the standard excuse is openly circular: that other languages are more popular.
(Beware of such reasoning. It gets you Windows.)
Я отвлекусь в философию непрограммирования. Вообщем-то, это справедливо. Для того, кто выбирает только то, что уже проверено, есть только один способ принять новую технологию: если ему её навяжут насильно Моё жирное имхо, что .Net (и C#.Net в частности) никогда так быстро не заняли бы свои позиции, если бы не заявление Microsoft, что следующая версия ОС будет содержать .Net и более того, многие новые API будут доступны только из managed-кода. Если кто-то сомневается, как eao197, то ему дают гарантию.
На самом деле не думаю, что у Microsoft есть в запасе какая-нибудь волшебная палочка (или волшебная кредитка? ), с помощью которой она может такую гарантию всем обеспечить. Просто они уже на практике проверили, что "личные качества" технологии мало на что влияют, а решающим является количество вложенных усилий. Иными словами, любая технология может стать широко распространённой и повсеместно используемой, (зачеркнуто '(если Microsoft этим займется )) если этим просто заняться. Без всяких ноу-хау и волшебства, без неоспоримых достоинств, которые посрамят всех конкурентов; ничего не нужно. Примеры уже приводились — Basic, Windows, x86, MFC.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я отвлекусь в философию непрограммирования. Вообщем-то, это справедливо. Для того, кто выбирает только то, что уже проверено, есть только один способ принять новую технологию: если ему её навяжут насильно Моё жирное имхо, что .Net (и C#.Net в частности) никогда так быстро не заняли бы свои позиции, если бы не заявление Microsoft, что следующая версия ОС будет содержать .Net и более того, многие новые API будут доступны только из managed-кода. Если кто-то сомневается, как eao197, то ему дают гарантию.
Кё>На самом деле не думаю, что у Microsoft есть в запасе какая-нибудь волшебная палочка (или волшебная кредитка? ), с помощью которой она может такую гарантию всем обеспечить. Просто они уже на практике проверили, что "личные качества" технологии мало на что влияют, а решающим является количество вложенных усилий. Иными словами, любая технология может стать широко распространённой и повсеместно используемой, (зачеркнуто '(если Microsoft этим займется )) если этим просто заняться. Без всяких ноу-хау и волшебства, без неоспоримых достоинств, которые посрамят всех конкурентов; ничего не нужно. Примеры уже приводились — Basic, Windows, x86, MFC.
Да все это правильно. Одно смущает: почему же с Lisp-ом такого (в смысле популяризации и расширения применения) не происходит за сорок-то лет существования? С Perl-ом происходит, с Python-ом происходит, с Ruby происходит. Даже у C++, который только ленивый не ругает -- и то проблем с популярностью нет. А вот с таким, на словах, замечательным Lisp -- нет.
Ну да ладно, я здесь и так этим вопросом всех достал. Пора завязывать.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
> вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно E>
> Все написано правильно. Это называется "мультиметоды", и этого С++ не умеет.
Гм... А библиотечные решения отвергаются? Если да, то по каким соображениям?..
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Трурль, Вы писали:
Т>>Здравствуйте, eao197, Вы писали:
E>>>А то, что было выделено жирным сильно смахивает на обычный overloading.
Т>>Обычный overloading в языке с динамической типизацией
E>"руководствуясь типами нескольких параметров" в C++ работает обычный overloading.
Разница тут в том, что в Лиспе оверлоадинг возможен в рантайме.
Более того, сама идея generic functions/methods напоминает
специализацию темплейтов в C++, только в период выполнения
(а поскольку выполнение может быть и в период компиляции, то
фактически ничего не теряется).
Например, AVC вполне толково рассказывал про Оберон, 
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
), с помощью которой она может такую гарантию всем обеспечить. Просто они уже на практике проверили, что "личные качества" технологии мало на что влияют, а решающим является количество вложенных усилий. Иными словами, любая технология может стать широко распространённой и повсеместно используемой, (зачеркнуто '(если Microsoft этим займется 
