Abstraction stacks and multi-paradigm software design

Originally published in Abstraction stacks and multi-paradigm software design, 19 Feb 2004 7:57 PM.

 

Why is important to learn Microsoft Common Intermediate Language (CIL)?

In your role of software technology end-consumer, there is very little, almost non-existent need to.

In your role of software technology producer, a software designer most likely, then the answer is the same as answering: Why is important to a Daytona race pilot to know his engine?

The answer has a relationship with the eagerness of the pilot or the software designer to win!

When my CIL knowledge would be necessary?

From the very first design decision to the last pulse of the crafted bits. That is, if the software artifact is intended to last then it must be designed with that goal in mind.

It seems that most commercial software is designed with other priorities in mind, but not to last. Perhaps, that is a factor behind the reason why, sometimes, end consumers don’t buy more technology.

What is an abstraction stack?

The basic client-server model where a piece of software (the client) asks for something to another software artifact (the server) without caring what the server has to do in order to fulfill the request. This involves the server taking the client role to ask for help to another server, which in turn takes the role of client and…, you got the point.

If you think a little bit about it, an abstraction stack is endless in both directions, server and client, at least philosophically.

The microprocessor (or the running engine like CLR) can be seen as a pragmatic end of current computational abstraction stacks.

Is not the purpose of an abstraction stack supposed to isolate me from knowing all this low-level stuff?

The main purpose of an abstraction stack is to isolate software artifacts, packaging them in layers, subsystems or components of functionality in order to tackle complexity and convey design decisions at higher levels of abstraction.

It is good and desirable for a software artifact to not know the details of its server.

For a software designer, it is neither good nor desirable to not know the details of every layer, subsystem or component in a target abstraction stack.

So, at your next design decision, take in account that you do not have the luxury to not know the details of how your requests are fulfilled. Options are, either the knowledge of the details is in your head or in the head of somebody else in your very same design and programming team.

What is multi-paradigm software design?

Modern software design encompasses a broad set of techniques coming to us from several schools of thought and paradigms. Design skill comes from understanding, articulating, practicing and feed-backing concepts, methods and techniques from all those paradigms.

Multi-paradigm software design is the practice of growing the best possible software in a given context.

“Multi-paradigm design is a domain analysis technique that features concurrent analyses of the application and solution domain. The goal is to find solution domain constructs that most naturally express the structure of the application domain.” As stated by James O. Coplien in “Multi-paradigm design for C++”

If you know CIL, or the details of what ever layer of your abstraction stack, you are at a better position to take proper design decisions.

CIL is another programming language where you have more design options than popular programming languages C# and VB .NET

How this can possibly be related to my current and future job?

Software design is a very singular endeavor at its current state, a combination of art, science, craft and engineering; proper design allows maximum correctness, robustness, modularity and flexibility. Poor design guided by bogus assumptions leads to misery and despair within development teams.

Or in the words of Bertrand Meyer: "The in-the-large aspects of programming rely on the lower-level parts, and you can't get them right unless you get the small things right too"