Tuesday, June 19, 2012

How I Met Your Editor

Kids, I first met your editor in the early weeks of semester one in second year uni (circa early '90s). I tried vi one night in the labs and experienced my first software panic attack - how the heck do you exit this thing?! I promptly put it down and used emacs in a barely-better-than-notepad fashion for several weeks thereafter.
One day I was in a CS lab and a guy needed to change a variable across several different files. The prof said, "just use sed". The stench of stale foods from our gaping mouths informed him that we had no idea what he was talking about. He promptly sat down in the guy's chair and started banging out a sed line. It was all wiggles and swirls of an arcane tongue none of us spoke, but we all watched wide-eyed as he finished his one-liner and with a flick of the wrist had accomplished what it would have taken us in our clumsy editors an hour to do, I'm sure.
I was sold. Right then I decided to pursue this magical path of Awesome Editing and I am today so glad to have been there at that time to be so inspired.
I taught CS in several unis and tafes in Oz and there were a few things I'd always try to impress upon my students before the semester was over:
  1. Master a text editor. In those days, the choice was emacs or vi.  That's pretty much still the case, as far as I'm concerned. Religion aside, the text editor is the workbench of your craft. Mastery here is not optional.
  2. Master the shell. At uni, we used Sparc (iirc) X dumb-terminals. We didn't have GUI file managers or drag & drop desktops. We had to use the shell. I thank the gods for this. As a modern CS undergrad, you have to make extra efforts to immerse yourself in the world of the shell, and I heartily advise you to do so.
  3. Master regular expressions. Regexes are by far the sharpest tool in the coders toolbox. A competent coder will read and write dozens if not hundreds of regexes every day in the course of their work, either directly in the code they're writing or incidentally through their editor and shell. A regexless CS grad isn't one, imho.
  4. Embrace polygramy. Professing knowledge of a single language is naive and narrow minded. While you do not need to be a master of many languages, you should have at least seen each of the major programming paradigms: functional (e.g. Lisp / Scheme / Haskell), procedural (e.g. C), object-oriented (e.g. Java / C++ / Ruby / Python), declarative (e.g. SQL / Regex / Prolog) and even assembly language. I've abused the hierarchy and set membership a tad there, but the point is to play with more than one style of programming.  Another important message here is to be equally well versed in compiled languages as scripting languages. And don't be fooled by the seemingly missing suite of modern, hip languages - the languages cited above represent well-known examples within their categories. Of course I heartily recommend learning any new language.
There are many more things that make for a good CS grad these days.  The set of skills one must know seems larger than when I graduated, and the rate of new arrivals would seem overwhelming. I'd hardly expect a CS grad these days to not be au fait in at least one distributed version control system, for example. However, the skills I have outlined above should provide a solid foundation upon which any CS grad can build their tower of song.

It would be a waste for me to waffle on any more here about this.  Suffice to say, I recommend the passionate programmer to bask in the wisdom of these fine tomes:

What do you think?

Is this still valid advice for the modern CS undergrad? What more or else would you advise the burgeoning programming student to pursue?


  1. Version control (and related set of good development practices: testing, reviewing and so on). And compilers.

  2. By compilers, do you mean the craft of building your own compiler? I must admit, that was my favourite unit at uni and I think every CS grad should know how to do at least rudimentary parsing.