At the Geek Ranch we recently made a decision to implement some software in Python. Or, more accurately, I decided and there was no disagreement. Then Python gets picked as the best scripting language in the LJ Readers' Choice survey. That inspired me to write this article (and get ready for Perl and Ruby fans to start yelling at me).

To understand my position, you need to understand my background and experience. Yeah, this is is going to be long but I think it is necessary.

The first programming language I learned was Fortran with Format over 40 years ago. Fortran quickly evolved and I learned Fortran II, Fortran IV and Fortran V. For you Fortran folks, I need to explain Fortran V.

Based on Fortran IV, Fortran V was implemented on Univac 1100-series hardware (and probably other Univac systems such as the 494) by Computer Sciences Corporation in the late 1960s. It extended Fortran to include parameter statements—basically a way to define constants, conditional compilation, and statement functions—basically macros that produced in-line code.

In 1970, I went to work for Computer Sciences Corporation working on systems testing of a new timesharing system they were developing called CSTS. While some of my work was done in assembly language, the majority was done in Fortran V. For me, it was the "best scripting language" I had available. (It was also the only language I had available on CSTS itself for a while.)

Except for toying with Sympl, a language designed by CSC for systems programming that I used on CDC Cyber systems, Fortran remained my primary high-level "solve the problem" language until 1980. The other languages in my life were assembly language for various processors including the Motorola 6800, 6809 and 68000.

The one diversion from that was a bit of time with Pascal. This was somewhat accidental. I secured a part-time job teaching a Programming Style class at The Evergreen State College. The course outline made sense to me and the interview went well. The surprise was when I accepted the job and my boss said, "oh, here is the text book we use". While the class was mostly theory, Pascal was "the tool" used to put theory into practice.

Armed with a Pascal compiler for my SWTP 6809 system, I learned Pascal two weeks ahead of my students and all went well. Pascal was designed to be a teaching language and it made a lot of sense. It, for example, forces you to jump through hoops to do type conversion preventing programming surprises.

In 1980 I got a job with a company that made semiconductor wafer probers. Their past systems had been controlled with little more than a bunch of hardware logic but we were going to make the ultimate prober. That included the ability to memorize the layout of a chip and then automatically align the prober to the chips when a new die (a round silicon wafer with multiple chips on it) was placed on it.

Being the software guru, I needed to decide in what language we would implement this system. I initially thought Pascal would work and ordered two different Pascal compilers for our CP/M system. To make a long story short, Pascal wasn't ready for prime time. To make it into a "production language" it was extended badly.

This lead me to a new decision: we needed a UNIX system and we would develop in C. My boss believed me (he didn't know anything about software, UNIX or C) and I ordered everything. What he didn't know at the time was that I had never seen a UNIX system and had never programmed in C.

UNIX and C proved themselves, the project was a success and I moved on to the next company to pretty much do the same thing. But, as I got more comfortable with UNIX I decided I needed a higher level language for some of my work. After looking around a bit, I decided awk was that language. It was and, to me, still is an amazingly useful language if what you have is some character data that needs to be massaged. I even went as far as writing a web application which allowed customers to inquire as to the status of their order in awk just to prove it could be done. And it wasn't even painful to do.

In a more "awkish" venture, my old boss who was now at a company that made microprocessor hardware emulators, asked me if I could do a project for him. They were converting from a 6809-based emulator to a 68000-based one and needed to convert thousands of lines of instruction set encode and decode tables from 6809 assembly language to C. He had estimated a month to do the task assuming it would be done in C. I did it in about three days using awk and sed.

So, I was now a C programmer and an awk scripter. The problem was that there was a gap in my toolset. Unlike Fortran V where I even found a way to build and execute assembly language code within the Fortran framework, if I wanted to do anything other than process characters, I had to write the code in C. In most cases this wasn't bad but sometimes 99% of a task could easily be done in a few lines of awk but would require a lot of C.

Well, in 1999 I had the opportunity to interview Guido von Rossum, the father of Python. While I had already been playing with Python, my chat with Guido (a lot more than an interview) inspired me to get more serious. The interview actually addresses what is wrong with awk and Perl so I won't go into more detail here.

While my life in the last almost ten years has not been primarily programming, I do turn to Python as my tool of choice. Some of what I have done can be called scripting but not all. For example, I implemented a credit card processing system for Visanet (the nastiest of all possible credit card protocols) in Python. I also have done some work with Karrigell, a web framework implemented in Python.

Ok, I talked about awk's limitations and Guido helped me beat up Perl in the interview. Note that my default comment about Perl is that if you don't know regular expressions and UNIX/Linux shell programming, Perl is not the best way to get to knowing a scripting language. So, what's left? The obvious choice is Ruby.

Well, this is where my long, boring history of my Pascal experience fits in. First, let me say that I like Ruby. It is a nicely-designed and very clean language. If you don't already know Python, you should seriously give it a try. But, is it better than Python? I think not.

Ruby, while not really new, just hasn't done as much work as Python. Much like Pascal 30 years ago, Ruby looks good on paper. Pascal's claim to fame was that there were no surprises. Ruby's is that it is pure object oriented. Those are both good things. But, as Ruby does more heavy lifting, it seems likely to me that it will have to evolve. That is, its purity will get subverted much like the purity of Pascal did.

In any case, I will stick with Python. It has certainly evolved over the years but that evolution feels like taking a solid base, seeing what makes it more useful and cleanly handling the evolution. To me, Python 2.5 is easier to explain to someone that Python 1.5.2.