(OT) "Learn one new language every year"? Yeah, right.

[FoxtrotUniform]

Now, I tend to be a fairly rabid fan of the Pragmatic Programmer book and/or approach. I've adopted most of the techniques in their eponymous book, and it's made me a better hacker. But I don't buy the advice: "Learn at least one new language every year" (p. 14).

I can't think of any language that I've been competent in after a year. C? (Hell no.) Pascal? (Er, did I just admit to knowing Pascal?) SQL? (shudder) Java? (Pshaw.) Common Lisp? (Not even close.) Prolog? (I'm still not competent in Prolog.) Perl? (Well, I was sort-of competent in C at the time, does that count?) Scheme? (Still writing defun, and it's been three years.) Haskell? (What's a monad?) I've been hacking C for a decade or so, and I'm far from C-guru status. Why should I expect to get far after a year of study?

Not counting assembly languages, shells, and one scripting language that shall not be named, that makes nine languages that I "know". After a year's experience with each language I hadn't even scratched the surface of what that language had to offer.

That might've been different if I'd been using the new language exclusively for a year, but who can devote a year's worth of programming to learning an unfamiliar tool? I'm in a better position than most -- I'm a grad student, with flexible deadlines and a tolerant supervisor -- but I'm mostly interested in using the right tool for the job, not in advancing my skills with a nifty language unconnected to my job. I have a feeling that most programmers, Pragmatic or not, are in an even worse position when it comes to learning the ins and outs of a new language - and especially developing a new point of view on programming, which IMO is the best reason to learn a new language.

Not that I think we should stick to the languages we know (although they deserve brain-time, too). Of course we should learn new languages, especially languages that break our brains in useful and creative ways. I know C, C++, Java, and Perl. Learning another procedural/OO language (Objective C is on my hit list) isn't likely to teach me anything world-shatteringly new. Learning a stack-based language like FORTH (or perhaps more usefully PostScript), on the other hand, would probably be a decent idea. (That's on my little list, too.)

I just think that the "one a year" timeframe is misleading. Unless you devote an impractically large chunk of time to that new language, one year isn't enough. Ten years might be closer to the truth. (Who knows? Maybe nine years from now I'll grok continuation-passing style in fullness.) Start learning a new language a year (or every two or three), but don't expect real results for at least two. Crank up a pipeline.

While we're at it, I don't think we should be focusing on languages. Rare is the language that's conceptually different from every other computer language with an open-source cross-platform implementation. Concepts are more important than languages, hands down. It doesn't matter whether I write closure-slinging functional code in Haskell, Common Lisp, OCaml, or Perl, I can express what I want to regardless. The idea of closure-slinging is what's important, not the implementation language.

Programming languages, especially programming languages that teach you something you didn't already know, are too complex to be properly learned in a year. Programming, in general, is hard. Let's keep that in mind.

Edit 2004 Oct 7: Fixed the PragProg link. What's that preview button for, again? sigh

[Zero_Flop]

I think what the author intended is not for you to become proficient at a new language every year. Instead you should try a new language each year. Learn new ways of doing things and apply them to the languages you are trying to become proficient at.

For example, I have had a hard time getting my head wrapped around OO in Perl. So I picked up a Java book, I am a little more comfortable with a language focused on OO now I can go back and study OO under Perl. I realize that the implementation may be slightly different, but the concept is the same.

[FoxtrotUniform]

I think what the author intended is not for you to become proficient at a new language every year. Instead you should try a new language each year. Learn new ways of doing things and apply them to the languages you are trying to become proficient at.

Part of my point is that you (likely) won't be able to learn new ways of doing things in just one year of study. After a year's exposure to the language, my Perl looked like a funny flavour of C, only with regexes in places (I'd learned regexes earlier, working with Vim and grep). I think it'll take well more than a year to get very much that's useful out of a language.

[pdcawley]

I think it depends on how you look at the language. For instance, I wouldn't say I've learned Smalltalk, in the sense that I would be comfortable writing a proper application in the language, but I've spent enough time with it to get a much deeper understanding of the possibilities of a dynamic object oriented language (like, say, Perl). It also helped me come to understand what it is I don't like about Java and C++ (Static typing is just wrong! OO without blocks/closures isn't really OO! Surely if you're designing a language with OO as its central feature, it would be a good idea to come up with a nice, concise syntax for making use of that feature. Ahem).

My take on Andy & Dave's advice is to learn enough of a programming language that you can read good code written in it, then do that. Find books that are well respected by people in the language's community (for example, SICP for scheme, On Lisp for common lisp, Smalltalk Best Practice Patterns for Smalltalk...) and read them. You're not trying to become an ace programmer in your new language; you're trying to get a feel for the mindset that goes with the language.

[osfameron]

I spent a couple of weeks recently learning C, as it's the scripting language (!) of a tool I've been using at work. By doing various exercises (reverse a string in place, reverse it word-wise, write string-buffer functions etc.), I learnt about pointer manipulation, structs, and manual memory management: though none of this makes me a C programmer, the learning experience was incredibly useful.

Maybe it's easier to get something from learning C after Perl than the reverse, because you can't write Perl in C, so you have to learn lower level ways of doing it?

[hardburn]

My experiance differs. For instance, I spent a few days picking through OCaml a while back. I can't say I'm proficient in the langauge, but I did learn a lot about modern type systems (C and Java are not modern type systems). I'm sure I could pick up other things if I used the language every day for a few years, but even the little I did learn was valuable.

[periapt]

I agree with your assertion that 1 year isn't enough to do more than scratch the surface of a language. However, I also agree with the author that learning new languages add to your primary skill set. A new language provides the framework for exploring new ways to look at things. You may be using the term concept to represent this idea.

The atomic detail of assembly, the procedural nature of C, the set orientation of SQL, the macro focus of TeX have all given me new ways to look at problems that have paid off in my Perl programming. I don't think I would have developed these perspectives without the framework provided by these languages. I do most of my work in Perl and SQL but every now and then, I will try to solve a small problem using another language/tool just for the experience. It usually pays off.

I won't say I've learned a language a year but, it is amazing how much you do pick up a little at a time. Now that I think of it, the only language I have't gotten much out of is VB. I don't mean to knock BASIC you understand-I learned to program in BASIC-It's just that I don't think I've gotten much out of recent versions. I learned more from LOTUS 1-2-3 HAL than I ever have from Excel VBA (I know VB and VBA are not quite the same thing but the point is still the same).

The real strength I've found is to develop an approach that fits you and then grow that style to handle new and varied problems. ( a somewhat more expansive variation of zentara's one punch philosophy )

[hardburn]

The one thing I got out of VB: the idea of having two different division operators. One for integer division, and one for floating-point division. It seems like a really Perlish idea to me. Although it also seems to me that VB's type system ought to be able to tell if you're assigning to a float or to an int and Do the Right Thing. It doesn't make sense in even a nominially static typed language like VB, though it would fit right in with Perl.

[itub]

Pascal was like this: there was / and there was div.

[apotheon]

OCaml does that as well. It uses a type inference system with static typing, though, so it makes a lot of sense for OCaml.

edit: Woah, I didn't notice the timestamps here at first. This response is a little late.

[zentara]

I had a "self-defense instructor" tell me once, that if I was an amateur, and couldn't devote myself to full-time training, to "learn 1 blow, and concentrate on throwing it well".

That is my approach with programming too. I like Perl, Perl can do just about anything I want, so I figure I'm better off learning Perl well, than being half-ass at 5 different languages. Even after 5 years, I'm only three-fifths-ass at Perl. :-)

[dimar]

Which brings up an interesting point, is it possible for *anyone* to be 100%-ass at *any* language?

Oh, sure, every community has its 'gurus' ... but even if you spend every waking moment mastering your chosen 'school of thought' the wheel keeps turning and inevitably your goal becomes a moving target.

If you want to become a master of the English language, why study English exclusively? English is changing subtly and overtly right from under us (jargon, slang, cultural trends, values)

You may benefit more by comparing it to Esperanto, French, Arabic and Japanese ... comparing differences helps you see the forest for the trees.

No matter where you go in the world, you can never know *everything* about a given city, so why not try to visit a new one each year, and take some souvinirs back to the place you call "home"

[hardburn]

For any reasonably complex field of study, you'll eventually hit a point of diminishing returns on what you can learn further. You can keep figuring out new things, but it'll take more effort.

A lot of programmers brag that they can learn a new language in a day. That's only true if you squint enough. Getting the full use out of a language will take years of study. That's especially true of systems like LISP, Unix, and Euclidian Geometry, where the basic system is made of a few simple parts that combine in incrediably complex ways. It's easy to learn the basics of such a system, but the combinational explosion cannot be grasped so easily.

[SpanishInquisition]

• Lisp makes me think differently. And in weird (good) awys.
• Ruby lets me know what clean Perl and magic simplicity looks like. (And reminds me why package management needs to be orderly)
• C teaches me how to create order where there is no order. Plus, it allows me to get "real" work done when there are no bindings for something in a HLL.
• C++ reminds me to only selectively use language features and how to be skeptical.
• Batch languages and shell scripts (and make) remind me that sometimes you just need to keep it simple.
• Java reminds me what anti-design is. And really, how to write REAL OO by using it as a counter-example.
• Python reminds me how a solution to a problem can still be a problem
• Pascal. Hmm. Teaching languages. Those languages that can't do... (grr...)
• (GW) Basic reminds me how even bad languages can be fun to play with and can be made useful.
• SQL is useful as both a toolkit and an idea -- 4GL's -- dealing with arbitrary input to do arbitrary things, flexibility
• Haskell and OCaml are on the "to visit" list. Unless something funkier comes along. Functional Programming is the right kind of mind bending...

Of all, Lisp most changed how I think, I'll probably never use it again ... the point is that you don't get yourself in a rut where you think in a certain way and don't change it. Even languages you don't like (some may actually like ones I don't), can provide lessons on language design, software design, and programming style.

Computer Science is no more about computers than astronomy is about telescopes.

Replace "computers" with "programming languages" and you get my general point. The same goes with operating systems. Just using Windows, or just Linux, or just Mac ... you miss out on the differences and ways to borrow from them all. However, the downside of being worldly in such persuits, is you start to find your perfect language doesn't exist ... and you would have to make it yourself!

Yeah, it's about concepts though. I discard 80% of what I learn. And that keeps me sharp. The language list on the resume are the ones I could still employ, I keep LISP on there just to show I know how to think functionally because if you put "functional programming" on a resume, most OOP-biased managers think you are talking about procedural (which is NOT really bad either) code -- and they've probably been conditioned against it.

I was always ticked when my university made programming about languages. My best professors didn't even write code on the board. Computer graphics was about math. Finite automata was about math. AI was about algorithms and data structures. And all those things have changed the way I code. Do I remember anything from CS1 and CS2 (first badly-trained C++ and later Java-centric courses)? I've tried to UNLEARN it. I do Java at work but I don't let it change the way I think...

My desert island list is C and Perl. I'll learn the corners of those, what I don't already know. They are tools. Languages are tools. These are the sharpest tools (or heaviest hammers), and beyond that what is most important is your brain. If a language is boring and uninteresting, skip it unless forced (or it's required resume experience...though I don't recommend working where you don't like it -- been there, doing that).

One rant I see is that employers often don't recognize that interviewees (sp?) are sometimes really sharp people that think abstractly -- they are looking for ACME-FOO 9.6 and you have ACME-BAR, they don't want you. They don't know how to seperate thinkers from implementers.

[talexb]

Hmm, not sure I can match Herveus' list of 28 languages .. I graduated high school in '75 so you'd think I'd learned a few along the way ..

1. BASIC
2. Some exposure to APL, my Dad's favourite language
3. COBOL at university. Y2K was still over 20 years away. Who knew?
4. Assembler in various flavours (bit-slice, 6809, 68000). Fun, fun stuff. And fast.
5. C -- still have the K&R I bought in November 1981. Almost like writing in assembler.
6. DOS batch files -- ugh, clumsy.
7. Pascal -- ugh, I hate over-typed languages. And feeble pointer support, too.
8. REXX -- ugh, almost incomprehensible.
9. awk -- pretty handy little tool.
10. Perl -- wow. Wow.
11. SQL -- various flavours.
12. bash scripting -- way better than REXX or DOS batch files, still not my favourite way to get things done.
13. Ruby -- only very recent experiments.
So only 13 languages on my list. That works out to be about two per year.

Actually, my test of whether or not you know a language is whether you can teach someone else the language. I did that with C, and consider myself a (past) master of that language. I'm still learning Perl .. there are dark OO corners that I really just don't get, and I still haven't mastered regular expressions. I get AUTOLOAD now, and I even get MethodMaker (cool craziness). Nothing on CPAN yet.

What I take away from the Pragmatic Programmer is that you've always got to be learning, explanding your mind. If you let yourself get stale, then you're not exercising your brain. One way to keep the brain active is to learn a new launguage. One a year is impossible -- I don't have time for that, but I do have time to try new SysAdmin things on my Linux box, try a few things with Ruby, follow up on some of the programming ideas that have been percolating for a while.

Conclusion? If you're in shape, you can reel off the latest technical book you've read, or the cool feature you've found and used recently. If you're not in shape, you just go in to work, stumble through your eight hours and wish for the weekend. Your choice.

Update: Good grief, I forgot FORTRAN, my highest mark at university (yay). That would show up as 2a.

[coreolyn]

The benefits I've received from leaning new languages on a regular basis are, OS/Language de-mystification, cultural expansion, and wider professional and social acceptance

I tend to agree that with the exception of my foray into Smalltalk most were just exercises in memorizing different semantics. But for the time that I put in I gained back the ability to converse with more people and those people opened many doors that would not have been open to me if I did not at least have a minimally functional understanding of their language of choice.

Every language seems to create a slightly different culture of devotee's around it. Each of these cultures seem to understand the strengths of different aspects of approach to problems. This, more so than the learning the language itself, seems to be the biggest benefit I've received from learning multiple languages.

Probably the easiest way this can be understood is in gaining the understanding of what is "Perlish" and what is "Pythonish".

Looks for lightening to strike....

Just another .02 for the pick a penny

[dimar]

I wonder what they call the subculture of people who willingly and happily traverse "language boundaries" without overtly becoming a devotee of any single camp?

"Under appreciated?"

[coreolyn]

Employed

[DrHyde]

I intend to learn Faroese and Arabic in the next two years, does that count?

[Tabari]

Did you manage to do that? Please give me a hint as to how, I am learning Arabic for 20 years and am just scratching the surface.
As for perl , I am using it for a long time and am still stunned at its possibilities (not to mention Perl6, I can't wait till Christmas Getting Involved with Perl6 )

[herveus]

Howdy!

Hmmm...lessee...I'm coming up on 30 years since I graduated from high school... In no particular order, I've learned and written code in the following languages:

1. Algol
2. TUTOR
3. C
4. Pascal
5. FORTRAN
6. COBOL
7. Z80 assembler
8. PDP-11 assembler
9. BASIC
10. awk
11. (k)sh
12. csh
13. Perl
14. Lisp
15. Pilot
16. CourseWriter
17. DOS batch
18. Java
19. SQL (multiple dialects)
20. HyperTalk
21. Postscript
22. C++
23. (Web)Focus
24. PMS
25. Forth
26. JavaScript
27. Business Objects (I think)
28. ...

I may have left a couple out... OK, so it's not quite one per year in the long run, but it comes pretty close...

[dws]

But I don't buy the advice: "Learn at least one new language every year".

How about "Learn at least one new framework every year."

Things have calmed down in the language space, and the energy has moved into frameworks. Already learned Python? Study Zope. You can easily spend a year there if you're limited to a few hours a week. Learned Ruby? Experiment with the Rails framework. Plenty of good ideas there.

[geekgrrl]

I think you can become reasonably competent in a language in a year. I was hacking out awesome Lisp macros after five months or so of programming in it. Also, taking a course or two on programming languages can be educational - you don't have to be a guru in a language to use it or pick up useful ideas from it.

Also - why are you blowing off some of these languages? Sure, I don't want to get a full time job coding Java but there are lots of good things to learn from it. Sometimes you learn what you really don't like! Also - why does everyone hate Lisp so much? What is it about parens that just turns everyone off? Its actually a very cool language but I think most people are just so scared or intimidated or turned off because it doesn't look like C.

well there's my two cents.

Personally, I wouldn't mind learning Ruby and Japanese. (perhaps a ruby job in Japan?). And Arc, if it ever gets released.

--rachel

[stvn]

So much has already been said here, but I still wanted to throw in my 2 cents.

I agree with you, a year is not enough to really learn a langauge. But that is not to say you cannot still learn a lot from even a few months of light study and experimentation. And I think that is their point, to (at a minimum) expose yourself to something new and try to gain a new perspective from it.

Personally, I have never written an application in Erlang, but I learned a number of very valuable concepts from the langauge which I use regularly in my perl code. I once spent a vacation reading a book on Lucid and I never looked at arrays and parrallellism the same since. I have never written anything more than a toy in LISP, but I tend to mark my growth as a programmer in terms of before LISP and after LISP. I have never written a real-time distributed system in Ada 95, but I learned a lot of very useful stuff by reading a book about it. I can say the same for FORTH, Standard ML, Eiffel and Smalltalk; never used them for real, but learned a lot from reading and fooling around with them.

I also have books (that I got off Ebay for cheap) kicking around about SNOBOL, Fortran, CLU and Algol. I have read/skimmed enough of them to understand some of the basics of what they have to offer. Sure they may not be useful outside of niche uses, but it is interesting to me from a historical perspective to see how languages have evolved. Which in turn helps me to see why some of the languages of today are as they are.

I guess my point really is that you don't need to be the worlds best <insert programming language here> hacker to learn important and valuable concepts which can be applicable in your everyday work. Sometimes it's best to just do it for fun ;-)

[tmoertel]

If the goal is to master the most languages, then one year probably isn't enough time. But if the goal is to learn the most, and to be the best programmers we can be, one year is probably as good of a guideline to follow as any.

Our brains are extremely good at selecting and retaining useful information while letting less important things fade away. We get the most value from our brains by feeding them lots of weird, new ideas. That way, our brains will have more opportunities to find and retain new, useful ideas and add them to our "working set" of knowledge.

If, on the other hand, we feed our brains with the same ideas over and over again, we can't take advantage of the amazing selection and filtering capacity at our disposal. For this reason, I think the best learning strategy is to maximize the likelihood of being exposed to new, valuable ideas.

When learning programming languages, then, it pays to choose the languages that are the most different from those we already know and yet are still likely to be practical. If Perl is our first language, for example, choosing Python or Ruby as a second language probably isn't the wisest learning investment we could make. Most likely, Scheme or Haskell or Erlang would be a better use of our time and brain cells.

Similarly, once we start to learn a new language, we become exposed to its radical new ideas quickly, and from then on the quantity of new ideas fades rapidly. It's a classic case of diminishing returns. Once again, we risk re-learning the same old ideas and not using our capacity to its fullest.

For these reasons, I think that the one-new-language-per-year guideline is reasonable. While one year may not be enough time to master a new language, that time probably is sufficient to provide reasonable exposure to the most valuable new ideas that a language has to offer. It also makes a good milepost at which to stop and ask ourselves whether switching to another new language would be a better investment than continuing with the current language.

Cheers!
Tom