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!
6 comments:
You have really great taste on catch article titles, even when you are not interested in this topic you push to read it
While i agree that object oriented programming can do more evil then good to code. It has its merits. After all it allows to encapsulate data und function into a single entity.
Functional- and structural programming both have problems with becoming large. Modularisation and Generalisation help, and oop, for me, is just a way of doing that.
A prime example for oop are guis, and languages like qml are in essence just a human-readable format of object trees.
While I agree that grouping data together with functions working on that data can be a good design approach in many cases, I'm still not convinced that this requires syntactic support from a programming language. I must admit though that my experience with OOP languages is mostly limited to C++, which is known not to the best example of the specimen :-) (And even for C++ my knowledge is mostly theoretical...) So my dislike against such language features is not really set in stone.
As for GUI programming, it is true that the UI elements naturally form a hierarchical data structure of elements with attached behaviour -- but does it follow that interaction with the elements should be done with object-oriented method invocations? The great thing about approaches like Edje or QML is that most UI interactions are specified directly in the definition of the UI elements themselfs, considerably reducing the need for doing much external invocations at all!
The internal behaviour can mostly be specified in a simple declarative fashion in these frameworks. More complex behaviours are expressed using imperative code snippets; and in the case of Edje, interaction with other UI elements happens with an event-based approach. (Don't remember how QML handles this... Might be using method invocations instead.) My intuition is that further advantages could by gained by specifying the more complex interactions in a declarative fashion too, using a functional-reactive approach -- though I must admit that my ideas regarding this are rather vague at this point...
Great blog! Is your theme custom made or did you download it from somewhere?
A design like yours with a few simple adjustements
would really make my blog jump out. Please let
me know where you got your design. Many thanks
My web page ... dog undercoat
When someone writes an post he/she maintains the thought of a user in his/her
mind that how a user can understand it. Thus that's why this article is great. Thanks!
Here is my site - new balance life trnr
Thanks for your marvelous posting! I actually enjoyed reading it,
you might be a great author. I will make certain to bookmark your blog and may come back
down the road. I want to encourage you continue your great work, have a nice
evening!
my weblog pole pruner saw
Post a Comment