Hacker News new | ask | show | jobs
by StavrosK 4189 days ago
I just started learning Clojure, so I don't really understand this article very well. Is Clojure significantly different from other LISPs (e.g. Racket)?
4 comments

The author of this article is straining logic to argue that Clojure is not a functional language. It's true that Clojure is not a purely functional language, but most people should already know that. Unlike Haskell, Clojure allows side affects in code. It exposes the underlying Java platform 'transparently' which is definitely imperative. In that respect it's not too much different from other Lisps which allow side affects and generally have an FFI of some sort for working with imperative code written in other languages.

Unlike other Lisps, though, Clojure's core semantics are very strongly functional. All of Clojure's core data structures and types are immutable and to have mutable state you need to resort to reference types with special semantics to have mutable state. It would be uncomfortable to write Clojure code in a primarily imperative fashion. Common Lisp by contrast has no problem with imperative code or mutable state.

Ah, thanks. It does look pretty functional from my limited experience so far, plus I think these debates are very academic. You can write purely functional Python if you want, it's just going to be neither easy nor practical.
No, and there's nothing wrong with this.

Actually - I didn't read the article very carefully, so I may be completely wrong here - it looks like the OP uses a bit incorrect term. To me it looks like the word he wants is "applicative", and the opposition to it would be "concatenative" (see: http://evincarofautumn.blogspot.com/2012/02/why-concatenativ...).

"Imperative" is usually contrasted with "declarative" (and not with "functional", which TFA seems to suggest) and in practice most languages are imperative to some degree, even the ones which are said to be "declarative" are most often not purely so (but see Datalog).

Not in this respect, no.
No.