Pinderkent

I read an article today lamenting the lack of good documentation accompanying the recent Ruby 1.9.1 release. While very true, I think it's a result of the general nature of the Ruby community. The general attitude has often been a preference towards the typical "quick and dirty" approach. Performance, maintainability, feature set and documentation have often taken a back seat.

In some cases this is a good attitude to talk. It has made Ruby and Perl useful languages for many system administrators, for instance. They can quickly write one-off scripts with minimal effort. But for software development on a larger scale, those typically aren't good languages to use. There's nothing stopping them from being used, of course. It's just that the end result often isn't of a high quality, and maintainability is often a huge nightmare.

Python is often much better in this regard. The community has generally taken a more careful approach, with greater emphasis on correctness and quality. We see this reflected not only in documentation that actually exists, but documentation that is very informative and clear. So while you many not be able to develop a one-off script as quickly with Python as you could with Ruby or Perl, Python does lend itself towards larger-scale application development.

I have recently worked with several Django-based Web applications, and a number of Ruby on Rails Web apps before that, at one company I'm consulting with. I have to say that the Django Web apps were much cleaner, better documented and had fewer bugs than the Ruby on Rails Web apps. Management always initially liked how quickly the Ruby on Rails development team could get their Web apps up and running in production, but were never pleased with the numerous problems that arose afterwards. Those issues just didn't arise with the users of the Django apps, because the effort was put towards doing it much more correctly the first time, even if it took slightly longer to get the apps into production use.

Unless the general attitude within the Ruby community changes, I think it's unlikely that we will see better documentation. But this will become more of a problem as we have increasingly more Ruby code that needs to be maintained. Good documentation is always essential when performing code maintenance, especially when the underlying programming platform (eg. Ruby) changes so rapidly. So maybe this will help drive demand within the Ruby community for better documentation efforts.

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.

Although it's not a new concept by any means, the use of JavaScript for server-side development has gotten some attention recently. This is unfortunate, as JavaScript is not the sort of technology you want to use when developing the back-end for a Web site.

Even as a client-side language, JavaScript has proven to be of a very questionable quality. I think Jonathan Edwards was correct when he described JavaScript as being "quick" and "dirty", and only just "good enough" for most users. For years now, even the major JavaScript implementations have exhibited horrible performance. Only after 15 years of use are we seeing that start to change, with faster VMs from Adobe, Mozilla and Google. As a language, JavaScript itself does very little to encourage the development of secure, high-quality code.

Server-side development calls for a more rigorous programming language and environment than JavaScript can offer. Considering JavaScript's performance problems on the client-side, it's likely they'd be magnified when it comes to server-side development. And JavaScript really doesn't offer anything beyond more traditional server-side languages like Java, C#, PHP, Perl, Python and Ruby. As is mentioned in the Ajaxian article, there is a huge amount of basic Web back-end infrastructure that will need to be built to make server-side JavaScript even barely comparable to any of the aforementioned programming languages.

What's worse, however, is the general "attitude" associated with JavaScript. It has always been a language that appeals to those who want to get their scripts written quickly, even if the quality is terrible and there are major security flaws. It has often been used by Web designers to quickly add some interactivity to the pages they have designed, without needing an extensive programming background. Indeed, this amateurish attitude becomes very dangerous on the server.

PHP is a good example of such danger. For years many PHP developers generated SQL queries directly using data sent to their script by the user, with little to no filtering. This resulted in SQL injection attacks becoming very common for PHP-based software. We still even see this sort of development happening today, in some very sad cases. Meanwhile, more mature server-side languages and environments like Java and .NET have for years provided support for parameterized SQL queries. But even the most inexperienced of Java and .NET developers know better than to not appropriately filter user input.

While there will of course be some professionals using it, and using it well, I fear that the rise of server-side JavaScript would lead to nothing but problems. Just as the PHP community is starting to get its collective act together, we might see a new generation of inexperienced, amateurish developers start with server-side development using JavaScript.

Then again, maybe that's not a bad thing. It'll guarantee a steady stream of work for those of us who have made a career out of fixing such mistakes. But it is unfortunate that we couldn't stop such problems in the first place, but using better languages for server-side development. With some work, Haskell could become very useful for server-side development where quality is concerned, while Erlang plays its part in reliable and highly-scalable systems. Regardless, the main thing we need to keep in mind is that JavaScript should be avoided for server-side development.

Thanks to this blog post by Peter Harkins, I was alerted to Michael Meeks' analysis of the recent progress of OpenOffice.org. Both articles bring up some interesting points. Meeks provides various measures of activity relating to the development of OpenOffice.org. While software metrics are often suspect, he uses practical measures such the number and affiliation of contributors, lines of committed code, and so forth. His conclusions suggest that OO.o is "stagnating".

Meeks appears to put a lot of blame on the processes the developers must cope with, as well as the involvement of Sun. Harkins further suggests that the nature of the project doesn't itself towards generating an active developer community.

They're both correct. Unlike many other open source projects, OO.o never really felt open to community involvement. It originated as a commercial development, it was open sourced by one of the largest software and hardware providers, and has been developed using resources and people from a variety of companies. It fell onto the open source community, rather than growing forth from it.

OO.o isn't the only such project to have been in this position. The Mozilla project is similar in many respects. Like OO.o, the initial software was a commercially-developed, closed source product that was eventually open sourced. Netscape and AOL were quite involved with its initial development. And for the first five years or so, we saw stagnation. There were usable releases put forth, but they weren't truly innovative or inspiring.

Things started to change once Phoenix, now known as Firefox, was released. We saw innovation. We saw a more useful piece of software emerging. And best of all, it was a community effort. As such, a healthy developer and user community formed. Since then, we have seen it become a very prominent and widely-used Web browser. The original Mozilla Suite has taken a back seat to Firefox and the Thunderbird email client.

Something similar might be what the OO.o community needs. Namely, an effort from the community itself that aims to tackle many of the problems of OO.o. In a sense, it'd be the OO.o community competing with itself. The best parts of OO.o would be used, while the software develops into a product that satisfies the needs of the users better than OO.o currently does. There would be less focus on competing with other commercial office suites, and instead a focus on providing, for instance, a word processor that best meets the needs of its developers and users.

OO.o might also want to take another page from Firefox, and become more of a host for plugins. It provides the basic functionality of a word process or a spreadsheet application, for instance, but it's the plugins that really make it suitable for a given user. So instead of getting an awkward, poor-performing and memory-intensive integrated jumble of functionality, 95% of which is unused by most users, they would instead get a leaner application where they use the vast majority of the functionality it offers, and use a few plugins here and there to really tailor it to their needs.

Are we likely to see this happen? It's somewhat doubtful. I'm not sure if the open source community really needs an office suite as badly as, for example, Firefox was needed. For instance, many developers I know will just use plaintext files, HTML or LaTeX when they need to create a document. But if the OO.o project were to stagnate further, perhaps that would actually help generate the grassroots initiative needed for OO.o to experience its own Firefox-style revitalization.

Although widely used, PHP is known to have many, many problems. Security-related issues have always been problematic for it. Performance is another area where there have been numerous problems. In many cases, its semantics and syntax leave much to be desired. Some people believe that a rewrite of the PHP implementation itself will solve all of the problems associated with PHP. Others lean towards that viewpoint, but suggest that the current PHP developers should not be involved with such a rewrite. Personally, I think PHP as a language is inherently flawed, and any implementation that tries to remain true to the "spirit" of PHP will itself be flawed.

Security, for instance, has always been a problem for PHP. Part of this problem is independent of the implementation. PHP, as a language and platform, has always proved attractive to inexperienced developers. To a large extent, PHP has even been marketed towards amateurs and hobbyists. Such people are not aware of the various SQL-related exploits that are possible, let alone how to prevent them. So when their PHP-based Web sites went public and were subsequently cracked, the PHP developers ended up adding half-brained "solutions" like the notorious magic quotes. So we can see at least two problems here. The first is that PHP is targeted towards and widely used by people who don't understand security. The second problem is that the developers of PHP tried to compensate for this in ways that just caused further problems.

The developers of PHP have made a good decision by opting not to include magic quotes in PHP 6. But there's nothing they can do about their language being widely used by people who probably shouldn't be using it. The insufficient experience and knowledge of its userbase would be a problem for every PHP implementation.

Likewise, performance has always been one of PHP's biggest problems. A variety of approaches have arisen over time to deal with these issues. Caching the compiled PHP code is one of the most frequently-used solutions. Any implementation that wanted to improve on PHP's performance while allowing for source deployments would likely need to incorporate such transparent caching, which in turn may not be flexible enough for many users. Other approaches would include forcing the user to deploy some form of pre-compiled object file, rather than deploying the source code itself. But this is contrary to how PHP has historically approached deployments.

The lack of organization is one problem that the PHP developers have begun to tackle with the introduction of namespaces. But even the selection of a namespace separator has been highly controversial within the PHP community. This incident indicates the struggles and hurdles that any other significant reform efforts would face.

Arguably, the only way to successfully reimplement PHP is to discard the language as it exists now, as well as discard the community that it has now. Discarding the community will be problematic, as it is the armies of inexperienced users who make PHP as popular as it is. Many of the language changes would in turn make the resulting language much unlike PHP, as its users currently know it.