Pinderkent

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.

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.

There have been reports recently suggesting that IBM may soon acquire Sun Microsystems. For those of us in IT, acquisitions of these types are always a big deal. While Sun's server hardware is widely deployed and of great importance to many, my interest is mainly in software, so that's the area I'll focus on in this article.

In the software world, Sun is most well known for Java and Solaris. I suspect that we'll see two very different outcomes for these technologies if an acquisition does occur. It's difficult to say what will happen for some of the smaller or more obscure software products and projects that Sun was involved with, such as OpenOffice.org and NetBeans.

In terms of Java, I don't think we'd see much, if any, negative change. IBM has embraced Java, and understands its use, at least for business users. For some time now they've provided their own JDKs for a number of platforms. Java also plays a significant role in their prominent WebSphere Application Server. They're actively involved with developing new Java-based technologies. And their involvement and contributions to Eclipse have had a huge impact within the development community.

In some respects, such an acquisition may be quite good for Java. Although known for generally being more conservative, IBM does have the resources needed to make the changes to the Java language and platform that are necessary for it to compete better with Microsoft's .NET platform. We need to see half-baked technologies like JavaFX and JavaFX Script discarded. But we also need to see functional or object-functional languages like Clojure and Scala perhaps brought in as core components of the platform.

If IBM put their weight behind such technologies, we very well may see more developers be willing to adopt them. As we move into a world with massively multi-core CPUs, we will need to make use of functional programming techniques to write scalable software that effectively uses such hardware. Given IBM's (and Sun's) emphasis on high-end server hardware, a willingness to adopt and support Scala and Clojure could really put them in the lead in this area.

Things don't look as good in terms of operating systems. As basically everyone in the industry knows, Sun has offered Solaris for years, while IBM has offered AIX. While both high-end UNIX-based operating systems, I'm not certain if they could be successfully integrated. At a technical level, I suspect they are just too different.

If an acquisition were to take place, I imagine that Solaris would be supported for some time, but eventually deprecated in favor of AIX. This would be similar to what happened to Tru64 UNIX when HP and Compaq merged. If I recall correctly, HP originally planned to transition Tru64's more advanced features to HP-UX, but this didn't end up happening, for the most part. Now Tru64 is essentially on its last legs.

Given that Sun has released much of the Solaris source code over the past few years in the form of the OpenSolaris project, it seems likely that it will live on in at least some form. A truly self-sustaining community, akin to the Ubuntu project for Linux never seemed to develop, however. So it's difficult to say how much, if any, innovation we'd see out of the OpenSolaris project were Sun no longer supporting it.

Another interesting area to consider is that of the MySQL-related technologies and business that fell into Sun's fold with their acquisition of MySQL AB at the beginning of 2008. Given IBM's pivotal role in the development of relational databases, and their offering of the very solid and professional DB2 family of database products, MySQL's future in such an organization seems quite limited. Even within the open source community, MySQL is generally considered an inferior RDBMS. I really can't see it having much of a future, especially with Marten Mickos and Monty Widenius out of the picture.

We'll just have to wait and see what comes out of these rumors. But in terms of the software world, such an acquisition could have some significant impacts. They'd mainly be felt by those working with and developing enterprise systems, but may still be noticed by others, including, for example, OpenOffice.org users. So I see such an acquisition as potentially being good for Java, but less so for the Solaris, and potentially disastrous for MySQL.

Today I read an article reminiscing about the high responsiveness of BeOS. It is unfortunate that people in general are beginning to forget about BeOS. It was a truly remarkable operating system, and as the article I read correctly points out, the responsiveness of the desktop environment it provided over a decade ago still hasn't been matched even by contemporary desktop environments.

It's no wonder that BeOS was able to provide such a responsive desktop experience. We can better understand this by reading the The Media OS whitepaper from Be, Inc.. Their BeOS R4 datasheet is also a useful document to read.

They correctly predicted the rise of multiprocessor systems, although perhaps anticipated their widespread adoption somewhat prematurely. Furthermore, they correctly predicted that such processors would be 64-bit processors. The result was an operating system that was heavily threaded throughout, with powerful 64-bit filesystem, and high-performance graphics and I/O subsystems.

At a higher level, BeOS's various "Kits" provided very well-organized and sensible chunks of functionality. In addition, it offered a very UNIX-like filesystem layout and set of commands. I recall feeling very comfortable and productive with BeOS the first time I used it in the 1990s, because I could reuse so much of my knowledge from my previous experiences with operating systems like Solaris, HP-UX, Linux and BSD/OS.

Even today, over ten years after its release, we can read through the BeOS Release 4 specifications and still not find some of this functionality suitably implemented in today's best desktop and workstation operating systems. And we can't forget that BeOS Release 4 wasn't even the last release of BeOS!

For a variety of reasons, BeOS never succeeded in the marketplace. In many respects, it was likely available far too early to really prove its worth. It's only now that we are just beginning to have widely-available systems, like those built around Intel's Core i7 CPUs, that could really benefit from the pervasive multi-threading and 64-bit support that BeOS offered a decade ago.

Although there have been some attempts, it's unlikely at this point that we'll see much, if anything, further come of the original BeOS codebase. Thankfully, there have been efforts by the open source community to develop operating systems that bring us the benefits of BeOS. The most notable of these projects is likely Haiku. It has been progressing well, with VMware images available for use.

BeOS was a truly amazing desktop and workstation operating system, clearly a decade before its time. Were it to have survived and been continually developed, today it would likely provide a tremendously responsive, productive and powerful desktop environment. This is would be especially true on today's computers with 8 logical 64-bit CPUs, extremely capable graphics hardware, and much faster I/O. Even if open source efforts like Haiku manage to capture a small fraction of the BeOS experience, we'll be very well off.

Although Java's Swing has very little usage in consumer-grade software applications, it is used in a significant amount of in-house business software at many companies, as well as in a variety of system administration tools. While it was one of the major benefits of Java for some time, Swing is really starting to show its age. With it now being roughly a decade old, it's time to start looking for a replacement.

Jonathan Giles recently wrote about what he'd like to see in what he calls "Swing 2.0". His suggestions are excellent. Many of them revolve around updating Swing to make better use of the new language features introduced with newer versions of the Java language.

The use of enumerations is a must. One of the main sources of problems with Swing applications is an incorrect integer constant being passed to a method. The effects of such a mistake can vary significantly, and can often be very difficult to detect and debug. Unfortunately, Swing makes use of integer constants in numerous places. For compatibility reasons, these likely would have to remain as integers. Having a mix of integer constants and enumerations is arguably worse than just having one or the other.

Giles suggests that "Swing 2.0" would be a cleanup of the existing Swing code, with it being ideal if API compatibility could be maintained. My thought is that it's best to not base the updated library on the existing Swing codebase. The existing codebase has served us well (or not so well, in some cases), and given its age should probably be retired.

An added benefit of starting afresh would be the chance to eliminate the dependency on the AWT. In terms of desktop application development, the AWT is basically a relic now at almost 15 years of age. It came about in an age when Windows 95, Mac OS 7, and on UNIX the Motif toolkit ruled the roost. The amount of change since then has been huge. AWT is essentially useless on its own for modern software development, yet we still feel its presence when doing Swing development.

A new version of Swing should probably not take the same approach as that of SWT. Anyone who has worked with SWT knows the criticisms mentioned in the Wikipedia article quite well. Inheriting from existing widgets can be a hassle in many cases, and the manual resource deallocation of some SWT objects goes against the Java mentality of automatic resource deallocation.

However, it would be beneficial if the new toolkit did offer better performance than that of Swing. Giles mentions misuse of Swing's event-dispatch thread as one problem that needs to be addressed. But even well-written Swing applications running on a modern computer often don't feel as responsive as native applications do. A focus on making better use of resources and hardware acceleration may help with this.

Now would be a good time for the development of such a toolkit. Java 5 has become relatively widely deployed over the past few years, so it would be feasible to make use of the new language constructs it offers. And compared to .NET, Java as a platform has stagnated somewhat. A high-quality GUI toolkit may help bring developers back over to Java, or at least renew interest in it.