What do you think?
Rate this book
Seven Languages
Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages
You should learn a programming language every year, as recommended by The Pragmatic Programmer . But if one per year is good, how about Seven Languages in Seven Weeks ? In this book you'll get a hands-on tour of Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Whether or not your favorite language is on that list, you'll broaden your perspective of programming by examining these languages side-by-side. You'll learn something new from each, and best of all, you'll learn how to learn a language quickly.
Ruby, Io, Prolog, Scala, Erlang, Clojure, Haskell. With Seven Languages in Seven Weeks, by Bruce A. Tate, you'll go beyond the syntax-and beyond the 20-minute tutorial you'll find someplace online. This book has an audacious to present a meaningful exploration of seven languages within a single book. Rather than serve as a complete reference or installation guide, Seven Languages hits what's essential and unique about each language. Moreover, this approach will help teach you how to grok new languages.
For each language, you'll solve a nontrivial problem, using techniques that show off the language's most important features. As the book proceeds, you'll discover the strengths and weaknesses of the languages, while dissecting the process of learning languages quickly--for example, finding the typing and programming models, decision structures, and how you interact with them.
Among this group of seven, you'll explore the most critical programming models of our time. Learn the dynamic typing that makes Ruby, Python, and Perl so flexible and compelling. Understand the underlying prototype system that's at the heart of JavaScript. See how pattern matching in Prolog shaped the development of Scala and Erlang. Discover how pure functional programming in Haskell is different from the Lisp family of languages, including Clojure.
Explore the concurrency techniques that are quickly becoming the backbone of a new generation of Internet applications. Find out how to use Erlang's let-it-crash philosophy for building fault-tolerant systems. Understand the actor model that drives concurrency design in Io and Scala. Learn how Clojure uses versioning to solve some of the most difficult concurrency problems.
It's all here, all in one place. Use the concepts from one language to find creative solutions in another-or discover a language that may become one of your favorites.
Ruby, Io, Prolog, Scala, Erlang, Clojure, Haskell. With Seven Languages in Seven Weeks, by Bruce A. Tate, you'll go beyond the syntax-and beyond the 20-minute tutorial you'll find someplace online. This book has an audacious to present a meaningful exploration of seven languages within a single book. Rather than serve as a complete reference or installation guide, Seven Languages hits what's essential and unique about each language. Moreover, this approach will help teach you how to grok new languages.
For each language, you'll solve a nontrivial problem, using techniques that show off the language's most important features. As the book proceeds, you'll discover the strengths and weaknesses of the languages, while dissecting the process of learning languages quickly--for example, finding the typing and programming models, decision structures, and how you interact with them.
Among this group of seven, you'll explore the most critical programming models of our time. Learn the dynamic typing that makes Ruby, Python, and Perl so flexible and compelling. Understand the underlying prototype system that's at the heart of JavaScript. See how pattern matching in Prolog shaped the development of Scala and Erlang. Discover how pure functional programming in Haskell is different from the Lisp family of languages, including Clojure.
Explore the concurrency techniques that are quickly becoming the backbone of a new generation of Internet applications. Find out how to use Erlang's let-it-crash philosophy for building fault-tolerant systems. Understand the actor model that drives concurrency design in Io and Scala. Learn how Clojure uses versioning to solve some of the most difficult concurrency problems.
It's all here, all in one place. Use the concepts from one language to find creative solutions in another-or discover a language that may become one of your favorites.
330 pages, Paperback
First published November 17, 2010
264 people are currently reading
3421 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 87 reviews
January 14, 2012
I did not like this book one bit. There are a number of reasons for this, so let me take them in turn.
First the tone is resolutely jokey, with an overall conceit that each of the seven languages is a character from a movie. Now this may help some people, but to my mind words spent discussing Ferris Bueller are words that could have been devoted to discussing the language in question. As far as I'm concerned, the shorter a technical book is, the better, and I'd prefer it if it didn't try to tell me what I ought to find amusing. Your milage may vary.
Second, the author is ever so, ever so full of himself, and is a very strong believer in the curious philosophy that if something was invented five years ago then it must be better than something that's been in serious use for decades. It's rather like the way that each generation of teenagers appear to believe that they are the first people in the world ever to have had sex, and about as instructive. The reality is that (say) Clojure may be really big with the people who prefer hype to substance, but basically all it is is a crippled version of LISP with an overly complex syntax. Why waste your time learning the ins and outs of Clojure when you cal learn the syntax of LISP in ten minutes? Especially as LISP has a rather large literature of extremely high quality. I also find it instructive that nowhere does the author actually admit that Clojure is LISP with more brackets; he makes it sound new. Because new is good!
Third, and as a corollary, he seems to think that if he doesn't understand something, it's impossible to understand. Thus he gives a horribly garbled description of Monads in Haskell and then, on the grounds that his explanation is incomprehensible, asserts that we can't possible hope to understand Monads, and therefore Haskell is too hard for anyone to use. As any number of authors (including me) have shown, Monads are very simple and really rather elegant beasts, and incredibly powerful: they're just machines for making stateful widgets.
So, is the book worth reading at all? For six of the seven languages covered, the answer is a definite 'no'. Better books exist on Ruby, Prolog, Scala, Erlang, Clojure and Haskell (most published by o'Reilly). The one exception is IO, a language that the author doesn't do full justice to, but which, with its paradigm that everything is a message passed from one object to another, is quite fascinating. As far as I am aware, this is the only book that covers IO, so it might almost be worth reading for the chapter on IO along. But it's an expensive book to buy, so borrow a copy if you decide you do want to know more.
First the tone is resolutely jokey, with an overall conceit that each of the seven languages is a character from a movie. Now this may help some people, but to my mind words spent discussing Ferris Bueller are words that could have been devoted to discussing the language in question. As far as I'm concerned, the shorter a technical book is, the better, and I'd prefer it if it didn't try to tell me what I ought to find amusing. Your milage may vary.
Second, the author is ever so, ever so full of himself, and is a very strong believer in the curious philosophy that if something was invented five years ago then it must be better than something that's been in serious use for decades. It's rather like the way that each generation of teenagers appear to believe that they are the first people in the world ever to have had sex, and about as instructive. The reality is that (say) Clojure may be really big with the people who prefer hype to substance, but basically all it is is a crippled version of LISP with an overly complex syntax. Why waste your time learning the ins and outs of Clojure when you cal learn the syntax of LISP in ten minutes? Especially as LISP has a rather large literature of extremely high quality. I also find it instructive that nowhere does the author actually admit that Clojure is LISP with more brackets; he makes it sound new. Because new is good!
Third, and as a corollary, he seems to think that if he doesn't understand something, it's impossible to understand. Thus he gives a horribly garbled description of Monads in Haskell and then, on the grounds that his explanation is incomprehensible, asserts that we can't possible hope to understand Monads, and therefore Haskell is too hard for anyone to use. As any number of authors (including me) have shown, Monads are very simple and really rather elegant beasts, and incredibly powerful: they're just machines for making stateful widgets.
So, is the book worth reading at all? For six of the seven languages covered, the answer is a definite 'no'. Better books exist on Ruby, Prolog, Scala, Erlang, Clojure and Haskell (most published by o'Reilly). The one exception is IO, a language that the author doesn't do full justice to, but which, with its paradigm that everything is a message passed from one object to another, is quite fascinating. As far as I am aware, this is the only book that covers IO, so it might almost be worth reading for the chapter on IO along. But it's an expensive book to buy, so borrow a copy if you decide you do want to know more.
February 4, 2018
The good:
* A fantastic way to improve your programming abilities and understanding. Learning a number of different programming languages and paradigms in a short time period is a great way to compare them, see the trade-offs, and expand your thinking.
* Good choice of languages. You'll get to see several different varieties of object oriented programming, functional programming, logic programming, meta programming, concurrency constructs, type systems, and more.
* Great exercises at the end of each chapter to get you to actually try each language out and get first-hand experience with it.
The bad:
* Some of the explanations of language features are overly shallow, or even outright wrong. The discussion of how STM works in Clojure is missing the absolutely critical idea that the transaction may be retried and therefore, must be side-effect free; Erlang actors are introduced, but not how to make them distributed, which is a core use case; the explanation of how monads work is confusing and incomplete. Some of this is due to the need to fit so much content in a single book, but some of it seems like sloppy research and not enough peer reviewers.
* The author is very judgmental and opinionated about the languages. Java is awful, Haskell is too complicated, Clojure's syntax is too painful, yada yada yada. Perhaps this is an attempt to make the book more fun, but if the goal is to encourage programmers to learn new paradigms and languages, spending a considerable amount of time trashing some of those languages and paradigms is very counterproductive. I recommend ignoring the color commentary and forming your own opinions.
Overall:
I would recommend that every programmer (a) reads this book and (b) goes through the exercises. If you do this, I guarantee you'll be a better programmer when you're done.
Note, however, that going through the exercises is ESSENTIAL. To fit seven languages in a single book, the author could only include a short tutorial and a tiny sampling of features from each one. If all you did was read these short summaries, and you didn't actually do the exercises, you will not truly grok what each language is about, and you will get very little out of this book—I'd wager most of the negative reviews on GoodReads are from people who solely skimmed the book.
If you actually go through each of the exercises, which will take a few hours per chapter, you'll get a much deeper understanding, and enjoy the book far more. For context, I started reading this book in 2012 and only finished it in 2018! I'd read it in spurts, doing a few chapters and exercises when I had free time, and then putting it away again for many months or even years (the last pause was for ~4 years until I stumbled across this book and realized I still had two more languages to go!). So instead of seven languages in seven weeks, it took me almost seven years... But YMMV :)
* A fantastic way to improve your programming abilities and understanding. Learning a number of different programming languages and paradigms in a short time period is a great way to compare them, see the trade-offs, and expand your thinking.
* Good choice of languages. You'll get to see several different varieties of object oriented programming, functional programming, logic programming, meta programming, concurrency constructs, type systems, and more.
* Great exercises at the end of each chapter to get you to actually try each language out and get first-hand experience with it.
The bad:
* Some of the explanations of language features are overly shallow, or even outright wrong. The discussion of how STM works in Clojure is missing the absolutely critical idea that the transaction may be retried and therefore, must be side-effect free; Erlang actors are introduced, but not how to make them distributed, which is a core use case; the explanation of how monads work is confusing and incomplete. Some of this is due to the need to fit so much content in a single book, but some of it seems like sloppy research and not enough peer reviewers.
* The author is very judgmental and opinionated about the languages. Java is awful, Haskell is too complicated, Clojure's syntax is too painful, yada yada yada. Perhaps this is an attempt to make the book more fun, but if the goal is to encourage programmers to learn new paradigms and languages, spending a considerable amount of time trashing some of those languages and paradigms is very counterproductive. I recommend ignoring the color commentary and forming your own opinions.
Overall:
I would recommend that every programmer (a) reads this book and (b) goes through the exercises. If you do this, I guarantee you'll be a better programmer when you're done.
Note, however, that going through the exercises is ESSENTIAL. To fit seven languages in a single book, the author could only include a short tutorial and a tiny sampling of features from each one. If all you did was read these short summaries, and you didn't actually do the exercises, you will not truly grok what each language is about, and you will get very little out of this book—I'd wager most of the negative reviews on GoodReads are from people who solely skimmed the book.
If you actually go through each of the exercises, which will take a few hours per chapter, you'll get a much deeper understanding, and enjoy the book far more. For context, I started reading this book in 2012 and only finished it in 2018! I'd read it in spurts, doing a few chapters and exercises when I had free time, and then putting it away again for many months or even years (the last pause was for ~4 years until I stumbled across this book and realized I still had two more languages to go!). So instead of seven languages in seven weeks, it took me almost seven years... But YMMV :)
September 29, 2012
While I was glad to see the material on Clojure--I was a LISP person back in the 1980s--I have to say that the rest of the material left me pretty cold. Like the author, I use a lot of different computer languages (C#, Perl, and R get a lot of use), but rarely have the choice of which I use...it's dictated either by company policy, or by which language that I already know that best addresses the problem I'm dealing with. Maybe it's just me, but none of the languages I saw in this book made me think "I should be using *that* language!"
And frankly, I couldn't care less about the author's opinions on language aesthetics, because they're just opinions. For example, as a long time Perl guy, Ruby's syntax looks clumsy and amateurish to me. I haven't even found a compelling reason to switch to Python yet...for me, Ruby was a total non-starter.
Started out reading this, then switched to skimming when I found very little that was really engaging. This is probably a great book for hobbyists and beginning language snobs...I doubt that a professional programmer would find it very useful, beyond the ending summary of strengths and weaknesses of each language.
And frankly, I couldn't care less about the author's opinions on language aesthetics, because they're just opinions. For example, as a long time Perl guy, Ruby's syntax looks clumsy and amateurish to me. I haven't even found a compelling reason to switch to Python yet...for me, Ruby was a total non-starter.
Started out reading this, then switched to skimming when I found very little that was really engaging. This is probably a great book for hobbyists and beginning language snobs...I doubt that a professional programmer would find it very useful, beyond the ending summary of strengths and weaknesses of each language.
October 1, 2018
Tate decides to gender a bunch of programming languages, and his decision it to make 6 of the 7 languages male. One is allowed to be female, Ruby, because of how "beautiful" she is.
if you don't want to be repeatedly whacked in the face by extremely intellectually lazy sexism, skip this title. 🙃
if you don't want to be repeatedly whacked in the face by extremely intellectually lazy sexism, skip this title. 🙃
August 27, 2014
Wanna to experiment? This book is for you.
I wonder why Prolog is less popular than Java?
I wonder why Prolog is less popular than Java?
July 16, 2019
A couple of random thoughts about this book:
First off, you have the idea that, for each language the author would spend one week (I'll not get into the fact that each "week" has 3 days only). This is a great idea: How much of the concepts of a programming language can you capture in just one week. Are the interfaces good? Are they simple and easy to understand? The fact is, the author did not spend one week on each language. In the Clojure chapter, he mentions that he got the idea after a month. So instead of trying to capture the good and bad points in one week -- which, again, it's a good thing, so one can understand how "ergonomic" a language is -- the author decided the reader should only take one week per language.
Second, there is a huge about of "obvious", "obviously" and "simple". Sure, it may seem obvious for the author, but most of the time, things are not obvious for people who never saw anything related.
Not only there is an abuse of "obvious" things, sometimes the author seems to either not understand some concepts of the language or tries to simplify an explanation to the point it sounds wrong -- and I just realized that 'cause I've read books about some of the languages.
And there are times when the author shows a piece of code, with something completely new, and forgets to explain what that new thing means. I'm glad I've read books about Clojure and Haskell before, otherwise I'd never understand what the thing really was.
On the general, it's a book about seven languages. Instead of reading this book, I'd suggest getting the list of languages and going after them in other ways instead of reading this.
First off, you have the idea that, for each language the author would spend one week (I'll not get into the fact that each "week" has 3 days only). This is a great idea: How much of the concepts of a programming language can you capture in just one week. Are the interfaces good? Are they simple and easy to understand? The fact is, the author did not spend one week on each language. In the Clojure chapter, he mentions that he got the idea after a month. So instead of trying to capture the good and bad points in one week -- which, again, it's a good thing, so one can understand how "ergonomic" a language is -- the author decided the reader should only take one week per language.
Second, there is a huge about of "obvious", "obviously" and "simple". Sure, it may seem obvious for the author, but most of the time, things are not obvious for people who never saw anything related.
Not only there is an abuse of "obvious" things, sometimes the author seems to either not understand some concepts of the language or tries to simplify an explanation to the point it sounds wrong -- and I just realized that 'cause I've read books about some of the languages.
And there are times when the author shows a piece of code, with something completely new, and forgets to explain what that new thing means. I'm glad I've read books about Clojure and Haskell before, otherwise I'd never understand what the thing really was.
On the general, it's a book about seven languages. Instead of reading this book, I'd suggest getting the list of languages and going after them in other ways instead of reading this.
March 30, 2012
I've been slinging Java code since 1996 and have become very comfortable with its object-oriented paradigm and syntax. This is the 21st century so surely there must be other programming languages out there that are worth exploring? This book helped me to understand the various paradigms that are out there. This book isn't a deep dive but gives you a very good feel for what it is like to craft a solution in each language. Missing are how exceptional conditions are handled or how a large solution might bundle different pieces together but you can learn enough to decide if the language is worth your time to explore further. I especially appreciated interviews with the authors of each language to see why the language was created and what they think are its shortcomings. Each chapter provides a nice summary of the current state of the language and what you can expect to find in terms of a community. I found that this book helped to better understand the different ways problems can be solved in software and inspired me to take a deep dive into the Clojure world.
September 27, 2011
Good book that provides coverage of different programming languages, trying to explain their paradigms, and basic constructs... This book could be used as a base to find which language to study next
July 24, 2024
One of the more adventurous technical book series I've read. I highly recommend the pragmatic Programmers' "in Seven Weeks" series, including the "Seven Database in Seven Weeks" book. Then there's "Seven More Languages in Seven Weeks", which I wasn't curious to read.
These books definitely won't make you an expert in any of the languages. These books are there for you to gain breadth. If you're stuck in a single programming language yet want to learn more about what else is out there, viz., Scala, Erlang, Clojure, Haskell, give the book a try.
The book was relevant to me when I wrote Ruby and Clojure. A year or so after - Scala. I wasn't alienated by new languages due to already exploring them in this book. :)
I find it a 4-star read due to the honestly redundant way fictional characters are artificially inserted to make each language stand out as a poignant thing. Imo, not needed. But if you like a mix of inner child plus professional development, sure, this is not a bad thing. :)
These books definitely won't make you an expert in any of the languages. These books are there for you to gain breadth. If you're stuck in a single programming language yet want to learn more about what else is out there, viz., Scala, Erlang, Clojure, Haskell, give the book a try.
The book was relevant to me when I wrote Ruby and Clojure. A year or so after - Scala. I wasn't alienated by new languages due to already exploring them in this book. :)
I find it a 4-star read due to the honestly redundant way fictional characters are artificially inserted to make each language stand out as a poignant thing. Imo, not needed. But if you like a mix of inner child plus professional development, sure, this is not a bad thing. :)
August 3, 2022
This was a disappointing read :( I really struggle to recommend it to anyone.
I have to agree with other reviewers that this was a cool idea (hence what made me pick it up) riddled by poor execution.
The book spends way too much time on surface level concepts on most languages, and spends very little time on actually interesting language features. I can't help but feel that this book, if it was written in a way that does justice to the features and languages, would be about 700-800 pages, not 330.
It also doesn't help that the author doesn't appear to have a robust background in Programming Language Theory/Implementation, which means that the book is riddled with inaccuracies and downright mistakes in nearly all of the chapters (as an example, in the Scala chapter, the author mistakes static/dynamic typing for the properties expressed by nominal vs structural type systems).
Another thing to note, is that in 2022, the book already feels old (you have to compensate for the syntax changes in some of the languages - especially Scala, which the more I'm looking at, the more I feel an urge to kill rising in me - but I can't hold this fact against the author, given that the book came out some time in 2010.
I have to agree with other reviewers that this was a cool idea (hence what made me pick it up) riddled by poor execution.
The book spends way too much time on surface level concepts on most languages, and spends very little time on actually interesting language features. I can't help but feel that this book, if it was written in a way that does justice to the features and languages, would be about 700-800 pages, not 330.
It also doesn't help that the author doesn't appear to have a robust background in Programming Language Theory/Implementation, which means that the book is riddled with inaccuracies and downright mistakes in nearly all of the chapters (as an example, in the Scala chapter, the author mistakes static/dynamic typing for the properties expressed by nominal vs structural type systems).
Another thing to note, is that in 2022, the book already feels old (you have to compensate for the syntax changes in some of the languages - especially Scala, which the more I'm looking at, the more I feel an urge to kill rising in me - but I can't hold this fact against the author, given that the book came out some time in 2010.
December 3, 2013
The author does not go so much deep, but after all you are full of ideas enough. So take it as a teaser for these languages.
----quotes----
Learning to program is like learning to swim. No amount of theory is a substitute for diving into the pool and flailing around in the water gasping for air. The first time you sink under the water, you panic, but when you bob to the surface and gulp in some air, you feel elated. You think to yourself, “ I can swim. ” At least that ’ s how I felt when I learned to swim.
A Zen master might tell you that to be better at mathematics you ’ d better study Latin. Thus it is with programming. To better understand the essence of OO programming, you should study logic or functional programming (FP). To be better at FP, you should study Assembler.
I won’t make you an expert, but I’ll teach you more than “Hello, World.”
Scala represents pure heresy to pure functional programmers and pure bliss to Java developers.
Every ten years or so, programming paradigms change. As the Java language became more limiting for me...
Java was like having a rich lawyer as a brother. He was fun when he was younger, but now he’s a black hole that sucks away all the joy in a 100-mile radius.
Prolog seemed to be an all-or-nothing approach to problems, or at least to the problems I was working on. In the laboratory scheduling problem, the system would churn for 30 minutes and then either give us a beautiful schedule for the day or simply print “no.” “No” in this case meant that we had over-constrained the day, and there was no full solution. It did not, however, give us a partial solution or much of any information about where the over-constraint was.
Strictly speaking, Scala is not a pure functional programming language, just like C++ is not a pure object-oriented language.
When the object-oriented paradigm was new, the masses could not accept Smalltalk because the paradigm was too new. We needed a language that would let them continue to do procedural programming and experiment with object-oriented ideas. With C++, the new object-oriented tricks could live safely beside the existing C procedural features. The result was that people could start using the new tricks in an old context.
I do find Scala’s syntax to be a little academic and hard on the eyes.
The problem is that moving back and forth between Scala and Java will take more effort than it should.
I would use Scala to improve my productivity if I had a significant investment in Java programs or programmers. I’d also consider Scala for an application that has significant scalability requirements that would require concurrency. Commercially, this Frankenstein has a good shot because it represents a bridge and fully embraces a significant programming community.
Functional languages are at a higher level of abstraction than object-oriented languages. Though they are more difficult to understand, you can express bigger ideas with less code.
Dozens of dialects tried to launch Lisp into the mainstream and failed.
Clojure and Java desperately need each other. Lisp needs the market place that the Java virtual machine can offer, and the Java community needs a serious update and an injection of fun.
Clojure has wonderful abstractions but many of them. To truly embrace and use those features effectively and safely, a programmer will need to be highly educated and extremely talented.
You need to have an extremely talented and experienced team to make Lisp work.
A very unusual thing about Haskell is that it is a successful committee language.
Since I started building software for myself, I feel like I’ve just discovered independent films. I’ve been able to make a living coding Ruby, but I’m not naive enough to think Ruby has all of the answers. Just as independent films are advancing the state of the art in movie making, emerging programming languages are changing the way we think about program organization and construction.
As a Java developer, I had to wait a decade for closures, mainly because people like me were uneducated and did not scream loud enough for them. In the meantime, mainstream frameworks like Spring were stuck with anonymous inner classes to solve problems that could have used closures extensively. My fingers bled from the oppressive amount of typing, and my eyes bled because I had to read that stuff.
----quotes----
Learning to program is like learning to swim. No amount of theory is a substitute for diving into the pool and flailing around in the water gasping for air. The first time you sink under the water, you panic, but when you bob to the surface and gulp in some air, you feel elated. You think to yourself, “ I can swim. ” At least that ’ s how I felt when I learned to swim.
A Zen master might tell you that to be better at mathematics you ’ d better study Latin. Thus it is with programming. To better understand the essence of OO programming, you should study logic or functional programming (FP). To be better at FP, you should study Assembler.
I won’t make you an expert, but I’ll teach you more than “Hello, World.”
Scala represents pure heresy to pure functional programmers and pure bliss to Java developers.
Every ten years or so, programming paradigms change. As the Java language became more limiting for me...
Java was like having a rich lawyer as a brother. He was fun when he was younger, but now he’s a black hole that sucks away all the joy in a 100-mile radius.
Prolog seemed to be an all-or-nothing approach to problems, or at least to the problems I was working on. In the laboratory scheduling problem, the system would churn for 30 minutes and then either give us a beautiful schedule for the day or simply print “no.” “No” in this case meant that we had over-constrained the day, and there was no full solution. It did not, however, give us a partial solution or much of any information about where the over-constraint was.
Strictly speaking, Scala is not a pure functional programming language, just like C++ is not a pure object-oriented language.
When the object-oriented paradigm was new, the masses could not accept Smalltalk because the paradigm was too new. We needed a language that would let them continue to do procedural programming and experiment with object-oriented ideas. With C++, the new object-oriented tricks could live safely beside the existing C procedural features. The result was that people could start using the new tricks in an old context.
I do find Scala’s syntax to be a little academic and hard on the eyes.
The problem is that moving back and forth between Scala and Java will take more effort than it should.
I would use Scala to improve my productivity if I had a significant investment in Java programs or programmers. I’d also consider Scala for an application that has significant scalability requirements that would require concurrency. Commercially, this Frankenstein has a good shot because it represents a bridge and fully embraces a significant programming community.
Functional languages are at a higher level of abstraction than object-oriented languages. Though they are more difficult to understand, you can express bigger ideas with less code.
Dozens of dialects tried to launch Lisp into the mainstream and failed.
Clojure and Java desperately need each other. Lisp needs the market place that the Java virtual machine can offer, and the Java community needs a serious update and an injection of fun.
Clojure has wonderful abstractions but many of them. To truly embrace and use those features effectively and safely, a programmer will need to be highly educated and extremely talented.
You need to have an extremely talented and experienced team to make Lisp work.
A very unusual thing about Haskell is that it is a successful committee language.
Since I started building software for myself, I feel like I’ve just discovered independent films. I’ve been able to make a living coding Ruby, but I’m not naive enough to think Ruby has all of the answers. Just as independent films are advancing the state of the art in movie making, emerging programming languages are changing the way we think about program organization and construction.
As a Java developer, I had to wait a decade for closures, mainly because people like me were uneducated and did not scream loud enough for them. In the meantime, mainstream frameworks like Spring were stuck with anonymous inner classes to solve problems that could have used closures extensively. My fingers bled from the oppressive amount of typing, and my eyes bled because I had to read that stuff.
August 13, 2020
It took me a good while longer than seven weeks to read this book (and complete the programming exercises), but it was a great investment and I am glad I finished it. I have always wanted to try my hand at a couple of the seven languages covered in the book (Ruby, Io, Prolog, Scala, Erlang, Clojure and Haskell); and there was no way I could find the time to embark on such a journey without some guidance from a book or short course.
Even though I worked as a software engineer in the past, I come from an electrical engineering background where we were trained to program in a pragmatical fashion to solve engineering problems effectively; with little regard to computational efficiency (unless absolutely required), elegance, or even maintainability. Electrical engineers are essentially instructed in one or two common programming languages (such as C/C++ and Python) and sent into the real world; while computer science students get a solid background in multiple programming languages and their comparative strengths. For this reason, I had little understanding of how different some of these languages worked: even with 25+ years of C/C++ experience, I was completely blown away by how alien Haskell was, for example.
The author managed to present the gist of each language with good commentary and a few programming experiments, considering how little space could be dedicated to each language in a book of this length. If I could find one nit to pick: the book could probably benefit from an online addendum explaining how to install the programming environments for each of the languages covered - most of them are very easy to find with a quick online search, some of them are more involved to set up.
Even though I worked as a software engineer in the past, I come from an electrical engineering background where we were trained to program in a pragmatical fashion to solve engineering problems effectively; with little regard to computational efficiency (unless absolutely required), elegance, or even maintainability. Electrical engineers are essentially instructed in one or two common programming languages (such as C/C++ and Python) and sent into the real world; while computer science students get a solid background in multiple programming languages and their comparative strengths. For this reason, I had little understanding of how different some of these languages worked: even with 25+ years of C/C++ experience, I was completely blown away by how alien Haskell was, for example.
The author managed to present the gist of each language with good commentary and a few programming experiments, considering how little space could be dedicated to each language in a book of this length. If I could find one nit to pick: the book could probably benefit from an online addendum explaining how to install the programming environments for each of the languages covered - most of them are very easy to find with a quick online search, some of them are more involved to set up.
April 9, 2014
A fantastic book. I would urge anyone thinking of reading this book to DO THE EXAMPLES. The first time I went through the Ruby section I missed so much by not going through the examples.
On the fourth language I skipped the examples because I strongly dislike Scala; I'm already very familiar with Java, I don't like the syntax and Venkat gave Scala a bad rap with his poorly executed book.
I enjoy Bruce's writing, he really brings out the unique aspects of the language in a concise, frank, humurous way.
Some of these languages are old or obscure but they are very fun and very "mind expanding"; I've looked at different languages before (e.g. Haskell, Scala, C) but they never filled me with the urge to explore like this book.
Learning about the different typing systems and working with the different languages just long enough to fall in love with them has been an eye-opener.
I haven't gotten around to reading the Haskell section of the book. Don't know if I will; I've already read "Learn You a Haskell" several times and I got half-way through the O'Reilly Haskell book.
May 1, 2012 Update: I finished the Haskell section. I'd already read up on Haskell but the chapter was still good.
Dec 14, 2012 Update: I'm now employed writing Erlang and you really need OTP for commercial Erlang; the official name of the language is actually "Erlang/OTP". Once you've read this book, check out "Learn You Some Erlang" for everything you need to get started in OTP.
On the fourth language I skipped the examples because I strongly dislike Scala; I'm already very familiar with Java, I don't like the syntax and Venkat gave Scala a bad rap with his poorly executed book.
I enjoy Bruce's writing, he really brings out the unique aspects of the language in a concise, frank, humurous way.
Some of these languages are old or obscure but they are very fun and very "mind expanding"; I've looked at different languages before (e.g. Haskell, Scala, C) but they never filled me with the urge to explore like this book.
Learning about the different typing systems and working with the different languages just long enough to fall in love with them has been an eye-opener.
I haven't gotten around to reading the Haskell section of the book. Don't know if I will; I've already read "Learn You a Haskell" several times and I got half-way through the O'Reilly Haskell book.
May 1, 2012 Update: I finished the Haskell section. I'd already read up on Haskell but the chapter was still good.
Dec 14, 2012 Update: I'm now employed writing Erlang and you really need OTP for commercial Erlang; the official name of the language is actually "Erlang/OTP". Once you've read this book, check out "Learn You Some Erlang" for everything you need to get started in OTP.
January 5, 2015
Instead of seven weeks, it took me about two years. I would read a chapter on one language and do the exercises, then get distracted by other things and not come back to it for several months. I finally forced myself to run through the final three languages during my Christmas vacation since I was sick and didn't want to leave the house.
Overall, this is an excellent book that will expose you to different ways of thinking as a programmer. I enjoyed all seven languages and I plan to dive deeper with a couple of them (Erlang and Clojure). Tate does a good job of balancing breadth and depth with each language and really gets to the core of what makes each language unique, and points out the strengths and weaknesses of each. My one complaint is with the final section of the final language in which he covers "monads" in the Haskell language. He points out at the beginning of that section that he dreaded writing about such a difficult concept, and unfortunately, I don't think he succeeded in explaining it very well. But that remains the only flaw in this book in my opinion. I think it is well worth the time of any serious programmer to read through this book, whether it takes seven weeks or seven years.
Overall, this is an excellent book that will expose you to different ways of thinking as a programmer. I enjoyed all seven languages and I plan to dive deeper with a couple of them (Erlang and Clojure). Tate does a good job of balancing breadth and depth with each language and really gets to the core of what makes each language unique, and points out the strengths and weaknesses of each. My one complaint is with the final section of the final language in which he covers "monads" in the Haskell language. He points out at the beginning of that section that he dreaded writing about such a difficult concept, and unfortunately, I don't think he succeeded in explaining it very well. But that remains the only flaw in this book in my opinion. I think it is well worth the time of any serious programmer to read through this book, whether it takes seven weeks or seven years.
December 16, 2014
I like the idea of this book more than the book itself. Granted, Tate took on a daunting task: how do you introduce seven divergent languages with seven divergent styles and seven divergent intents in the space of one book? The mission is a good one at least: introduce apprentice or journeyman programmers to a diverse array of programming languages and styles to help thing break out of their comfortable little already-known toolkit.
The approach is at least a half-way decent one: introduce a language, give three days worth of lessons (plus homework) and then use that to bridge into the next language/style.
But it also comes across as very surface-level. Tate even comes right out and says in many instances that he is just barely scratching the surface of each language, that he is giving some language feature a barely cursory overview, or else leaving it out all together. So you wind up with your appetite whetted but without any satisfying take-away knowledge (e.g., my experience here with Scala and Clojure), or else you're turned off to that language all together (e.g., my experience with Io and Prolog).
The approach is at least a half-way decent one: introduce a language, give three days worth of lessons (plus homework) and then use that to bridge into the next language/style.
But it also comes across as very surface-level. Tate even comes right out and says in many instances that he is just barely scratching the surface of each language, that he is giving some language feature a barely cursory overview, or else leaving it out all together. So you wind up with your appetite whetted but without any satisfying take-away knowledge (e.g., my experience here with Scala and Clojure), or else you're turned off to that language all together (e.g., my experience with Io and Prolog).
January 13, 2021
A really cool idea let down by poor execution. There's a lot to be said for exposing yourself to new programming paradigms, and I think the author did a solid job picking languages that really help you narrow into specific ideas (Io, Prolog, and Haskell being particularly single-minded in their focus) but I think a person would be better off spending some time with these languages on their own.
The author often spends too long on language basics and then needs to rush through the important complexities. He also lets his personal preferences (such as hatred of explicit types) color the writing and code examples of the book, which completely ruins chapters like Haskell where he leaves off type definitions, making his code much harder to read.
He also has a writing style that is very exclusionary and patronizing. I can't count the amount of times he described new (and potentially confusing) concepts/code as "simple", "easy", or "obvious". It's very frustrating to be struggling to understand a new concept while the author is telling you how simple it is.
Long story short, do a worthwhile exercise like this on your own and skip this book.
The author often spends too long on language basics and then needs to rush through the important complexities. He also lets his personal preferences (such as hatred of explicit types) color the writing and code examples of the book, which completely ruins chapters like Haskell where he leaves off type definitions, making his code much harder to read.
He also has a writing style that is very exclusionary and patronizing. I can't count the amount of times he described new (and potentially confusing) concepts/code as "simple", "easy", or "obvious". It's very frustrating to be struggling to understand a new concept while the author is telling you how simple it is.
Long story short, do a worthwhile exercise like this on your own and skip this book.
July 26, 2012
Bruce Tate does the nearly impossible in providing a fast paced but accomplish-able guide through seven programming languages.
He provides a good balance between the why and the how, while always focusing on pragmatic, delivered results. He spares no sacred cows in illuminating the weaknesses of each language, but also spares nothing in featuring their strengths.
In the end, you'll be left knowing, just as you always knew, that no one tool is the best at all things. But, you'll also know which of these tools is probably best at tackling a specific problem set.
An added bonus were the interviews of people involved with each language, often the person who invented it. They added depth and perspective, and, occasionally, surprising historical nuggets and language trivia.
Prerequisites: You'll do best if you've got some programming experience. This should not be your first toe in the water of computer programming.
He provides a good balance between the why and the how, while always focusing on pragmatic, delivered results. He spares no sacred cows in illuminating the weaknesses of each language, but also spares nothing in featuring their strengths.
In the end, you'll be left knowing, just as you always knew, that no one tool is the best at all things. But, you'll also know which of these tools is probably best at tackling a specific problem set.
An added bonus were the interviews of people involved with each language, often the person who invented it. They added depth and perspective, and, occasionally, surprising historical nuggets and language trivia.
Prerequisites: You'll do best if you've got some programming experience. This should not be your first toe in the water of computer programming.
February 19, 2020
I'm loving this book. Any professional developer, or anyone who loves the thrill of crafting something efficient and elegant in code, will find lots of fascinating insight through a brief but intensive study of 7 languages you might not otherwise have a reason to look at. You don't have to have any intention of actually taking any of those languages up after you've read the book - you will learn something interesting and potentially useful just by reading about them.
Studying other languages in this way is a bit like travel. Travel opens your mind to other cultures, ideas, cuisines, and ways of life. If you were to spend a week each in Marrakesh, Florence, Cape Town, Sydney, St Petersburg, Dublin and Delhi, you would almost certainly come out of it a more worldly, rounded and tolerant citizen of the planet, even if you never intended to live in any of those places.
Give it a go!
Studying other languages in this way is a bit like travel. Travel opens your mind to other cultures, ideas, cuisines, and ways of life. If you were to spend a week each in Marrakesh, Florence, Cape Town, Sydney, St Petersburg, Dublin and Delhi, you would almost certainly come out of it a more worldly, rounded and tolerant citizen of the planet, even if you never intended to live in any of those places.
Give it a go!
June 16, 2019
This book is like having a smart friend introduce you to the defining themes in a language, instead of tutorials that generally teach you the syntax and give few clues as to what is generally preferred -- for example using map and fold instead of iterating at all possible times in languages with functional and imperative abilities :)
I wasn't at all familiar with the functional-ish concepts in ruby, I had no idea that scala is java + type inference + functional features, I had no idea clojure is a lisp language for the JVM! Coming back to concurrency in each language was a nice defining/contrasting thread (haha, thread)
I wasn't at all familiar with the functional-ish concepts in ruby, I had no idea that scala is java + type inference + functional features, I had no idea clojure is a lisp language for the JVM! Coming back to concurrency in each language was a nice defining/contrasting thread (haha, thread)
November 25, 2021
A typical introduction to a programming language starts with syntax. "Here's how you do an if/then"; "here's how to write a function" and I just don't care. I always think, yeah yeah yeah, but what are the ideas? How can I express things with this? What kinds of programming tasks are easy with this language? Which are hard?
This book introduces seven languages in a way that's more in line with the latter approach, and I really enjoyed it. This approach means that even though this book is ancient (for a technical book), and some of the things in it are super outdated, it's still a great read.
This book introduces seven languages in a way that's more in line with the latter approach, and I really enjoyed it. This approach means that even though this book is ancient (for a technical book), and some of the things in it are super outdated, it's still a great read.
June 30, 2013
Ruby, Io, Prolog, Scala, Earlang, Clojure and Haskel,
This book was not so much about the languages, but more about the different paradigms in programming.
Ruby's syntax showed me how enjoyable writing code can be, Prolog blew my mind when it breezed trough a soduku puzzle by just giving it the rules of the game. The functional languages like Clojure and Haskell made me realize that I have a lot to learn, there's a whole different way of reasoning about computations. I am definitely going to look try out these languages.
Great read.
This book was not so much about the languages, but more about the different paradigms in programming.
Ruby's syntax showed me how enjoyable writing code can be, Prolog blew my mind when it breezed trough a soduku puzzle by just giving it the rules of the game. The functional languages like Clojure and Haskell made me realize that I have a lot to learn, there's a whole different way of reasoning about computations. I am definitely going to look try out these languages.
Great read.
September 15, 2015
Thought this will be shallow overview of languages but I was wrong. Book very well presents strong & weak spots of languages with a clean structure. Now I find to understand JavaScript better after learning about Io. Have skipped the Scala part. Prolog was tricky to grasp would be interesting to use it in some future project. Got lost in Clojure brackets and interested in transactional memory. Erlang seemed very familiar to Go. Haskell as Day 3 describes 'Mind Meld'.
July 19, 2020
I have read this book eight years ago and it still is one of my favorite books.
In the past months I have had the pleasure of getting in touch with the author (now he has a company called Groxio which helps you become a better developer) and I can understand even more what he thinks about the importance of learning different programming languages.
An important fact: this book helped Jose Valim create Elixir.
In the past months I have had the pleasure of getting in touch with the author (now he has a company called Groxio which helps you become a better developer) and I can understand even more what he thinks about the importance of learning different programming languages.
An important fact: this book helped Jose Valim create Elixir.
August 20, 2011
It's a lot of work to go through the book. And you really need to work through at least some of the examples to get the most of the book. But it's a really well-structured book, with the chapters building up on each other and introducing new concepts along. Probably best read in some sort of study group to keep one from slacking off.
October 3, 2016
Such a great introduction to new Programming topics. All programmers MUST read this.
May 31, 2017
One of the most fun programming books I've been through. Great intro to several languages I had not played with and to functional programming.
June 4, 2022
An absolutely astounding piece of work. Truly enjoyed it.
November 21, 2022
A funny and interesting book about different languages and paradigms. I would prefer "Three Languages in Six Weeks" though :)
What I liked:
- Comparing different paradigms - object-oriented vs prototype vs functional. I appreciate the idea of getting out from the comfort zone and taking a look at the language you've been most comfortable with, with a different perspective (this is how I understand the main message of the book). In the last chapter, the author has placed a thought-provoking sentence: "As a Java developer, I had to wait a decade for closures, mainly because people like me were uneducated and did not scream loud enough for them.". From this perspective, the book is doing the job!
- Prolog! I haven't heard about it before. Playing with the syntax and the capabilities was a pure fun.
- Chapters about Erlang and Haskell. The latter was especially intellectualy engaging.
- An individual style of the writing. Strictly speaking, Bruce A. Tate is a seasoned writer and it can be felt. Each language is anthropomorphised (for example, Clojure is Yoda because of its inverted prefix syntax), each chapter has a similar strucutre. It just reads well.
What I didn't like:
- Too much love for JVM-oriented languages :P
- Seven was too much for me. At first I was very excited, but as I read the excitement slowly diminished. Also, I don't understand why as many as four languages were from the functional family. In the end, we have some duplication of the concepts that are similar in each of them.
- Putting aside nice guide role of the author, it's just a simple tutorial to the seven different technologies. Most of the examples are similar to the ones from the official documentations.
What I liked:
- Comparing different paradigms - object-oriented vs prototype vs functional. I appreciate the idea of getting out from the comfort zone and taking a look at the language you've been most comfortable with, with a different perspective (this is how I understand the main message of the book). In the last chapter, the author has placed a thought-provoking sentence: "As a Java developer, I had to wait a decade for closures, mainly because people like me were uneducated and did not scream loud enough for them.". From this perspective, the book is doing the job!
- Prolog! I haven't heard about it before. Playing with the syntax and the capabilities was a pure fun.
- Chapters about Erlang and Haskell. The latter was especially intellectualy engaging.
- An individual style of the writing. Strictly speaking, Bruce A. Tate is a seasoned writer and it can be felt. Each language is anthropomorphised (for example, Clojure is Yoda because of its inverted prefix syntax), each chapter has a similar strucutre. It just reads well.
What I didn't like:
- Too much love for JVM-oriented languages :P
- Seven was too much for me. At first I was very excited, but as I read the excitement slowly diminished. Also, I don't understand why as many as four languages were from the functional family. In the end, we have some duplication of the concepts that are similar in each of them.
- Putting aside nice guide role of the author, it's just a simple tutorial to the seven different technologies. Most of the examples are similar to the ones from the official documentations.
December 2, 2020
Maybe a little beyond my level. In general, I might have understood the book more if the syntax and semantics of the examples were more clearly separated. Ideally, I would have like a Rosetta stone language (e.g., Python or Ruby) with the example coded in this and then "translated" into the language being studied. A single running example (more complex than Fibonacci) may have helped here.
For example, I found the Haskell monad section particularly confusing because of this. I was unfamiliar both with Haskell syntax and with the monad concept. Two moving parts. It turns out that you can explain monads in Python (a language I'm familiar with), which is what I finally resorted to to understand this concept: https://nikgrozev.com/2013/12/10/mona...
Lastly, I felt like the book often jumped into the "what" of the languages without spending a lot of time on the "why". Why does Haskell worry so much about types as opposed to say, Scheme?
For example, I found the Haskell monad section particularly confusing because of this. I was unfamiliar both with Haskell syntax and with the monad concept. Two moving parts. It turns out that you can explain monads in Python (a language I'm familiar with), which is what I finally resorted to to understand this concept: https://nikgrozev.com/2013/12/10/mona...
Lastly, I felt like the book often jumped into the "what" of the languages without spending a lot of time on the "why". Why does Haskell worry so much about types as opposed to say, Scheme?
August 23, 2017
I really like this concept of teaching seven languages in seven weeks (one for each weekend). I started with the book seven databases in seven weeks which I also enjoyed a lot and then bought this one two. I am working in IT development for 13 years now and in the past years I wasn't looking too much for new programming languages and whatelse changes there. This book is a good overview on nowadays programming languages and should be read by every programmer just to keep updated on what's going on in the programmin world outside.
Displaying 1 - 30 of 87 reviews