Pinderkent

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.

One of the main purposes of high-level programming languages is to save developer time by abstracting away the onerous and tedious aspects of the underlying hardware. In general, most high-level languages tend to do a good job at this. Unfortunately, we see these same high-level languages wasting significant amounts of developer time. Many times, this is due to performance problems. What becomes problematic, however, is that in order to properly diagnose and fix many of these performance problems, the developers involved need to obtain a high degree of understanding about the implementation of the high-level language that's involved.

A good example of this is a performance issue described recently with IronPython, an implementation of Python for Microsoft's .NET platform. In short, a very innocuous line of code was apparently responsible for the poor performance.

This incident highlights several main problems. The first is that high-level code can lead to some very unexpected interactions within the high-level language's implementation. This can obviously cause problems by misleading the developer or developers dealing with the performance problems. What appears on the surface to be a simple and likely very fast operation ends up being the culprit. A lot of developer time can be spent looking in the wrong places.

The second concern is that tracking down the problem requires in-depth knowledge about the high-level language's implementation. To some extent, we use such high-level languages in the first place to avoid needing to acquire such lower-level knowledge. We want to focus on the application we're writing, not on dealing with issues pertaining to the platform we're building upon. Time spent learning about the high-level language's implementation is time not spent on developing the application at hand.

This particular situation seems to have had a "happy" ending. The victim of the poor performance got a rapid response from somebody who did have inside knowledge about IronPython's implementation. Unfortunately, this isn't always the case. I've seen far too many times when developers have spun their wheels trying to track down obscure performance problems of that type. And it isn't a problem associated just with programming languages like Python, Ruby, or Perl, either. We often see it happen with SQL. A minor change to a query can result in a huge performance gain or loss.

As we start using high-level programming language implementations like IronPython, Scala, Clojure and JRuby, which are themselves often implemented in high-level programming languages like Java or C#, which in turn run on some sort of a virtual machine, we'll run into these sorts of problems more and more frequently. Each additional layer of software abstraction that we add in makes the situation more and more difficult. Soon we may need to look in two or three very different layers of software, assuming we even have source access, to track down performance issues. This could very well lead to a serious waste of developer time and effort.

Today, over at Hacker News, I saw a topic asking why C++ isn't commonly used for Web applications. The question itself is quite valid; we typically don't see Web applications themselves developed in C++. But that doesn't mean that C and C++ don't have an integral role within a Web-based system. Their use isn't as visible as that of Ruby, PHP, Python or Perl, but it's important nevertheless.

Admittedly, the back-end of many Web applications really isn't all that complex. In many cases, it's basically just a friendlier interface to a datastore of some sort, maybe offering some caching, and usually some basic data manipulation. And although C++ libraries like the STL and Boost allow for such tasks to be performed with relative ease, there's essentially little benefit in using C++. Scripting languages are often sufficient.

That said, C and C++ still do have a huge role in most Web application stacks today. We shouldn't forget that most of the popular server operating systems, Web servers and database systems today, as well as the most widely used implementations of most scripting languages, are typically written in C or C++. This is quite apparent within the popular open source Web stacks.

At the very core, we have C playing an integral role in virtually all of the popular server operating systems today, especially UNIX-like systems like Linux, FreeBSD, and Solaris. On top of that, we have popular Web servers like Apache, nginx, and lighttpd that are all written in C. And for database systems, PostgreSQL and SQLite are written in C, while MySQL uses both C and C++.

C and C++ are also critical to the programming languages used to implement many Web applications. The most widely used implementations of Python, Ruby, Perl and PHP all use C. Even Sun's HotSpot Java virtual machine makes very extensive use of C and C++.

So when we take a more holistic view of Web applications, we see that C and C++ prove to be very widely used. They're used for some of the most critical aspects of Web-based systems, where performance and reliability truly matter. Even if they get more of the attention, languages like PHP, Python, Ruby, Java and Perl end up being little more than glue languages, tying together the software implemented in C or C++. It becomes easy to forget their importance, but this may just be because the software developed using them has matured to the point where they provides such stable interfaces that we can totally ignore their implementation language. Nevertheless, C and C++ are very critical to the vast, vast majority of Web applications that exist today.

The Where are the RIA "killer apps"? article that Kas Thomas recently wrote is both insightful and absolutely correct. Despite all the hype around them, he correctly points out that RIAs, short for Rich Internet applications, have been an utter failure. And it's not just one vendor's implementation that has failed, either. We just haven't seen anything truly useful produced using Microsoft's Silverlight, Adobe's Flex and Sun's JavaFX.

In the past, I have written about the lack of technical merit of these RIA platforms. I think this contributes to why we really haven't seen anything truly innovative and useful built upon them. They're such a feeble foundation to begin with that perhaps they can't allow for anything truly useful to be done with them.

One thing we can consider is why some people think we even have a need for RIAs in the first place. The typical argument is that the Web browser just isn't a suitable platform for building more complex applications. This is obviously quite true. The browser and the Web were originally intended for displaying documents and allowing for navigation between them. Over time, hacks like JavaScript were integrated into the more popular browsers, allowing for some degree of programmability. Some developers soon mistook the browser as an application development platform. So here we are today, with many believing that the Web and Web browsers are somehow replacements for our existing desktop environments.

Of course, the Web browser is quite a crippled software development environment. You're limited to essentially one language, JavaScript. Pixel-perfect layout is a huge hassle. When you add in the numerous bugs, incompatibilities and inconsistencies between browsers, life becomes even more difficult. In short, what we could do relatively easily with more traditional application development platforms quickly becomes much more awkward in the Web browser, leading to poor-quality applications that take longer to develop.

RIAs have arisen as a bandage to try and make application development within the Web browser more friendly. Java applets and Silverlight are good examples of vendors trying to essentially push their desktop-oriented platforms into the browser. Of course, anyone who has developed software using the non-embedded versions of those platforms know how much nicer they are to work with than the browser-based variants, and more importantly, how much more productive.

I don't think that RIAs and their platforms can be salvaged. They're a failed technology, built specifically to exist within a feeble technology. If we want our applications to be network-aware and network-accessible, there are much better approaches. And nothing is stopping is from using HTTP; we can use it more effectively if it's not returning HTML, JavaScript, or CSS. So perhaps we should just let these RIA platforms die off, so we can get back to writing innovative software using real application platforms that promote developer productivity.