In response to my earlier article, a number of people suggested various JVM parameters that could be altered to improve the performance of NetBeans. And just today I noticed another blog post about setting such JVM parameters to improve the runtime performance of NetBeans. Now, I haven’t tried such tuning myself, to see if it would improve NetBeans for me. At this point, I don’t care. I have no reason to use NetBeans, as Eclipse works far better.

However, I think it’s pathetic that we have to resort to tuning JVM memory usage parameters just to run NetBeans in a somewhat-usable manner. We’re not talking about some multi-protocol, high-scalability application server software that handles thousands of simultaneous users, where such tuning is understandable. We’re talking about NetBeans, which is basically a glorified text editor. Given the immense processing power offered even by PCs from five years ago, there’s absolutely no justifiable reason why we should have to be manually setting such JVM parameters.

I’ve never had to manually set such parameters when running Microsoft’s various Visual Studio incarnations. I’ve never had to set them when running Eclipse, or JDeveloper, or JBuilder. Other modern IDEs, offering a comparable feature set and some even developed using essentially the same technology as NetBeans, manage to run fine without manual tuning.

The NetBeans developers really must re-evaluate the performance of their software. At the very least, it should not be necessary to resort to tuning such a large number of Java virtual machine parameters to get even just acceptable, let alone good, performance out of NetBeans.

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:

Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException:
Cannot cast object 'test' with class 'java.lang.String' to class 'java.lang.Integer'
at typesafe.run(typesafe.groovy:1)
at typesafe.main(typesafe.groovy)

If Groovy were truly a statically typed language, then the compiler would have raised a compile-time error. But since that did not happen, one or more of the following may be true:

1. The Groovy compiler does not perform adequate compile-time typechecking.
3. The Groovy compiler performs compile-time typechecking, but a bug prevents it from catching this particular error.
4. The semantics of Groovy prevent it from being a statically typed language.

The essence of static typing is that such an error would always be caught at compile time. We can’t say that a language is statically typed if such an error occurs at runtime. Just because the programmer can specify the type of a variable (eg. ‘int’ in this case), it does not mean that the language is statically typed. This is especially true if the compiler or interpreter completely ignores such type specifiers at compile-time.

So in this case, I think the verdict is quite clear: Groovy cannot be considered a statically typed language, as it exhibited a runtime type-related error.

Our example program will be simple. It will consist of two functions. One will be called ‘test’, it will take two integers, and it will return the arithmetic sum of them. The other function will be called ‘main’, and it will invoke the ‘test’ function in two different ways, depending on the size of the array or list containing the command line arguments passed to the program. If there are over three command line arguments, the result of the ‘test’ function applied to the values 1 and the function ‘test’ is returned. Otherwise, the value of ‘test’ applied to values 1 and 2 is returned. Thus the program should have a return value of 3 up until the array or list storing the command line parameters has more than 3 elements.

Since James mentioned Ruby, let’s start with the Ruby version of the code:

def test(a, b)
  a + b
end

def main()
  if ARGV.length > 3
    test(1, test)
  else
    test(1, 2)
  end
end

Process.exit(main())

And now we’ll run it, with warnings enabled and set at the most verbose setting:

$ ruby -w -W2 t.rb; echo $?
3
$ ruby -w -W2 t.rb 0; echo $?
3
$ ruby -w -W2 t.rb 0 1; echo $?
3
$ ruby -w -W2 t.rb 0 1 2; echo $?
3
$ ruby -w -W2 t.rb 0 1 2 3; echo $?
t.rb:7:in `test': wrong number of arguments (0 for 2) (ArgumentError)
        from t.rb:7:in `main'
        from t.rb:13
1
$

As is expected from a dynamically typed language like Ruby, the error wasn’t detected until runtime. Not only that, but the program ran quite successfully before then, without giving any indication that a hidden problem might arise were too many command line arguments given. Even were unit tests to be used, it is quite possible that duplicating such a scenario would be missed, and a perplexed user would be faced with an error such as the one above.

Python doesn’t fare much better. Here is the code we’ll use for it:

"""docstring"""
import sys

def test(first_arg, second_arg):
    """docstring"""
    return first_arg + second_arg

def main():
    """docstring"""
    if len(sys.argv) > 3:
        return test(1, test)
    else:
        return test(1, 2)

sys.exit(main())

Just to be safe, that code was run through the pylint utility, which rates the above code as “10.00/10″. So an unsuspecting programmer may believe they have written high-quality Python code, when they surely have not, as we will soon see when we go to run the code:

$ python -W error t.py; echo $?
3
$ python -W error t.py 0; echo $?
3
$ python -W error t.py 0 1; echo $?
3
$ python -W error t.py 0 1 2; echo $?
Traceback (most recent call last):
  File "t.py", line 15, in ?
    sys.exit(main())
  File "t.py", line 11, in main
    return test(1, test)
  File "t.py", line 6, in test
    return first_arg + second_arg
TypeError: unsupported operand type(s) for +: 'int' and 'function'
1
$

Python behaves similarly to Ruby. The error isn’t caught until runtime, and there’s a good chance that unit testing would not have caught it, as well.

Let us try OCaml, a statically typed language. Compiling:

let test a b =
  a + b;;

let main _ =
  if (Array.length Sys.argv) > 3 then
    test 1 test
  else
    test 1 2;;

exit (main ());;

gives the following error:

$ ocamlopt -w A t.ml
File "t.ml", line 6, characters 11-15:
This expression has type int -> int -> int but is here used with type int
$

The OCaml interpreter also catches the error, even without the code being executed:

$ ocaml -w A t.ml
File "t.ml", line 6, characters 11-15:
This expression has type int -> int -> int but is here used with type int
$

Unlike when using Python or Ruby, the OCaml compiler and interpreter catch the error before the code begins to execute. And note that this is done without any source-level type annotations. This compile-time failure forces the programmer to deal with the error, rather than the user. Thus we end up with a more reliable program. Not only that, but the error was caught without the developer having to write even a single unit test. Now instead of writing unit tests to check if his or her code types correct, the developer can write unit tests to check the actual functionality of his or her software.

We can write a similar program using Haskell, another statically typed language, and it will also catch the error during compilation:

import System(getArgs)
import System.Exit

test :: Int -> Int -> Int
test a b = a + b

main :: IO ()
main = do
  args <- getArgs
  if (length args) > 3
    then exitWith (ExitFailure (test 1 test))
    else exitWith (ExitFailure (test 1 2))

When we go to compile the above program using GHC, we get:

$ ghc -Wall t.hs

t.hs:11:39:
    Couldn't match expected type `Int'
           against inferred type `Int -> Int -> Int'
    In the second argument of `test', namely `test'
    In the first argument of `ExitFailure', namely `(test 1 test)'
    In the first argument of `exitWith', namely
        `(ExitFailure (test 1 test))'
$

The same error is given by ghci, the interactive REPL of GHC. As with OCaml, the problem is caught at compile time, rather than runtime. Thus the developer must actively deal with it for his or her program to just compile, let alone execute. This helps increase the program’s reliability.

As we have clearly seen above, dynamically typed languages like Ruby and Python can allow for some flawed code to be written with ease. But more dangerously, it is possible for the code to run just fine, until a certain context arises upon which a runtime error occurs. Even when running the interpreter with warnings enabled, or after using a code-checking tool like pylint, such problems go completely undetected. This deception is dangerous. Some developers think that unit testing for such situations is appropriate, but there’s a very good chance that such typing errors won’t be detected by the unit tests, either.

It can be said that the code above is unrealistic. That’s true. But the scenario it simplifies is very real. Based on my own experience, I have seen far too many problems arise with dynamically typed languages, where rarely-executed code contains a type-related error, and the execution of this code causes a runtime error (usually at a most inopportune time).

Thankfully, statically typed languages provide a very natural way of avoiding such problems at runtime, instead having them be caught at compile-time. When using languages like Haskell and OCaml, that support type inference, it’s not even necessary for the developer to specify the types in the source code. So such developers get the convenience of languages like Python and Ruby, but without the inherent runtime danger of those languages, and without the inconvenience of having to write unit tests to handle checking that a proper compiler can do automatically, and more rigorously than a human could.

(UPDATE: Fixed mangled Haskell code.)

In this company’s case, they had a number of legacy, in-house systems developed in C and COBOL that were eventually moved to Web applications written in Java in the late 1990s. By early 2006, their Java-based software systems were starting to show their age, and it was decided that they would start rewriting many of them using Ruby on Rails. After an initial analysis and design period, the implementation began, with the greatest portion of the work being completed by August of 2007. The rollout was complete by the beginning of last September.

There has been an endless stream of complaints from the users of the software since that time. I’ve read through six 3″ binders full of complaint reports. Now, the software itself isn’t poorly implemented. It’s actually among some of the better corporate Ruby on Rails code that I’ve seen over the past few years. Design-wise, it’s actually pretty decent, too. From the complaint reports I’ve read, most of the users are also happy with the performance of the system. It’s just that the applications themselves cannot be used well in a productive manner.

After talking to a number of the developers who were involved with that project, I heard repeatedly that Ruby on Rails was too restrictive in a variety of ways. The developers had to developer towards what Ruby on Rails would effectively let them develop, rather than developing the software to meet the needs of the users. The management had decided on a Ruby on Rails-or-nothing approach, so using alternative technologies in such situations was unfortunately not an option.

At this point, the company is trying to return to their Java-based systems, which worked better than their Ruby on Rails implementation. This will not be an easy task for us. Their data model changed in many ways, to name one major stumbling block. It’s not been decided yet whether they’ll update their Java code to handle the new model, or transition their new data back to the previous databases. Regardless, that aspect of the transition alone will be difficult. Updates to the Java code to handle the new capabilities introduced to the Ruby on Rails system since its deployment will also be required. There has been some consideration of a hybrid approach, with some of each system being used, but some of the stakeholders feel this will only cause more problems.

A lesson we can take from this, beyond the obvious ones, is that when performing a large-scale rollout of a new system, it’s important to be able to revert back to the existing system nearly immediately. Not only that, but it should be possible to do this several months after the new system is initially rolled out. Although it will incur an extra cost of doing business to maintain the old, albeit unused, software for some time, not having it available to roll back to could be tremendously more costly.

One of the main problems affecting browsers today is that of resource allocation and usage. These are the very same issues that operating system developers faced in the 1950s and 1960s, when their craft was first maturing. These days, we have the browser acting as a code execution environment, and allowing for multiple, concurrent executions (eg. in multiple browser windows or tabs).

It’s very easy for a malicious or poorly-written JavaScript to execute in such a manner that it locks up the entire Web browser. Some improvements have been made in this area, such as the use of watchdog timers that will prompt the user to kill the script if it has been running for a long time. But this is not the correct path to take. It only scratches at the symptoms, rather than curing the actual root cause.

Web browsers today need greater isolation between the different Web pages that are being displayed in multiple browser windows or in multiple tabs within a single window. Konqueror does this to some extent. Unlike with browsers like Mozilla Firefox or Opera, it is by default possible to launch multiple Konqueror processes at once. That way, poor JavaScript or a browser crash will only affect one window. Unfortunately, such isolation is either not easy or not possible to do with Opera and Firefox.

Unfortunately, Konqueror doesn’t offer that degree of isolation when it comes to multiple tabs. A resource-consuming JavaScript in one tab has a lot of potential to lock up the entire browser window, rendering the other tabs inaccessible or essentially useless. Of course, the situation is far worse with Firefox and Opera, where other browser windows will be locked up, in addition to the tabs sharing the window with the problematic Web page.

A problem in one browser tab should never be responsible for a decrease in the availability or usability of another browser tab, let alone another browser window running in the same process. This is the most basic level of isolation, an it is a disappointment that after nearly two decades, even the most popular Web browsers cannot handle this task in a suitable manner.

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.

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.

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.

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.

There are programs available to help with the development of JavaScript scripts. JSLint analyzes JavaScript code, looking for a variety of problems. A JavaScript debugger, such as Venkman, is also essential. But even these tools do not catch many serious problems.

As more complex Web applications are developed using JavaScript, we’ve started to see certain limitations being hit. One such limitation is the maintenance of a sufficiently high level of quality. This is not only in terms of correctness, but also in performance and portability. The very nature of JavaScript makes quality control a tedious task.

It may be time for us to look beyond JavaScript, to technologies that offer the capabilities needed for larger-scale software development. One essential feature is strong typing. Ideally, this typechecking can be done statically (ie. before the code is executed). Type-related errors caught before an application is executed leads to the developer addressing them, rather than a bewildered user encountering a confusing error message at runtime, typically interrupting (if not losing outright) what they were working on.

Strong, static typing has additional benefits, especially when it comes to optimizations. The more restrictive semantics allow the optimizers within compilers and interpreters to make assumptions and decisions that could not otherwise be made. This in turn often allows for greater optimization techniques to be applied to the code, improving runtime performance and decreasing code size.

So instead of looking at a language like JavaScript, we should probably be looking more towards a language like Standard ML or Haskell. I think Haskell would be an optimal choice. It offers many of the high level constructs of JavaScript, but it also addresses many of the aforementioned problems. What we lose relative to JavaScript is the ability to use techniques that lead to poor-quality, buggy code. But furthermore, we gain a language that promotes quality software through strong, static typing. Beyond that, Haskell has many advanced features, including pattern matching and lazy evaluation, that we really don’t find offered by JavaScript.

Haskell has even more going for it. Another major benefit is the availability of several interactive environments and interpreters. GHCi, for instance, is actively maintained, and is of a very high quality. There is also Hugs 98, which is a rather complete implementation of Haskell 98.

The purely functional nature of Haskell will become more and more important as consumer PCs begin to offer four to eight (or more) cores per CPU. Haskell can allow for the safe, automatic parallelization of code to a far greater extent than JavaScript ever could. We will need to take advantage of such features if we will want our Web applications, or even our applications in general, to effectively use the PCs of the near future.

So what we need to see is a Haskell implementation embedded within a major browser, and extended to offer DOM integration. This would allow for developers to use it instead of using JavaScript. The very nature of Haskell would allow for the development of complex, high-quality Web applications. With such Web applications becoming larger and more essential each day, we need a much more significant focus on quality and performance. Haskell will allow us to achieve this, while JavaScript will not.

I haven’t seen a company use Ada this extensively for such a wide range of software development tasks. They have back-end database applications written in Ada. They have client-side applications written in Ada. They’ve developed an in-house framework for developing Web applications using Ada. Even their custom build system is itself implemented in Ada.

So today I had an opportunity to talk with one of the managers there about why they use Ada so much. His responses were very interesting, I think. He said that Ada was introduced to their company by one of their developers in the early 1990s. Although they’ve had some difficulty finding developers who are proficient with the language, this manager reported enormous productivity gains for those developers they do employ.

I asked him to elaborate on the productivity benefits of Ada. The first benefit he mentioned was that it’s a language that inherently leads one to develop high quality software. This is no accident, of course. The language was designed for this very purpose, and thus explains why it has been successfully used for a vast amount of mission-critical software. The manager said that some developers initially found it too restrictive, but soon enough discovered that by following its best practices, they’d produce software with fewer bugs.

The manager went on to discuss how by using Ada and peer-review, they were able to eliminate a great many bugs before their software was deployed. As anyone who has deployed large-scale applications knows, the earlier a bug is found, the better. But the manager also pointed out that by writing less-buggy software in the first place, his developers ended up spending less time investigating and fixing their mistakes, and instead were able to produce more software to help meet the company’s business needs.

Many developers have reported similar benefits from programming languages like Eiffel, Haskell and Standard ML. Strong, static typing and other features like design by contract are known to help lead to reliable software. And so I asked the manager if they were considering using such languages. He replied that they had actually considered using Haskell for some smaller projects, and one of their developers was in the process of familiarizing herself with the language. He promised to keep me up to date with their developments, of which I am eager to hear about.

So far, this has been one of the most interesting clients I have worked with in the past while. After working with numerous Java, C#, VB.NET and Perl development teams over the last few years, it’s refreshing to see a team that adopts an alternative technology like Ada, and manages to boost their productivity to a level that is rarely achieved. Maybe it’s time for more developers to consider the use of Ada, even those who are working on fairly typical business applications.