Language Dabbling Considered Wasteful

http://duartes.org/gustavo/blog/post/language-dabbling-considered-wasteful

Learning new programming languages is often a waste of time for professional programmers. It may be a fun waste of time (i.e., a hobby), but it’s a waste nonetheless. If you do it for pleasure, then great, but profit is scarce. Pointing this out among good programmers is heresy: even the pragmatic programmers, whose teachings are by and large excellent, suggest we should learn one new programming language every year. That’s rubbish.

The theory is that by learning a new language you "expand your mind" and become "a better programmer". Right. By that kind of argument we should all be eating LSD (don’t). In reality learning a new language is a gritty business in which most of the effort is spent on low-value tasks with poor return on time invested. You need to get to know the libraries, struggle with the environment, find or tune a text editor, look for tools, and so on. Most of the effort has to do with housekeeping chores, which are surely not mind-expanding by anyone’s measure. If you hope to be productive in the new language, things are even bleaker: proficiency has less to do with the language itself than with the myriad technologies you must master to use it effectively.

Even core language learning offers dubious return. How much does it really help to learn a new syntax? How does it expand your mind to learn new operator precedence quirks? Much of what constitutes a language is lexical and syntactical bureaucracy. Worse, you’re learning absolutely nothing about fundamental aspects of computer science. No algorithms, no operating systems, no compiler theory, no math, no AI. If you’re an undergrad, then you should have time to pick up languages on the side while learning all that, of course. But a professional is making a trade-off: what else could you learn with that time? We’re better off studying business, security, usability, architecture, software estimation, and so on, rather than spending time with a different language every year.

If your goal is better programming, you will learn far more from reading high-quality code bases in your current languages than from a new language. Go read top-notch code in the languages you know already; it’ll teach you techniques and style quickly, plus different ways of thinking about problems, with the added bonus that you can actually use what you learn. You can also understand a lot about programming languages in general (issues like typing, scoping, functional vs. imperative) by reading a good book.

There’s another pernicious effect to language hopping: it hurts your momentum. Every time you rely on your current languages you get a little better. Not in a fluffy expand-your-mind way, but in a concrete way. You learn more about your libraries, you set up a new macro in the editor, you have a chance to use that new language feature. Scott Hanselman argues that learning a new language is sharpening your saw, but I see it as neglecting your half-sharpened saw while playing with the dull, new, shiny one. The upfront cost is not the only one either. It’s better to have 3 razor-sharp saws than 8 so-so ones. Each new language you add to your toolbox is making it harder for you to become furiously productive in any given language.

>>1
Yet, any programmer worth their weight in silicon must know multiple languages. Sometimes the new saw is of a different type altogether, and it’s worth having. Right off the bat there are major obvious reasons. Different systems or parts of a system call for different languages; that’s been true in any environment I’ve ever worked in. For a while this was mostly due to speed and level of control. My first apps were written for MS-DOS in Clipper, which was a database-oriented rapid development language. Fast to develop, but no power. Soon enough we wanted to add features that called for C and assembly. Using C we could write terminate and stay resident (TSR) programs and spice up our apps with features no one else had. Sometimes the issue was not so much power, but speed. There have been many happy marriages to deal with this: Tcl and C, VB and C++, Perl and C, you name it. Fast processors and web apps have largely killed the speed/power motive. Computers can happily run applications written wholly in Python or Ruby. And if they can’t, a different language probably won’t help; you just need more web servers. But alas, you now need to know SQL and JavaScript too, so we’re back to obvious reasons for multiple languages.

Aside from the immediate reasons, there’s some merit to the mind expansion argument. I think being proficient in at least two languages is indeed important for boosting your ability as a developer. This resembles human language: learning a second one changes the way you think and your perception of the world. The third or fourth, not as much. But it can’t be any two languages. If you know Portuguese and Spanish, your mind didn’t have to expand much. Likewise, learning VB.net and C# doesn’t count. Also, I agree that some programming languages are hazardous to your skills if used exclusively. Edsger Dijkstra claimed COBOL crippled the mind and that its teaching should be regarded as criminal offense. We all know who’s the new COBOL. Java, the kingdom of nouns, is a programming straight jacket. I imagine Dijkstra would have called for harsh no-parole sentences for any CS Department chairs whose students learn only Java. If you write a lot of Java code, being fluent in a richer language does sharpen your saw. This is true for other statically typed languages, but to varying degrees. More on that in a bit.

You might think this is contradictory. You’d be right. Life’s not simple; sorry, I wish it were. The realities are:

- Learning new languages is very expensive (in time), a huge opportunity cost
- There is loss associated with using multiple languages: the "jack of all trades, master of none" problem
- A good programmer uses multiple languages

But there’s a sane way to deal with these. Why, you just need to find the minimal language set. The smallest set of languages it takes to crank out great software quickly while growing as a programmer and making rivers of cash. In the next entry I’ll talk about my personal language set and the factors I used to compose it.

By that kind of argument we should all be eating LSD (don’t).
Was sagst du krazy mann? LSD ist einer wünderlich invention.

once you learn python you can stop learning other languages and start forgetting the other languages you already knew

>>4

#include <Python.h>

learn lisp

problem solved

>>6
>CANCEL DOWNLOAD

>>7
y u so mad tho lol gb2segfault faget

>>8
FUCK YOU FAGGOT

>>9
lolol is ur buffer overflow is ur porgarm segfault
U MENA SEPPLES

TL;DR

If you know only one language, you suck, regardless of what it is. You NEED to learn different programming paradigms and different approaches to different problems. That doesn't mean "herp, learn a n00 language every x, derp". If a language won't teach you anything new, there's no point in learning it.

You're not a good programmer if you don't know, and appreciate, every one of those languages or ones that are very similar to them: C, C++, Lisp, Haskell, Python, JavaScript (FUCK YOU, YES JAVASCRIPT), Java, Ruby, FORTH, Assembly and [insert an assortment of declarative and non-programming languages like SQL, logic languages, HTML, etc.]

The point is that you have to be familiar with every main paradigm. Structured, imperative, functional, OO (both class-based and prototype-based), both strict-type and lazily-evaluated, the new, ``dynamic'' languages (JS is a pretty dynamic, despite being shit in many ways), as well as different approaches to old paradigms, even if they're not good. (Ruby is a prime example)

If you know all of those languages, and you wanted to learn, say, Visual BASIC, I'd say drop it. You won't gain anything from learning it. But if you want to add a new language that will teach you something new, then definitely go for it.

>>11
OO (both class-based and prototype-based)
You speak like those are the only existing approaches to OOP.

You have made a list of mixed shitty languages, that are useful for the ``real world'', but will teach you bad habits, and the so-called mind-openers, said to be useless in ``real world''. I don't see Smalltalk there too.

List of decent, real languages for each paradigm:
Structured: ALGOL. You can hate structured language however you want, but ALGOL was one of the most influent programming languages, and was pretty nice too. I really can't see how C and derivates could ruin it so much.

OOP (Prototypes): Io. Why not JS? JavaScript is an impure piece of shit. Its potential got completely destroyed by the ``Java'' part of its name, even if it has nothing to do with it. So, not only you have to deal with retarded coercion rules, but also need to deal with a bastardized function syntax to define objects. Io is a pure, homoiconic prototype-based OOP language, so it's the best way to learn this paradigm.

OOP (Message-passing): Smalltalk, then Scheme. Objective C and Ruby suck. If you want to be hip and cool, programming is not about being cool, and you should find another hobby. Many think that Smalltalk is OOP done right, and it's one of the three languages I always raccomend (the others being Lisp and Forth). Why Scheme? Because writing a simple message-passing OOP system in it is just one page of code, and a perfect way to understand what's going when you pass a message to an object.

OOP (Multi-dispatching): CLOS-like object systems. No need to say more. Read TinyCLOS' source code.

OOP (Class-based): One of the worst approaches to object-orientation. There's no class-based language that does not suck, as far as I know. Learn some C#, if you need to do some real world work. If you really need it.

Lisp (Lisp): Lisp/Scheme. Learning them will make you a better programmer, even if you'll never actually use them. Most concepts in modern high-level programming languages come from Lisps. Read SICP.

Functional (impure, strict): Scheme. I'm not a fan of Ocaml, and its syntax is pretty horrible too. Scheme is decent at being functional, and its tiny core will make you spend more time on thinking how abstract the problem than chaining functions.

Functional (pure, lazy): Haskell/Clean. They are similiar, but Haskell has nomads. They are not as scary as you may think, when you'll understand them you'll realize how much a stupid mental masturbation they are. It's still good to know them. Idiomatic Haskell code tends to be point-free, teaching you how to compose functions and split a problem in many smaller problems. The forced immutability will show you how overrated is mutable state.

Stack-based: Forth.

Low-level: Your architecture's assembly language, Forth. Forth is the best low-level programming language, and it's complementary to Lisp. It really does give the programmer the full control over the machine and the language. It's extensible assembly. If you want to learn it, jonesforth is a good start, but you'll need basic knowledge of x86 assembly, so read the Intel manuals first.

Congratulations, you're now a decent programmer.

>>11
You should have read it, he went on to discuss what you said pretty much.

>>13
I feel ashamed now that I have read his posts. He's right about everything. I assume he is >>12? Either way, thank you, >>12. And thank you, OP. This was a good read.