If you want to get shit done, and make sure the types are correct, and make sure all side effects are properly managed and accounted for, that's Haskell's niche.
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.
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).
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.
Dont Clojure's immutable types handle the side-effect issues well? Without the contortions that Haskell puts you through.
But there are many more side effects than changing variables. Clojure makes no guarantees that a given function is referentially transparent, nor does it promise that a given function doesn't write to stdout/stderr, read from stdin, change the file system, make a network connection, send missiles to foreign countries, etcetera.
https://clojuredocs.org/clojure.core/io℅21
The 'io!' macro marks a code block to have side effects which prevents using it in a STM transaction as 'dosync' might need to execute the functions multiple times in case of conflicts during the optimistic locking.
In the sense C programmers use the term? Why should humans be trusted with identifying all operations that can't be safely performed within a transaction?