Pinderkent

JavaScript has been around for over a decade now. During that time, we've seen it implemented by every major browser vendor, and thus we've seen it become widely used by many Web sites. We've even seen JavaScript used in non-Web applications and uses.

But JavaScript has some pretty serious drawbacks. The performance of the various JavaScript interpreters embedded in the popular Web browsers has always been less than ideal. And being interpreted, it often becomes more difficult to detect syntax errors and other common mistakes. Worse yet, being weakly typed opens JavaScript scripts up to a whole host of type-related problems.

There are programs available to help with the development of JavaScript scripts. JSLint analyzes JavaScript code, looking for a variety of problems. A JavaScript debugger, such as Venkman, is also essential. But even these tools do not catch many serious problems.

As more complex Web applications are developed using JavaScript, we've started to see certain limitations being hit. One such limitation is the maintenance of a sufficiently high level of quality. This is not only in terms of correctness, but also in performance and portability. The very nature of JavaScript makes quality control a tedious task.

It may be time for us to look beyond JavaScript, to technologies that offer the capabilities needed for larger-scale software development. One essential feature is strong typing. Ideally, this typechecking can be done statically (ie. before the code is executed). Type-related errors caught before an application is executed leads to the developer addressing them, rather than a bewildered user encountering a confusing error message at runtime, typically interrupting (if not losing outright) what they were working on.

Strong, static typing has additional benefits, especially when it comes to optimizations. The more restrictive semantics allow the optimizers within compilers and interpreters to make assumptions and decisions that could not otherwise be made. This in turn often allows for greater optimization techniques to be applied to the code, improving runtime performance and decreasing code size.

So instead of looking at a language like JavaScript, we should probably be looking more towards a language like Standard ML or Haskell. I think Haskell would be an optimal choice. It offers many of the high level constructs of JavaScript, but it also addresses many of the aforementioned problems. What we lose relative to JavaScript is the ability to use techniques that lead to poor-quality, buggy code. But furthermore, we gain a language that promotes quality software through strong, static typing. Beyond that, Haskell has many advanced features, including pattern matching and lazy evaluation, that we really don't find offered by JavaScript.

Haskell has even more going for it. Another major benefit is the availability of several interactive environments and interpreters. GHCi, for instance, is actively maintained, and is of a very high quality. There is also Hugs 98, which is a rather complete implementation of Haskell 98.

The purely functional nature of Haskell will become more and more important as consumer PCs begin to offer four to eight (or more) cores per CPU. Haskell can allow for the safe, automatic parallelization of code to a far greater extent than JavaScript ever could. We will need to take advantage of such features if we will want our Web applications, or even our applications in general, to effectively use the PCs of the near future.

So what we need to see is a Haskell implementation embedded within a major browser, and extended to offer DOM integration. This would allow for developers to use it instead of using JavaScript. The very nature of Haskell would allow for the development of complex, high-quality Web applications. With such Web applications becoming larger and more essential each day, we need a much more significant focus on quality and performance. Haskell will allow us to achieve this, while JavaScript will not.

A few weeks back, at the end of December, FreeBSD 7.0-RC1 was released. FreeBSD 7 will no doubt prove to be quite revolutionary. For one thing, this will be the first major FreeBSD release in a number of years. FreeBSD 6.0 was released in November of 2005, so there has been quite some time for the development of FreeBSD 7 to take place.

If you're unfamiliar with what FreeBSD 7 will bring, I'd suggest that you look over the excellent What's cooking for FreeBSD 7? Web page. As you can see, the amount of change FreeBSD 7 will bring is quite significant.

I'm particularly looking forward to FreeBSD's support for ZFS. ZFS alone is a rather revolutionary filesystem originally developed at Sun for Solaris. It addresses many of the difficult issues we face when it comes to dealing with the huge datasets that are becoming all too common these days.

Having support for ZFS available in FreeBSD will be a major win for those who already have extensive FreeBSD infrastructure in place, but need the features that ZFS offers. So it will become possible for them to continue using FreeBSD, rather than having to integrate Solaris into their network infrastructure. This proves very helpful in maintaining an effective, reliable server environment.

Another major improvement will be the use of the new jemalloc userland memory allocator. While phkmalloc has served us well for some time now, jemalloc has been designed from the ground-up to take into account the multiprocessor systems that are becoming virtually ubiquitous today. For those of us who are dealing with heavily threaded software running on multiprocessor systems, there is evidence that jemalloc will bring some significant performance gains.

Also of importance are the improvements to the networking stack. With gigabit (or faster) network cards being the norm these days, FreeBSD's support for TCP/IP Segmentation Offload (TSO) and Large Receive Offload (LRO) will no doubt prove to be very useful. Along with the new sendfile() implementation, and the improved sosend() functionality, we will likely see some large networking performance boosts.

There are, of course, many other improvements that have been made. There are security enhancements, improved audio support, libthr becoming the default threading library, updated support for executing Linux binaries, and the new SCHED_ULE replacement, just to name a few.

It's time for those of us in the IT profession to start considering the use of FreeBSD 7. The new features and improvements offered by this release will no doubt have a great impact for many of us. We will be getting better support for storing huge amounts of data, networking performance improvements to help us better transmit that data, and userland performance improvements to better let us manipulate it. And we can't forget to thank the many FreeBSD developers and contributors for all of the time and effort they have put into creating such an excellent operating system.

When you mention the Ada programming language to most developers, they tend to think of embedded software development, typically in mission-critical environments such as aircraft and electric power plant control systems. But we shouldn't think that such environments are the only place where Ada can be of use. For the past several weeks, I have been working with a shipping company that makes extensive use of Ada for their in-house software.

I haven't seen a company use Ada this extensively for such a wide range of software development tasks. They have back-end database applications written in Ada. They have client-side applications written in Ada. They've developed an in-house framework for developing Web applications using Ada. Even their custom build system is itself implemented in Ada.

So today I had an opportunity to talk with one of the managers there about why they use Ada so much. His responses were very interesting, I think. He said that Ada was introduced to their company by one of their developers in the early 1990s. Although they've had some difficulty finding developers who are proficient with the language, this manager reported enormous productivity gains for those developers they do employ.

I asked him to elaborate on the productivity benefits of Ada. The first benefit he mentioned was that it's a language that inherently leads one to develop high quality software. This is no accident, of course. The language was designed for this very purpose, and thus explains why it has been successfully used for a vast amount of mission-critical software. The manager said that some developers initially found it too restrictive, but soon enough discovered that by following its best practices, they'd produce software with fewer bugs.

The manager went on to discuss how by using Ada and peer-review, they were able to eliminate a great many bugs before their software was deployed. As anyone who has deployed large-scale applications knows, the earlier a bug is found, the better. But the manager also pointed out that by writing less-buggy software in the first place, his developers ended up spending less time investigating and fixing their mistakes, and instead were able to produce more software to help meet the company's business needs.

Many developers have reported similar benefits from programming languages like Eiffel, Haskell and Standard ML. Strong, static typing and other features like design by contract are known to help lead to reliable software. And so I asked the manager if they were considering using such languages. He replied that they had actually considered using Haskell for some smaller projects, and one of their developers was in the process of familiarizing herself with the language. He promised to keep me up to date with their developments, of which I am eager to hear about.

So far, this has been one of the most interesting clients I have worked with in the past while. After working with numerous Java, C#, VB.NET and Perl development teams over the last few years, it's refreshing to see a team that adopts an alternative technology like Ada, and manages to boost their productivity to a level that is rarely achieved. Maybe it's time for more developers to consider the use of Ada, even those who are working on fairly typical business applications.

KDE 4.0 was released several days back, and thanks to the KDE Four Live CD, I was able to give it a try with very little effort. Having used it for about a day and a half now, I'd like to share some of my impressions of this new release of KDE. Specifically, I will be focusing on the Konqueror 4.0 Web browser. But please keep in mind that I have not performed any formal studies or benchmarking, and what follows is merely my opinion.

Qt 4.3 is phenomenal. The KDE 4.0 applications in general, including Konqueror 4.0, feel far more responsive than in the past. Menus open without any noticeable delay. The scrolling of Web pages has a beautiful fluidity. The major effort that Trolltech has put into Qt over the past few years has surely paid off, and the results are immediately visible.

One other major benefit of Konqueror 4.0 is that it still feels very much like Konqueror 3.x, in terms of its appearance and layout. Long-time Konqueror users won't have to adjust to a new menu layout, or anything of the sort. In many ways, this just further indicates the maturity of Konqueror. It has had a very clean organization and interface going back several years now, and the Konqueror developers apparently knew not to change what was already working so well.

One thing that has changed is the Konqueror configuration dialog. It has been reorganized, and I think for the better. The general layout of the configuration options is similar to that of Konqueror 3.x, but it should now be easier for users to find the settings they wish to change. Nevertheless, the default settings are quite sensible, and should work fine for most users.

The JavaScript implementation, KJS, has undergone some significant optimization. Various JavaScript-intensive Web sites, such as Digg, that used to run slowly under certain versions of Konqueror 3.x now work perfectly fine with Konqueror 4.0. I think it would be interesting to see some benchmarks comparing the performance of the new version of KJS with that of other JavaScript or ECMAScript implementations, including Mozilla's SpiderMonkey, Mozilla and Adobe's Tamarin, Opera's linear_b and Opera's futhark.

One feature I particularly like is that the 'Go' menu now sports a 'Closed Tabs' submenu, which lists browser tabs that have recently been closed. This is of course a major benefit for when a tab or tabs are accidentally closed. By using that menu, it is possible to return to those pages quite quickly, and with little effort. The 'Undo' menu item of the 'Edit' menu now also allows for the restoration of a tab that was just closed.

We have to keep in mind that Konqueror 4.0, and KDE 4.0 for that matter, are still quite young. This is a fact that the KDE developers themselves freely admit. Nevertheless, KDE 4.0 proves to be a very suitable platform upon which the KDE developers can continue to build and optimize. It gives me a good feeling to see this high level of quality so early on in KDE 4's lifetime. I have no doubt that it will get even better as time goes on. And to all of the contributors who have put in countless hours working on KDE 4 and Konqueror 4, thank you for your effort!