Pinderkent

When unit testing is used in conjunction with a dynamic programming language, it's typical to see many unit tests whose sole purpose is to test for errors that a language employing static typing would have caught at compile time. Justin Etheredge recently discussed this, and it's something that I have written about in the past in my "Unit testing is not a substitute for static typing" article.

This isn't necessarily an argument about whether statically-typed or dynamically-typed languages are better. There is no single answer to that argument, as what's best really depends very much on the situation at hand. When we want to write software really quickly and are willing to accept a low degree of quality, then dynamic languages are quite suitable. A good example of this is a system administrator writing a short Perl script to scan through certain log files, for instance. Chances are a reasonably competent administrator will be able to write such a script with no significant errors. But once we start moving beyond that scale, we need the help of a compiler, and often static typing.

While proponents of dynamic languages are often quick to point out that such languages allow for more rapid development, they often neglect to see the greater picture. Initially writing code is a very small portion of the lifetime of a typical software product. This is especially true as the software systems get larger and more complex. Significantly more time is often spent testing the software initially, testing for regressions as changes are made to other parts of the system, and debugging user-discovered problems after it has been deployed.

Automated unit tests have become a popular way of reducing this post-initial-development burden. While using a statically-typed (and often, but not always, compiled) language, such tests are usually about testing the actual functionality of the software. More trivial checks, such as whether we're assigning textual strings to variables we expect to be purely numeric, are left to the compiler to perform. And this makes perfect sense; developers shouldn't be wasting their time writing unit tests to essentially perform checks that a compiler could do far more thoroughly and efficiently.

There have been numerous times now when I've had to work with larger software systems developed using languages like Ruby or Python. Thankfully, there have been extensive unit test suites available in the majority of those cases. But the value of those test suites is diminished by the numerous tests that would be rendered immediately unnecessary by strong, static typing. Whatever time the developers might have saved by using the dynamic languages ended up being used instead to write trivial unit tests.

This isn't to suggest that we shouldn't use dynamic languages. Like I mentioned earlier, they're often practical and suitable for very small scripts and applications. But when we're writing serious software that's expected to perform reliably, it's in everyone's best interest to use a more static language. That way the developers don't have to waste their time writing unit tests that essentially test for typos and minor programming mistakes, rather than testing the functionality of the software. Likewise, the testers don't have to file numerous bug reports about the inevitable mistakes that the programmers made, but which were missed by their unit tests. And most importantly, the end-users don't have to fall victim to typing errors that both the developers and the testers missed. In short, it just makes more sense to use static languages.

Today I read Kevin Smith's recent article entitled Erlang Doesn't Fit The JVM. As the title suggests, he discusses why efforts to port Erlang to the Java Virtual Machine really wouldn't be of much value. In general, I tend to agree with his points. The JVM does indeed lack the necessary functionality that makes Erlang particularly valuable.

Unfortunately, I think he missed discussing one of the major arguments often used in support of having non-Java programming languages target the JVM, namely that of reusing existing Java code. The Scala homepage, for instance, currently mentions in its introduction to Scala that "Scala has the same compilation model (separate compilation, dynamic class loading) like Java and allows access to thousands of existing high-quality libraries." Likewise, the Clojure Rationale page lists the reuse of existing Java code as a necessity: "Ability to call/consume Java is critical." Thus we can see that code reuse is one of the driving factors behind these new languages targeting the JVM.

Code reuse is one of those things that sounds great, especially to managers. But in reality, however, it's often of somewhat limited value. That's not to suggest that all code reuse is bad; clearly it isn't. There is little point in having developers today write basic string handling code, or common math functions, and so forth. But once we start getting into application- or domain-specific code, reuse starts to become less useful, and can often become quite a problem.

I think this becomes even more of an issue when trying to integrate code written in one language with that in another. This is especially true when one language (such as Scala) offers higher-level functionality and concepts much in excess of the other language (Java, for instance). Libraries and frameworks written with Java in mind very likely won't be designed in such a way as to make the best use of the language features and approaches that Scala, for example, makes possible.

The same goes for Erlang. One of the main reasons why we may choose to use Erlang over Java is that Erlang brings a set of concepts and solutions that, at the language level, just aren't offered by Java. In many ways, the general principles of Erlang-based development don't mesh well with the Java philosophy. This is evident at the very basic of levels, where Erlang embraces immutability, while mutability is widely used and encouraged within the Java development community. Likewise, lists and tuples are first class language constructs in Erlang. But when using Java, one has to resort to arrays or classes wrapping arrays to reproduce the functionality of lists. The Java equivalent of a tuple is usually just a class with several member variables. And while an Erlang developer will typically use recursion to iterate over a list of values, a Java programmer would likely use a loop. Things become even more complicated and mismatched when we consider how Erlang's approach to concurrency and distributed computing can be somewhat emulated in Java, but it isn't as natural as it is in Erlang.

When trying to combine the Java and Erlang philosophies, or more generally when trying to combine traditional imperative and object-oriented techniques with those of functional programming, we often run into the so-called "impedance mismatch" so often seen between object-oriented class hierarchies and database-based relational models. So the concepts of Java and Erlang can be mixed, but they often come together poorly, assuming the outcome is even usable.

While languages like Scala and Clojure, as well as an implementation of Erlang for the JVM, might allow for interoperability with existing Java code, the practical benefits likely don't exist. On one hand, we can choose to reuse existing Java code heavily, but at a cost of not making use of the new and often productive features of the newer, non-Java language. At that point, we might as well just go back to using Java. On the other hand, we can heavily use the language features of languages like Clojure, Scala and Erlang, and make a more minimalistic use of existing Java classes. Unfortunately, this will likely just lead to interoperability hacks, which can become maintenance headaches down the road. Trying to find a middle ground will just result in lost functionality, or an increasing number of hacks.

When moving to a new paradigm of programming, we sometimes just need to admit and accept that we shouldn't try to reuse our previous code directly. We're likely moving to the new paradigm because we need to increase our productivity in order to remain competitive and viable. And while reusing our existing code may initially sound like a good idea, it will only serve to become an anchor. A better idea is to keep in mind the knowledge and experience we obtained while developing the older code, but to put the focus on using the features of the new language or languages to our best advantage. This likely will mean reimplementing existing functionality, but doing so with a new philosophy and mindset. And so we'll make true progress by applying new ideas to existing problems, rather than by trying to convolute our existing solutions and ideas into the new way of thinking. It just doesn't make sense to cripple a powerful and advanced language like Erlang just for the sake of reusing some existing code.

Today we finally heard the sad news about what's probably going to be the end of SGI. This doesn't come as a surprise to anyone who follows the industry, of course. SGI's fortunes have been steadily declining for the past decade. But it's still humbling to think of how what was once a great company could fall so far.

The Silicon Graphics of the 1980s and 1990s can perhaps best be compared to Apple today. There was always a certain excitement around SGI's offerings, often due to their quality and power, but also due to their unique flair. This really isn't surprising; they were at the forefront of computer graphics technology. Their systems allowed for the creation of what were, at the time, very spectacular visual effects. Seeing an SGI system at work didn't just leave a strong visual impression of whatever was rendered, however. The unique designs of many of their systems also left an impression.

SGI is best known for their MIPS-based systems, their IRIX operating system, and OpenGL. In terms of hardware, SGI was typically at the forefront of the market. For instance, they offered 64-bit MIPS systems in the early 1990s. This may not seem like much now, but it wasn't until a decade later that we saw the x86 world start to move towards 64-bit computing. And in terms of advanced graphics hardware, they led the way for many years.

Although I didn't work with companies who used SGI workstations for their high-end graphics capabilities, I did use an Indy workstation for some time during the 1990s, and was able to work with some companies who used SGI systems as servers because of their power and flexibility. And as servers, they were always very reliable, and often a pleasure to work with compared to the UNIX-based offerings of various other vendors.

Their IRIX operating system was always interesting to work with. During the time when I worked with such systems, they'd already moved to X and 4Dwm. While I always sort of preferred CDE, 4Dwm nevertheless did provide a unique desktop experience.

Aside from its graphical nature, IRIX was always known for scaling quite well. Given the needs of many of SGI's customers, high performance was always a necessity, and scaling well was typically the only way to get that sort of performance given the hardware of the day. One aspect of IRIX that was particularly interesting was its XFS filesystem. Being a 64-bit journaled filesystem, it was always capable of reliably storing huge amounts of data. While this was necessary for those doing video capture and editing, for instance, it nevertheless proved very useful for others who needed to store huge amounts of non-graphical data. Thankfully, XFS was released as open source software, and has been integrated with the Linux kernel. Even today, fifteen years after it was first released, XFS is still a very usable and practical filesystem, employed by many.

For some time, SGI had many of the brightest minds in the field of computer graphics working for them. OpenGL was one of their notable achievements. Like XFS, they were quite open with OpenGL, and thus it flourished, with it now being well-supported on many modern operating systems and graphics hardware. Just over a week ago the Khronos Group announced the release of the OpenGL 3.1 specification.

One thing about some SGI workstations is that they had a distinct appearance. Take their O2 and Octane systems, for instance. Both offered curved designs with uniquely powerful color schemes. It was easy to recognize such systems, even from a distance, in much the same was as many of Apple's designs stand out. And for their systems with a less-remarkable appearance, the 3D wire cube logo they used to use always made their systems identifiable.

It's unfortunate to see SGI end like this. Even if their products were expensive, they were typically quite innovative, and were the sort of products that one could get genuinely excited about. Not only did they give their systems a unique appearance, but they followed through and produced systems that were very capable, extremely powerful for the time, and generally quite reliable. Unfortunately, market pressure from below took its toll on SGI. Many of their higher-end customers reportedly moved towards commodity hardware. The loss of talent to companies like NVIDIA and ATI didn't help the situation, either. And although their future may be limited, it's likely that we'll see at least some of their work live on for some time in the form of XFS and OpenGL. Hopefully it's not forgotten where such achievements originated.