The Productive Programmer (Theory in Practice (O'Reilly)) [ILLUSTRATED] (Paperback) by Neal Ford (Author) http://www.amazon.com/Productive-Pr...bs_sr_1?ie=UTF8&s=books&qid=1226878466&sr=8-1 Imo, it is the modern successor to the classic, "Mythical Man Month" http://www.amazon.com/Mythical-Man-...=sr_1_1?ie=UTF8&s=books&qid=1226878613&sr=1-1
Another must read, imo: The Art of Concurrency: A Thread Monkey's Guide to Writing Parallel Applications (Paperback) by Clay Breshears (Author) http://www.amazon.com/Art-Concurren...1537/ref=sr_1_1?ie=UTF8&qid=1249929031&sr=8-1
i like this one http://www.amazon.com/Art-Multiproc...UTF8&coliid=I3IXORIZ3UM9AM&colid=S7ESOT0S346L also MIT ocw has a multipcore video course up now. http://ocw.mit.edu/OcwWeb/Electrica...r-Science/6-189January--IAP--2007/CourseHome/
As stated in the first book in this thread, Unit Testing may be the biggest differentiator of modern Software Engineering from Hacking. Many programmers hate it, but once you get the hang of it, it is actually quite natural imo. I recommend: Pragmatic Unit Testing in C# with NUnit, 2nd Edition (Paperback) by Andy Hunt (Author), Dave Thomas (Author), Matt Hargett (Author) http://www.amazon.com/Pragmatic-Uni...6673/ref=sr_1_1?ie=UTF8&qid=1250468403&sr=8-1 It is amazing how well NUnit integrates with Visual Studio and MonoDevelop.
Manning is offering 40% on many books. Use this code on check out: a2740. One very nice thing about Manning is that they also give you the eBook free with the hardcopy. I am going to get Functional Programming for the Real World EARLY ACCESS EDITION http://www.manning.com/petricek/
That book is okay, yet another FP intro. I've also personally found Clojure and Scala to be more practical if you're wanting to dive into that realm, but you're bound to Java, unless you go with the CLR ports. I believe the guy behind Clojure is bootstrapping a large effort to rewrite most of the Clojure libraries in Clojure as to make it much more VM independent.
I agree with lolatency ... I have found Scala to be a nice middle ground between something like SML (or OCaml) and Ruby. Yes, it inherits heavily from Java, but really only the good stuff. I moved from C++ to Ruby because Ruby allowed me to prototype very, very quickly. Unfortunately, it also ultimately made me a bad programmer. Through the forced abstraction of declaration and definition, closed classes, and just the whole 'header' 'source' file paradigm, C++ made me design and code at the same time. Ruby just let me code. Therefore, I just didn't follow good software engineering practices. Also, it is very, very slow. JRuby helps, but doesn't solve all the problems. So while I got great 'coder-time' speed up using Ruby, and all the libraries available to it (the gems package is amazing), I ultimately lost time from having to start each project from scratch. SML, on the other hand, was too strict for me. Sometimes I need a mutable object. Sometimes it just doesn't make sense to be passing everything as state. Sometimes a loop is the correct solution. Thinking 'functionally' can be very helpful, but not always the right solution, in my opinion. Scala lets me get the best of both worlds. I can get the type correctness of a static language, and still a good amount of freedom from mutability. It has garbage collection (thanks to the jvm), and incorporates Erlang's actor paradigm. I can write my concurrent actors with non-mutable state, and even do cool stuff like <a href="http://jonasboner.com/2007/12/19/hotswap-code-using-scala-and-actors.html">hot swapping</a>. This allows me all the concurrent safety of languages like Erlang, but with all the libraries of Java. Hell, if a Java library is NOT thread safe, I can just typically wrap the methods I want into an actor and I get thread safety! Seriously. Check out Scala. O'Reilly has a nice free e-book available <a href="http://programming-scala.labs.oreilly.com">here</a>. I hear clojure is good too. Haven't tried it yet though.
whats your recommendation to test/debug realtime event driven and threaded systems? I have no trouble testing individual pieces but the whole is different