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"

Summary

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.

The resume version of my programming knowledge looks something like this:

Expert: Perl, C
Advanced: Autoconf
Intermediate: Automake, Bourne shell
Basic: Python, make, Emacs Lisp, lex, yacc
Familiar: PHP, Ruby, Java, C++
Forgotten: Pascal, BASIC, Fortran, DCL, COBOL

Languages marked expert I've used for many years, am familiar with most of the strange edge cases, and would be very surprised to encounter a language feature I wasn't aware of (although I've not kept pace with Perl 6 development). Advanced means that I know most of the edge cases and can answer most questions about that language, but am not familiar with every corner. Intermediate means that I'm generally comfortable in the language but might be a bit idiosyncratic about how I use it. Basic means that I can write a substantial program in that language, but I'll probably have the manual and library reference open while I do it.

The last two sets of languages are languages with which I have a passing familiarity but would have to do a lot of code copying and reading to write a program in, and languages that I once knew (sometimes very well), but which I haven't used in so many years that I'd have to relearn a lot of the language.

History

Pre-College

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.

College

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 was slow to adopt the object-oriented mindset, but at this point I'm mostly a convert. I still write small programs in a straightforward imperative model, but I use object-oriented structure for anything large. Ironically, most of my large-scale object-oriented programming has been in C, which is surprisingly capable as an object-oriented language even though the language doesn't have a lot of direct support for it.

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.

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.

Professional

Since graduating, the only languages I've used extensively have been Perl (my first language of choice for most problems) and C, plus supporting languages for C package development (make, Autoconf, and Automake). I've written multiple non-trivial applications in C as well as helped maintain INN and OpenAFS, and I use Autoconf and Automake for all C projects now. I've also written a goodly number of Bourne shell scripts. (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've used Perl in just about every way one can, from straight imperative or object-oriented pure Perl programs to both XS bindings for C libraries in Perl (multiple times) and embedding Perl in other software. I used to actively follow Perl development and I have several modules in Perl core, including the primary text and *roff POD converters.

I started learning Python in April of 2001 and completed a couple of projects in that language, but I never stuck with it for long enough to become as comfortable with it as Perl and C. I still have to reach for the standard library.

Most of my professional work has concentrated in C and Perl and on implementation rather than exploration, so I tend to keep reaching for the languages that I already know, which has made it hard to use other languages for long enough to consider switching, or at least turning to them more frequently. Usually there's a deadline involved and learning a new language would add unnecessary time. However, I have been exposed to several other languages as part of maintaining bindings and additional implementations for remctl, which is why I know some PHP, Ruby, and Java.

I've used Emacs as my primary editor since 1994 and have both extensively configured and customized Gnus and significantly enhanced the Emacs mode for editing Puppet manifests, so I have some practical experience with Emacs Lisp. It's still very much at the stage of reading and copying bits of other Emacs Lisp code, though, and that's the only functional-style programming language I've done much with.

As of 2010, I'm starting to study Java more comprehensively, as the first in a series of steps to refresh my understanding of programming and get back into the habit of studying and learning new ways to do things.