Pinderkent

At the beginning of this month, I wrote about BeOS, and how far ahead of its time it was. It turns out that a former colleague of mine from many years back had read that article. He contacted me this week and mentioned that the company he works for in Germany still uses BeOS on a small number of systems!

While I'm sure it still has casual hobbyist users, I can't say that I had really expected BeOS to still be used commercially. He said that they had gotten some custom animation software developed for them nearly a decade ago, and the developers recommended BeOS since it was the most suitable OS at the time for such work.

I tried to find out more about the version of BeOS they were using, as well as what hardware they were running it on, but my former colleague wasn't sure. He didn't work directly with the systems, but said he'd try to talk to one of the users to see if they had any idea. I haven't heard back from him yet, however.

As for why they still use such old systems, he said that they work fine, the custom application still allows them to get their work done, and they don't feel any need to upgrade. That is fair enough. It's a pretty common response from small businesses who are still using older hardware and software.

I'm pleased to see that BeOS is still of use to some people, years after it was effectively discontinued. Perhaps as Haiku matures, it will eventually provide my former colleague's company (and any other BeOS users) a way to upgrade their hardware, while still being able to make full use of their custom applications, as well as the BeOS software platform.

I read an article today suggesting that functional programming hasn't caught on widely because most developers today haven't been convinced that it is necessary. I'm not sure that's completely correct. Those who are truly "in the know" will have been at least investigating functional programming for some time now. The rest can merely be considered stragglers, who don't yet realize that they currently do have, or will have, a need for functional programming in the near future.

Although it was clear several years ago, we can now say with almost complete certainty now that we will soon be seeing consumer-grade PCs with 32 or more logical processors. Intel's Core i7 has recently brought us part of the way there. At the higher end, Sun's UltraSPARC T2, for instance, offers 8 cores for 64 threads of execution. The trend is obviously towards processors offering multiple cores, each of which may offer multiple threads of execution. And today's mainstream programming languages just don't take advantage of such environments too well.

Some industries have dealt with these issues already. That's why Erlang has been around for over 20 years now. Anyone who has worked on telecom systems or even just worked with Erlang knows the benefits that its concurrency model brings. These days, with the advent of consumer-grade multicore CPUs, such benefits are applicable even when using the low-end systems. In fact, to make the most of today's and tomorrow's CPUs, we will need to develop our software to be more concurrent.

To do this effectively, we likely will need to make use of at least some of the techniques pioneered by the functional programming community. Immutability is perhaps the most important and useful technique when writing concurrent software. Strong, static typing as offered by languages like Haskell and Standard ML is also very useful. Well-integrated support for writing concurrent applications, such as that offered by Erlang, is another major benefit.

However, we likely won't see the development community at large using Haskell, ML or Erlang any time soon. What we'll probably see first is a move towards hybrid or multi-paradigm languages. Clojure and Scala are two of the most familiar at this point. Both target the Java platform, which makes them appealing to existing Java users.

Somewhat surprisingly, Microsoft may very well be the ones who bring functional programming to the mainstream, through their F# language that is to be included as part of Visual Studio 2010. Functional programming will quickly be made easily accessible to a large number of application developers, at a critical time when many will likely be looking for ways to better leverage systems with many logical processors.

Unfortunately, Sun seems content with spinning their wheels with Java and worse, JavaFX Script. Given Sun's long history providing back-end hardware and software, especially hardware that offers many threads of execution, it's sort of surprising that they aren't giving more support to languages like Clojure and Scala. These are the sort of languages that give current JVM users the boost they need to remain or even become competitive.

We're starting to see a variety of factors come together now that will make functional programming techniques far more useful to the mainstream software developer. Multicore CPUs are now readily available, including in low-end consumer-grade desktops and laptops. This will start increasing the demand for efficient, scalable and practical methods of making use of these resources. A variety of open source functional languages, like Haskell, Erlang, Scala and Clojure, have shown that they're willing to help meet these demands. Microsoft is going with F#. The need to use functional techniques combined with readily-available language implementations will allow for this flourishing to occur.

Today I read an article suggesting that 8 GB of RAM is "only just enough" memory for a typical developer's PC running Windows. I'm not here to dispute that claim. Indeed, the RAM usages given in the article are somewhat realistic. Using recent versions of Microsoft's various software and database development tools does require a significant amount of RAM. In many ways, the need for that much RAM is unfortunate and likely quite unnecessary.

In the mid-1990s, I had the pleasure of doing software development on a NeXTstation Color. Unlike the base NeXTstation Color models, which came with 12 MB of RAM, the system I was using had been upgraded at some point to 16 MB of RAM. But by that point, it had been used by several developers before being passed on to me. Yet it was still an extremely powerful development system.

Now, it might be argued that Windows development today isn't much like the software development we did on a NeXT system 15 years ago. In some sense this is true, but for the most part very little has changed. Objective-C is relatively similar to C#. The various NeXTstep kits are fundamentally similar to the .NET standard class library. We had Project Builder for development, as well as Interface Builder for drag-and-drop GUI creation. And although it wasn't available yet when I was developing on that NeXTstation, NeXT would later introduce WebObjects for developing Web applications.

Anyone who has done any Mac OS X development lately has a general idea of what it was like to develop software on a NeXT system. It was an experience quite comparable to software development today, due to how far ahead of its time NeXT and their software offerings were. And although many people today might find it difficult to believe, we actually were able to develop relatively complex business software on a system that had only 16 MB of RAM. To put things into perspective, the article I read today claims that at least 500 times as much RAM is needed today than was needed 15 years ago. But the software we're developing today really isn't much more complex.

It's obvious why this has happened. Since then, the price of RAM has dropped considerably. It has become far cheaper to acquire more RAM than it is to pay a developer to write more efficient software. In fact, we see this reflected throughout the entire software stack. It's no secret that Windows Vista requires a significant amount of memory to run efficiently. The same goes for .NET. Developer tools like Visual Studio are also very memory-intensive. Given the platform and development tool vendor's general disdain towards writing memory-efficient software, it's no surprise that the applications developed by software developers using those tools would also consume more memory than necessary.

One thing to consider is how we now approach a simple task, such as reading and writing data files, versus how it was done 15 years ago. Today, we're likely to see some given data persisted to an XML file on disk. To work with such files, we'll need an XML parser, some way of representing the XML document in memory, custom code to tie everything together, and so forth. Fifteen years ago, we would have used a custom binary format, and written the serialization and deserialization code ourselves. Although it would have taken longer to develop, the overhead in terms of memory usage and CPU usage would have been considerably less with the custom binary format.

But to require over 500 times as much memory today is still quite excessive. I think it just goes to show how little developers today care about minimizing memory usage of their applications. The low cost of RAM no doubt helps our "cause" immensely. Today we can get away with waste that would have been considered intolerable a decade ago. But on the other hand, I think we are shortchanging ourselves to some extent. The memory we consume today, essentially out of waste and carelessness, could no doubt be better used for other purposes. Extra memory put towards even just caching data from disk is typically beneficial to system performance, even in systems with significant amounts of RAM.

Fifteen years ago, I don't think I would have believed it if somebody from now had come and told me that we'd have low-end PCs with 4 GB of RAM, typical development systems with 8 GB, and we'd actually need that much RAM to run contemporary applications. Yet here we are. And I don't even think it'd take that much more care or effort to minimize the amount of RAM we use, or at least bring it down to a more reasonable level. To have any effect, we'd need to see this initiative at all software levels, from the operating system, to any higher-level runtimes like .NET and Java, to our software development tools, and finally to the applications we develop. Unfortunately, I don't see this happening.

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.

When it comes to purchasing consumer-grade PCs these days, it's rare to find a system with a CPU that only has a single core. Most laptops even offer a dual-core CPU. So as software developers, we're entering a unique era where we can start to employ parallelism in ways that would not have been practical before. In some cases, we will need to exploit this parallelism if we hope to increase the performance of our software.

Unfortunately, we are also seeing a move towards the development and use of Web-based applications. These are applications that are hosted on a remote server, and provide an HTML- and AJAX-based interface that is accessed via a Web browser.

These Web browsers attempt to give us some degree of parallelism, often through tabbed browsing. While this works great for relatively static content, we experience problems with JavaScript scripts that run for anything longer than 500 ms or so. Since the computation of all of the tabs is performed within the same (main) thread of the browser, a long-running JavaScript script immediately locks up all of the other tabs.

The solution is quite clear: each browser tab should have its own thread, in which a separate instance of a JavaScript interpreter executes. A long-running JavaScript script in one tab (ie. one that runs for 2 to 3 seconds, if not more) will not prevent, at the very least, the user from switching to an alternate tab and continuing to work there.

Of course, most Web browsers today just aren't prepared for such an architectural change. And considering how large of a job it is to write a high-quality browser, it seems unlikely that we'll see a Web browser written from the ground up that better supports the benefits offered by the now-prevalent multi-core CPUs. So it's quite unfortunate that we have all of this processing power available to us, but it can only be exploited to a limited degree because developers are choosing to write JavaScript-based applications that execute within parallelism-unfriendly Web browsers.