Hacker News Reader

Comment by nickbauman | Hacker News Reader

I think the hardest thing for people to get for programming in Lisp is the immutability. Once you get over that hump, everything is downhill. From the outside, the parenthesis seem pedantic but it's completely superficial. You will stop noticing them in a few hours, if not days.

View on HN

Are you perhaps coming from a Clojure perspective? Scheme is no more inherently immutable than, say, JavaScript. Many Scheme programs I've seen use mutation quite liberally. Immutability is a useful pattern in lots of languages and situations, but Lisp per se doesn't particularly enforce it.

Indeed. Common Lisp is similar with regard to the proliferation of mutation.

It in fact takes it to amusing extremes, allowing you to mutate even the strings associated with symbols.

    (setf (char (symbol-name nil) 1) #\U)

(Though I guess that could be taken as being the same thing as doing nonsensical pointer arithmetic in C -- you simply should know better.)

I'd point out that Common Lisp, kind of like Smalltalk, is a highly dynamic environment that has historically been used as an operating system in itself. That's one reason why the system is so mutable—you don't want to have to relaunch it even to modify core functionality.

I actually don't view mutation in Common Lisp as a downside. I find writing high performance (usually numerical, but sometimes not) code in Clojure to be painfully obtuse compared to Common Lisp, but I love Clojure otherwise. Writing highly optimized code can be quite elegant in Common Lisp, and I appreciate that when the problem at hand calls for it.

Actually, this expression is non-conforming: you must not try to modify the string returned by cl:symbol-name.

"non-conforming" means you will get different results in different implementation, perhaps something like a nasal dragon, or perhaps an error signaled, or perhaps some more benign behavior.

    $ clall -r '(progn (setf (char (symbol-name nil) 1) #\U) (quote nil))'
    CLISP                          Attempt to modify a read-only string: "NIL" 
    ECL                            Detected access to an invalid or protected memory address.
    Clozure Common Lisp            --> #|symbol not found in home package!!|#COMMON-LISP::NUL
    Armed Bear Common Lisp         --> COMMON-LISP::NUL
    CMU Common Lisp                --> COMMON-LISP::NUL
    SBCL                           --> COMMON-LISP::NUL

Some implementations will gladly and blissfully modify the symbol name, and your program will break because it cannot intern the original name anymore (not the best behavior for an implementation IMO); some implementation will detect the non-conforming access. Worse could have happened (remember, you are on the Internet so you can be located by geoip/gps/wifi, and missiles silos can be hacked by botnets).

But otherwise indeed in general, mutable lisp objects are mutable, and you can implement mutating algorithms as well as purely functional algorithm. Foremost, you can have an hybrid approach, using what's best to solve the current problem.

Racket also defaults to immutable cons and you have to require set-car! and friends. But I agree, most Lisps do not impose/favor immutability

Ah, right, but that doesn't mean the language is immutable to the degree that it would make for a steep learning curve. Mutating cons cells is arguably an obscure feature; you are free to mutate variables, vectors, structs, tables, and so on (even if you might have to specify that you want mutability).

My experience with racket is certainly not one of steep learning curve. Plus it is _thoroughly_ documented. If I had to recommend a Lisp implementation for someone that wants to learn a Lisp it would definitely be Racket as it is easy to install (and works on windows), has great documentation and a super friendly and interesting community.

The only thing I'm not fond of Racket is that compared to CL w/ Slime it feels way less interactive, a step up from Python, but still not CL (nor Smalltalk)

But lets focus on the positive, the OP is highlighting that the trite criticism of non-lispers about parens is bogus.

Perhaps I am but even Clojure is not "purely functional" in that respect.

Lisp is not an immutable language.

There's setf and setq for assigning; nconc, nsubst, and the destructive list operations; rplaca and rplacd; etc.

It's easy to write Lisp that doesn't mutate (let), or use constructs that hide it (dolist, dotimes, etc.), but mutable data has been in Lisp since the beginning.

That said, there are languages in the family that don't allows mutation, but they're a small minority.

Clojure isn't immutable either. It favors immutability, though, and has strong opinions directing the developer away from mutable state.

Reply on news.ycombinator.com