TuxTips

There is something that I have to admit, even though it may cost me a few geek points. I’m not fashionable. I’m not quite the old codger who things things were fine with punchcards and this internet thing is just a fad, I certainly enjoy using the latest version of $whizbang_app, and I’m happy to upgrade my hardware with acme’s Greatest-Thing-Ever(tm). I was using Linux on the desktop when most people were trying to decide if they should upgrade to Windows 98, and I was running Compiz when it was just a couple of tarballs and a neat video from Novell. In certain areas however, I am far more conservative.

As a software developer, it’s important for me to stay on the leading edge of software development trends. Fail to keep up and you could just find yourself stuck maintaining legacy code in a dreary job for the rest of your life. The problem is that software development is particularly prone to Best-Thing-Ever syndrome. Programmers are often accused of having ADD, and there are few places this accusation is so aptly demonstrated than in the seemingly weekly changes in “the one true language”, “the one true paradigm”, “the one true pattern”.

I’m not talking here about enterprise programming, although enterprise development certainly has it’s share of bandwagons. What I’m really talking about here is programmer culture (or what I would have called hacker culture had the term not been bastardized). I’m not trying to say that this is a bad thing, it’s part of what makes programming culture what it is, but it’s something to be aware of.

A lot of these “greatest things ever” are good ideas, often temporarily over-hyped, but they serve a solid purpose and are useful in their context. Even the ones that aren’t useful are often at least fun to play around with. Times change to quickly, however, and nobody can be an expert in (or even familiar with) every “greatest thing ever.” It’s easy to miss things because of lack of time, and sometimes “the greatest thing ever” just doesn’t seem so great, and it gets ignored.

Python, for me, has falling into both of the latter two categories. I originally looked at Python back in 2000, because I was interested in trying to fix a bug in Redhat’s Anaconda installer. Since Python hadn’t really gained the large following that it currently has, combined with the fact that I was a fairly inexperienced developer with limited internet access at the time, I never really got very far in my ambition, and quickly moved on. Python continued to grow however.

I started hearing a lot about python in 2006 or so, and by 2007 it had really started to reach a critical mass of popularity. Hearing all of the good things about Python, and remembering back when I had tried to learn it several years ago, I decided to look back in on it early in 2007. Perhaps it was too soon since I’d had to take a COBOL class and the significant whitespace thing put me off, or maybe the stars were just aligned in a certain way, but I was not really impressed with python.

The syntax seemed ugly to me, the “there’s only one way to do it” philosophy was at odds with my personal philosophy of “give the developer as much power and flexibility as possible”, and the fact that every introduction to python I read basically told me that I was a bad developer, and my favorite languages (C++ and perl) sucked, and I should be thankful for having python to rescue me – it all added up to put me pretty dead set against python. In fact, all of those things still keep my bias against python; but in the end we can’t be a slave to our bias.

Over the last year, I’ve noticed that a lot of the applications that I’m using are written in python. Music players, Desktop widgets, version control systems, and even my favorite websites are all being re-written or replaced by versions written in python. For the most part, I’ve never had a problem with this. If a program works well, then who cares what it’s written in; and I know that a lot of people never shared my own personal bias against python. That said, the transition to more applications being written in python did have an effect; subtle at first it grew more noticeable as time went on, and eventually culminated in my decision to finally sit down and get comfortable with python.

As a Linux C and C++ developer, I always had a fairly distinct advantage over a lot of other people when it came to the Linux desktop. C and C++ were the dominant languages for a long time for even desktop applications under Linux. I had the advantage of speaking the lingua franca. Not only did free software give me the right to have and modify the code, but the fact was most code was written in my preferred languages (C, C++, perl). Using the rights afforded to my by the GPL and other free software licenses was a practical and easy thing for me to do. But every python application on my system is an application written in a foreign language; by not knowing python I was leaving myself in a position where I was unable to exercise my freedom to alter the free software on my computer.

So, all of that to say this: I’ve decided to make my peace with python. After I’ve used it for a while I may learn to like it, or I may always have a lingering hatred for the language for either technical reasons, or purely because I can’t get over my own issues, but at least, love it or hate it, I’ll be able to use it as another tool in my repertoire. And, in the spirit of keeping myself on track and honest about it, I’ve decided to document the whole process right here on tuxtips.org. I’ll be posting every couple of days with my updates on what I’ve learned, what I’m liking, and what I’m not liking. A live feed of the thoughts, trials, and tribulations of a systems programmer with a bias against python taking the dive to learn what it’s really about.

Stay tuned for part 1 tomorrow, where I’ll discuss the books and documentation I’m using to learn, my development environment, and my learning plan and goals.