> ... Clojure is fine (though any other Lisp would arguably be better than Clojure).
Care to elaborate why you think any other Lisp is better than Clojure? I would like to hear your arguments.
Care to elaborate why you think any other Lisp is better than Clojure? I would like to hear your arguments.
* TIMTOWTDI. Doing everything with map/reduce/filter is great, but sometimes it's more direct to just use the LOOP macro. Immutability is great, but sometimes it's way faster to just SETF something (and not have to worry about atoms).
* Batteries (more) included. IME, I find myself needing to use third-party libraries sooner with Clojure than with CL. Also, QuickLisp is arguably faster to get rolling with than Leiningen (I've found it easier to get the new library into my existing lisp image). And CL tends to have clusters of functions that do similar-but-different things, whereas Clojure puts the cognitive burden on you to do things right (example off the top of my head: CL has REMOVE, REMOVE-IF, and REMOVE-IF-NOT, Clojure has ????? (like ten different ways, I'm serious), `(filter pred list)`, and `(filter (complement pred) list)`).
* The debugging situation is fantastic. Both because CL deals with errors a lot more gracefully than Clojure (are we allowed to blame the JVM?) and because SLIME >>> CIDER, at least for now.
My take on the 'versify' example in 4 lines:
(for [book book-order
chapter (range 1 1000) :when (get-in bible [book (str chapter)])
verse (range 1 1000) :when (get-in bible [book (str chapter) (str verse)])]
[book chapter verse (get-in bible [book (str chapter) (str verse)])])
One of such patterns is when I have to accumulate multiple kind of things while I zip through the input. Somewhat contrived example: You have a hashtable that maps integer key to a list of strings. You want to scan it just once and build two lists, strings associated with odd keys and strings associated with even keys.
;; populate input
(defvar input (make-hash-table :test 'eql))
(setf (gethash 1 input) '("ichi" "hi"))
(setf (gethash 2 input) '("ni" "fu"))
(setf (gethash 3 input) '("san" "mi"))
(setf (gethash 4 input) '("yon" "shi" "yo"))
(setf (gethash 5 input) '("go" "itsu"))
;; loop
(loop for k being each hash-key in input
when (oddp k) append (gethash k input) into odds
when (evenp k) append (gethash k input) into evens
finally (return (values odds evens)))
; => ("go" "itsu" "san" "mi" "ichi" "hi") and ("yon" "shi" "yo" "ni" "fu")1. You could add "using (hash-value v)" in the iteration clause to directly have the value (no gethash).
2. There is maphash too.
As far as collections go, there's filter, remove, reduce, and various take functions. I don't see the deficiency.
Debugging is still an issue, but I personally don't find it too difficult... probably because I'm used to it.
The whole point of benefiting from immutable data structures is their ubiquity. If they're something you reach for only when you personally decide you need them, they're unlikely to work well with 3rd-party code; you will have to do a lot more digging to understand how the code you're writing will behave in a concurrent context vs having it be obvious. Making it opt-in is almost making it pointless, unless you never use 3rd-party code.
(0) The compiler can automatically perform optimizations like fusing small nodes and hash consing.
(1) The garbage collector can take advantage of the fact that traversing (the immutable portion of) the heap sequentially produces a topological sorting of the object graph.
I actually really like recur because it signifies intent. It tells the future-me that I intended for this function to be tail recursive (ie, it not being tail-recursive should be considered an error).