Pinderkent

Pain and glory from the trenches of the IT world.

XML is not a suitable syntax for programming languages.

Posted on Friday, January 23, 2009 at 1:12 AM.

An XML-like syntax is suitable for marking up other data. XHTML is a good example of an appropriate use of XML. There are numerous data transmission formats that make use of XML rather effectively. Even configuration files, to some extent, can be represented via XML. But one thing that should not be represented via an XML-like syntax is logic of the sort found in programming languages.

X# is a good example of why XML-based programming languages aren't a very good idea. One look at their X# sample programs should make it obvious why this is true. Any of those tasks could have been performed using a language like Perl or Python. But the Perl or Python equivalents would have been shorter, easier to read (and thus easier to maintain), and more portable. Many people often comment that Common LISP and Scheme have an awkward syntax to work with, but XML-based programming languages take that awkwardness to the next level, often without the benefits that LISP and Scheme do offer.

XML is best left as something a machine should process. It's not well-suited for humans to be reading and manipulating more than need be. It's especially not a good syntax to use for a programming language, especially one that offers non-declarative, imperative features. So I hope I never encounter XML-based programming languages like X# in practice.

Permalink: http://pinderkent.phumblog.com/post/2009/01/xml_is_not_a_suitable_syntax_for_programming_languages
Share:

Benchmarking open source software: we can't just focus on the numbers.

Posted on Sunday, January 28, 2007 at 6:24 PM.

My last article was about the performance and memory consumption of the popular open source KDE and GNOME desktops. Well, it seems that that particular article was submitted to Digg. I looked at some of the comments that people posted, and I specifically wanted to address this one comment in particular.

The comment suggested that it is improper to compare desktop environments based on qualitative, rather than quantitative, measures. That attitude is, of course, incorrect. Open source software may not have been adopted as quickly as it could have been because many developers likely do ignore qualitative data, and thus did not get an adequate idea of what the users liked or disliked.

I understand why many developers would feel more comfortable dealing with numerical data. It is, in many cases, a lot easier to work with and analyze than qualitative data. We can easily calculate various statistics and measures from that data. We can plot graphs. But we have to remember that this is of little concern to many computer and software users, especially those who are relatively non-technical.

We can only play the numbers game up to a point. Suppose for a moment that it typically takes a KDE application running on a particular system 0.5 seconds to draw a menu. It takes a GNOME application on the same system 2.0 seconds to perform a similar operation. Windows Vista takes 1.0 seconds. We could go around playing number games all we want, saying things like KDE is four times faster than GNOME when it comes to drawing menus, and GNOME is twice as slow as Windows Vista. We could even say that Windows Vista's menu drawing is twice as slow as KDE's. Regardless, such data and claims are quite meaningless.

What matters is how users find the system to work. And this will likely involve qualitative, rather than quantitative, information. For the aforementioned example, they will say things like "KDE and Windows Vista feel quick", or "GNOME's menu redrawing seems a lot slower than KDE's". Non-technical users, who tend to be the majority of computer users these days, do not sit there with a stopwatch timing how long it takes for a menu to redraw, or for some other action to be performed.

This is something that I think a lot of developers have missed, both those working on open source projects and closed source commercial developments. For the users' experience to be enjoyable, we as developers do need to pay a lot of attention to their qualitative assessments of our software. When they say it feels slow, we damn well better look into what they're talking about, even if our benchmarking data may suggest we're faster than our competitors' systems.

Furthermore, we need to use such data when deciding what to improve. If our menu drawing speed is twice as slow as that of our competitors' systems, but the users in general don't seem to mind, then it's likely not something we should bother improving. There are no doubt other features that we could better put our attention and efforts towards working on.

But I suspect that the person who posted that comment at Digg did not actually read my article, because he or she further requests some "charts and numbers". Anyone who had read my article would have been directed to this page with desktop environment memory usage data. Instead of just providing the numbers, that site also describes the methodology used to obtain such data. So I did provide some numerical data to back up my claims regarding KDE. I invite you to check out that data, and the way it was collected, for yourself. Then you can see how it correlates to my qualitative analysis of the memory usage and responsiveness of GNOME and KDE.

When we as developers are working on software, we need to consider both quantitative benchmark data, and qualitative user analysis. Only when considering both of these data sources can we truly begin to make our applications better, not just in terms of raw performance, but also in terms of satisfying our users.

Permalink: http://pinderkent.phumblog.com/post/2007/01/benchmarking_open_source_software_we_cant_just_focus_on_the_numbers
Share:
Feeds
  • RSS 2.0 Feed
  • Atom 2.0 Feed
Tags
Archives