I'm surprised this has gotten positive responses. This really is an idea that seems to run counter to a lot of progress in the industry. The notion that repetition improves performance is absolutely true, but that doesn't mean that you can neglect your continued education just to repeat.
What's more, learning new languages is repetition of the process of learning. It's learning how to think about a problem differently (assuming it does, you may not learn so many new concepts going from Ruby to Python). Learning to turn over a problem and attack it from a new angle is an essential skill.
There is a terrible temptation that we as engineers all face: to stop learning. After all, our skillsets are broad enough and it's hard to justify all these skills we may never use professionally. But that's a dangerous negative feedback cycle, because all these computer linguists build on other concepts. Once you fall a generation behind, you the have that much larger a gap to cross when pioneers have carved out a market that you do want to enter.
Finally, there is this kind of hidden belief in hacker circles that functioning but inelegant code is somehow worthless. Of course it's preferable to have elegant, extensible code... but in a space where there are no alternatives any functioning code is better than no code at all. Even if you can't make beautiful code with a skillset, working code is 1000x better than no code at all.
P.S. Also, the reader should care what Zed Shaw thinks of their code? Facile understanding of the history of mongrel detected, captain.
My first inclination was the same, but as i read further it became clear that his core argument, under all that chaff, is simply to pick an interesting problem for your new year rather than assuming that a new language for the sake of a new language is in itself a worthwhile problem. new problem for the new year is hard to argue against if you're into that sort of thing & will probably net out the same benefits you're looking for, namely, more learning. that said, his argument has a lot of noise obfuscating a signal that's too general to be strong. meh.
More illustratively, I'd say he's more saying "go to France, then learn French as you go" versus the common programmer course of "learn French then never go there".
Learning Haskell, Erlang, Lisp, etc, can be interesting on its own, but if you instead try to achieve something or learn about a subject area where Haskell, Erlang, or Lisp are strong, it's a far better way of learning. Go to France and then learn French.
Are you sure you aren't inserting that message because it seems more reasonable?
That really doesn't seem like the message that's being stated. It is a little hard to pick out the relevant parts, but it seems like he's going to stick to what languages he knows and instead focus on solving problem domains.
Learning new languages as you explore new problem domains doesn't seem like the message in the post, at all.
You might be right, but he talks about using Seaside, which is based on Smalltalk. I've been following his blog for quite a while and haven't seen strong reference to learning Smalltalk, yet if you wanted to use Seaside's strengths to solve a certain problem, you would end up learning some Smalltalk en-route.
This is what I've been doing. I've been taking one computer science course per semester, and picking a language to learn to do the problems in. Well, actually, more like 4 semesters and 3 languages (Common Lisp for 2 semesters, Python and Clojure 1 each). This is in addition to doing Java as my day job, and trying to learn it better, too.
This has occasionally led to more excitement than I wanted, like trying to push Python to do a processing intensive task and then switching to Java at the last minute so it would finish by the deadline. But for the most part it has worked well and by picking more productive languages to learn has even made some tasks easier than they would have been with my day job language.
However, my goal for the new year is to start a blog and write more. One of the first topics I want to write about is the programming languages I've used and what I've learned from them.
This seems to me to be more of a descent into wankery than anything else. The one constant of our industry is that language platforms seem to have a 5-9 year popularity-span. Google pushes Python, Java eclipsed C++ for a huge portion of the market, C++ has now supplanted C in many places. (Please note that I know there are outliers in this and it's not an absolute rule! Objective-C, for example, hasn't gone away.)
I enjoy new problems and domains too. It's great to dive into a new subject, and often very valuable. But the reason people say, "Learn a new language ever <time increment>" is because you're not just tackling a new domain, you're talking a new way of understanding domains. This kind of meta-exercise is invaluable, in my opinion.
"If you do that, Zed Shaw will find you and skullfuck you to death. I'm not kidding. He and I have made a deal with Satan, and this was one of the perks he requested."
Looks like Giles missed the memo that the ZSFA persona has been put to rest. Guess Giles will have to take on this role solo, now.
How true. As an example, learning and understanding Python/C API was much more practical and enlightening experience for me than experience of learning a new language like Haskell or O'Caml.
What's more, learning new languages is repetition of the process of learning. It's learning how to think about a problem differently (assuming it does, you may not learn so many new concepts going from Ruby to Python). Learning to turn over a problem and attack it from a new angle is an essential skill.
There is a terrible temptation that we as engineers all face: to stop learning. After all, our skillsets are broad enough and it's hard to justify all these skills we may never use professionally. But that's a dangerous negative feedback cycle, because all these computer linguists build on other concepts. Once you fall a generation behind, you the have that much larger a gap to cross when pioneers have carved out a market that you do want to enter.
Finally, there is this kind of hidden belief in hacker circles that functioning but inelegant code is somehow worthless. Of course it's preferable to have elegant, extensible code... but in a space where there are no alternatives any functioning code is better than no code at all. Even if you can't make beautiful code with a skillset, working code is 1000x better than no code at all.
P.S. Also, the reader should care what Zed Shaw thinks of their code? Facile understanding of the history of mongrel detected, captain.