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.
Recent Comments