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.

For years now, Andy Tai has done a great job of maintaining the The GUI Toolkit, Framework Page. It's a very extensive list of GUI toolkits and frameworks, both open source and commercial, for a wide variety of languages and platforms. In fact, it's almost too complete. Many of the toolkits listed are no longer developed or became obsolete years ago. So my aim here is to narrow down his huge list to the toolkits and frameworks that are practical, from a developer's perspective, and worth using today.

First and foremost, we have Qt. Many consider it to be the premiere C++ GUI toolkit. That's not surprising, of course. It has a long history of being developed as a commercial product, first by Trolltech and then by Nokia after they acquired Trolltech. Nevertheless, it has also been released under a variety of open source licenses throughout its lifetime. Given its maturity and use in a wide variety of software systems, including KDE, Opera and Google Earth, it has become known as a very reliable, portable, high-performance and high-quality toolkit.

Although Qt is written in C++, a variety of bindings have been developed for other languages. Some of the most notable include QtAda for Ada 2005, PyQt for Python, PHP-Qt for PHP, QtRuby for Ruby and qtHaskell for Haskell. In short, it proves to be a great toolkit, almost regardless of what language or platform you're using.

After Qt, we can consider wxWidgets to be the next most practical GUI toolkit. Like Qt, it is written in C++, is available under an open source license, is extremely portable, and can allow for the development of a professional-grade UI. Also like Qt, there are bindings for a number of popular languages, including wxPython for Python, wxRuby for Ruby, wxHaskell for Haskell, wxPerl for Perl, and even wxErlang for Erlang and wxLua for Lua.

One of the main benefits of wxWidgets over other GUI toolkits is its use of native controls. This allows applications developed using it to integrate nearly seamlessly with the host operating system, even while remaining somewhat portable. So while other toolkits offer themes that try as best as possible to emulate the behavior and appearance of the native platform's UI toolkit, this is often done imperfectly. A perceptive user will know they're not using a native application. But with wxWidgets, we typically don't find this happening.

After wxWidgets, GTK+ can be considered the next most usable toolkit. One difference that it has from Qt and wxWidgets is that it is written in pure C, rather than C++. While this makes language bindings easier to develop, it does have some drawbacks. One such drawback is that it makes extensive use of the GObject object system to provide object-oriented-like functionality for C. This typically feels inferior to using an actual OO language.

While it is portable to other platforms, its origin as an X Window System toolkit can still be felt. Applications using the Windows port of GTK+, for instance, typically don't truly feel like a native Windows app. Nevertheless, the Windows ports of applications like GIMP and Inkscape are usable and reliable. For the best experience, however, it's usually recommended to use GTK+ applications within an environment such as GNOME or Xfce, both of which are built upon it.

Like wxWidgets and Qt, GTK+ also has a wide variety of language bindings. Some of the most widely used include gtkmm for C++, PyGTK for Python, Gtk2-Perl for Perl, Ruby-GNOME2, PHP-GTK for PHP, Gtk2Hs for Haskell, Gtk# for the languages supported by Mono and .NET, and LablGTK for OCaml. Unlike Qt and wxWidgets, which are quite usable for large applications written in their native language (C++), it's probably best to use GTK+ from one of its more mature bindings, such as gtkmm, PyGTK or Gtk#, rather than from straight C.

Swing is relatively old and well-known. Originally Java-centric, it is becoming a more viable option as languages like Scala and Clojure, which target the JVM, become more prevalent. Other language implementations targeting the JVM, like Jython for Python and JRuby for Ruby, make it even more usable. Unfortunately, it does have a number of problems. It has never been known for offering high performance, and is somewhat memory-intensive. Applications written using Swing never truly feel like native applications, even when using a platform-specific theme. The API itself is also quite messy, having accumulated much cruft after a decade. And many developers don't want the extra baggage associated with the Java runtime, which makes it less appealing for those not writing an application specifically for the Java platform.

The FOX Toolkit is likely the most practical toolkit after Qt, wxWidgets, GTK+ and Swing. Like Qt and wxWidgets, it's written in C++. But unlike them, it doesn't offer as much of an accompanying framework. So in many respects it's a much more lightweight toolkit. And unlike some other toolkits, it doesn't (yet) include support for themes, so it has its own unique look and feel that is reminiscent of the traditional Windows look and feel. Nevertheless, it is portable and released under an open source license.

Unlike the aforementioned toolkits, the FOX Toolkit doesn't have as wide of a variety of language bindings. FXRuby for Ruby is a mature and usable binding, but others, like the FXPy binding for Python and the EiffelFox binding for Eiffel, have stagnated. So the FOX Toolkit is probably best used from its native C++ or from Ruby.

FLTK is similar to the FOX Toolkit in many ways. It's also written in C++, is portable, and is more lightweight than toolkits like Qt and wxWidgets. Unfortunately, it doesn't have as many bindings for other languages, and the ones that do exist (like the Ruby wrapper and pyFLTK for Python) aren't updated very frequently. So while FLTK is usable, it probably isn't the best option for more complex applications that are expected to have a long lifespan.

There are many other GUI toolkits out there, both commercial and open source. In terms of cost, portability, usability, user-experience and programming language interoperability, the toolkits mentioned above are typically the best options. Qt is perhaps the most flexible option for writing high-quality, portable GUI applications, followed closely by wxWidgets. GTK+ is good for software running on UNIX-like systems, but doesn't offer as seamless as an experience on other platforms. Swing is typically the choice for those targeting the JVM. And toolkits like FOX Toolkit and FLTK provide alternatives for those who don't want the baggage of the larger and more complete frameworks. While no toolkit is perfect for every piece of software, picking Qt, wxWidgets, GTK+, Swing, FOX Toolkit or FLTK should prove to be a safe, viable, practical and capable choice.

There has been some discussion lately on several blogs about Java and its feasibility as a programming language for practical development these days. The articles I'm talking about are Bruce Eckel's "The Positive Legacy of C++ and Java", "Java as Legacy Language" by Kas Thomas, and "Is it time to retire Java?" by David Arno.

The general theme of all three articles is that the Java language has not kept up with the times. That's not to suggest that it's useless or will disappear any time soon, however. Anyone with experience in industry knows that there is an absolutely huge amount of Java code out there, critical to many business operations. But it is true that Java does not offer the productivity it once did. Relative to languages like C and C++, it did allow for more complex systems to be developed with less effort, and in a shorter period of time. But languages like Python and Ruby have been attacking it from beneath, and now prove to be a better option for many software development projects.

The general feeling after reading those articles is that although the Java programming language isn't as beneficial as it once was, it did provide us with the JVM, and this in turn proves to be a useful platform for languages and implementations like Scala, Clojure, JRuby and Jython.

I'm not so sure that this is the case. The JVM has never really been a spectacular platform. Performance problems have plagued it from the very beginning. Some of the problems are inherent to the Java language itself, namely in limiting what optimizations the compiler, runtime and programmers can perform. Although there have been improvements relating to JIT compilation, for instance, I think a lot of the performance problems of Java have only been mitigated somewhat by hardware consistently getting much faster during the late 1990s and most of this decade.

When the topic of Java performance comes up, some people like to toss around various microbenchmarks showing that some obscure task can be done relatively quickly using code running on a Java virtual machine. Unfortunately, these results don't translate well to the real world, where applications tend to be far more complex. Part of the reason why desktop Java apps never really took off, for instance, was because most of them felt sluggish relative to other applications written in languages like C and C++. Application startup time has also always been a problem with applications running on the JVM. Were it not for server-side applications typically being long-running and typically running on more powerful hardware, it's doubtful that Java would have made the inroads it managed to make there.

Bloat is another issue plaguing the Java platform. The earliest versions of the runtime had installers that were 2 to 5 MB in size. While that seems like almost nothing today, in the mid-1990s that was a hassle to download over a dail-up connection, especially if one was paying by the hour. Although not as much of a problem now due to the prevalence of broadband Internet connections, the Java 1.6.0_12 runtime installer for x64 Linux is still relatively large at over 18 MB.

Even today, with many computers having two or more gigabytes of RAM, we see Java applications using a disproportionate amount of memory. On Linux using Sun's 64-bit 1.6.0_12 runtime, we see the Scala 2.7.3.final REPL using 593 MB of virtual memory, with 153 MB resident, as reported by top. And this is just after starting up the REPL while it's still at its first prompt, without having entered any expressions that may have increased the memory usage. Some applications are even worse. Just after startup, before loading any projects, NetBeans 6.5.1 is already using 1029 MB of virtual memory, with 249 MB resident. We can't blame just the JVM for such problems, but we also can't overlook its involvement.

The Java class library was once one of the key selling points of Java and the Java platform. It provided a lot of common functionality in a manner that could be easily reused by developers, thus increasing their productivity dramatically. But over the past decade, we've seen a variety of libraries for other languages arise that provide the same functionality, but often with much nicer and effective abstractions or APIs. Microsoft's .NET class library is one of the most widely used. Faced with such competition, the Java platform just doesn't look as attractive as it once did.

The Java class library is also starting to really show its age. While many classes and methods have been officially deprecated, they do remain around cluttering up the library. Others, like the AWT, are impractical for use today, but still must remain around due to later technologies, like Swing in the case of AWT, being built directly upon them.

Furthermore, a great deal of the classes don't make good, if any, use of generics, enumerations and the various other language features introduced since Java 5. The benefits of having such language features in Java are negated when many of the core library classes we use don't support them. We're often stuck still using integer constants where enumerations would be much more appropriate, for instance. Unfortunately, there is great reluctance to change the library in ways that would impact compatibility with older Java applications. So it's unlikely we'll ever see these problems fixed up appropriately.

When it comes to running non-Java languages on the JVM, we end up with even more problems. A language like Scala offers features, functionality and concepts that we just don't find within the scope of the Java language. So although it can be used, actually using the Java standard class library from a language like Scala negates many of the benefits of using the newer language in the first place. While such interoperability and reuse is often touted as a benefit of using advanced languages that target the JVM, I fear it's actually a significant downside, as it doesn't promote the effective use of the new language features that really do boost programmer productivity or application quality. They're crippling themselves by trying to reuse existing code that doesn't fit their philosophy.

So while languages and implementations like Scala, Clojure, Jython and JRuby are bringing more impressive languages to the JVM, they can't really do anything about the poor performance or the excessive resource usage of the JVM, nor can they do much about the poor state of the Java class library. But I'm also not suggesting that we have a viable alternative. Even though they recently released Parrot 1.0.0, it's still not a platform suitable for widespread production deployments. The Mono project is making some good progress, although they're typically playing catch-up to Microsoft's implementation, and don't have complete freedom to dictate how their runtime should behave. LLVM is perhaps the most promising alternative, but as the name implies, it is very low-level, not offering functionality we've come to expect from virtual machines (like garbage collection).

If the Java platform is to continue to serve us into the future, I suspect a significant overhaul is necessary. Performance and memory usage improvements to the JVM would be of a huge benefit to many. Better support for acting as the target of non-Java languages would likely be beneficial, as well. And a complete cleanup and reworking of the Java class library is a must. Unfortunately, this would not be a small undertaking, and would require huge amounts of time and effort. So it seems unlikely at this time that we'll see such a rework occur. This is somewhat unfortunate, as now is probably the best time to do it, while languages like Scala and Clojure have really started to mature, but just before they become so widely used that momentum against change develops.

Frameworks have become a familiar sight within the field of software development. They exist for virtually every language, every platform, and for all sorts of domains. One area where frameworks have really taken hold is that of Web development. Some people are very much in favor of using frameworks. Others suggest that frameworks are not such a good thing. In the end, it ends up being a mix of both viewpoints.

Frameworks prove to be quite useful when initially developing a Web site. In many cases, it is unknown how much interest there will be in the site. So it proves to be very helpful when one can use a framework to help quickly get a basic version of the site functional and deployed. The effort of initially developing the Web site is minimized to better account for the greater risk. This becomes even more important if the site is a business venture, and funding is limited.

If all goes well, the Web site will become popular. This is often the point when the framework that initially was very useful starts to become a burden. One of the first problems that developers typically encounter is the need to add highly-specialized functionality to their site, only run head-first into the framework. What they want to do doesn't mesh well with the philosophy of the framework. Unfortunately, the only course of action is to either circumvent what the framework tries to enforce, or twist the implementation of the feature in a way that'll fit with the framework. Either way, this usually results in numerous hacks, which in turn lead to code that is far more difficult to debug and maintain.

If the site is really lucky, performance will start to become a problem. This is one area where frameworks really start to become a hassle. Depending on the framework and its architecture, it may not scale very well. This is especially true for frameworks that integrate with a database system of some sort. We often run into a situation where the database access, often in the case of automatically-generated queries, is suboptimal, if not outright horrid. Many times the fixes are easy, but require some custom SQL code to be written, for instance. Soon, the developers may need to be continually avoiding the framework in order to maintain a suitable, or even just reasonable, level of performance.

By the time an application or system has become more advanced and mature, we often see a trend towards moving away from whatever framework was originally used. Sometimes this is easy to do, but usually it is not. The framework has become tightly woven with the software system, typically at the most fundamental levels, including user and session management. Any attempt to rip out and replace that framework-provided functionality will quickly cascade throughout the rest of the system. The scope of the necessary changes soon becomes too great, to the point of being too risky and requiring far too many resources to adequately test.

This is a trend I have seen for years now, regardless of the programming language or environment used. Frameworks really started to become widely used as Java gained in popularity, so this is where we see a lot of these problems arising. For many organizations in the aforementioned position, they really have a limited set of choices. On one hand, they need to continually develop their software to remain competitive, but this has become difficult to do because the initial use of a framework has contributed to a convoluted, unmaintainable code base. And on the other hand, they don't have the resources to partake in the significant refactoring and rewriting necessary to fix or replace the code base they currently have.

Some have tried to move from one framework to another as a way of solving their problems. One notable example is that of CD Baby, who tried to move to Ruby on Rails from PHP, but ended up falling back on PHP after Rails proved to not be flexible enough.

The best thing to do may be to initially start with a framework, but as soon as the site proves itself viable, every effort should be taken to move away from the framework and towards custom solutions that are crafted to tackle the specific problems at hand. This allows the development team to make the best use of the framework at the start of the project when they really need it, but it also gets it out of their way early on in the lifespan of the code base, to prevent too much other code from depending on it. This compromise may not always be possible, but should likely be chosen if possible.

I saw an article today talking about a "new wave" of activity within the Perl community. Although things have been looking more positive for Perl, it's still far too early to suggest that there is a Perl resurgence in progress.

The most significant progress the Perl community has made lately is that of actually getting some traction behind Parrot and Perl 6. For most of the past decade, we saw little to nothing substantial. There was a lot of talk, but little in the way of tangible software. What was available was not production-ready by any means, which of course is unsuitable for a pragmatic language like Perl.

Pugs, a Perl 6 implementation written in Haskell, was perhaps the most useful of what was produced during what we might come to refer to as the "Perl Dark Ages" of 2001 to 2008. During 2005, it saw relatively active development, and frequent releases. Unfortunately, it lost momentum during 2006, and since then has essentially stalled. A good indication of this is its very homepage, which at the time of this writing (February 18, 2009) still says "© Copyright 2005-2007, The Pugs Contributors."

The announcement last December suggesting that we'd actually see Parrot 1.0 during the first part of 2009 was a good first step. Indeed, it appears as though the March 2009 release of Parrot 1.0 is still on track. This upcoming release will no doubt be highly publicized online, and will likely raise significant awareness of Parrot and Perl 6. Although it isn't mature yet, this release will be an important milestone in lending some legitimacy to both the Parrot team and to the Perl 6 efforts so far.

A month after the aforementioned announcement regarding Parrot 1.0, we got word that the Rakudo implementation of Perl 6 was going to become more independent of the Parrot project. Over the past month, we have seen this happen to some extent.

Without a production-ready implementation of Perl 6, we can't yet say that there is a true resurgence or "new wave" within the Perl community yet. The recent activity surrounding Parrot and Rakudo has helped put the Perl community on the right track. But we likely won't see any true and widespread excitement arise until we have a decent Perl 6 implementation readily available. Only then can module authors start writing code that makes use of Perl 6's new features, which sets the stage for framework authors and application authors to start making use of Perl 6. At that point we'll need to see the Perl community produce something truly spectacular, much like Ruby on Rails was to the Ruby community several years back. Once that happens, we can consider the Perl community to have revitalized itself.