So, you came here looking for a receipe for achieving world domination? We don't have one! You fell for our PR stunt!
But then, what you will find here is almost as good... ;-)
Let's start at the beginning. I was at LinuxTag 2009. Hurray.
So, what was I doing there? Well, that's rather obvious: meeting nice girls. Why else would anyone go to a major free software event, with 95%-or-so male geek population?... ;-)
Quite surprisingly -- in view of the above numbers -- I still managed to attend a few interesting talks. One of them was the keynote on QML. They did no less than declare a new paradigm: declarative UI programming!
Admittedly, it's not really all that new. In fact, it has been around for a while -- this is essentially what web pages are. The reason people find it easy to get going with HTML is, as everyone knows, the lovely syntax of HTML...
OK, just kidding. The really nice thing about HTML and CSS is that they are declarative. I must admit that I can't quite explain why declarative languages are so intuitive and nice -- but they are. And I'm not just saying that because I'm a raving lunatic either. Promise! ;-)
Indeed people tend to like this declarative stuff a lot. So much in fact that there have been some attempts to bring HTML-based applications to the desktop. (!!!) I'm not kidding now. Maybe you heard about it. I guess some people are just crazy -- and not *all* of them in a positive way ;-)
If declarative UI programming is so attractive, that people are willing to go through this kind of hoops and even put up with Web standards, the logical conclusion must be: to create a proper language for declarative UI design -- but unlike previous attempts, actually designing it to be sane, instead of trying to build something on top of the HTML legacy...
I contemplated something like that for a while, and now the ex-trolls have invented just that: a (hopefully) sane declarative language for creating proper user interfaces.
It's not all bliss, though: while simple interactions can be described in a purely declarative manner using builtin functionality and standard modules, more complex stuff is implemented using JavaScript. Ouch.
Aside from JavaScript specifically being a glorious achievment in backwards evolution -- it almost, though not quite, reaches the standard of sophisticated ugliness set forth by such historic highlights as COBOL or ADA -- I always felt that imperative scripting languages generally do not really fit in with a declarative markup language.
Functional programming much more seems a logical complement to declarative languages. Both describe how the result relates to the input state; without needing to specify in what order individual calculation steps are to be performed. The purely declarative part describes states, while the purely functional part describes relations between states. It seems to me that when a declarative language evolves toward more sophisticated state transformations, the desription of these relations will naturally look more and more like a full-blown functional language.
This paradigm is actually not limited to GUI programming: I have been feeling for a while now, that the reason Hurd translator programming is rather tricky, is related to the imperative languages used: translators tend to describe functional relations between the presented file system, and some underlying state -- I'm pretty sure these could be expressed much more naturally with a declarative/functional approach.
But back to QML and the glorious keynote: at the end, the speaker's great conclusion was that he considers this a paradigm shift, similar to the shift towards object-oriented programming that happened in the past... This conclusion shocked me a bit. Why so negative?!
I never took to this "object-oriented programming" silliness: it always struck me as the kind of questionable abstraction, which manages to do the amazing trick of obscuring the internal workings, and limiting possibilities, without actually hiding any complexity in exchange...
Declarative programming on the other hand -- as I have *discreetly* hinted at during the course of this article ;-) -- is something I actually do consider a great idea.
So indeed, a paradigm shift it is -- but not at all like the one towards OOP!
