Pinderkent

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.

Automated unit tests have their place. But they should not be used to check for typing errors. Software typechecking is a mechanical task, and thus is just the sort of thing that should be delegated to a computer. And this has been done for quite some time now, in the form of statically typed programming languages. Users of such languages, such as Haskell, OCaml and Standard ML are freed from having to worry about such menial and tedious tasks. The rigorous nature of the compilers for those languages often do a far better job at checking for type errors than a human typically could.

Proponents of dynamic languages often suggest that such languages bring an increase in developer productivity. But if the developer ends up spending so much time writing unit tests to perform a task that is readily done automatically, we really don't see the supposed productivity boost. And if the developer doesn't write such unit tests, the chances of a runtime type error crashing the application are far greater. So now the developer must choose between his or her software crashing and disrupting the users' work, or spending a lot of time to write unit tests. None of the choices are reasonable, let alone optimal.

Static typing is clearly the answer. Not only does the compiler take care of the tedious task of type checking, but any inconsistencies are detected at compile-time, rather than runtime. Thus it is the developer who deals with such errors, rather than the user. Furthermore, the developer is now freed up from writing automated unit tests to check for type errors, and can instead put more emphasis on unit testing the functionality and integration of his or her code. Clearly, static typing is the only sensible, and the most efficient, route to take.

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.

The first myth is that "static typing requires extra typing." Anyone who has used a language like OCaml or Standard ML knows this to be a blatantly incorrect statement. Such languages offer static typing, yet also offer type inference. So it is very rare that one must manually specify the type of a function argument, for instance. A developer will do just as little typing as when using Python or Ruby, but will get the numerous benefits of compile-time type checking.

The second myth is that when it comes to static typing, "people will want to work around it." Developers who strive to work around static typing clearly do not understand how to use it to their best advantage. Often, attempts to work around static typing are caused by a lack of preparation. Although one will never know everything about the problem domain in which he or she is developing a software solution for, even a small amount of research and preparation will allow one to use static typing to its full advantage.

That article discussed several other issues, but on further investigation it becomes clear that they have little to nothing to do with static typing, are convoluted micro-examples that have no real-world relevance, or actually are irrelevant when using languages like SML or Haskell.

There was one other paragraph that I wanted to discuss: Have I ever written dynamically typed code that has run for two hours, only to return and find that it broke because of a typeo or a wrongly-used type? Yes. But in almost every case it could have been fixed by better unit tests. Besides, those few situations pale in comparison to the man-months saved in typing, digging through verbose code, and wrestling with the type system..

This is clearly the wrong attitude to take when developing software. There is no reason for a type-related error to ever occur at runtime, especially when such checking can be performed at compile-time (ie. static typing). Furthermore, the use of unit tests to detect typing errors is sloppy and senseless. You're manually doing work that even a rudimentary compiler can do for you (and probably a lot better than you could, too). And it's just laughable to think that writing verbose unit tests somehow requires less typing than using a statically-typed language that supports type inference.

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.

As the article mentions, one of the main problems with PHP is that it's sloppy. The standard library naming scheme is one particularly problematic area. This in turn promotes sloppinesss elsewhere, namely for those developers who use PHP to developer their own applications. Try as a developer might to keep his or her code clean, the use of standard PHP functions will begin to introduce inconsistencies.

The mixing of content and presentation is of course another very sore point when using PHP. Although it is possible to avoid this, we don't always see this in reality. It becomes very convenient in the short term to mix those two distinct layers. But once an application starts to mature, nothing but problems arise. For instance, one team I worked with would continually break the logic of their PHP Web application when making cosmetic changes, since the business logic was so intertwined with the presentation code.

And when dealing with the Web, security is paramount. The Web is a very hostile place, and so we need to use programming languages that help enforce good software design. In this respect, PHP's dynamic nature is unacceptable. While it allows programmers to rapidly create Web applications, these applications are often full of security glitches. Furthermore, type-related errors all too often cause problems when using a PHP application. Users are not impressed when an application crashes due to a failed type conversion because the PHP developer wrote sloppy code.

When you combine the factors above, you end up with a language that also promotes the development of near-unmaintainable code. Even if a PHP application is initially developed by somebody with patience and discipline, this level of care must be maintained throughout the entire lifetime of the PHP application. If the development standards drop for even the slightest of code, it is quite likely the PHP application will become a mess quite soon. Although languages like Java and C++ are not immune to such problems, they do tend to be far more resilient than PHP.

In short, PHP is just not a language that should be used for most large-scale applications. Although it may have its place for small Web sites, bringing it beyond that is just looking for trouble and heartache. Basically every time I have seen PHP used for real software development, the result has been spectacularly horrid.