Pinderkent

James Hamilton recently wrote about the use of low-cost and low-power servers, with a focus on ARM-based systems running Linux. He points out that the linux-arm.org site itself is running on such a setup. Looking at the specs of their systems reminds me of the servers we used in the mid-to-late 1990s, and even into the 2000s. Having been involved with software development for many years now, with much of my work revolving around networked business applications and server applications, I find this to be an interesting topic.

Clearly, a huge part of the problem today is the software we'd be running on such hardware. With the rise of Java, and especially frameworks like Ruby on Rails, far less of our hardware resources are used for actually performing the work of our software applications, and instead go towards powering the numerous frameworks, virtual machines, and platforms typically underlying our applications. Indeed, it has gotten so bad that some people are surprised when their Ruby on Rails-based Web application can handle "multiple requests per second", on modern hardware, without exhibiting performance problems.

Most recently, I wrote about Stack Overflow's outrageous hardware usage. Give the generally simplistic nature of that site, and the huge amount of processing power offered by today's low-end hardware, it's almost absurd to see how much they're apparently using.

When discussing lightweight servers, we shouldn't forget to consider the use of NetBSD instead of Linux. Aside from it already offering several ports to various ARM-based platforms, NetBSD is among the highest-quality open source software out there. I know of one person who used NetBSD on old PCs to serve images. I've also advocated it as an alternative to lightweight Ubuntu Linux distributions, as well as for use on low-power systems like Intel's classmate PC.

People today seem to forget just how powerful a typical server is today. Even the ARM-based servers that James mentions, or those powering the linux-arm.org Website, sound much more powerful than what we used a decade ago. That's not unexpected, of course. The cost of hardware rapidly drops, while its capabilities rapidly increase. Unfortunately, our software systems seem to eat up those gains rather quickly.

The main barrier to the widespread use of low-power and low-cost servers will likely be our existing software, frameworks, and platforms that use hardware resources very inefficiently. Instead of trying to salvage those, many of which are already a lost cause, perhaps we should be more willing to start from scratch, strip out all of the unnecessary layers of software that have accumulated, and make better use of functional programming languages like Erlang and Haskell. So not only would we get the benefits of using more efficient hardware, but we'd also get a much simpler and efficient software platform upon which to build our applications.

Joe Stump recently wrote about why he switched from PHP to Python. What he says is absolutely true. He nails down many of the problems with PHP, and also lists many of the benefits of Python. In the end, however, I think we can just sum up the comparison between the two languages as being one of comparing Python's professionalism versus PHP's amateurism.

When I describe Python as being professional in nature, I am referring to the emphasis on care, contemplation, quality, and doing-the-right-thing-even-if-it's-difficult we generally see embraced by the Python community. Like Joe mentions in his article, the language itself exhibits a high degree of sensibility, consistency and predictability. It has clearly been carefully evolved and grown, rather than having features and functionality tossed on here and there. It's a language developed by people who know what they're doing, and it's a language used by people who know what they're doing.

On the other hand, we've seen much of the opposite out of the PHP community. The language itself is a good testament to the general preference of that community towards doing things quick-and-dirty, rather than correctly and with care. It's full of quirks, it's inconsistent, and generally a jumble of differing ideas and philosophies. We've seen this happen with its standard library, as well. With the core platform having such poor quality, any software build upon it typically ends up suffering from quality and security problems, too.

It's no wonder that so many developers are moving away from PHP towards better languages and environments like Python and Ruby whenever possible. PHP is deceptively attractive. Sure, it's widely supported, and yes, it's got a large standard library. But it has many hidden and not-so-hidden costs, including horrid maintainability of applications written in it, numerous security flaws within critical code, and numerous hurdles towards developing decent software. Even if the perceived costs seem higher when using a more professional language like Python, in the long run it becomes the only viable choice when the alternative is something as amateurish as PHP.

While some descriptions of pair programming suggest that "all code to be included in a production release" is to be developed jointly by two programmers working in tandem at a single computer, that isn't a steadfast rule.

Teams wishing to employ such a development technique can be flexible about their pair programming arrangements. One team I worked with in the past only chose to use pair programming while developing the most critical parts of their software system. This allowed for the core functionality to be well-understood by all of the developers, but as soon as that work started to stabilize, they each went back to working on code alone. But as soon as core functionality had to change, pair (or even triplet, in some cases) programming was used.

This proved quite effective. Code that the team agreed was trivial could quickly be developed by a lone developer without too much overhead, while more complex or critical changes still had the oversight and involvement of at least several team members. They managed to strike a very good balance, which allowed them to develop their software quickly and efficiently, while also helping to keep the number of bugs to a reasonable level.

Other teams using pair programming shouldn't be afraid to experiment with introducing some flexibility into their process. It is possible to practice pair programming even if it's only done some of the time, or even just when absolutely necessary. Given that each development team's situation and software system is different, some teams may be best of pair programming only 20% of the time, while others are best off pair programming at or near 100% of the time. It should be tailed to each team's specific needs.

I recently saw an article about the accepted Project Coin changes that are planned to be included in JDK 7. This is some good news for the Java community. After a relatively long period of stagnation concerning the evolution of the Java language, and some fierce competition from C#, these are the sort of practical changes we need to see.

Most of these proposed changes aren't exactly revolutionary. Several of them have already been implemented for some time in C# and other .NET-based languages. They've proven to be effective there, and will hopefully bring the same benefits to Java.

The Automatic Resource Management proposal is a good example of a feature that is badly needed in Java. The using statement of C#, and the Using statement of VB.NET, have proven this concept. They make it safe and easy to ensure that certain non-memory resources are disposed of appropriately. This is exactly the sort of practical language-level change that Java needs.

The Strings in Switch proposal is another one that suggests a very useful change. Not being able to use a switch statement to select a case based on a string value has always been an annoyance to me.

The Improved Type Inference for Generic Instance Creation proposal may help making coding quicker, although I'm not convinced it's as beneficial as it sounds. Although it reduces what some may consider to be redundancy in code, most decent Java IDEs offer auto-completion support that helps prevent a programmer from actually typing out the parameterized types. And we do lose some detail within the object instantiation code, which otherwise is self-documenting in some sense. I think the benefits of this change will require some experimentation once an implementation is available.

Some of the other proposed changes, such as the addition of language support for JSR 292 and the collection-related changes don't seem as sensible to me. In the case of adding more support to the JVM and the Java language for supporting dynamically typed languages, I think this is a bad idea. The JVM itself is better suited to statically typed languages, and trying to hack on support for dynamically typed languages may just result in further bloat.

In the case of the collection-related changes, we are getting to the point where a major reworking of the collection classes is in order. We already have older classes like java.util.Hashtable and java.util.Vector, as well as the Java Collections Framework, and then all the changes that were made to both groups during the introduction of generics with Java 5. Trying to further build on the existing mess may just make the situation worse. But a clean up would be massive, and would have many repercussions on existing software. So there may be no easy answer here.

The acceptance of these proposals is a very good sign. They show the sort of activity and change needed to keep the Java programming language and platform relevant in the face of numerous other competing programming languages and platforms. I do hope that we get to see these implemented in JDK 7, as some of them do sound to be practical and badly needed by Java developers.

Guido van Rossum, of Python fame, recently twittered about how using CSS instead of tables for Web page layout just isn't worth it. This was submitted to Reddit, and the discussion it generated there is somewhat predictable. Many of the comments get into the typical arguments surrounding the topics of HTML tables versus CSS for layout, and the necessity of separating content from presentation. But I think most of the comments that are currently there miss some key issues.

First of all, a number of the posters point out that once you learn the many quirks and incompatibilities of the various popular Web browsers, CSS-based layout becomes quite natural. To a great extent, this is true. There are many Web designers out there who can make very good looking sites using CSS. Unfortunately, it takes literally years of effort, learning, experimentation and failure to get to this point. And with browser technology continually evolving, it takes further effort just to keep pace.

Now, some people will argue that any inherently complex task will take much time and effort to master, and they're correct. But in this case, CSS-based layout shouldn't be such a task. Reality, however, shows that it is, mainly due to artificial difficulties created by low-quality, inconsistent and obsolete-yet-widely-used Web browsers.

Another thing to consider is that not everybody wants to make complex Web layouts. Many people who aren't Web designers want to quickly throw together a site that has a relatively simple layout, and looks decent. On one hand, they can battle with the many troubles that CSS brings to inexperienced users. On the other, they can just use HTML tables, which for many simple layout tasks end up being much more practical and efficient to work with.

CSS should be able to cater to people in both camps, namely those professionals who want to develop complex pages with a high degree of control, and those who just want to throw together a page quickly and easily. Unfortunately, it fails both groups of people a lot of the time. The trend seems to be that most professional designers struggle with it until they finally learn how to wrangle it, most of the time. By that point they've invested so much time and effort that the only way they can obtain some degree of payback is to employ their hard-earned "knowledge", which itself is more an understanding of numerous broken and poorly-implemented Web browsers than anything else. And those people who deem their time better spent on other tasks, like Guido, apparently, just resort to HTML tables.

The fact that the CSS versus HTML tables debate has raged for so long should suggest that CSS is a dead end. It doesn't do a sufficient job in fixing the huge variety of problems associated with what should otherwise be a straightforward task. Perhaps Internet Explorer 8's better support for the CSS table model will help improve the situation. Then again, it may just make things worse. Perhaps the only solution is to throw out the sub par technologies that we employ now, and find a better way to solve the problems of Webpage layout.