I really like CTM. I'm only about halfway through it (it's big!), but IMHO the writing is quite clear without being dry or shying away from harder material. Very well written.
The main idea of the book is that no one programming paradigm is the best fit for all problems, so it's worth knowing several, their respective strengths and weaknesses, and the ways in which they can be combined. The examples are mostly written in Oz, a language of the authors' invention, but they're not dogmatic about it - it's just a multi-paradigm language well suited to showing different techniques in isolation. (I made a quick attempt to port Oz/Mozart to OpenBSD/amd64, but didn't get it working. I wrote examples in OCaml and Scheme instead.)
Also, if you appreciate reading attempts to solve problems from multiple angles, Project Euler (http://projecteuler.net/) is worth a look. You can read other peoples' solutions after solving each problem; I've learned a lot about algorithms that way. (The problems are predominantly mathematical.)
Mozart-Oz http://www.mozart-oz.org/ is by no means a toy language.
It is used and have been used in some serious commercial applications (I've used it myself in some even if it was never talked about or said in a even a single word (big secret)).
It's been awhile since I did any heavy lifting in mozart-oz but I keep it in my reference stack together with lisp, smalltalk.
I haven't written it off as a language. It looks very interesting, I just ran into trouble porting it to OpenBSD on amd64* and haven't gotten back to it. (I've done several ports for OpenBSD, and when/if I get it ported I will submit it.)
I prefer to work in languages that are reasonably portable across Linux, BSD (inc. OS X), and Windows. Combined with my other priorities and general taste, this means Lua, various Scheme implementations, OCaml, and C. (Your taste and priorities probably differ, though. Peace.)
* Which is an interesting portability test - Linux-isms are invalid, stuff that isn't 64-bit clean won't work, it's not quite i386, and OpenBSD's randomizing malloc tends to expose interesting bugs as well. (The only real loss has been Haskell, but I'm uneasy with how Haskell's de-facto standard seems to be "whatever the newest GHC does" when GHC has bootstrap/portability issues, e.g. http://hackage.haskell.org/trac/ghc/ticket/1346 .)
Just to clarify, I was i no way criticizing your choice to not use mozart-oz. I took the opportunity to give a reference to the mozart-oz as a language used outside the context of book.
well, my old link collection for oz is a little out of date but there should be some academic mention in the http://www.cpaior.org/ conferences series.
(I used mozart-oz to create some hybrid algorithms back in the days but I didn't do it in the academic field but used it in commercial applications that I no longer are involved in)
Christian Schulte,http://web.it.kth.se/~cschulte/papers.html, wrote a book or collection of papers "Programming Constraint Services" that really what I can recall was using mozart-oz.
As you can see I only reference mozart-oz in the context of CP-AI-OR but 2000-2004 I used it more or less weekly to do all kind of "normal" programming (whatever that is;)).
I really like CTM. I'm only about halfway through it (it's big!), but IMHO the writing is quite clear without being dry or shying away from harder material. Very well written.
The main idea of the book is that no one programming paradigm is the best fit for all problems, so it's worth knowing several, their respective strengths and weaknesses, and the ways in which they can be combined. The examples are mostly written in Oz, a language of the authors' invention, but they're not dogmatic about it - it's just a multi-paradigm language well suited to showing different techniques in isolation. (I made a quick attempt to port Oz/Mozart to OpenBSD/amd64, but didn't get it working. I wrote examples in OCaml and Scheme instead.)
Also, if you appreciate reading attempts to solve problems from multiple angles, Project Euler (http://projecteuler.net/) is worth a look. You can read other peoples' solutions after solving each problem; I've learned a lot about algorithms that way. (The problems are predominantly mathematical.)