For example, once you get started, I can type my program into the repl piece by piece and copy the working parts into my source file. Or, I can type my code into the source file and evaluate it with the repl. I imagine one choice has more pros/cons than the other.
Emacs... I'm not using it, and I don't know what I'm missing. It seems like the majority of the hardcore clojurists are though and I'd like to know why.
With debugging, I feel like the clojure error messages are not very helpful. I'm pretty sure this is just because I'm new to the language and the programming paradigm. Maybe that can't be taught and just takes time. But I also feel like there are a lot of debugging techniques out there I don't know about.
I've documented my debugging complaints in detail on Stack Overflow here: http://stackoverflow.com/questions/16901836/how-do-i-get-bet...
This is how I start Emacs:
* Open emacs
* `c-x c-f` to navigate to and open my clj file
* `c-c m-j` to start nrepl session (opens up in a pane split)
* `c-w h/j/k/l` to move between windows
* `m-x find-file-in-project` (I mapped to `;a`) to navigate to
other clj files in the git project
And this is my workflow once I have source file and nrepl split-panes open: * Edit code
* `c-x c-e` to eval the expression above cursor
* `c-c c-k` to eval entire source buffer
* `m-hyphen c-c c-z` to load source file
namespace into nrepl window which I rarely do
I actually rarely use the repl window since you can eval code in the source file.* I pretty much treat my source file as my repl and use `c-x c-e` to execute the previous form. (Screenshot: http://dl.dropbox.com/u/51836583/Screenshots/l0.png)
* Also, I'll often put the code I'm trying to get to work like `(my-func 1 2 3)` at the bottom of my source file. Then, while I'm hacking on `my-func`'s implementation, I mash `c-c c-k` (eval buffer) which returns the result of the last expression in the file.
* Another nice way to utilize `c-c c-k` is to put your `(assert (= (my-func 1 2 3) 42))` tests right into the source file. The tests will get run every time you eval the buffer. It's a solid test-driven loop baked into the core library!
(See more nrepl keymappings here: https://github.com/kingtim/nrepl.el#keyboard-shortcuts)
What editor are you using? Emacs certainly has had the most mindshare so far, but it's a beast to get started with. I recommend CounterClockwise for non-emacs folks: it's got all the features you need to be effective, and has full integration with Leiningen.
As far as errors and error messages; yeah, it's hard, and a lot if it is just getting experience. But one thing that will really help you out is to write your program in very small chunks, and test each part as you go. That way, when something goes wrong, you'll have a very good idea about where to start looking.
Your last paragraph is good advice, but IMO I code like that in general. Consider this code:
(-> x doSomething1 doSomething2 doSomething3)
This was tested as I went, but after the fact, I had to change x. Now any part of the whole series of steps could be broken. This is where I spend 15 minutes trying to understand what the error message means. shrug Maybe this is just what's expected when you're new to clojure.
It's not just about the REPL and syntax highlighting. You need to see someone use paredit (things like paredit-raise-sexp or paredit-forward-slurp-sexp), evaluate expressions in-place (either seeing the results in the minibuffer or inserting them into the code), use M-. to instantly jump to anything that is defined in the active runtime, etc.
As for debugging, the Clojure experience is pretty bad, compared to (for example) Common Lisp. I'm experienced and use Clojure every day to write large applications, but I still stick to logging for most debug work. And yes, backtraces are horrible.
This is what I've been looking for, but I don't know any experienced lispers, which has left me with a huge hill to climb to migrate from CCW to Emacs. Are there any annotated videos (i.e., showing keypresses) available showing lispers at work?
Which is helpful for quick inspection.
Slime/swank (nrepl replaces it, but I'm just slowly transitioning to it), provides code completion, documentation lookup, REPL, macro expansion and even live code updates on a running application; which can be a bit of a pain to setup on other editors. And the integration in Emacs is really great, as the repl buffer is really just a text buffer, the same as the one you are coding in.
But the biggest reason for me to code LISP in Emacs is paredit. It really makes all the trouble with balancing parenthesis and moving around the sexps really easy. It might seem counter intuitive and a bit troublesome at first, but I really recommend you to try it. For a short and enthusiastic video on paredit, see http://www.youtube.com/watch?v=D6h5dFyyUX0 -- and maybe the other Emacs Rocks! videos to learn more about modern Emacs.
Saying all these, the reason I am still using vim is that my CTS prevents me from using emacs all the time, and most of the advantage Emacs brings can be achieved by a good tiled windows manager such as xmonad.
https://github.com/clojure-cookbook/clojure-cookbook/blob/ma...
What author royalties there are will go towards getting print versions of the book to our largest contributors, and then to Ryan and I as editors.
I don't think it would be feasible to split the royalties fairly amongst all our contributors; not only would it be a large overhead, but the actual amounts would be pretty tiny unless you've written a pretty large proportion of the book. And if you do that, we'd be happy to talk to you about sharing some of the royalties.
What proportion of the book do you expect the editors to write?