Может кто-нибудь объяснить мне дизайнерские решения, стоящие за Autolisp / visual lisp?

Question

Интересно, кто-нибудь может объяснить логическое обоснование дизайна следующих функций autolisp / visual lisp? Мне кажется, они бросают вызов принятой практике программного обеспечения ... я что-то упустил?

• По умолчанию все переменные являются глобальными (т. Е. Если не помещены после / в аргументах функции)
• Чтение / запись данных из autocad требует помещения материала в список ассоциаций с большим количеством магических чисел. 10 означает координаты x / y, 90 означает длину списка координат, 63 означает цвет и т. Д. Хорошо, вы можете хранить их в некоторых константах, но это будет означать еще больше глобальных значений, и документация побуждает вас использовать магические числа напрямую.
• Lisp - это язык функционального стиля, который поощряет программирование путем рекурсии по итерации, но хвостовая рекурсия на самом деле не оптимизирована в визуальном шумихе, что приводит к ужасным стекам вызовов - если, конечно, вы не выполняете итерацию. Но синтаксис цикла очень ограничен; например Вы не можете выйти из цикла или вернуть значение из цикла, если не установите какой-либо флаг в условие завершения. Результат, безобразный код.
• Как правило, вы вынуждены объявлять переменные повсеместно, что бросает вызов функциональному программированию - так зачем использовать функциональный (-ish) язык?

Answer 1

Лисп - это не язык, это группа иногда удивительно разных языков . Схема и Clojure являются функциональными членами семьи.Common Lisp и более специализированные породы, такие как Elisp, не особенно функциональны и по своей природе не поощряют функциональное программирование или рекурсию.CL на самом деле включает в себя очень гибкую объектную систему , чрезвычайно гибкую итерацию DSL и не гарантирует оптимизированные хвостовые вызовы (диалекты Scheme делают, но не Lisps в целом; это ловушкадумать о «Лиспе» как об одном языке).

Теперь, когда мы это выяснили, AutoLisp - это реализация 1986 года, основанная на ранней версии XLISP (самая ранняя из которых была опубликована в 1983 ).

Причина, по которой это может противоречить принятой в настоящее время практике программирования, заключается в том, что она предшествует принятой в настоящее время практике программирования.Следует также помнить, что самый дешевый нетбук, доступный сегодня, на в несколько сотен раз мощнее, чем тот, на который программист мог рассчитывать получить доступ в середине 80-х годов.Это означает, что даже если данная функция была признана превосходной, ограничения ЦП или памяти могли помешать ее реализации на коммерческом языке.

Я никогда не программировал специально для Autolisp / Visual Lisp, и цитируемый вами материал звучит чертовски раздражающим, но он мог иметь некоторое преимущество в производительности / памяти, которое оправдывало его в то время.

Answer 2

Если я правильно помню, AutoLisp - это форк из ранней версии XLisp (некоторые источники утверждают, что это был XLisp 1.0 (см. эту статью C2 ).

XLisp 1.0 - это 1-клетка (функции и переменные имеют одно и то же пространство имен) с некоторыми довольно странными странностями.

Answer 3

Вы можете добавить динамический обзор в микс, кстати, и если вы не знаете, что это такое, считайте себя счастливчиком. Но на самом деле не все ваши четыре пункта так важны для ИМО:

• "Необъявленные переменные создаются автоматически как глобальные." То же, что и в CL, не так ли (через setq)? Другой вариант - потерпеть неудачу, и он не очень привлекателен для языка, который предполагается использовать для сценариев quick-n-dirty.

• "магические числа" - это DXF-коды, которые, как вы правы, являются большим неудобством, поскольку они имеют тенденцию изменяться с изменением версий ACAD иногда (к счастью, редко). Вот только как это. Исправление этого потребовало бы серьезного пересмотра, введения некоторых "схем", а что нет, и почему "они" беспокоятся? AutoLISP был оставлен в своем состоянии примерно с 1992 года, и с тех пор никогда не беспокоился. Visual LISP сам по себе является совершенно другой и гораздо более функциональной системой, но все это заблокировано для обычного пользователя и предназначено только для одной цели - максимально точно эмулировать старый AutoLISP (кроме случаев, когда в него добавлены новые функции, связанные с VBA). во второй половине 1990-х годов и с тех пор был заблокирован).

• (while (not done) ...) - это не , что безобразно. Нет никакой гарантии оптимизации хвоста, да, точно так же, как в CL и Haskell ее нет (последний действительно меня смущает - нет гарантированного способа кодировать цикл в Haskell в постоянном пространстве без монад - как насчет этого?).

• «Вы вынуждены объявлять переменные повсюду», здесь я не следую за вами. Вы объявляете их, где должны были объявить - во внутреннем списке аргументов функции. Какие еще места ты имеешь в виду? Я не знаю ни одного.

На самом деле самым большим камнем преткновения в AutoLISP является его динамическое разрешение имен IMO, но так оно и было в Xlisp, всего через несколько лет после появления Scheme. Кроме того, это его неизменное хранилище данных, но это было сделано главным образом для простоты реализации и предотвращения слишком большой путаницы и, следовательно, вопросов со стороны пользователей, я думаю.