The Programmer Litmus Test

One of my current projects has induced me to learn Haskell, a rather dogmatic programming language notorious for its insistence on purely functional programming and extremely strict data type enforcement.  It's been both interesting and frustrating: Haskell clearly shows its origin in mathematical thinking.  On the good side, there is the elegant way that data types are inferred, the fact that sophisticated and subtle manipulations of mathematical functions are elementary to the language, and the intuitive handling to sets and recursion.  On the bad side, anything that doesn't fit the elegant paradigm is horribly painful to handle, when things do go wrong they go very wrong very quickly, and there is a mathematician-style culture of using single-character symbols and minimal comments.  I detest this last, since it renders programs extremely hard to decode.  It reminds me of a criticism of Perl that I once heard: "banging on the keyboard has a 50/50 chance of producing a valid program."

Learning Haskell also reminds me of a litmus test that I like, for testing whether somebody is a Real Programmer.  The test is a single simple question: 

"What programming languages do you know?"

If the person responds with a clear and simple list, they aren't are Real Programmer.

My own answer?  Well, mostly I work with C, C++, MATLAB, Lisp, Java, and now Haskell.  But I also deal with GNU make and bash and tcsh, some Python, recently a little SQL, then HTML and Javascript of course.  I've done a little bit of elisp hacking when I needed to, a little VHDL.  I don't know if I should count representation languages like SBOL or LTML.  Do nesC and AVR macros count as the same as C/C++ or separate?  I think the other parts of the autotools suite besides Make probably count as separate languages.  Almost forgot about regexp patterns, I think they count.  And parser definition languages like flex and yacc.  680x0 assembly, back in the day, when graphics accelerators and OpenGL didn't exist, and I guess I did some x86 assembly too in classes, and there was another processor, a toy processor specifically for classes whose name I don't remember.  Oh, and BASIC of course, my first language ever.  Research languages like Proto and MGS.  LabView made me use G---I hate graphical programming languages---though I guess Logo was fun as a kid.  I can't remember whether I ever actually wrote any AppleScript or not; same with SmallTalk.  Curl was another that came from classes, along with whatever it was we used for PAL programming before we switched to CPLDs and used VHDL instead.  Oh, and LaTeX of course---anything you can write quicksort in definitely counts as a programming language.

You get my point, I think.  I could probably keep going on for a while, and still not have everything.  This is part of the nature of working with code.  If you spend enough time working with enough complex systems, you'll inevitably have to tangle with lots of different programming languages, just through the pragmatics of making things work in whatever context of duct-tape and spackle your partners and predecessors have had to set up to get stuff done. Likewise, if you tangle with enough languages and gain a deep enough understanding of the underlying concepts, then picking up new languages is relatively easy---at least to an intermediate level.  Real Programmers have done both of these things, and it will have left its scars on their memory in one form or another---and I don't think you can really be fluent without it.

Note that being a Real Programmer doesn't necessarily make you any damned good at any particular task, though.  It just means you've got the potential to get there with a sharp learning curve if you've got the time and motivation.  For example, I'm no longer competent to carry out any but the most basic system administration tasks, since I stopped tracking that field early in grad school, which is why I own a Mac.

So, dear reader: are you a Real Programmer?