Pinderkent

I recently saw an article about the accepted Project Coin changes that are planned to be included in JDK 7. This is some good news for the Java community. After a relatively long period of stagnation concerning the evolution of the Java language, and some fierce competition from C#, these are the sort of practical changes we need to see.

Most of these proposed changes aren't exactly revolutionary. Several of them have already been implemented for some time in C# and other .NET-based languages. They've proven to be effective there, and will hopefully bring the same benefits to Java.

The Automatic Resource Management proposal is a good example of a feature that is badly needed in Java. The using statement of C#, and the Using statement of VB.NET, have proven this concept. They make it safe and easy to ensure that certain non-memory resources are disposed of appropriately. This is exactly the sort of practical language-level change that Java needs.

The Strings in Switch proposal is another one that suggests a very useful change. Not being able to use a switch statement to select a case based on a string value has always been an annoyance to me.

The Improved Type Inference for Generic Instance Creation proposal may help making coding quicker, although I'm not convinced it's as beneficial as it sounds. Although it reduces what some may consider to be redundancy in code, most decent Java IDEs offer auto-completion support that helps prevent a programmer from actually typing out the parameterized types. And we do lose some detail within the object instantiation code, which otherwise is self-documenting in some sense. I think the benefits of this change will require some experimentation once an implementation is available.

Some of the other proposed changes, such as the addition of language support for JSR 292 and the collection-related changes don't seem as sensible to me. In the case of adding more support to the JVM and the Java language for supporting dynamically typed languages, I think this is a bad idea. The JVM itself is better suited to statically typed languages, and trying to hack on support for dynamically typed languages may just result in further bloat.

In the case of the collection-related changes, we are getting to the point where a major reworking of the collection classes is in order. We already have older classes like java.util.Hashtable and java.util.Vector, as well as the Java Collections Framework, and then all the changes that were made to both groups during the introduction of generics with Java 5. Trying to further build on the existing mess may just make the situation worse. But a clean up would be massive, and would have many repercussions on existing software. So there may be no easy answer here.

The acceptance of these proposals is a very good sign. They show the sort of activity and change needed to keep the Java programming language and platform relevant in the face of numerous other competing programming languages and platforms. I do hope that we get to see these implemented in JDK 7, as some of them do sound to be practical and badly needed by Java developers.

If you go into the office of any professional, such as a lawyer, doctor or civil engineer, you will likely find bookshelf after bookshelf of books, journals, and other reference material. Any computer programmers striving to achieve and maintain even the lowest levels of professionalism should likewise have an extensive hardcopy library.

Antonio Cangiano recently wrote about how the wide availability of online content can lead computer programmers to avoid buying physical books. While he makes some very good arguments in favor of buying printed material, many of the programmers I work with on a daily basis don't seem to think that way.

Recently while at lunch with a group of developers, the topic of books came up. Some of the younger developers, already several years out of university, admitted that they hadn't purchased any programming-related books since graduating. I was somewhat surprised by this. I find myself purchasing, and actually reading, at least one book a month. Depending on what technologies my clients are using, this may sometimes reach a book or two a week.

Now, eventually computing books do become quite outdated. So every few years I donate some of the worst offenders to local thrift stores. This helps keep my personal library focused and relevant, and helps maintain its usability and efficiency.

Most of the older developers said they were in the same position as I am, with them purchasing a large number of hardcopy books each year. We thought that perhaps this had something to do with how things were when we started in the industry a few decades earlier. We could all recall the shelves and shelves of books, similar to these DEC manuals, that'd be located near most significant computer installations.

To us, it just seems natural to have easily-accessible printed documentation available, be it a book or a manual. Admittedly, things have changed significantly over the past couple of decades, and we find much more content online or in various electronic forms. So it's seems reasonable that younger programmers would be more accustomed to reading such documentation. However, I hope that they don't neglect to recognize the value of a large printed library. It's the sort of thing that can make a very good programmer even better.

For several years now, those of us involved even in the slightest degree with Web development will no doubt have run into the numerous problems associated with supporting Internet Explorer 6. Although it has survived longer than much other software, and even today still has a significant number of users, many Web developers are finding that it's just not worth supporting IE6.

So while many Web developers and sites are beginning to phase out support for IE6, apparently even including heavyweights like YouTube, others aren't ready to do so yet. Toby Joe Boudreaux, for instance, suggests that we shouldn't stop supporting IE6.

All in all, this is a situation that those of us who have been in the industry for years have faced time and time again. There ends up being a platform of some sort that was heavily used at some point, but has clearly become obsolete. And there's always some resistance towards moving away from it, or no longer supporting it. Yet we typically find that once we've moved on to newer versions or newer platforms, we're much better off that we were in the past.

A good example of this is the JS2E 1.3 and J2SE 1.4 releases of the Java platform. A huge number of businesses standardized on it a few years back. Large systems were build upon it, and it became quite entrenched. Eventually, we had Java 5 available to us, and then Java 6. Yet there was a huge amount of resistance within these enterprise operations when it came to moving forward from 1.3 or 1.4.

I work with a number of different clients who have each standardized on different versions of Java. If there's one trend that is quite clear, it's that those who have transitioned to newer versions of the Java platform are much better off. For instance, one of those clients uses Java 1.3, even today. While it is generally suitable for their needs, they've been finding it more and more difficult to find good Java developers willing to work on such an old version of the platform. They also find it difficult to make use of the numerous class libraries and frameworks that don't support Java 1.3.

On the other hand, some of those clients are on Java 6. One of them is even actively developing some upcoming projects targeting Java 7. And what we see with them is a development team that is on the cutting edge, eager to use the new language features and third-party code or frameworks to develop more effective software in a more efficient manner. Whatever effort is spent on transitioning to newer versions of the Java platform ends up being dwarfed by the benefits the newer versions have brought to the developers, and then the users of the software systems themselves.

So one main lesson we can take away from this is that we shouldn't be afraid to discard old software, especially when we know there is much better out there, even if it means ruffling the feathers of some entrenched users. This is exactly where we are with IE6 today. Firefox, Safari, Opera and Chrome are clearly superior browsers, in just about every way. There are significant benefits, for both developers and users, to moving away from IE6. It's just one of those things that we should do, and the sooner the better. We shouldn't be afraid.

Although it's still in its infancy, with its first release coming just at the beginning of May 2009, the Haskell Platform is apparently making quite a splash, especially amongst Windows users. In many ways this isn't surprising, as the Haskell Platform offers just what Haskell has been lacking for some time now.

By providing a convenient and standardized Haskell environment, the Haskell Platform helps make Haskell much more accessible and practical to a much wider developer audience. Indeed, part of the reason why languages and platforms like Java, .NET, Perl and Python are so popular and widely used is because they offer a good all-in-one platform so that developers can focus on developing their software, rather than trying to put together a suitable development environment.

Solid platforms of this style are essential for larger, real-world software systems like those commonly fulfilling critical tasks for businesses of all sizes. By having such a platform, especially one with a vibrant community backing, developers can begin to trust Haskell more and more. And in some cases it will become essential to make use of functional programming techniques if we want to effectively make use of the massively multi-core CPUs of the near future. Efforts like the Haskell Platform will help get us there quicker, and will allow us to produce higher-quality and higher-performance software more reliably and efficiently.

As the Haskell Platform matures, I don't doubt that it will garner much support throughout the Haskell community, which will in turn help it improve even further. I'm very interested to see how quickly the Haskell Platform can build momentum, and how quickly it'll be able to help bring Haskell to the forefront of modern software development. Given our current situation, we very badly need the power of a strong, statically-typed functional language. It looks like Haskell may just be the language to provide that to us.

A common trait among some of the poorer-quality programming languages, namely PHP and JavaScript, is their use of weak typing. While some developers are convinced that it's acceptable, it's generally a bad idea to have a programming language essentially guess at what the programmer means.

Recently, I saw an article describing some problems within a PHP script caused by automatic conversion. Frankly, these kinds of issues should just not exist. Strong, static typing is clearly a better approach. Although it puts slightly more of a burden on the programmer, the act of manually specifying type conversions leads to higher-quality software, especially if any errors are caught at compile-time, rather than run-time.

JavaScript is another language that employs weak, dynamic typing. I recently saw another article that gives some good examples (under the "2. Plus operator overloading" section) of how this behavior may result in unexpected results, especially for novice developers. But even seasoned professionals still make mistakes, and such conversions should at least be flagged with warnings, if not outright disallowed.

Even though we often deal with fuzzy and incomplete specifications when developing software, we shouldn't bring such uncertainty and guesswork to our communication with the computer itself. We should specify exactly what we mean, even if it does take slightly more typing. Then again, when using languages like Haskell and OCaml, we can clearly see how strong, static typing and type inference can be implemented without overly burdening programmers. Any type conversions that must be manually specified help to force the programmers to think about what they're doing, which in some cases may be quite wrong, especially if a type conversion is necessary.

For the sake of trying to achieve even a moderately reasonable level of quality in our software, especially when programming for a hostile environment like the Internet, we shouldn't resort to languages like JavaScript and PHP that allow for type-related errors to occur so easily. It's even worse when they try to make automatic conversions that result in unexpected behavior. That's just plain unacceptable.