I know your feeling, I've programming in Clojure for one year now (although I don't have time to program with it full time). I think your kind of problems are more related on "how" you use Clojure rather than Clojure itself. Errors are obscure only if you try to do too much things in one function. Try to keep functions as simple as possible and to do one task per function, no more. Then message errors are not that hard to figure out, although yes, I agree that for example in Java errors are easier to figure out (but definitely not fixing them...). And anyway using the REPL you can test one function at a time, given it's a pure function, which is also a new state of mind: eliminate all possible mutable state.

I've found that when using Clojure you have to think in a different way about the problems to be able to "see" how your problem can be resolved in Clojure in a more elegant and concise way. This is hardest task I've found when moving to Clojure from Java: change your mind. With the right mindset, everything (in my case at least) seems like pretty trivial in Clojure, and definitely much faster to code and test than Java.

I can so related to this. Thank you for articulating the problem (I thought I was just doing it wrong). To elaborate on what you're saying in pseudo code, imagine writing this in algorithm in clojure:

    take a collection -> split by is-even? -> for each collection, sort ascending -> take the first of each collection

This is the level of abstraction I want to think about. But, when one of these functions takes or returns something you don't expect, debugging the problem usually took me 30 minutes. The error messages were very opaque to me.

I could never figure out a good work flow to debug these problems. I still feel like there's something I'm doing wrong. People on IRC tell me you eventually understand the errors better, they're just confusing at first. I never got to that point though.

Am I missing something here or is the algorithm you describe simply: "Find the smallest even and odd number in a set of numbers?" This shouldn't be hard to do in any language.

That's exactly what it is and I agree. Clojure is awesome because you can almost write the actual code just the pseudo code.

> But, when one of these functions takes or returns something you don't expect, debugging the problem usually took me 30 minutes. The error messages were very opaque to me.

>you can almost write the actual code just the pseudo code.

Yes, often true. E.g. in this case:

  (->> [2 3 4 7 5 3 11 12 7] ;collection
     (group-by even?)        ;get a map of evens and odds
     vals                    ;get just the values
     (map sort)              ;sort them
     (map first))            ;first is smallest

(disclaimer: there's probably prettier ways to write this - I was just trying to keep it simple)

I agree that there are sometimes inscrutable errors. For me it's often because of a type conflict between a function and what it's operating on.

Example: I'm a little rusty and when I tried to quickly code the example above I did this:

  (->> [2 7 5 3] (partition-by even?) vals)

And got:

  ClassCastException clojure.lang.Cons cannot be cast to java.util.Map$Entry  clojure.lang.APersistentMap$KeySeq.first (APersistentMap.java:152)

Doh! I wanted "group-by". And partition-by doesn't make a map! But why this specific error? Frankly I'm not sure. I'd probably have to look at the source. My sin of course was trying to compose operations in one go, rather than build them up by baby steps in the REPL. I don't think the errors ever get that much more readable, but you start to recognize the category of error you've made by the type of error that's thrown.

Spending time on 4Clojure is very helpful to build your intuition for this.

You can make that somewhat more close to the correct computation, you don't need to sort the lists, you just need min values.

  (->> [2 3 4 7 5 3 11 12 7]
       (group-by even?)
       vals
       (map #(apply min %)))</pre>

However, operation like this can be made much more readable if you actually use variables like this:

  (defn min-even-odd [xs] 
    (let [evens (filter even? xs)
          odds (filter odd? xs)] 
       (list (apply min evens) (apply min odds))))

  (min-even-odd [2 3 4 7 5 3 11 12 7])

Which is a bit longer, but I think it makes more sense.

To address one of your points, I've found it much easier to get a complex line of clojure code working since I started using the InstaREPL in LightTable.

It shows the REPL output of each line of code as you write it, which is spectacularly handy.

LightTable is nice, and I eagerly await some stability. But I somehow foobar my session and have to restart the repl all the time. Slow as hell.

Not to mention, LightTable started out as something special and morphed into something mundane. I have high hopes that it was just organiziation and the cool shit we saw at the begining will come back via plugins, but right now it's just not there compared to vim or emacs.

Care to explain about LightTable starting special and morphing into the mundane? I've checked out a few versions along the development cycle and I wouldn't say that's the case.

Also, it's not "foobar", but FUBAR: Fucked Up Beyond All Recognition/Reason/Repair.

Go look at early versions. The concept of files was secondary for example. Program flow meant something. Not it's just a text editor. I am hopeful big changes are coming though.

They are :)

You are generalizing your experience and treating it as though it were some universal truth. I am far more productive in clojure than in go.

your post is recursive.

No, it is a counter point. Demonstrating that all you can glean from someone's personal experience is their personal experience, not some universal truth about the languages.

That's a bit facile. The evidence for "universal truth" comprises many data points, of which DigitalJack's is one, and yours is one. It's not that the approach is invalid or the anecdote uninteresting, but that these are samples of size one (i.e. anecdotes) and hence insufficient for inference.

Yeah, that's what I was saying. He is taking his personal experience, and generalizing it as if it were a universal truth. That's why I said exactly that.