Background

There is no best programming language, contrary to what some people will say. And to understand why I picked Python as my goto language, you need to understand a little bit about the context of my decision.

Most of my career has been spent developing proprietary software for small groups of users (10-50) in the financial services industry, either for small departments in a larger firm or for all employees within a small company. There are a few important characteristics of this environment that are worth noting:

1. The financial services domain changes rapidly. New types of products are created every few months, new trading strategies are constantly developed, and the landscape for third-party products and financial market data evolves and changes at a very fast pace.
2. The number of users is relatively small (from a handful to dozens).
3. The users are not technical. They do not understand the complexities of software development and it can be very difficult to get the users to spend the time to define a problem with any level of clarity or detail that would provide a useful specification.
4. These are not technology companies. You will usually not find a lot of internal support to build a complete development team (e.g. with roles covering project management, quality assurance, tools developer, support, etc). If your boss doesn't see everyone on your team writing code all day then they will think something is wrong.

We can identify some requirements for a "good" programming language from the above points:

• The first point speaks to flexibility and the need to design for change. You want to develop solutions that can be easily modified as business needs change, and you want to choose tools that lend themselves nicely to this goal.
• The second point simply reminds us that we don't need to get carried away on complex architectures or get preoccupied with performance - simpler solutions will usually suffice.
• From point 3, I've learned that it really helps to know the financial business and to try and hire people that are conversant in the problem domain. But that's not easy so you can't rely on growing a team to meet the demands of the business. You may need get by with a smaller group and need to choose tools that really help your productivity.
• The last point has always been one of the harder things about working in finance - I usually don't have much in the way of technical peers to bounce ideas off of or to get a "second pair of eyes" when debugging. So its good to pick a language that has a rich community so you can fill that void outside of the office.

There are also a couple of important lessons I learned from previous jobs in this environment:

1. One language is better than many. I know people will often say you should use the right tool for the job, but in environments I've worked at where using multiple programming languages was the norm, its always been a disaster. There has always been way too much time spent on integration between the languages, and you will often end up with multiple implementations of the same components. Its also rare that every team member will be proficient in every language, so you don't have the ability to reassign people to different projects as easily.

2. Web applications work well for most problems. Web applications have a lot of benefits even for intranet applications. Deployment is dead simple and updates can be rolled out intraday. Users are familiar with the model and often don't require much training and support. Web applications perform well even for remote users connecting over a VPN. And modern development techniques have demonstrated that the web works nicely even for more dynamic, interactive types of applications.

The Language

Lessons Learned

I've used a number of programming languages over the years but have never really been passionate about any one. I started in C, enjoyed it a lot, and used it in the first few years of my career, and like many others, moved "up" to C++ for the next few years. But I never really liked C++. It always seemed that the benefits from the better OO support were outweighed by the added heft and complexity of the language. Add to that templates and MFC, and you sometimes feel like you are using a Rube Goldberg programming language.

From there I moved onto the more modern compiled languages, first Java and then later C#/.NET. While I found both those languages a breath of fresh air from the C++ world, I also found the simplicity of the languages lost in the sheer scale of the ecosystem they lived in. The class libraries were very large, but oddly void of some useful libraries (where is the FTP library in C#, for example?). And the index page of the Java docs for J2EE should borrow a line from Dante and warn the naive programmer "Abandon all hope, ye who enter here".

In the financial services area, there are also lots little data processing tasks that need to be performed (parsing broker files, web scraping, exporting data to vendors). I found C# too verbose for simple things like parsing a flat file and transforming the lines.

But there were a couple of things I did like about my experience using C#/.NET - it was the only language we used at that firm and the advantages of one language were real and notable:

• great reuse due to one common library
• good collaboration on the team as we all were "thinking in C#"
• a sort of network effect of shared knowledge that occurs when everyone is gaining expertise in the same set of tools

Interpreting the Options

With those experiences behind me, I started looking at interpretive programming languages. I had used Perl in the past and quickly ruled it out. I just think that it promotes "write only code" and that the language (and community) seems to value tricky one-liners more than explicit, understandable (and maintainable) code.

So I quickly whittled my choices down to Python and Ruby. After reading a lot of articles, primers and sample code, I found Python a better fit for my needs. I liked the focus on simplicity, explicitness, readability, practicality and "batteries included". It has great documentation and a very rich and helpful community. Ruby had a lot of the same things going for it but I found the libraries less comprehensive and developed and the community at least seemed smaller when I surfed around for various resources. (And frankly I don't find Ruby code that beautiful like your hear so often from many of its fans.)

The Framework

Once I settled on the language, I wanted to learn the "right" way to build web applications in Python. I had done a fair amount of ASP.NET in C# in my past job and found it lacking. If you stayed within the basics - using standard web controls and following the post-back model - it worked well. But for any real application, you quickly needed to go "outside the lines" where ASP.NET quickly became both complex and confining. Also, I just don't think that trying to make web programming like VB GUI programming is the right conceptual model for web apps.

In researching Ruby, I of course had run across Ruby on Rails. In some ways its probably more popular than Ruby itself. Python had a number of frameworks and tools to build web applications, but three stood out: Turbo Gears, Django and web.py. Turbo Gears and Django are higher level, full featured systems similar to Rails, while web.py is a much simpler and smaller toolkit, but quite compelling, nonetheless.

Since I was really looking for big productivity dividends, I ruled out web.py. There were too many things that the other frameworks had that I would need and I would end up having to build (or locate and integrate) on my own. While I liked both Turbo Gears and Django, I liked the consistency of Django that comes from a single complete project rather than a "best of breed" approach that Turbo Gears takes.

Results

I've now been using Python and Django for about 10 months and am very happy with my decision. I've written this blog and a simple todo app for the fun of it, and have built up about 12k lines of code on my work projects. At work I built up a nice collection of tools to help my dev process mostly by using standard Python packages. These include

• a web app for monitoring and managing scheduled tasks
• a unit testing framework that produces a complete web site of coverage charts, statistics and decorated source listings
• automated code documentation site

The more I learn about both Python and Django, the better I feel about the direction I've taken. Python seems to be a language that is simple when you are learning, but rich and powerful when you need it to be. Django shares these same qualities, and while still in its infancy, has already proven itself in many large scale web sites.

But probably the best thing I can say about Python is that I really enjoy using it. And that is "Why Python."

Tags: python