60 of 69 people found the following review helpful
Too shallow to be interesting,
This review is from: Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages (Pragmatic Programmers) (Paperback)
I was very disappointed in this book. I could have attain a similar level of depth with fewer unnecessary film-based analogies by reading each langauges' wikipedia page.
The author focuses heavily on syntax, program structure, and how common things are represented in each language, what the REPL, looks like in each case, etc. There many belabored explanations of well-understood language-agnostic concepts like prototypes, actors, futures, recursion, laziness, and immutability. Zero of these languages are interesting because of how lists work yet the book laboriously visits this example over and over. Similarly, only one or two of the languages has truly interesting things to say about concurrency, but he discusses concurrency over and over.
Each of these languages has made important contributions to the field of programming language design and culture. This is where the time should be spent--not developing a familiarity with basics like syntax and list operations. If I want to know what the code is going to look like visually, I can use wikipedia.
For instance, a core idea behind prolog is unification. The author gives lots of examples of prolog code, but fails to explain at any level of detail the theoretical basis for unification or how it works. I don't have a prolog background, and when I sat down to read the chapter, I hoped to come away with a basic working understanding of the concepts. All I ended up with is some ideas of how prolog is used and what it feels like at the surface of its syntax/semantics.
One of the most interesting things in Io is the combination of an unusually transparent message-passing discipline with a mutable syntax tree. In Io, you can build messages that serve as macros--mutating their call-site at the first invocation in order to generate code, accomplish call-by-name semantics, or do any number of other interesting things. These patterns exist throughout the standard library, and at least when I was participating in the Io community more actively, were one of the most frequent topics of discussion. This stuff is really, really cool, and the author didn't do it justice, instead spending time explaining basic ideas like actors and prototypes as if Io is extremely unique for having them.
Ruby is actually fairly boring as a programming language in and of itself. It's largely a reboot of smalltalk semantics into the clothing of a scripting language. Hardly a great innovation. However, the ruby community has developed an awesome culture--a culture that is certainly informed by ruby itself, but is not at all inherent to it. Even though ruby stopped being an everyday language for me several years ago, the lessons I learned from its culture continue to influence my work in other languages. The author should have spent time discussing this culture and how culture contributes to ruby's success instead of belaboring the basics of syntax or explaining ruby's unimpressive module system or its approach to concurrency.
Instead of focusing on the beauty in these systems, the author opted to do something far more boring--write a collection of shallow tutorials.
Finally, I was disappointed that the author neglected to include any languages suitable for high-performance computing or systems programming. This might have included Go or D.
I'm not sure who this book is good for. I didn't get much out of it, and despite my vast appreciation for the contributions of these languages, I felt that the book didn't do them justice, instead opting to focus on basics and trivialities. My advice is to skip it. Maybe someone will do this concept well someday, but this book isn't it.
Sort: Oldest first | Newest first
Showing 1-3 of 3 posts in this discussion
Initial post: Jun 20, 2012 11:00:57 AM PDT
Rusty Shackleford says:
"Finally, I was disappointed that the author neglected to include any languages suitable for high-performance computing or systems programming."
You mean like Erlang?
In reply to an earlier post on Jul 23, 2012 3:13:12 PM PDT
Brian L. says:
I mean like go or D.
Erlang is for building distributed systems with a fault tolerance and malleability, not folding proteins, multiplying matrices, or dealing with giant data sets in non-distributed scenarios. It's several times slower than java/C/C++, and can't natively call the C ABI functions exposed by most kernels.
In reply to an earlier post on Jul 27, 2013 2:36:59 AM PDT
two in tents says:
‹ Previous 1 Next ›