Programming Background

When I got out of school, I thought I was the best programmer in the world. I could write an unbeatable tic-tac-toe program, use five different computer languages, and create 1000-line programs that WORKED. (Really!) Then I got out into the Real World. My first task in the Real World was to read and understand a 200,000-line FORTRAN program, then speed it up by a factor of two. Any Real Programmer will tell you that all the Structured Coding in the world won't help you solve a problem like that -- it takes actual talent.

— Ed Pest, "Real Programmers Don't Write Pascal"

The following information is here mostly so that you can evaluate my opinions regarding programming languages. One's choice and view of languages is, in my opinion, very much driven by one's background and problem domain.

I started programming in late 1983 (yes, I still have it -- no, I'm not going to show it to you) using VMS BASIC. For those who aren't familiar with it, think QuickBASIC; they're surprisingly similar. For those who don't know either, think BASIC with some structured programming tools (like IF and WHILE blocks without needing line numbers), a statement modifier form of IF, and a way of defining procedures and functions but without separate variable namespaces. I fiddled around with it for quite a few years, as well as straight line-number BASIC (on the Commodore VIC-20).

Around the same time, I also did a bit of programming in DCL, which is a rather odd language. These days, I'd describe it as what you'd get if you took a shell like bash but with a Fortran-like syntax and grafted on a decent chunk of Perl's standard library set.

I moved on to QuickBASIC in about 1986, 1987, and wrote the first programs that I'd really call full programs in it (a program to control a Citizen 120D printer, and a little arcade game). I stuck with QuickBASIC for a good many years until college. It's actually a fairly nice language, although it suffers badly from the lack of real procedures with private variables and therefore is only semi-suited for real structured programming.

I played around a little bit with x86 assembly language, enough to write a simple bubble sort and some other similar things, but I don't remember any of it. I also played around with C enough to understand the basic concepts, but not enough to switch to it.

In 1990 and 1991, I got a crash course in a bunch of languages, taking one-semester courses in Fortran, COBOL, x86 assembly language, and Pascal. Fortran is interesting but not particularly useful to me. COBOL was rather fascinating, and to this day I still really like the language, even though the syntax is very ugly. It makes some tasks, like report generation, remarkably easy, and it's maligned much more than it deserves.

The most useful thing gained from learning x86 assembly language was really understanding pointers and exactly how they worked.

Pascal stuck, of all those languages. In particular, Turbo Pascal, which has pointers and therefore is a lot more C-like than some of the Pascals. For the next few years, I did all my major programming and wrote several more applications in Turbo Pascal, and even played some with Borland Object Pascal writing full-blown Windows applications (with icons and resources and whatnot) for Windows 3.1. It was fun at the time, and I'm not particularly interested in ever going back to that.

In 1993, I was exposed to Standard ML (the New Jersey implementation), which was absolutely fascinating as a complete departure from anything I'd ever done before. Unfortunately, I never got a chance to do anything real in the language, just implement a few abstract data structures like trees, but I did at least get exposed to the concept of pattern matching (for those not familiar with functional programming languages, pattern matching in this context is completely unrelated to regular expressions). At the same time, I also got quick crash courses in Ada, C, C++, and some OO variety of Lisp (not that we ever used the OO parts).

C was trivial to pick up after Turbo Pascal, and since everything I used was Unix, Turbo Pascal didn't exist on Unix, and everything was written in C, I started writing C and pretty much never looked back. Some school projects used a bit of C++, but except for a complete nightmare project using Symantec C++ on the Macintosh in 1995 (never, never, never again), none of them really made any significant use of object orientation.

I've never really been converted to the benefits of an OO mindset in the general case. I understand it, and I write object-oriented C code when it seems worthwhile, but I default to writing non-OO code unless there's some obvious reason not to. Frequently it just feels like pointless overhead.

In late 1993, 1994, and 1995, I also learned TinyMUSH programming, which is an interesting and different perspective, being entirely event-driven and object-oriented in a more fundamental and grounded way. All the code exists as elements attached to objects and can define additional commands for anyone in the vicinity of that object that, when entered by a user, trigger the execution of the code. I still have some formatted TinyMUSH code I wrote (along with the Perl script that strips the formatting and turns it into something suitable for upload via TinyFugue /quote) that I should put up on these pages sometime as a curiousity.

I learned lex and yacc in 1994, re-learned lex and yacc after I graduated and was writing a system log rotation program and wanted a configuration file, and learned to hate lex and yacc while working on maintaining INN. yacc in particular drops a bunch of global cruft into your program and requires that I relearn its entire syntax each time I want to use it since it won't stick in my head. (Admittedly, for a complex syntax, it's a lot nicer than trying to write an unstructured parser with error recovery by hand. And I never really did understand parser construction well, although I also haven't tried hard to learn it.)

In the summer of 1995, I learned Perl, and immediately fell in love with it. It fit my normal problem domain perfectly (I'm a systems administrator and hacker who does a lot of stuff with network protocols and with moving files around on Unix boxes, not to mention lots of fiddling with text-based files of all sorts), and it fit the way I thought. Since then, I've slowly become what probably qualifies as an expert in Perl; I've written several modules that are now included in Perl core, I've done some Perl XS hacking inside INN, I understand some of the more obscure parts of the language like ties, and I've been following and participating on perl5-porters for years now.

Around 1996 and 1997, I worked with C++ some more while doing some research projects as part of my master's degree, but I never really got very deep into the language (and don't particularly like it). C++ feels far too crufty and full of special cases for me.

Since then, the only languages I've really used extensively have been Perl (my first language of choice for most problems) and C. I've helped maintain INN, a fairly large portable C program that uses autoconf, and I've written a few other non-trivial applications in C, and am pretty comfortable with it. I've also written a goodly number of Bourne shell scripts, although Bourne shell is easy enough to learn for anyone with any programming background (and particularly for anyone with Perl background) that I don't really count it. (I learned Perl before I learned shell, which is backwards from most people.) I've dabbled in a bit of Tcl, but not enough to really have a well-considered opinion about the language.

I have a master's degree from Stanford in software theory, but most of what I did for that degree was related to mathematical models of concurrency and I did far more set theory than programming language theory. I do have some basic exposure to compiler theory and the fundamentals of programming language theory. I understand lambda calculus (although I may have to reach for the more subtle stuff these days), and I'm familiar with and rather like currying. Most of those skills haven't been exercised much since I graduated (in 1997) and went to work full-time as a systems administrator.

As of April, 2001, I'm starting to work on picking up a few new languages, having decided that I've been using the same tools for a bit too long without a fresh perspective.