Pinderkent

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.

Today I perused an article suggesting that Microsoft is a "dying giant". While that article is correct to point out that we are seeing things change for Microsoft, I don't think the article's interpretation was correct. They're adapting to changing circumstances, and are doing a better job than many of their competitors.

Yes, they have or will be making some significant layoffs. That's often necessary during a time of change. Efficiency and productivity has become a necessity, and those who don't offer one or both must go.

But unlike many of their competitors, especially Sun, Microsoft has potential. They're going in the right direction where it matters. One such example is F#. With virtually every PC sold these days having CPUs with two or more cores, software will need to start making better use of such resources. One of the most effective ways of doing this is through the techniques of functional programming. With the release of Visual Studio 2010, which will include support for F#, Microsoft will bring functional programming to the masses.

Sun has failed miserably in this respect. Considering the hardware they offer, they should have been at the forefront of delivering what it takes to write effective software that runs on systems with 32 or more processing units. After all, that is what we'll see in typical desktops in a few years, if not sooner.

Java has stagnated, and in many ways is becoming irrelevant in the coming software development world. While Java did help bring multithreaded programming to a wider audience, its techniques are no longer suitable. We, as developers, need functional programming. So Sun should probably have put much more emphasis on programming languages that target the JVM like Scala and Clojure, rather than Java. They do offer the functional programming capabilities that we're really beginning to need these days, and that we'll find crucial in the very near future.

Although I have used Sun's hardware and software for years, and have very much enjoyed using them, I see Microsoft as bringing more innovation and practicality to developers than Sun is these days. So although Microsoft is falling on some troubling times these days, as most companies and individuals are, they have a better future ahead of them. They're adapting during these crucial times, and will be much better prepared to face the computers we will be using shortly.

I just finished reading this account of a developer who spent over an hour trying to track down an unexpected application crash that was eventually determined to be due to a tuple being passed to a function that was expecting a list. This incident happened while using Erlang. For certain types of systems, Erlang is a fantastic language and platform to use. In the coming years, it is likely that its model for handling concurrency will become familiar to most developers. Unfortunately, for all of its benefits, Erlang does have some drawbacks. One of the most significant is that it is a dynamically typed language.

The main problem with dynamic typing is that it allows incidents like the one described by Travis. A simple typo, in his case involving only two characters, can quickly become an hour or more of wasted time. Were static typing, such as that offered by OCaml or Haskell, being used, the problem would have been detected immediately.

Using OCaml (via its interpreter) as an example, we'll define a function that takes a list of strings, and prints each one to stdout:
    $ ocaml
        Objective Caml version 3.11.0

    # let f = List.iter (Printf.printf "%s\n");;
    val f : string list -> unit = <fun>


Next, let's see what happens when we accidentally call it with a tuple of strings:
    # f ("test", "test", "test");;
    Error: This expression has type string * string * string
        but is here used with type string list


It clearly has detected the mistake, and lets us know right away that there's a problem. Better yet, it tells us exactly what the problem is: it expects the argument to that function to be a list of strings, rather than the tuple of three strings that we passed it. Now that we have so quickly identified our mistake, we can go ahead and fix it. Passing in a list of strings has the expected result:
    # f ["test"; "test"; "test"];;
    test
    test
    test
    - : unit = ()
    #


We would have gotten similar results were we using the OCaml compiler rather than the interpreter.

Using a language that offers static typing is clearly the better route to take when we care about saving developer time, writing quality software, and detecting potential bugs and problems as soon as possible. It's unfortunate that Erlang is a dynamically typed language, as static typing would help increase the quality of code written using it even further. And it would've caught a minor mistake that has caught at least one developer over an hour of time.

Today I read yet another criticism of the GTK+ file selector dialog. And I must say, the criticism is completely valid, but nothing new. The GTK+ file dialog has always been one of the shames of the open source world.

Anyone reading this who doesn't agree and hasn't yet looked at the screenshot included in the article linked to above, please go check it out. There is no way that the appearance and layout of that dialog can be justified. It goes beyond a minor bug or annoyance, to the point of the dialog being unusable.

The poor state of the GTK+ file chooser dialog has been noted by a number of other people in the past. This artice, from 2007, goes step-by-step through the pains one must endure to just save a file using the GTK+ file selector dialog. There is an Ubuntu Brainstorm idea from 2008 that is calling for improvements to the GTK+ file dialog. There is a forum post from early 2005 pointing out the various UI design flaws of the GTK+ file selector dialog, plus a screenshot comparison to the much better KDE file dialog. Even regular GNOME users feel it is confusing and needs improvements, and it is also inefficient to use.

In fact, we can go all the way back to this archived screenshot from the GTK+ Web site, apparently taken before the end of January 1999. As we can see, there has been little real improvement over the past decade. While the file selector dialogs of other UI toolkits and environments have evolved and improved over time, the GTK+ file dialog started out lousy, and has remained that way for years. And I don't think it can be salvaged. What's there now needs to be trashed, and re-implemented properly, drawing from the more usable file selector dialogs of Qt, FOX Toolkit, and even Microsoft Windows.

A public beta of Windows 7 was made recently, and one area that has seen some change is the Taskbar. Not everybody is happy with these changes, either. One article that I read focused on how it's difficult to tell which applications are running, and which are not. I have to agree with the points that were made there. It really isn't immediately obvious which items on the Taskbar represent executing programs, and which are just icons to start the applications.

One of the commenters to that article, going by the name technology, suggested at 3:04 PM that it doesn't matter if one can tell whether or not a given application is running: In the majority of use cases, what does it matter if a program is running or not? If I want to browse the internet I click on the Firefox icon. If I want to check my mail I click on the Outlook icon.

I have to disagree very much with this stance. Not everyone starts an application, uses it, and then closes it once done for the time being. Myself, and many others, start an application, use it, let it continue to run while we move on to some other task, come back to the application sometime later, use it some more, move on to another task, and so forth.

I may have several different instances of PowerShell or cmd.exe open at one time. Depending on the task, they might have been changed to different working directories. Some may have also had certain environment variables set. What I don't want to be doing is starting up a new instance of say cmd.exe, when an existing instance has already been adjusted to allow me to perform a certain task.

I would like to see Microsoft make some changes here. It needs to be clear to users which icons represent applications that are currently executing, and which are icons that can be used to start a new process for a given application. Starting new processes and managing existing ones is a core aspect of using a desktop environment. Mistakes here can have significant productivity impacts for the desktop environment's users.