Appropriate Levels of Abstraction – Follow up

Thank you all for the great comments on the blog entry "Appropriate Levels of Abstraction". We all seem to acknowledge the general solution of
finding the right level of abstraction to express our intention. Still,
we recognize the issues with current coding practices. As Refux
said:

Let’s face it, the code is dumb, there is
no higher level picture.
We need to figure out how to encode real useful and
actionable data so code path decisions can be made at runtime.

This is exactly right – it is only the code in its context, with its generator or
compiler – that gives it meaning during execution. But still, there is a higher
level picture – it is just not recorded. Even for the sort example, the domain description of what the data is likely to be like, could be useful to decide which way to go. And we can go even further – why do we sort? Is it for presentation to the user, is it for merging, is it for searching?

Separating these two issues are
at the core of the solution. By changing what we put into code to be more
intentional information that captures more useful and actionable data (our
intentions), we separate the source code from the execution of it, which is
controlled by the generator or the runtime components. Code therefore needs to
get refactored into one part that is the generator and runtime components, which
obviously can not be as static as they are today. The more intentional
code will then be what these components operate
on.

And as Paddy points
out

Often parts of a
problem could be better solved in a different language, if there were easier
ways to develop in multiple programming languages then savings could be
made.

So true! Our tools and languages are simply not designed to mix very well. Still, it is
getting to be the rule rather than the exception that languages like SQL, HTML
and XML gets embedded into C++, Python or Java, and this is often very clunky with
limited semantic and syntactic support from our tools. Today language design is out of reach
for most programmers (and managers). As Scott points
out:

… we tend to get stuck in the
mind frame of using general-purpose language for domain-specific problems (and
this idea is usually enforced by management).

So how do we
get unstuck from the current use of languages?
Obvioulsy new technology is required.

The software engineering community has aspired to new
more powerful languages for decades, and often very domain specific languages.
Indeed, the first higher level languages – Fortran and Cobol – were designed
with the goal to be used by domain experts directly, mathematicians and business people
respectively. They had many domain specific abstractions in them. As we know, they
were not fully successful in reaching their goal – still professional
programmers were required to use these languages properly. Interestingly, the
first programmer oriented programing language – Algol – actually came AFTER
these first higher level languages. And as we know, essentially all general purpose languages
today, including C, C++, Java, Python, Perl, Ruby and C#, are all direct or indirect descendants from Algol.

So not only do we need to revisit new language designs, but also the dominant paradigm of how languages are used and what they represent. Wes gives us a good example:

In my
experience, systems that work to permit one to move between abstraction layers
seamlessly have also made it extremely difficult to make unanticipated changes.
Conversely, source code is easy to understand and edit, and as a form it has
flourished in the face of many efforts to replace it, notwithstanding the lack
of seamless abstraction layers. I’m hoping that Intentional Software can make a
form that accomodates the evolution of software and lowers the cost of making
unanticipated changes.

First thanks
for your support, Wes! We certainly recognize that moving between abstractrion levels
to make unanticipated changes is troublesome although sometimes required. Many current DSL, model
driven and even aspect oriented tools simply work best when you stay at only one level of abstraction. And of course
this vastly limits the value of these type of approaches. Intentional Software
has a unique approach to resolve this that centers around unlimited
parameterization and unlimited projection. We will discuss more about this in a future
post.