[yakshaving_jgt]

Your flippant comment is not constructive, nor is it very accurate in my experience.

The last Clojure team I worked with decided to add “rop” to our project. The documentation in this library seems to go to great lengths to avoid using the word “monad”, despite the fact that the entire idea being encouraged by this library is monadic composition, but specialised to the Either monad. I mean come on, this library even takes its bind operator from Haskell.

These Clojure programmers were not Haskellers. They were just as indoctrinated as any other Clojurists and probably would have made the same flippant comment that you did.

And yet, here we are.

> clojure and haskell end up being pretty close.

In terms of the cost of building a software business, this has not been my experience. In my experience, the cost of building software at a scale beyond trivial is higher with Clojure than it is with Haskell.

[nimih]

I'm not sure I follow your complaint about "rop" (which is a library I'm not familiar with), and I suppose my jokiness obscured the point I was trying to make, so I'll try reiterating, since it seems like you're talking past it (I will also try to address the points you raise).

First, to be clear, haskell's type system is powerful and interesting and useful, and clojure's lack of good static analysis tools IMO represents a serious [comparative] deficiency in the ecosystem (and spec is obviously no substitute). I don't think that it will ever be possible for clojure to get even close to the sort of compile-time checking/guarantees that haskell offers, nor do I think clojure is particularly well-suited for the powerful higher-level abstractions that you see in e.g. lens or recursion-schemes (or, honestly, even Control.Traversable). My personal experience (both as a hobbyist and professionally) has been that there are some practical advantages from clojure's dynamism such that it probably makes sense (in a cost/benefit sense) to eschew static typing in some/many circumstances, but I really only have anecdotal evidence plus some intuition backing that up.

That aside, the point I was trying to get at was that both haskell and clojure encourage you to build complex data representations out of simple, easy to understand, composable, persistent structures, and then build up computations by composing pure transformations on them. Additionally, both languages have reasonable concurrency models/primitives, good tools for creating expressive DSLs (if that's your thing), and powerful interactive development environments. I, personally, find all of these features to be incredibly important for effectively developing software--they shape in a very real way the processes I use to plan and write and debug code--and most languages in common use today lack at least a couple of them (some languages have none of them, in fact).

[yakshaving_jgt]

Ok, thank you for clarifying.

Frankly, it’s not often I hear a rational argument like this in a typical Haskell vs Clojure debate. Usually I just hear zealotry and a refusal to address Clojure’s shortcomings, just like in the Robert Martin blog post. In fact come to think of it, many of the other comments on this thread which are replies to criticisms of Clojure are along the lines of “well, maybe you just didn’t try hard enough. Maybe you failed. It’s not the system that failed. Clojure is too perfect to fail.”

This kind of rhetoric is frighteningly similar to that used in multi-level marketing.

I won’t deny Clojure’s benefits. They are there, and I did say in another comment that Clojure is one of the most sound dynamic languages. But I don’t think everyone is honest like you were just now about its drawbacks. Robert Martin certainly isn’t honest about it.