Homo Sapiens Abstractus

[or: Abstractions are not born abstractly]

Being in the software research and business for about ten years now, and while trying to invent and build flexible software architectures, one (meta-) idea is always recurring in my mind: That you need to have enough concrete input in order to produce an abstract output.I am, of course, referring to the development of software engineering abstractions.

While looking at the history of maven earlier this morning, I was delighted to come across to this saying, attributed to Ralph Johnson and Don Roberts:

People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a reusable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be.

How well put, really! You cannot just develop abstractions directly, unless you talk directly to God, if you allow me to exaggerate a little.

It is generally accepted that abstractions are used to reduce software complexity. In my opinion that is only one part of the truth or, to be more precise, it does not reveal the essence. I believe that the real essence of abstractions is that they allow you to view the structure (or “meaning”, if you prefer a rather philosophical tone) of things in a clearer and deeper way. And this is what leads us to first understand and then deal with complexity.

And since I am in the consulting business, I cannot but comment on the fact that some people find it very hard to grasp the whole process of constructing abstractions and/or the domain a particular set of abstractions can be applied in. I wouldnot want to elaborate on this, at least not for now, but I have the feeling that they just do not get it. In my opinion, they are either under-experienced or under-educated. I would definitely recommend a little science history reading

While trying to write the “About Me” comment you can see in the sidebar, I remembered that a while ago (~2K?) I had proposed to my MSc advisor a research approach to flexible and more “open-minded” software.

The idea is that after you come up with a basic understanding of your problem area and pin down some basic requirements, you start building a kernel or a microkernel supporting the desired features. Everything else should come on top of that in the form of layers. Of course, operating systems work that way, and this is what gave me the idea.

In a previous paper of mine “Digital Typography in the New Millenium: Flexible Documents by a Flexible Engine“, I had proposed such an approach for an extensible next-generation typesetting engine (… those were the years I played around with LaTeX…). Unfortunately, due to lack of resources, these ideas have never transformed into coding, apart from some very early, unpublished attempts.

I have followed the same path in the paper “Non-stop Provision of Internet Services via a Reflectively Load-Sharing Architecture“, where the foundation of a meta-shell approach to programming with DSLs was publicly laid down. This time, my initial prototype in Python was almost feature-complete and the ideas in the paper were all implemented and tested. In the line of this proposal, I am continuing the project in Java. This time, I WILL make the source code publicly accessible and - of course - with an Open Source license. For now, I am preparing the supporting libraries under the ckkl-core project.

“Unfortunately” :-), the more I think about it, the more I become more and more certain that I basically follow this idea of (micro)kernel-based approach to building middleware (and software in general) in the whole line of my research and professional activities. My intention was to lay down the idea in this post, not to enumerate my countfull (cf. with the perfectly legal English word countless) papers. Probably I will speak more of them later on….