Pain and Glory from the Trenches of the IT World

Many Java developers have at least some experience with the NetBeans IDE. Although I prefer Eclipse for Java development, I do try to use NetBeans occasionally to keep up to date with their developments. The last time I tried it, the results were rather terrible. I found NetBeans 6.0 Beta 1 to be extremely slow, even on a modern system with a multicore CPU and gigabytes of RAM. It wasn’t just a matter of it not running well for certain intensive operations. It was sluggish and barely usable for even just editing text.

I recently wrote about how undetected type errors when using languages like Ruby and Python can be quite dangerous. That article has gotten some notice, with one response considering Groovy.

The article about Groovy purports to have an example of a statically typed Groovy script that compiles fine, but results in a type error at runtime. The script is:

int x = "test"

The error received at runtime is:

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.

Several months back, there was somewhat of an uproar in the Ruby and Ruby on Rails communities when it was revealed that after two years of effort, the CD Baby Web site was abandoning their Ruby on Rails rewrite. The CD Baby site was reimplemented in mere months after returning to the use of PHP. This past week, I have been working with another company that is in a very similar situation.

If more and more software developers are going to be developing browser-based applications using technologies such as JavaScript, Flash, and AJAX, we will need to see the Web browser become a much more capable platform. In short, the browser will need to duplicate much of the work that has been done over the years in the operating systems field.

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.

Today I read an article about static typing, written some months back. I believe it is a very short-sighted article, and factually incorrect in several respects. However, I do encourage you to read it, so that you’ll better understand the fallacies it portrays.

A few days back a colleague forwarded me a link to an article entitled Attacking PHP. It goes through a list of the problems associated with PHP. And based on my past experiences dealing with PHP in corporate environments, the analysis in that article is spot on.

In short, PHP is just not a suitable language for serious Web application development. I’ve seen it used for a wide variety of Web apps at numerous companies, but the results have always been negative.

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.