LINUX.ORG.RU
ФорумTalks

Эрик Рэймонд неосилил лисп

 , , ,


0

7

Для (NOT NIL):

«CLOS уродская куча уродства», — сказал Эрик Рэймонд, после того, как обламался переписать свою тормозящую поделку с Python на Common Lisp, решив таким образом ускорить выполнение с помощью нативно-исполняемого кода.

Будучи, по его словам, гуру по лиспу в 80-х, он стал искать альтернативу и (внезапно, sic!) открыл для себя SBCL — одну из самых быстрых и популярных реализаций Common Lisp. До этого, по его признанию, после 80-х он писал исключительно только для Emacs-lisp. Для него это стало невероятно интересным снова погрузится в мир лиспа изучая мануал SBCL. Думая, что переписывание с Python на Common Lisp будет легким и быстрым, вскоре он столкнулся с отличиями обьектной системы CLOS от объектной системы Python, и вследствие этого, невозможностью перепистаь свою поделку без измениния ее архитектуры.

Он также пожаловался на отсутствие метода дампа объекта, аналогичного str() в питоне, и не смог найти его аналога (что уже подсказывает низкий уровень его владения CL) в лиспе. Ему намекнули на реализацию метода PRINT-OBJECT, но он привел какие-то мутные доводы, что это не то, хотя это то, что ему нужно было в первую очередь. Ну да ладно, недоучил — бывает.

Сам лисп и идея мультиметодов Эрику, по его словам, понравились, но не понравилась их реализация в виде CLOS.

Конец истории поучителен — Эрик соптимизировал алгоритмы в своей поделке, оставаясь на питоне, и производительность возросла в разы.

Для (NOT Т): http://esr.ibiblio.org/?p=4861

★★
Ответ на: комментарий от naryl

Как-то тип всё-равно должен быть известен, чтобы компилятор знал какую операцию использовать. Вариантов всего три.

3. При формировании значения переменной. Python-way.

ШИТО?

tailgunner ★★★★★
()
Ответ на: комментарий от naryl

Эм, в Python duck typing - неважно, какого типа объект, если он умеет «крякать», когда его об этом просят. Вот, скажем, такой код

a + b
Интерпретатор сначала обратится к методу, имплементирующему поддержку объектом стандартной операции сложения «+». Такие методы называются специальными, и их идентификаторы обрамляются парой символов подчеркивания в начале и в конце. В данном скучает это метод «__add__». Если у «a» нет такого метода, ищется сходный метод «__radd__» у объекта «b» (right add, значит) - т.е. если «a» не умеет «прибавлять к себе» ничего, проверяем не умеет ли «b» «прибавлять себя» к чему-либо. Если и эта проверка не приносит успеха, бросается исключение, что-то типа
>>> class x: pass
... 
>>> x + 2
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'classobj' and 'int'
>>> 
Вот так выглядят «типы» в Python. И Python way - это «все переменные суть ссылки на объекты», т.е. у переменных нет никаких типов, типы есть у объектов. Операция «=» это операция связывания идентификатора с объектом.

Единственное, если объект это атрибут или метод, то можно контролировать разными способами (до известной степени, невзламываемыми) доступ к этому объекту.

С точки зрения очевидности очевидно, что инстанцирование экземпляра класса неочевидно ни в плюсах, ни в питоне, учитывая возможность перегрузки операторов, пока не посмотришь на реализацию класса. Типизация здесь причем? :-) P.S. Я, если честно, не совсем понимаю, на какой вопрос отвечаю и ответил ли :-), но мало ли.

Virtuos86 ★★★★★
()
Ответ на: комментарий от naryl

Это определение операции в момент вызова. Не вижу разницы с CL.

tailgunner ★★★★★
()

Если он так плохо знает Lisp, но хорошо освоил Python, стоило ли ему метаться. Оптимизировать код на Python, где нужно переписать кое-что на C и всё будет работать. Python и Lisp слишком разные, что-бы вот так сгоряча переписывать проект с одного ЯП на другой.

lucentcode ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.