Hacker News new | past | comments | ask | show | jobs | submit login

> no TCO

Neither does Emacs Lisp nor ABCL. Yet they are Lisps by your definition.

> different approach about side effects (-> avoid)

Though not precluded. You can write Clojure with side-effects, but to do so you need to be explicit about it.

> different idea of OOP (-> avoid)

Which says nothing about the language or its Lisp-nature. Clojure has generic dispatch with multimethods, supporting runtime polymorphism. As you say later, "OOP" is meaningless since it's definition is vague, so using this as a reason for Clojure to not be a Lisp is odd.

> Just think of it: zero lines of code is shared.

Are saying that a lisp is only a 'Lisp' if you can freely share code between them? Without modification? If the names used for functions aren't the same, then that disqualifies it from being a Lisp?

Your position seems to be that unless the lisp is a direct descendant of Lisp 1.5 then it cannot be called a Lisp. In addition to Clojure, this disqualifies Scheme (and its dialects.)

Different Lisps (by your definition) take different approaches to things like namespace separation (Lisp-1 vs. Lisp-2) and scope (dynamic vs. lexical). These differences can be subtle and lead to hard to find bugs when sharing code.

> My problem with that broader idea of 'Lisp': it is fully vague and it has no practical implications.

Yet you have put a stake in the ground and defined the broad idea of 'Lisp' as an entity that shares its roots with the ideas in MacLisp.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: