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.