Здравствуйте, Cyberax, Вы писали:

C>Эти языки появились всего лет 10 назад — и на них уже пишет в десятки
C>раз больше программистов, чем на Лиспе. Почему эти языки стали
C>распространенными (причем Питон и Руби никто не пиарил до недавнего
C>времени), а Лисп так и не стал?

Потому что они императивные. Понятные всем. А чтобы освоить новое мышление, нужно немного усилий.

Кодёнок wrote:

> C>Эти языки появились всего лет 10 назад — и на них уже пишет в десятки
> C>раз больше программистов, чем на Лиспе. Почему эти языки стали
> C>распространенными (причем Питон и Руби никто не пиарил до недавнего
> C>времени), а Лисп так и не стал?
> Потому что они императивные. Понятные всем. А чтобы освоить новое
> мышление, нужно немного усилий.

Ну так может оно того и не стоит? Кстати, на том же Питоне вполне можно
писать и функционально — никто не мешает.

--
С уважением,
Alex Besogonov (alexy@izh.com)

pvgoran wrote:

> C>Студенты плевались сильно и качество их программ было на очень низком
> C>уровне (они их писал в паскалевском стиле). Несколько раз было
> прикольно
> C>- ко мне по аське обращались с просьбами сделать практические задания,
> C>которые я же и помогал сочинять.
> Есть подозрение, что:
> 1. Преподаватель не захотел/не смог/не успел показать студентам, как
> правильно использовать Lisp.

Преподаватель учил Лисп вместо со студентами, стараясь все сделать как
можно более красиво Лисп вообще давался в этом курсе для изучения
функционального подхода. В следующем году будет либо Scheme, либо Clean.

> 2. Студенты, привыкшие думать "на Паскале" (это ключевой момент!), не
> захотели/не успели понять, как правильно использовать незнакомый
> инструмент.

Именно.

> В результате комбинации этих факторов Lisp воспринимался как
> незнакомый и неудобный аналог Паскаля — отсюда и низкое качество, и
> плевательство.

А это уже скорее недостаток Лиспа — он не побуждает думать по-другому,
если человек уже не знает что такое функциональное программирование и с
чем его едят.

> P.P.S. А если бы студенты, привыкшие к ФЯ, пересели на C++ — они могли
> бы заюзать библиотеки, позволяющие писать в функциональном стиле!
> Представляете результат?

Я его не представляю, я его видел. После натыкания по разу на
стандартные ляпсусы в С++ писали вполне нормальный код.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Кодёнок wrote:

>> C>Эти языки появились всего лет 10 назад — и на них уже пишет в десятки
>> C>раз больше программистов, чем на Лиспе. Почему эти языки стали
>> C>распространенными (причем Питон и Руби никто не пиарил до недавнего
>> C>времени), а Лисп так и не стал?
>> Потому что они императивные. Понятные всем. А чтобы освоить новое
>> мышление, нужно немного усилий.

C>Ну так может оно того и не стоит? Кстати, на том же Питоне вполне можно
C>писать и функционально — никто не мешает.

А макросы уровня лиспа писать тоже никто не мешает? Писать функционально мало, имхо, на плюсах тоже получается местами вполне функционально...

Курилка wrote:

> C>Ну так может оно того и не стоит? Кстати, на том же Питоне вполне можно
> C>писать и функционально — никто не мешает.
> А макросы уровня лиспа писать тоже никто не мешает?

Кстати, можно. Для Питона мне показывали что-то подобное R# — с помощью
скрипта обходили AST кода и добавляли трассировку вызовов определенной
функции. Выглядело очень красиво, вспомню как называлось — напишу сюда.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Студенты плевались сильно и качество их программ было на очень низком
C>уровне (они их писал в паскалевском стиле). Несколько раз было прикольно
C>- ко мне по аське обращались с просьбами сделать практические задания,
C>которые я же и помогал сочинять.

Это говорит только о плохом качестве преподавания.

Здравствуйте, Трурль, Вы писали:

Т>Хм, policy говорите. А вот это видели?
Т>

Т>(L|DEFUN, ISOMORPHIC, (L|TREE1, TREE2),
Т>  (L|COND, 
Т>    (L|(L|ATOM, TREE1), (L|ATOM, TREE2)),
Т>    (L|(L|ATOM, TREE2), NIL),
Т>    (L|T, (L|AND,
Т>      (L|ISOMORPHIC, (L|CAR, TREE1), 
Т>                     (L|CAR, TREE2)),
Т>      (L|ISOMORPHIC, (L|CDR, TREE1), 
Т>                     (L|CDR, TREE2))
Т>))))
Т>

А что это значит??

Дарней wrote:

> C>Студенты плевались сильно и качество их программ было на очень низком
> C>уровне (они их писал в паскалевском стиле). Несколько раз было
> прикольно
> C>- ко мне по аське обращались с просьбами сделать практические задания,
> C>которые я же и помогал сочинять.
> Это говорит только о плохом качестве преподавания.

Однако у этого же преподавателя студенты вполне нормально разобрались с
Рефалом (преподаватель его тоже вместе со студентами учил).

Кстати о квалификации — этот же преподаватель почти в одиночку пишет
софт для http://taxcalc.com (бывший http://taxchecker.co.uk — у них там
сейчас реорганизация, поэтому веб-версии недоступны) — систему для
подсчета налогов в Британии, ядро которой работает без изменений в
веб-версии и в stand-alone. В этой системе правила рассчета налогов
декларативно задаются в MathML, из которого потом генерируется
JavaScript-код для веб-версии и С++ для stand-alone, для каждого поля
генерируется скрипт, который вызывает пересчет зависимых полей,
валидацию и т.п.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:

>> C>Ну так может оно того и не стоит? Кстати, на том же Питоне вполне можно
>> C>писать и функционально — никто не мешает.
>> А макросы уровня лиспа писать тоже никто не мешает?

C>Кстати, можно. Для Питона мне показывали что-то подобное R# — с помощью
C>скрипта обходили AST кода и добавляли трассировку вызовов определенной
C>функции. Выглядело очень красиво, вспомню как называлось — напишу сюда.

Ждём, сравним с defmacro

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, eao197, Вы писали:

E>>Собственно, вопрос такой, на которого ответа все равно никто не даст. Это мои проблемы и решение должно быть моим.

Кё>Задал вопрос и сам же на него ответил Да, гарантии я тебе не дам.

E>>Но может кто-нибудь внятно объяснить, почему, если Lisp такой супер-пупер, он всех остальных не задавил (за сорок-то лет существования)?
E>>Пока я получил один заслуживающий внимания ответ: Re[9]: Metaprogramming et al

Автор: CrazyPit
Дата: 13.07.05

. Из которого понятно, что Lisp -- это язык для чокнутых программистов (в хорошем смысле этого слова). И тогда понятно, что Lisp просто не сможет применяться в командах, в которых нормальные, а не чокнутые, программисты работают. А ведь каких команд большинство. В том числе и у нас в компании.

Кё>Может быть принципиальная интерпретируемость и соответственно, низкое быстродействие на современных "mov ax,bx"-машинах. Сейчас набирают популярность интерпретируемые языки, и Лисп "всплыл" опять.

ЭЭЭ вообще-то большинство реализаций Common Lisp, компилируемые...

Так что это не аргрумент, скорее некоторые исторические причины + то что Common Lisp сильно навороченный и часто сложен в изучении не дают ему широко распостранится. А если учитывать все диалекты и встроенные языки лисп достаточно широко распространёт. Я видел много программ, которые используют те или иные диалекты лиспа, как внутренний язык.

Вот ещё интересная ссылка о мифах про лисп http://lisp.narod.ru/msg.html.

Курилка wrote:

> C>Кстати, можно. Для Питона мне показывали что-то подобное R# — с помощью
> C>скрипта обходили AST кода и добавляли трассировку вызовов определенной
> C>функции. Выглядело очень красиво, вспомню как называлось — напишу сюда.
> Ждём, сравним с defmacro

Это было сделано на основе (кажется),
http://www.logilab.org/projects/pyreverse или
http://www.python.org/doc/current/lib/module-parser.html, но сейчас тот
сэмпл не могу найти.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Кодёнок, Вы писали:

E>>Но может кто-нибудь внятно объяснить, почему, если Lisp такой супер-пупер, он всех остальных не задавил (за сорок-то лет существования)?
E>>Пока я получил один заслуживающий внимания ответ: Re[9]: Metaprogramming et al

Автор: CrazyPit
Дата: 13.07.05

. Из которого понятно, что Lisp -- это язык для чокнутых программистов (в хорошем смысле этого слова). И тогда понятно, что Lisp просто не сможет применяться в командах, в которых нормальные, а не чокнутые, программисты работают. А ведь каких команд большинство. В том числе и у нас в компании.

Кё>Может быть принципиальная интерпретируемость и соответственно, низкое быстродействие на современных "mov ax,bx"-машинах. Сейчас набирают популярность интерпретируемые языки, и Лисп "всплыл" опять.

Принципиальная интерпретируемость Лиспа — это в неправда. Есть много компиляторов Lisp (часть кода компилируется, часть выполняется на этапе компиляции). Элементарный пример — компилятор Scheme Gambit — была статья, в которой объяснялось, как написать простенький компилятор Scheme за несколько часов .

О быстродействии. Быстродействие реализации CLisp на целых числах сравнимо с Java, а CMULISP на равных с Java и при использовании плавающей запятой. Т. е. современные Лиспы работают примерно вдвое медленнее С++. Разумеется, писать быстрые программы на Lisp надо уметь — для начала не забывать давать аннотации типов.

Здравствуйте, pvgoran, Вы писали:

P>Здравствуйте, Трурль, Вы писали:

Т>>Хм, policy говорите. А вот это видели?
Т>>

Т>>(L|DEFUN, ISOMORPHIC, (L|TREE1, TREE2),
Т>>  (L|COND, 
Т>>    (L|(L|ATOM, TREE1), (L|ATOM, TREE2)),
Т>>    (L|(L|ATOM, TREE2), NIL),
Т>>    (L|T, (L|AND,
Т>>      (L|ISOMORPHIC, (L|CAR, TREE1), 
Т>>                     (L|CAR, TREE2)),
Т>>      (L|ISOMORPHIC, (L|CDR, TREE1), 
Т>>                     (L|CDR, TREE2))
Т>>))))
Т>>

P>А что это значит??

В пылу дискуссии участники незаметно перешли с русского на Липс, так как он дает больше выразительных возможностей чем любой другой язык.

Здравствуйте, pvgoran, Вы писали:


P>2. Студенты, привыкшие думать "на Паскале" (это ключевой момент!), не захотели/не успели понять, как правильно использовать незнакомый инструмент.


Вот именно, недавно провёл эксперимент, попробовал обучить человека, вообще ничего не знающего о программирование сначала питону потом scheme(ну схема то конечно намного проще CL, хотя в том что я показывал особой разницы нет), во втором случае результаты оказались намного лучше, так что дело тут именно в закостенелости мозгов.

Здравствуйте, Cyberax, Вы писали:

C>Курилка wrote:

>> C>Кстати, можно. Для Питона мне показывали что-то подобное R# — с помощью
>> C>скрипта обходили AST кода и добавляли трассировку вызовов определенной
>> C>функции. Выглядело очень красиво, вспомню как называлось — напишу сюда.
>> Ждём, сравним с defmacro

C>Это было сделано на основе (кажется),
C>http://www.logilab.org/projects/pyreverse или
C>http://www.python.org/doc/current/lib/module-parser.html, но сейчас тот
C>сэмпл не могу найти.

Без сэмла слабо понятно, что имеется в виду, чем это принципиально от того же рефлекшна в C# отличается? Через него тоже по идее можно преобразования над кодом выполнять, но по сравнению с лисповскими макросами...

Здравствуйте, Cyberax, Вы писали:

C>Однако у этого же преподавателя студенты вполне нормально разобрались с
C>Рефалом (преподаватель его тоже вместе со студентами учил).

я не знаю, что общего у него с Лиспом и чем они отличаются, поэтому не знаю, какие из этого можно сделать выводы

C>Кстати о квалификации — этот же преподаватель почти в одиночку пишет
C>софт для http://taxcalc.com (бывший http://taxchecker.co.uk — у них там
C>сейчас реорганизация, поэтому веб-версии недоступны) — систему для
C>подсчета налогов в Британии, ядро которой работает без изменений в
C>веб-версии и в stand-alone. В этой системе правила рассчета налогов
C>декларативно задаются в MathML, из которого потом генерируется
C>JavaScript-код для веб-версии и С++ для stand-alone, для каждого поля
C>генерируется скрипт, который вызывает пересчет зависимых полей,
C>валидацию и т.п.

хороший специалист != хороший преподаватель

Дарней wrote:

> C>Однако у этого же преподавателя студенты вполне нормально разобрались с
> C>Рефалом (преподаватель его тоже вместе со студентами учил).
> я не знаю, что общего у него с Лиспом и чем они отличаются, поэтому не
> знаю, какие из этого можно сделать выводы

Это язык, еще более извращенный: http://refal.ru/

В отличие от ЛИСПа, основу РЕФАЛа составляет сопоставление с образцом.
Благодаря этому типовая программа на РЕФАЛе вдвое-втрое короче по
объему, чем аналогичная программа на языке ЛИСП, и гораздо более
читаема. От ПРОЛОГа РЕФАЛ отличает концептуальная простота. Его
сопоставление с образцом работает в прямом направлении, а не в обратном
(начиная от цели), как в ПРОЛОГе. Это более естественный подход к
написанию алгоритмов, что делает их более легкими для тестирования и
отладки.

Далее, имеется существенное различие между структурами данных в РЕФАЛе и
в большинстве других языков высокого уровня. Основные структуры данных в
ЛИСПе и ПРОЛОГе — это */списки/*, которые могут читаться только в одном
направлении. РЕФАЛ использует более общие структуры. Вы можете строить
и читать их слева-направо и справа-налево и, конечно же, прыгать внутрь
и наружу по скобочным структурам. Это очень удобно для программиста.
РЕФАЛ дает свободу и удобство в создании структур данных наряду с
использованием лишь математически простых механизмов управления —
/*сопоставления с образцом и подстановки. */Это именно то, что нужно для
символьной обработки и для искусственного интеллекта.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Кстати, можно. Для Питона мне показывали что-то подобное R# — с помощью
C>скрипта обходили AST кода и добавляли трассировку вызовов определенной
C>функции. Выглядело очень красиво, вспомню как называлось — напишу сюда.

Есть стандартный модуль compiler который умеет строить AST по исходному коду и удобно его обрабатывать.

Здравствуйте, CrazyPit, Вы писали:

CP>Вот ещё интересная ссылка о мифах про лисп http://lisp.narod.ru/msg.html.

Ссылка интересная, спасибо. Но вот один настораживающий момент:

В то же время, для ПЕРЕМЕННОЙ указание типа данных, вообще говоря, необязательно. Это можно рассматривать и как преимущество, и как недостаток. Например, для функции max, которую в Лиспе можно для двух аргументов определить как

(defun my-max (x y) (if (> x y) x y)))

и это можно расценивать как благо. Ведь, к примеру, в C++ так определить максимум нельзя. Нужно использовать перегрузку (overloading) либо пользоваться макросами. В случае определения в виде макроса, неправильный результат даст вычисление

MAX(i++,j++), поскольку i и j будут увеличены дважды. При использовании overloading придется написать множество версий сравнения.

Очевидно, что о простейшей C++ конструкции

template <typename T>
inline T max(T a, T b) {return a < b ? b : a;}

автор никогда не слышал и оперирует он знаниями совсем древнего C++. А это есть минус статье, т.к. взялся сравнивать — разберись в вопросе.

Здравствуйте, CrystaX, Вы писали:

CX>Здравствуйте, CrazyPit, Вы писали:

CP>>Вот ещё интересная ссылка о мифах про лисп http://lisp.narod.ru/msg.html.

CX>Ссылка интересная, спасибо. Но вот один настораживающий момент:
[...]
CX>автор никогда не слышал и оперирует он знаниями совсем древнего C++. А это есть минус статье, т.к. взялся сравнивать — разберись в вопросе.

Там и еще было:

Помимо списков и символов, в Лисп есть отдельные типы данных для строк, массивов, хеш-таблиц, записей (структур), потоков ввода-вывода. Кроме того, стандарт Common Lisp включает в себя систему объектно-ориентированного программирования CLOS, далеко превосходящую по выразительным возможностям систему программирования C++. Для доказательства этого превосходства достаточно отметить, что есть возможность выбирать вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно определить четыре метода

(defmethod draw ((x sentence) (y screen)) (message-box x y)) ; для отображения сообщения на экране

(defmethod draw ((x sentence) (y paper)) (write x y)) ; нужно просто написать слова на бумаге

(defmethod draw ((x picture) (y screen)) (show-picture-in-a-box x y)) ; показываем картинку на экране

(defmethod draw ((x picture) (y screen)) (paint-picture-on-a-paper x y)) ; рисуем картинку на бумаге.

При вызове

>(draw my-data my-device)

выбор одного из четырех определенных методов будет динамически осуществляться в момент вызова. Это невозможно в C++, где пришлось бы делать draw либо методом общего предка объектов screen и paper, либо методом общего предка sentence и picture, а выбор кода по типу второго аргумента осуществлять с помощью анализа этого типа в конструкции if.

И еще пару перлов:

Например, легко ошибиться, написав (i==j || k==l) вместо ((i==j) || (k==l)), а в Лисп такая ошибка просто невозможна, потому что нужно будет написать (or (= i j) (= k l))

Т.е. запись (or (= i j) (= k l)) сразу понятнее, чем (i==j || k==l). Кстати, насколько я знаю, обе приведенные записи в C++ эквивалентны (т.к. приоритет сравнения выше, чем приоритет логического ИЛИ).

А так же:

Например, оператор if в C не возвращает значения, и, чтобы это обойти, была придумана операция ( ? : ). Было бы удобно, если бы оператор switch в C мог также возвращать значение, которое можно присвоить переменной после завершения его выполнения. В Паскале и Бейсике даже присваивание является оператором и не возвращает значения, поэтому нельзя написать a=b=с. В Лиспе в этом плане все гораздо удобнее. if возвращает значение. Одну и ту же конструкцию if можно использовать для ветвления алгоритма и для выбора значения по условию. Также возвращает значение и cond (аналог switch), и setf (аналог присваивания). Да и вообще, в Лиспе значение возвращается всегда, где это имеет смысл.

Как будто в C++ подругому .