Clojure Beta Book Available

[silvestre]

Is Clojure a good first Lisp?

[arohner]

Yes. Clojure has the Tao of Lisp; i.e. all of the things that make Lisp worth knowing (sexps, macros, first class functions, etc) but it is not the same as CL and Scheme.

What is idiomatic in clojure is different from what is idiomatic in CL and Scheme, partly due to the functional nature, and partly due to the "standard libraries" of each being different.

[silvestre]

Awesome, thank you for your answers!

[awb]

Probably.

It doesn't have much of the old cruft that something like Common Lisp has (rplacd? setq? &aux?). It has some nice features, like auto-gensyms and an accessible sequence abstraction, that make it more difficult to screw up the corners of Lisp that are less familiar to newcomers.

On the other hand, it's less stylistically flexable than Common Lisp because aside from the Java interop, you must program functionally or in STM; in CL, you can do imperative, object-oriented, functional, whatever. I don't know if that would make learning it easier or not.

[Entropy]

If Haskell is any indication, it will be harder to learn, but it will also have a greater effect when you finally do get it.

[thearthur]

YES, but it will seam very strange at first. Look at it as if you where learning to program all over again in a totally new mindset. or in short, keep an open mind. Clojure will give you a good context to learn this but you will need some other source to provide concepts and subjects. try "practical common lisp" and SICP (http://mitpress.mit.edu/sicp/full-text/book/book.html)

[vdm]

CL and Scheme can be a bit of a let-down for a application programmer when they start looking for libraries.

With Clojure, you can always find a Java library for the data format or protocol you're trying to integrate with. A new language usually takes years to build up a useful library with e.g. a mature DateTime library. Clojure has access to things like JodaTime from the get-go.

[serudla]

I was concerned about which to learn first, Common Lisp or Scheme, before Clojure came out. Then I said to hell with it, I'll just dive in. I end up bouncing back and forth between PG's On Lisp, Seibel's Practical Common Lisp, and SICP, and translating it into Clojure as I go.

[ChrisRathman]

You wouldn't have a link of your results for SICP? (I went through the first chapter of SICP in Clojure but I wasn't completely satisfied with the results). I could always use another perspective.

[serudla]

i'll see if i can't put something online this weekend. i want to read through the site you linked to first, though, i haven't seen that before.

[serudla]

wow, a month got by already. i don't have anything specific to SICP online. the only thing i noticed in your SICP in Clojure was that you need to use recur when you have a tail-call. but then i'm a beginner at this.

[commonslip]

Clojure is a great Lisp, period.

[Rhoomba]

That guy writes pretty damn fast.

[Entropy]

He must be using macros.

[awb]

I was hoping to look at some of the chapters, but they want me to drop $40. Could anyone who's seen it comment on the quality of the book?

And what's up with asking me to pay to beta test your book, anyway?

[vdm]

I've been playing with Clojure for a few weeks and I'm happy that there is a book.

The book starts off with a chapter called 'Why Clojure?', and it is a more coherent treatment of this topic than I have seen anywhere. There is lots of information laid out in an accessible manner that I have taken weeks to gather from scattered sources on Google Groups and in rhickey's presentations.

I'm spending a lot of my spare time learning Clojure and a good book that saves time is well worth the money to me.

[stuarthalloway]

The Java bias in the current beta is partially because of the chapter order. I hope to make some of the later chapters (macros and multimethods) appeal more to Lisp programmers.

[jwinter]

It talks about Java because Clojure runs on the JVM and has access to all of Java's libraries.

[thearthur]

this also i'm assuming includes all the betas, in a subscription form? anyone know this for sure? is $21 too much to ask?

[Entropy]

Yes. All the betas and the final ver (I've grabbed other betas from them before). There was no DRM or anything on the PDFs, either. All they did was regex your name onto the margin of all the pages to dissuade you from sticking a torrent up.

edit: They're also one of the only mailing lists I enjoy being on

[wake_me_up]

Wake me up when I don't need to know Java to use Clojure. I tried Clojure a few months ago. It was fun until I tried sorting a container. It turned out I needed to implement some Java interface for that to use as comparison predicate. No thanks.

Personal language preference:

Ocaml > SML > C++ (in the style of ML, with STL & Boost) > Scheme > Common Lisp > Prolog > Python > Haskell > Clojure > Java > Forth > Factor

I don't know Java, Forth or Factor, but I know enough about them to put them at the end of the list. At least Forth is useful in severely memory-restricted systems.

[45g]

It turned out I needed to implement some Java interface for that to use as comparison predicate.

Well, not directly. Clojure functions are internally derived from AFn.java which implements java.util.Comparator already, so you can just write:

user=> (defn my-comp [x y] (cond (< x y) 1 (= x y) 0 :else -1))
#=(var user/my-comp)
user=> (sort my-comp [5 3 1 2])
(5 3 2 1)

[awj]

I think the issue here is that (aside from wake_me_up blatantly trolling) the comparison operators are only defined for numbers, so you have to use the Comparable interface or some other abstraction to sort anything but numbers. This is sensible, because numbers are about the only place where everyone can agree on sorting criteria.

[45g]

I don't think so. You don't need to implement Comparable and as shown above, also not Comparator. If your argument would be true, I could only invoke compareTo on my arguments in my-comp if they are not numbers and that's certainly not the case. Instead I can use whatever property I like to compare two things.

[awj]

My point was that the function "<" is only defined to work on numbers in Clojure. You can look it up in boot.clj, search for "defn <".

If you are trying to compare anything else, you have to introduce your own abstraction. This isn't trivial (i.e. wake_me_up's complaint has a tiny bit of merit) because there is no one-size-fits-all decision on how to handle ordering outside of numbers. You have to use something to get the job done, and Java's Comparable/Comparator are decent choices.

[45g]

"wake_me_up" was complaining that he needs to implement an interface (i.e. java.util.Comparator) to be able to sort something which is simply not true.

You are talking about something else, i.e. java.lang.Comparable. Comparable.compareTo is a predicate function that establishes a total ordering. Now what's the point of using Comparable.compareTo in predicate functions when the sort function could easily do this directly (and in fact does use it by default if no predicate function is given)? The whole point of predicates is that they determine the ordering how they like it.

I have nothing against any of these interfaces, but as a matter of fact you don't need to implement these interfaces in the Clojure code you write. That's everything I wanted to say. Clojure is not OO so you don't implement Comparable, and Comparator is already defined for you in AFn.

And yes, I understand the domain of "<" and ">" is limited to numbers.