Здравствуйте, Cyberax, Вы писали:
C>eao197 wrote:
>> Д>>>А давайте спросим у тех, кто два месяца назад начал с С++ знакомиться >> E>>А что мешает? Спроси. >> Д>Мне ответ уже известен. >> Дык по поводу C++ ответ мне так же известен. А вот про Lisp -- нет. >> И есть большое подозрение, что в случае с Lisp-ом это будет тот же >> самый ответ.
C>Да, в этом году на кафедре математики УдГУ первокурсникам решили C>преподавать Лисп на практике по программированию — мой коллега по работе C>как раз ее ведет (аспирантом порабатывает). Я помогал составлять C>практические задания — ничего сложного, простенькие вещи типа чисел C>Фибоначчи, сортировок, поиска.
C>Студенты плевались сильно и качество их программ было на очень низком C>уровне (они их писал в паскалевском стиле). Несколько раз было прикольно C>- ко мне по аське обращались с просьбами сделать практические задания, C>которые я же и помогал сочинять.
С прискорбием могу заметить, что мировая общественность игнорирует (очевидно, себе во вред) передовой опыт УдГУ. Куда только смотрит руководство вузов, использующих в обучении Lisp(scheme).
И главное — каких плохих специалистов наверно готовит лучший программерский вуз мира MIT, применяющий Scheme в качестве первого языка. И это что — посмотрите, сколько универовлицензировало этот курс у МИТа. Куда катимся...
Gaperton wrote:
> C>Студенты плевались сильно и качество их программ было на очень низком > C>уровне (они их писал в паскалевском стиле). Несколько раз было > прикольно > C>- ко мне по аське обращались с просьбами сделать практические задания, > C>которые я же и помогал сочинять. > С прискорбием могу заметить, что мировая общественность игнорирует > (очевидно, себе во вред) передовой опыт УдГУ. Куда только смотрит > руководство вузов, использующих в обучении Lisp(scheme) > <http://www.schemers.com/schools.html>.
Я это прекрасно знаю.
> И главное — каких плохих специалистов наверно готовит лучший > программерский вуз мира MIT, применяющий Scheme в качестве первого > языка <http://mitpress.mit.edu/sicp/>. И это что — посмотрите, сколько > универов <http://mitpress.mit.edu/sicp/adopt-list.html>лицензировало > этот курс у МИТа. Куда катимся...
Вот, кстати, надо было начинать именно со Схемы с забаненым set'ом.
Здравствуйте, Cyberax, Вы писали:
>> И главное — каких плохих специалистов наверно готовит лучший >> программерский вуз мира MIT, применяющий Scheme в качестве первого >> языка <http://mitpress.mit.edu/sicp/>. И это что — посмотрите, сколько >> универов <http://mitpress.mit.edu/sicp/adopt-list.html>лицензировало >> этот курс у МИТа. Куда катимся...
C>Вот, кстати, надо было начинать именно со Схемы с забаненым set'ом.
Надо было вообще взять МИТовский курс SICP на основе Scheme за основу . Материалы курса, как вы видите, открыты.
E>Да все это правильно. Одно смущает: почему же с Lisp-ом такого (в смысле популяризации и расширения применения) не происходит за сорок-то лет существования? С Perl-ом происходит, с Python-ом происходит, с Ruby происходит. Даже у C++, который только ленивый не ругает -- и то проблем с популярностью нет. А вот с таким, на словах, замечательным Lisp -- нет.
У lisp'а те же проблемы что и у forth'а, синтаксис(нечеловеческий ) и чрезмерная гибкость.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, eao197, Вы писали:
E>>Да все это правильно. Одно смущает: почему же с Lisp-ом такого (в смысле популяризации и расширения применения) не происходит за сорок-то лет существования? С Perl-ом происходит, с Python-ом происходит, с Ruby происходит. Даже у C++, который только ленивый не ругает -- и то проблем с популярностью нет. А вот с таким, на словах, замечательным Lisp -- нет.
FR>У lisp'а те же проблемы что и у forth'а, синтаксис(нечеловеческий ) и чрезмерная гибкость.
Я писал на форте, впечатления самые приятные. Проблем с нечеловеческим синтаксисом и (тем более) "чрезмерной гибкостью" не припомню, все очень просто и удобно. Реальная проблема форта как языка общего назначения — принципиальное отсутствие типов в языке — он типизирован примерно так же, как ассемблер, т.е. типы существуют только в воображении программиста. В лиспе такой проблемы нет.
Здравствуйте, Cyberax, Вы писали:
>> C>Преподаватель учил Лисп вместо со студентами, стараясь все сделать как >> C>можно более красиво >> Н-да... Звучит это довольно подозрительно. Если воспринимать >> буквально, то получается, что преподавателю надо было за время, >> отведенное на преподавание дисциплины (N часов в учебном плане), >> самому изучить язык.
C>Кто говорит, что преподаватель изучал язык на парах???
Написано же: "вместе со студентами".
C>Он его изучал C>дома (и на работе), составляя и решая задания, которые только потом уже C>давались студентам.
Ну, я и не думал всерьез, что все было так экстремально (на парах). Но и в описанном сценарии у преподавателя могло не оказаться достаточно времени. Хотя могло и оказаться...
>> C>Лисп вообще давался в этом курсе для изучения >> C>функционального подхода. В следующем году будет либо Scheme, либо Clean. >> Если интересно, могу рассказать/посоветовать одну книжку по Scheme (и >> не только).
C>Мне-то не нужно. А вот студентам — пригодится, причем надо на русском языке.
Ну, это скорее "в пользу" преподавателя, который будет вести курс.
Книга называется "Structure and interpretation of computer programs", написана вроде бы преподавателем MIT на основе курса, который он там читал. На Wiki ее превозносят прямо-таки до небес. (С другой стороны, кое-кто пишет, что она полезнее при самостоятельном изучении, а не при использовании ее в качестве учебного пособия.) Та часть, которую я читал, мне понравилась, и в качестве курса вроде подходит.
Перевод на русский есть URL http://newstar.rinet.ru/~goga/sicp/sicp.ps.gz. В бумажном виде, соответственно, тоже должен быть.
>> C>А это уже скорее недостаток Лиспа — он не побуждает думать по-другому, >> C>если человек уже не знает что такое функциональное программирование и с >> C>чем его едят. >> А что, он должен заставлять? Multi-paradigm языки не имеют право на >> существование? Вон C++ тоже не заставляет использовать ООП >> программиста, который знаком с C.
C>Ну так в С++ главная парадигма — это императивное программирование. В C>Лиспе — все же близкое к функциональному, но вот сам Лисп не особо C>побуждает его использовать.
C++ vs. C — это ООП vs "процедурное программирование", Lisp vs. C++ — это функциональное (допустим) vs. императивное программирование. Однако C++ можно использовать в процедурном стиле (не побуждает использовать ООП), а Lisp — в императивном (не побуждает использовать функциональный стиль). Ни то, ни другое IMHO не является недостатком соответствующего языка.
>> C>Я его не представляю, я его видел. После натыкания по разу на >> C>стандартные ляпсусы в С++ писали вполне нормальный код. >> Уточняю: речь идет о вещах вроде FC++. Их действительно можно >> использовать без особого напряга, не имея приличного опыта с C++?
C>STL они использовали совершенно нормально, а больше и не надо было.
Тогда это, наверное, был уже все-таки не функциональный стиль...
Здравствуйте, Gaperton, Вы писали:
>>> И главное — каких плохих специалистов наверно готовит лучший >>> программерский вуз мира MIT, применяющий Scheme в качестве первого >>> языка <http://mitpress.mit.edu/sicp/>. И это что — посмотрите, сколько >>> универов <http://mitpress.mit.edu/sicp/adopt-list.html>лицензировало >>> этот курс у МИТа. Куда катимся...
C>>Вот, кстати, надо было начинать именно со Схемы с забаненым set'ом. G>Надо было вообще взять МИТовский курс SICP на основе Scheme за основу . Материалы курса, как вы видите, открыты.
Здравствуйте, Gaperton, Вы писали:
FR>>У lisp'а те же проблемы что и у forth'а, синтаксис(нечеловеческий ) и чрезмерная гибкость. G>Я писал на форте, впечатления самые приятные. Проблем с нечеловеческим синтаксисом и (тем более) "чрезмерной гибкостью" не припомню, все очень просто и удобно. Реальная проблема форта как языка общего назначения — принципиальное отсутствие типов в языке — он типизирован примерно так же, как ассемблер, т.е. типы существуют только в воображении программиста. В лиспе такой проблемы нет.
Я тоже писал на форте(и даже как всякий уважающий себя фортист и на своей реализации языка ), на самом деле очень приятно писать, постоянно приходится немного напрягать мозги, очень стимулирует. Проблемы появляются позже, когда пытаешся читать то что написал, особенно если не позаботился комментировать то, что при написании казалось само сабой разумеющимся.
Здравствуйте, Павел Кузнецов, Вы писали:
>> E>Там и еще было: >> E>
>> вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно E>
>> Все написано правильно. Это называется "мультиметоды", и этого С++ не умеет.
ПК>Гм... А библиотечные решения отвергаются? Если да, то по каким соображениям?..
К слову, а есть библиотечные решения, которые решают проблему мультиметодов насколько же просто, как если бы это было встроено в язык?
Точнее, даже не так: как выглядит максимально изящное библиотечное решение?
On Wed, 13 Jul 2005 13:51:24 -0500, Зверёк Харьковский <21481@users.rsdn.ru> wrote:
> Здравствуйте, Павел Кузнецов, Вы писали: > >>> E>Там и еще было: >>> E>
>>> вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно E>
> >>> Все написано правильно. Это называется "мультиметоды", и этого С++ не умеет. > > ПК>Гм... А библиотечные решения отвергаются? Если да, то по каким соображениям?.. > > К слову, а есть библиотечные решения, которые решают проблему мультиметодов насколько же просто, как если бы это было встроено в язык? > как выглядит максимально изящное библиотечное решение?
Ну, "максимально изящное" -- не знаю, тут долго можно спорить, т.к. понятия об изящном у всех свои... Но достаточно близкий по количеству писанины к встроенному в язык:
struct shape {...};
struct square : shape {...};
struct triangle : shape {...};
struct options {...};
// объявление мультиметодаbool overlap( virtual shape& a, virtual shape& b, options const& );
// реализацииbool overlap( static square& a, static triangle& b) {...}
bool overlap( static triangle& a, static square& b) {...}
Mожет быть, например, таким:
// Объявление "мультиметода" в одном из заголовочных файлов:
MM_METHOD(
overlap,
bool ( MM_VIRTUAL(shape)&, MM_VIRTUAL(shape)&, options const& )
);
// Реализация, потенциально в разных .cpp-файлах:
MM_METHOD_IMPL(
overlap,
bool, ( square& sq, triangle& tr, options const& o ),
{
// use 'sq', 'tr', and 'o' to implement
}
);
MM_METHOD_IMPL(
overlap,
bool, ( triangle& tr, square& sq, options const& o ),
{
// use 'sq', 'tr', and 'o' to implement
}
);
Если кому-то макросы принципиально не нравятся, то вполне возможны варианты с шаблонами. Правда писать придется чуть больше. Например:
Дарней wrote:
> C>Это язык, еще более извращенный: http://refal.ru/ > можно предположить, что он просто не допускает программирование в > "чисто процедурном" стиле > так что неудача с Лиспом — это просто провал преподавателя
Вот уж не знаю... Человек смог объяснить как писать программы на Рефале
и как он соотносится с НАМ (Нормальные Алгоритмы Маркова). Этот кусок
курса вообще замечательно получился — теория и практика замечательно
дополнили друг друга. А вот при попытке объяснить лямбда-исчисление и
функциональное программирование — что-то не так получилось.
И чего-то мне кажется, что виноват не только преподаватель.
Сейчас читаю MITовский курс — неплохо сделано, хотя он достаточно обширный.
Здравствуйте, Cyberax, Вы писали:
C>Вот уж не знаю... Человек смог объяснить как писать программы на Рефале C>и как он соотносится с НАМ (Нормальные Алгоритмы Маркова). Этот кусок C>курса вообще замечательно получился — теория и практика замечательно C>дополнили друг друга. А вот при попытке объяснить лямбда-исчисление и C>функциональное программирование — что-то не так получилось.
Cyberax wrote: > Вот, кстати, надо было начинать именно со Схемы с забаненым set'ом.
У нас в школе было интереснее — RL. Переменные? Зачем? let — нет. Ничего
нет. Арифметики нет. И на этом — двоичное возведение в степень писать
(число — список из I и O). Для счастья (чтоб не застрелились?) car и cdr
заменены на FIRST,LAST,BF(but first),BL,EXPR(=cons).
Здравствуйте, Cyberax, Вы писали:
C>Не так: "Эта куча Лиспового кода уже давно не дает нам никаких C>конкурентных преимуществ, а после .COM-коллапса мы уже не можем держать C>штат из 30 лаурятов премии Тьюринга для его поддержки. Так что пора его C>по кусочкам переписать, а у нас тут как раз крутые С++-программисты из C>отдела поиска есть.".
И денег им платить не надо... готовы работать за идею и хлеб. А что с них взять? Маньяки...
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Gaperton, Вы писали:
FR>>>У lisp'а те же проблемы что и у forth'а, синтаксис(нечеловеческий ) и чрезмерная гибкость. G>>Я писал на форте, впечатления самые приятные. Проблем с нечеловеческим синтаксисом и (тем более) "чрезмерной гибкостью" не припомню, все очень просто и удобно. Реальная проблема форта как языка общего назначения — принципиальное отсутствие типов в языке — он типизирован примерно так же, как ассемблер, т.е. типы существуют только в воображении программиста. В лиспе такой проблемы нет.
FR>Я тоже писал на форте(и даже как всякий уважающий себя фортист и на своей реализации языка ),
Ну дык .
FR> на самом деле очень приятно писать, постоянно приходится немного напрягать мозги, очень стимулирует. Проблемы появляются позже, когда пытаешся читать то что написал, особенно если не позаботился комментировать то, что при написании казалось само сабой разумеющимся.
А вы не забывали следовать стилевым гайдлайнам? А именно — обязательный комментарий касательно входных/выходных параметров (одна строка) + короткие функции (в среднем 3-5 строк). Добавить сюда осмысленые имена слов + комментарии по структурам данных — и никаких проблем.
Здравствуйте, pvgoran, Вы писали:
P>C++ vs. C — это ООП vs "процедурное программирование", Lisp vs. C++ — это функциональное (допустим) vs. императивное программирование. Однако C++ можно использовать в процедурном стиле (не побуждает использовать ООП), а Lisp — в императивном (не побуждает использовать функциональный стиль). Ни то, ни другое IMHO не является недостатком соответствующего языка.
Более того. Лисп, строго говоря, не является функциональным языком — в нем императивный и функциональный стили равноправны. В упомянутом SICP рассмотрены оба стиля, также там рассмотрен ООП (объектная декомпозиция) и ФП (декомпозиция пограммы посредством "потоков" — ленивых списков).
Здравствуйте, Gaperton, Вы писали:
FR>> на самом деле очень приятно писать, постоянно приходится немного напрягать мозги, очень стимулирует. Проблемы появляются позже, когда пытаешся читать то что написал, особенно если не позаботился комментировать то, что при написании казалось само сабой разумеющимся.
G>А вы не забывали следовать стилевым гайдлайнам? А именно — обязательный комментарий касательно входных/выходных параметров (одна строка) + короткие функции (в среднем 3-5 строк). Добавить сюда осмысленые имена слов + комментарии по структурам данных — и никаких проблем.
Дело не в коментариях а в том, что читать нетривиальные манипуляции со стеками тяжело.
