Типичные ошибки при написании Лисп-кода

Здравствуйте!
Скажите пожалуйста, какие вы можете назвать типичные ошибки при написании кода на Лиспе?
Чего следует избегать в первую очередь?
Очень хотелось бы составить список, да побольше.
Заранее спасибо!

0

Сообщение от chessman2 Имеете какое-то обоснование, так считать ?

Очевидно же. Если использовать список как последовательность (типа "найти наибольший элемент в списке чисел"), то проход по нему циклом - O(1) по памяти, а рекурсией - O(n). Если нет разницы, зачем платить больше? Поэтому и в гугловском руководстве по стилю написано, что не используйте рекурсию без нужды.

1

Сообщение от helter Поэтому и в гугловском руководстве по стилю написано, что не используйте рекурсию без нужды.

Lisp может реализовывать многие хвостовые рекурсивные вызовы функции внутри как циклы
и избегать накладных расходов памяти стека при вызове функции.

При прочих равных условиях итерации и рекурсии,
скорее всего выберу рекурсию

1

Сообщение от chessman2 Lisp может реализовывать многие хвостовые рекурсивные вызовы функции внутри как циклы

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

1

helter, А как заставить оптимизировать?

0

Сообщение от Regrin1 А как заставить оптимизировать?

Можете эту умную разработку попробовать.
https://gitlab.common-lisp.net/frideau/ptc

0

helter, вот что написано в документации по SBCL:

5.3.4 Debug Tail Recursion The compiler is “properly tail recursive.” If a function call is in a tail-recursive position, the stack frame will be deallocated at the time of the call, rather than after the call returns. Consider this backtrace

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

Добавлено через 14 минут
вот я нашел статью по оптимизации хвостовых вызовов
https://0branch.com/notes/tco-cl.html
там сказано что sbcl точно будет оптимизировать все хвостовые вызовы глобально если задать
(declaim (optimize (debug 0) (safety 0) (speed 3)))

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

а вот что бы отменить эту оптимизацию надо поставить debug > 2 (из документации по sbcl)

2

Значит, был неправ. Мне казалось, нужно выставлять какие-то недефолтные debug и safety.

1

Catstail, вернемся немного к "изобретению велосипедов". Вот нашел интересное замечание в книге Идеальная Архитектура

Одной из самых неприметных, но серьезных проблем Мегаполиса было дублирование кода. Без четкой архитектуры и четких правил размещения функциональности программисты постоянно «изобретали велосипед» по всей кодовой базе. Простые операции, стандартные алгоритмы и структуры данных повторялись во многих модулях, причем каждая реализация обладала собственным набором неприметных ошибок и странностей. Более масштабные аспекты, такие как внешний обмен данными и кэширование, тоже были реализованы многократно.

0

Сообщение от IisNuINu Идеальная Архитектура

Хорошее название, что это за книга?

0

IisNuINu, да, дублирование кода - это плохо. Но проблема-то не в "велосипедах" как таковых, а совсем в другом: Без четкой архитектуры и четких правил размещения функциональности программисты постоянно «изобретали велосипед» по всей кодовой базе.. Против этого трудно возразить. Да я с этим и не спорю. Создание масштабных проектов должно базироваться на четкой архитектуре и правилах.

Я бы сформулировал свое "кредо" так: недопустимо, чтобы "чёткие правила" убивали креативность. Вы не согласны?

Добавлено через 7 минут

Сообщение от helter Хорошее название

- особенно, если учесть, что все, что сделано человеком - не идеально.

0

helter, так и называется Идеальная архитектура ведущие специалисты о красоте программных архитектур, Диамидис Спинеллис и Георгиос Гусиос.

Добавлено через 12 минут
Catstail, да я согласен. креативность это важно. но её важно проявлять вовремя и по месту. в той задаче которая перед вами стоит, возможно в той которую вы сами себе поставили. Но не возможно писать сколь нибудь значимую систему с нуля, с голого языка программирования. Вернее можно, но это займет много времени. ОЧЕНЬ много. и до решения самой задачи, той самой которая перед вами стоит можно и не дожить, погрязнув в решении мелких проблем, написании вспомогательных библиотек, которые возможно ктото уже решил.
Вот если их нет, то да, тут самое время проявить свою креативность и способность к программированию, как это сделал Баггерс, для занятия графикой написавший библиотеку cepl.

Я когда решил заняться лиспом, перевел две на мой взгляд основные документации по библиотекам: asdf и cffi.
Почему!? Потому что они являются ключем к использованию мирового опыта программирования на языке лисп.
cffi дает интрефейс к сторонним библиотекам, asdf дает интерфейс к системам написанным на лиспе.
Основной мой тезис, что начинающие не умеют использовать мировой опыт программирования, и его игнорирование
это ошибка! А чтобы его использовать его надо изучать, изучать не менее тщательно чем теорию программирования и
построение алгоритмов.

2

Сообщение от IisNuINu Но не возможно писать сколь ни-будь значимую систему с нуля

- я за это и не ратую! Поймите, наконец: креативность и стандартизация важны по-своему. Но они немного друг-другу противоречат. Очень важно соблюсти баланс.

Грамотный (в моем понимании!) программист - это тот, кто знает структуры данных и алгоритмы. Знание библиотек вторично.

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

PS

Я уже приводил на Форуме этот пример. Читали "Таинственный остров" Ж. Верна? Сайрес Смит сумел построить цивилизацию, потому что обладал фундаментальными инженерными знаниями. Современный "инженер" (зачастую не знающий даже сопромата - зачем? Все знает программа...) попади он на этот остров, жил бы в пещере и питался ракушками!

0

Сообщение от Catstail Я уже приводил на Форуме этот пример. Читали "Таинственный остров" Ж. Верна? Сайрес Смит сумел построить цивилизацию, потому что обладал фундаментальными инженерными знаниями. Современный "инженер" (зачастую не знающий даже сопромата - зачем? Все знает программа...) попади он на этот остров, жил бы в пещере и питался ракушками!

И что? При этом современный инженер приносит больше пользы современной цивилизации, чем древний. Приводить фантастическое произведение в качестве примера чего-либо --- такое себе. Как и гипотетические ситуации.

И да, не каждому инженеру нужен сопромат. Зачем?

0

korvin_, Я рассуждаю с моей (индивидуалистической) точки зрения. Я хочу быть похожим на С.Смита, а не на современный гибрид инженера с офисным клерком.

А мои оппоненты, как я понял, рассуждают с точки зрения так называемых "потребностей общества". И каждый прав по-своему. Например, "инженеру по технике безопасности" сопромат действительно не нужен.

0

Сообщение от korvin_ И что? При этом современный инженер приносит больше пользы современной цивилизации, чем древний.

Почему вы так решили?
Постройка аквидука для снабжения поселения водой - это несомненная польза.
Разработка айфона - это пустушка, выдаваемая за достижение.
Если говорить о строительстве мостов, зданий, машин, то тут сопромат в самый раз)

0

Говорят интернет все знает, а я вот попытался найти песню студентов бауманки по словам и не нашел, но первые слова такие:
"Дана вам балка, в ней все силы поперек.
А я и балку, а я и балку, а я и балку,
рассчитать не смог"

Catstail,
В данном контексте упоминание сопромата лишь усиливает мою аргументацию. потому как знание и изучение сопромата для инженера, это то же самое, что для программиста еще одна БИБЛИОТЕКА которую надо знать. В противном случае выпускник, будет при построении конструкции заниматься изучением прочностных характеристик материалов и ставить эксперименты с точки зрения общих знаний физики, над различными материалами, в то время как от него лишь требуется применить знания сопромата.

0

IisNuINu, сопромат - это дисциплина, а не "библиотека". Сопромат для инженера - то же, что понимание алгоритмов для программиста. Так Вы и математику объявите "библиотекой". Не стоит "гнуть мир" под свою картину. Я выхожу из дискуссии.

0

Сопромат нужен, но редко. Как бывший инженер-конструктор
это могу сказать.
Типа прикинуть расчет балки. Знаю что выдержит, но...
... полагание на существующие конструкции.
новую волшебную палку - изобретать долго и дорого.

0

Сообщение от chessman2 Как бывший инженер-конструктор

А почему бывший? Неправильно рассчитали? хи-хи-хи)

0

сменил профессию снова ))

0