http://groups.google.com/group/clojure/browse_frm/thread/c3418875208d89e1/0f5b80483329c151?lnk=gst&q=declare+rich+hickey#0f5b80483329c151

http://groups.google.com/group/clojure/browse_thread/thread/a99b420d5ee0aa40/0fb7f2d1936735d1?l#0fb7f2d1936735d1

I appreciate the commentary in this article as it’s well put together and echoes my own feelings in certain circumstances. But, a few warts aside, I find very little to complain about with Clojure. It’s actually gotten me back into coding in my free time which I haven’t done in years.

Check out this binding-map macro to see how you can do this in Clojure. Uses some tricks that aren’t exposed as part of the language definition, but presumably we’ll see some of this open up as the language itself stabilizes.

Yep, looks like binding-map is pretty much the equivalent of PROGV.

As far as , vs. ~ in backquote is concerned, I find ~ to be much more intuitive now that I’m used to it. But that may be tom-a-toes vs. tom-ah-toes.

Likely so.

I’m sure it’s not the right dish for everybody (and it is still a young language with all the “best practices still being discovered” that that implies), but for me and a bunch of other folks who’ve been developing in it, it really hits the spot!

Considering its pace of development, it will be interesting to see how Clojure sits a year or two from now. Maybe a couple things from this list will have changed (and maybe there will be a couple new things to add). In any case, I’m glad Clojure is around.

Mark, much cleaner.

These are well thought out comments and things I’ve thought about as well while I’ve moved from CL to Clojure. Let me add some color from someone who has drunk a lot of the kool-aid:

1) Dynamic binding

Check out this binding-map macro to see how you can do this in Clojure. Uses some tricks that aren’t exposed as part of the language definition, but presumably we’ll see some of this open up as the language itself stabilizes.

2) Pre-declaring vars

Yeah, I agree with this complaint. Rich has explained why Clojure does it (but I can’t find a link right now), but it just *feels* wrong in a lisp-like language.

3) Keyword args

This is this way to support super-fast calling into Java-land (no translation required). It’s pretty easy to wrap, but as you point out it would be nice to have wraps for all the ways you define things that take arguments.

4) Commas are whitespace

I’ve found that I’m happy to be able to use commas for grouping (esp. in tables, as you point out). They’re used at the discretion of the author and really don’t take up very much space.

As far as , vs. ~ in backquote is concerned, I find ~ to be much more intuitive now that I’m used to it. But that may be tom-a-toes vs. tom-ah-toes.

5) Type specifications are ugly.

I completely agree. This happens because type specifications use the super-general metadata annotation syntax. Perhaps we’ll get some cleaner syntax in a future revision.

As you point out, you don’t need type specifications too often anyway and Rich has hinted in various talks that he’s thinking of ways that you’ll need them less in the future.

6) All the good names are taken

I also see this problem with the names.

On the other hand, the switch to Lisp-1 has been a real breath of fresh air. As you say, this is an old debate, but Clojure is the first time in a very long time that I’ve used a Lisp-1 and the idea that a function is just a regular value that a variable can have really cleans up both my mental model of what’s happening and the syntactic expression of it.

7) Conclusion

I’ve been *completely* taken with coding in Clojure. While there are things I miss from CL, the elegance and taste with which Rich has combined the mechanisms of modern programming continues to astound me.

I’m sure it’s not the right dish for everybody (and it is still a young language with all the “best practices still being discovered” that that implies), but for me and a bunch of other folks who’ve been developing in it, it really hits the spot!

(let [#^Integer a 2
      #^Integer b 3]
  (list a b))

use:

(let [a:Integer 2
      b:Integer 3]
  (list a b))

Just a couple small corrections:

(let [a #^int 5] a) ;incorrect

The #^ is used only for Java classnames, not primitives. This is part of the difference compared to (int 5).

(let [a #^Integer x] a) ;hint that x will always return an instance of Integer

Thanks! This is something I did not know. It’s curious that there is no compiler warning.

Also, (cons 2 3) doesn’t make sense, since (seq 3) is an error.

Whoops! Some Common Lisp snuck in there.

Finally, I’m not quite sure if I understand the details of PROGV. Have you looked at Clojure’s Var/pushThreadBindings? It’s what the binding macro uses, and may be sufficient to allow a macro to implement what you want.

I have not — an external commenter noted a similar thing, and referred to this code. Likely Var/pushThreadBindings is exactly the piece that’s needed to support PROGV.

(cons 2 3)

makes sense to CL programmers, as cons cells are pairs, not necessarily lists. (Sure, lists are cons cells of cons cells or NIL… but that is not the only structure you can build with them.)

It’s common to use non-list cons cells as association lists:

'((foo . bar)(bar . baz)(baz (quux gorch))

. The advantage that

(cdr (assoc ...))

always gives you the data.

Dunno how this works in Clojure, but it would sure be weird to not have cons cells that can hold arbitrary objects in both the car and the cdr.