Pinderkent

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.

Recently, Adrian Bateman of Microsoft raised some questions, concerns and thoughts about HTML 5. Although Microsoft doesn't have the best reputation for supporting and complying with standards, especially when it comes to Web technologies, we shouldn't use those feelings as an excuse to ignore these questions. Had some other non-Microsoft individual or organization made these same remarks, they'd be just as valid and just as worthy of some serious consideration.

A number of questions are raised about the necessity of a number of the new elements. Indeed, many of the new section elements of HTML 5 do seem quite unnecessary. The use of <div> or <span> tags with an associated class should be more than sufficient replacements.

The same goes for the proposed <dialog> element, which is meant for representing a back-and-forth conversation between parties. Aside from the lack of necessity for this element, I personally don't like its name very much. Within the field of software development, the term "dialog" is often used to refer to dialog boxes, which is the first thing that comes to my mind when I see that tag. However, dialog boxes and the <dialog> tag are clearly two very different concepts.

With respect to some of the new tags relating to time and date handling, I have to agree with Adrian's description of such handling as "notoriously complex". Earlier this year I wrote about how care is needed when implementing time and date handling. But now HTML 5 seems to be opening this can of worms with its new <time> tag, and its <input> tag changes. I hope these new elements don't just introduce more problems than they solve.

The <bb> element sounds quite questionable. Aside from the completely non-descriptive tag name, the security implications of this element are obvious. Thankfully, both Microsoft and Mozilla seem aware of the potential dangers of this element.

The <progress> and <meter> elements theoretically sound useful, but I suspect that in reality, they just wouldn't be flexible enough for most Web developers. If their appearance couldn't be heavily modified, they'd likely just be passed over in favor of existing image-based approaches.

HTML 5 has always felt like a hodge-podge of different ideas from various groups, thrown together and called a "standard". It's good to see some realistic, solid criticism from one of the major Web browser developers. Hopefully their input will help HTML 5 resolve some of these issues surrounding unnecessary, impractical and potentially dangerous elements and changes.

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.

Thanks to a submission at Slashdot, I became aware of some recent efforts to prototype a new UI for the OpenOffice.org suite. Since OpenOffice.org isn't exactly known for having the nicest UI around, I thought we might see some significant improvements.

Unfortunately, that does not seem to be the case. I think this proposed UI is quite a step backwards, and not just because of its similarities to the "Fluent user interface" of Microsoft Office 2007.

My main complaint is that it's quite wasteful of space. It looks like about a quarter of the window space is consumed by the new toolbar or ribbon. This is partially due to the use of larger buttons. Functionality as simple as copying and pasting ends up using significant screen real estate.

So while we have larger monitors these days, we don't actually make better use of the greater screen area that they offer. Instead, it is wasted on unnecessarily large buttons and ribbons. And with smaller-screened netbook computers rapidly gaining popularity, even the slightest bit of wasted screen space becomes a hindrance.

For power users, a design of that sort is typically a step backwards when it comes to increasing their productivity. As some CAD software packages have shown, it often makes sense to get rid of mouse-based interaction. Some go so far as to offer a command prompt built into the bottom of the window, to allow for an experienced user to very rapidly interact with the software, and minimize the role of toolbars. Maybe this is an approach that OpenOffice.org should investigate.

Even for average or casual users, that sort of a design often proves to be confusing. Even now, a few years after Office 2007 has become widely used, there are many people I work with who just don't like it. While similar functionality is grouped, such a grouping may not be natural for all users. Such users have to repeatedly search through tab after tab, looking for how to perform the action they wish to perform. Their productivity ends up dropping significantly, as what should be simple tasks end up taking 10 seconds or more to perform.

I hope that the OpenOffice.org developers don't go ahead and adopt a design like the one that has been proposed. I'd rather see the UI left as it is for the time being, with more emphasis put towards improving the performance of OpenOffice.org, as well as reducing its often-significant memory footprint. Changes like those will, I think, help users out more than such a radical UI change, especially one that itself doesn't really bring any improvement.

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.