Thank you! I've been playing around with Clojure, because it's just so much fun, but setting up a development environment has been a nightmare (not in the least part, because, well, I've never seriously programmed in non-data/stats languages). I've been using ClojureBox, but that obviously has limitations.
If you're not committed to emacs, then there's plenty of other editors and IDEs that have quality Clojure support. It's worth experimenting a bit to find one you like.
I have been liking Clooj. It has almost nothing that most traditional IDEs have. I would like to see perhaps syntax highlighting, but it does highlight parens. The fact that it is only, for, and by Clojure though makes it pretty awesome. So it is somewhat minimalistic in that it only has what you need, and that's pretty great.
For what it's worth (relatively new to Clojure), I've enjoyed using IntelliJ with Clojure. Tried using emacs for a while but I'm hooked on vi-style bindings and evil-mode (+ emacs's unconventional ways in general) just didn't cut it for me.
Ive recently been working with SublimeText2. Yesterday I wanted to give Clojure another try, so I had a look and found the SublimeREPL plugin. It provides REPLs for several languages, Clojure included. It was very quick and easy to setup, I had it up and running inside of a short lunch break.
Hey, that's cool. I previously hacked up integration that sniffed for an existing JVM ran from the project directory and its REPL listen port, then sent text over telnet to it. Was too rough to use comfortably.
I found trying to get vim and clojure working together to be pretty painful. Right now I just use emacs w/ swank clojure, but with evil mode and a config that pretty accurately emulates my vim set up.
Thank you cemerick! I was hoping to catch your first screencast with O'Reilly, but only managed to catch the last 20 minutes - So this makes me especially happy.
On a side note, your book is fantastic - I have pretty much all the Clojure books out there, but I really like the job you and your co-authors have done.
Thanks so much for this! I tuned in to the webcast at O'Reilly but their Flex app was failing me, I couldn't ask questions in the group chat, couldn't see the screencast at O'Reilly although I did manage to see it at Livestream but I couldn't read anything because of small text. So yeah, I tuned out pretty soon, but this is fantastic.
I couldn't join the live session due to a flaky 3G connection. Thanks for coming up with this and posting this even before the recording was available from Oreilly. I am going through your book and liking it so far, this is a wonderful opportunity to see you in action.
Thanks cemerick. I'm still watching this screencast, so not sure if you get into this here, but if not, I have a request :)
I've been trying to understand how to do concurrency in Clojure - but haven't found any good guides - any chance you'd do a screencast on this topic as well?
I probably won't get into anything as nuanced as concurrency in a screencast format. We certainly get into it in detail in the book.
The presentation that Rich Hickey did some years back is still relevant though (helpfully linked by spacemanaki in another reply — and originally recorded near here in Northampton, MA :-D).
I really don't get this hype about lisp-like languages.
I think Scheme is the only language who is more or less acceptable for such a role. Others (including Common Lisp) are just too complex for writing in them ASTs (yes, S-expression is AST...).
Clojure is a functional Lisp with immutable, persistent data structures. This simplifies concurrency programming, which is becoming increasingly important in a multi-core world.
> I really don't get this hype about lisp-like languages.
Well for one thing some of us having been using Lisp for a very, very long time. I have personally been using it for years so it seems like the most natural thing to me at this point.
That is the historical element to Lisp. Of course, there are also practical advantages. The lisp-like languages are effectively the only class of languages available today that allow you to effective escape from text-based programming and use certain advanced techniques that are necessary for symbolic AI.
> Others (including Common Lisp) are just too complex for writing in them ASTs (yes, S-expression is AST...).
This part of your comment leaves much to be desired. How is Common Lisp complex and exactly what other languages share this feature? What does this have to do with "writing them ASTs"? Finally, please explain why you equate S-expressions with ASTs.
The likely cause here is a double-whammy of complaining about downvotes in a child comment, and a form of "what is posited without evidence can be rejected without evidence" that maps to downvoting comments without elaboration. What exactly makes you think the way you think regarding Common Lisp vs. Scheme vs. Clojure? What's a crowning example of Scheme's superiority over at http://hyperpolyglot.org/lisp ? Have you even read about what makes Clojure different from CL or Scheme so that you have an informed opinion? Not a bad place to start would be the official website, or perhaps the long article here: http://java.ociweb.com/mark/clojure/article.html
Yes, I know what differentiates Clojure from CL (or Scheme). What I'm saying is that it is possible to have most part of these goodies in non S-expr language. Except maybe homoiconicity and advanced macros (Although being S-expr is not required for homoiconicity (e.g. Prolog)).
Well, your second statement was not really accurate or even really coherent. CL and Clojure both have relatively simple syntax compared to most mainstream languages because of their use of S-expressions. Although reader macros mean they aren't purely S-expressions.
But the main reason that you're being downvoted is because this site tends to attract Lisp aficionados. Paul Graham is well-known for claiming that Lisp is better than all other languages:
Keep up the great work!