Hacker content on my hackernews? Yep, this is a pretty good book. I've only just started it but it is enjoyable if you are a Lisper or interested in how some Lispers tick.
I bought this a few hours ago and I already finished it: a fun read. If you are a Common Lisp hacker (or used to be one) you will enjoy reading about 14 hackers, how they use Lisp, got started, etc. I just plugged this book and Leanpub on my blog. Off topic, but if you are starting a writing project, check out Leanpub (I am using them for 2 book projects right now).
I am a huge common lisp fan and I recommend it to anyone interested in better ways of doing software. Start with Practical Common Lisp: http://www.gigamonkeys.com/book/
http://www.cliki.net/ has a lot of useful resources for people who are just starting.
If you prefer a functional language(Common Lisp is multi-paradigm, and isn't particularly better at FP than say python) clojure and scheme are good options. I recently started reading Realm of Racket, which seems like a pretty good introduction to Racket(a scheme like language).
I recommend learning all 3 dialects, all of them deserve deep study and I strongly favor Common Lisp as the most mature and versatile one.
I would instead recommend reading a Common Lisp tutorial, installing SBCL, and start playing. The book is fun, but it won't get you started coding Common Lisp.
Have you seen the Lisp resources on Paul Graham's website? The Lisp FAQ (http://paulgraham.com/lispfaq1.html) answered a lot of my own questions. I've been drawn towards learning lisp for some time too (because it just seems so... different), and this week I finally installed the Clisp implementation and worked through the two online chapters of PG's ANSI Common Lisp book. I wish more programming texts were that clear and fast-paced. The lisp essays are engaging too.
I also wish I had more reasons to use/learn lisp. Everything I do is better suited to another language, it seems like.
You could consider using Clojure, it has a huge community, one principal implementation, a lot of documentation and you can access Java libraries if you want to. I think at the moment it is the most "approachable" Lisp.
Though unlike other Lisps, it does have a functional focus. That is very fine with me, but YMMV.
I was considering paying for the book (and still might if after reading I decide it was worth it) but Leanpub is giving the author 40% of what I am paying them. I don't really like to give 60% to some publisher when I essentially just want to tip the author.
It's like buying someone a beer. That is only less than half full, because the barkeeper drank 60% of it.
So if you pay 10$ the author gets 8.50$. As a leanpub author myself, I find this arrangement very good. The only problem with leanpub I have is that the 45 day money back guarantee is too long, and if that period happens to end in the beginning of a month, you have to wait for the start of the next one in order to get paid(leanpub pays in the first 3 days of a month). I had to wait two months for my first payment. I'm not complaining, leanpub haven't wronged me in any way, and in fact I have benefited from people paying much more than the suggested price(15$ for my book, 5$ minimum price). Leanpub is a great service! I recommend more people republish their blogs or publish new material with it.
I didn't see that. I just tested the slider with $1 to get a percentage and it gave me 40ct for the author from which I concluded they take 60%. My bad, thanks for the correction.
The full quote is:
"It’s also very easy to turn Common Lisp REPL code into unit tests, which I tend to
do a lot. That is something that’s very hard to do with object-oriented code, which is
why idiotic things like dependency injection and Test-Driven Development have to be
invented.
– Vladimir Sedach"
Test driven development is essential for writing reliable distributed systems programs. Robert Morris' 6.824 class is proof of this. There is a time and a place for every tool.
I don't really have an opinion either way, having never tried TDD, but I do write distributed systems and don't see why you can't use post-facto testing to get the same results. I am interested in your reasoning. (Re: Proof, http://pdos.csail.mit.edu/6.824/schedule.html doesn't feature the word 'test' which though circumstantial sort of downplays the weight of an inextricable link such as that you are supposing.)
It sounds like the non-test specification is simply poor, and the tests elucidate parts of the specification that are unclear. This doesn't seem relevant to the original question of the claimed requisite-level efficacy of TDD in designing distributed systems.
Actually, the specifications are quite clear. The subject matter is just difficult to implement correctly. I encourage you to try it. It's a lot of fun.