Pain and Glory from the Trenches of the IT World

Several days back I wrote about how unit testing is not a substitute for static typing. A comment posted to that article by James asked for more clarification regarding what I was talking about. James wrote, “I can’t recall the last time I had Ruby code break because I tried to act on an object of the “wrong” type.” Well, I will give a simple example of how such problems arise, and how different languages deal with them. The languages in question will be Ruby, Python, OCaml and Haskell.

Users of of dynamic languages such as Python, Perl and PHP, are often faced with the additional task of ensuring that type-related errors do not occur in their programs at runtime. Some authors [1, 2] claim that this can be done effectively by the use of extensive automated unit tests. However, practice has shown this to just not be the case.

JavaScript has been around for over a decade now. During that time, we’ve seen it implemented by every major browser vendor, and thus we’ve seen it become widely used by many Web sites. We’ve even seen JavaScript used in non-Web applications and uses.

But JavaScript has some pretty serious drawbacks. The performance of the various JavaScript interpreters embedded in the popular Web browsers has always been less than ideal. And being interpreted, it often becomes more difficult to detect syntax errors and other common mistakes. Worse yet, being weakly typed opens JavaScript scripts up to a whole host of type-related problems.

When you mention the Ada programming language to most developers, they tend to think of embedded software development, typically in mission-critical environments such as aircraft and electric power plant control systems. But we shouldn’t think that such environments are the only place where Ada can be of use. For the past several weeks, I have been working with a shipping company that makes extensive use of Ada for their in-house software.

For the past couple of weeks I have been working with a very interesting system administrator. He’s responsible for maintaining a large number of Web servers, mail servers, and database servers. Like most system administrators, he employs a number of scripts he’s developed to automate a variety of tasks. While most sysadmins would use a language like Perl or Python for developing their scripts, this fellow uses Haskell. Of course, I asked him why he used Haskell. His answers really aren’t surprising to somebody who has used Haskell before.

Although it hasn’t (yet?) caught on much in industry, anyone who follows modern computing trends will no doubt have heard of D. Its Web site describes it quite nicely: D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. The D language is statically typed and compiles directly to machine code. It’s multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It’s a member of the C syntax family, and its appearance is very similar to that of C++.

Earlier this week I had a very surprising and unexpected Haskell encounter! It started when a fairly large furniture shop in the area called me in to do some work on some of their intranet software.

They wanted some functionality added to their existing Web-based purchasing system. They’d mentioned that it was CGI-based, so I was thinking it was comprised of Perl or Python scripts. However, I was quite wrong! After getting access to the source code of their CGI scripts, I noticed immediately that they were all written in Haskell.

Luke Plant has been working on a Haskell-based blogging application for a while now, and describing his progress. I was dismayed to read today that he’s giving up!

One of his main complaints was with regards to the poor state of the available Haskell database interfacing libraries. He does mention Takusen, which a colleague of mine has been using for a personal project of his own. But Takusen doesn’t appear useful to Luke, due to a lack of a proper MySQL backend.

When it comes to judging programming languages, there are three main factors that we need to consider: programmer productivity, the application feature set that can be implemented, and the runtime performance of the developed applications. There are, of course, many others, including memory usage, portability, and implementation cost. However, memory is plentiful these days, most languages have cross-platform implementations, and many of these implementations are free or have a low cost. So the three factors mentioned in the title become the most important ones.

When it comes to programming languages and programming technologies, I think we’re getting close to a point similar to that of twenty years ago. In 1987, many enterprise software systems were being written in languages like C, COBOL, and even PL/I at some shops. Some places were ahead of the curve, and were using Smalltalk.