Was solls

Sodalla,

Blog numero zwei. Wieso denn bloß? Ganz einfach. Ich schreib nicht erst seit gestern, sondern schon seit ner relativ langen Zeit. Und die Bemerkungen, die ich früher so von mit gegeben habe, sollen diesen Blog hier füllen.
 Er bildet sozusagen den logischen Vorläufer zu meinem aktuellen Blog laJo's Gedanken. An dieser Stelle werde ich nicht weiter posten, sondern verweise hiermit dorthin. Für jeden, den meine früheren Gedanken interessieren, der kann ja hier ein bisschen schmökern ;-)

Should I?

This is the first posting after a long time. Unexpectedly some people noticed that I haven't written much (meaning: nothing) over the last year. So, I think it's a good idea to sumarize my activities and also to discuss some of my approach.

So first: what was it that I did last year. From my point of view (and with the little spare time that is left for me) I have done a lot of things. Almost the whole time through I read  books - though one of them was lightweight entertainment literature all the others were very comprehensive textbooks, all of them dealing with the area of software engineering.

First I finished reading "Generative Programming". I was blown away. The vast collection of sophisticated development technologies and techniques was very mind opening. Following That I took a look at "Software Factories". The downside of this book is that it is a bit Microsoft-specific. The upside are the chapters about formal languages which provide a very good insight in the theory of formal languages. Suddenly I understood what tools like GME, EMF and the like really do. To deepen the knowledge about model driven software development I chose the german book "Modellgetriebene Softwareentwicklung" (there's also an englisch Version of it, but the authors are germans). After that I skimed some chapters of "Code Complete 2" and "Refactoring". The latter of these two books was a bit disappointing because it is just about mechanics of moving and reorganizing code. There is no sense of semantic. This is stuff that can also be learned during "doing". Finally I returned to some more elaborate literature in the form of "Domain Driven Design" which is what I am currently reading. This book provides a comprehensive methodology and a set of very useful patterns for modeling the domain logic of an application. The good thing about it is, that the scope the modelling techniques can be applied to is steadily becoming bigger - from the smallest entities to large scale software development. Very enlightening.

With this mind bending amount of theory I thought I could also do something useful. This is why I started to re-implement an old tool that I developed at the university. It's called the LC2 which means roughly "Learning Computer 2". The purpose of the tool is to teach the  concepts of a von-Neumann-Architecture. The interesting thing is, that students can implement tiny assembler programs (in the assembler language for the LC2) whose execution is then shown visually. The concept of this application can be compared with the MIXX computer that is know from the "The Art of Computer Programming" books by Donald E. Knuth.

Now what is the fascinating thing about "re-coding" an old application? That answer is easy to  be seen: The application contains a lot of interesting areas like building a parser for the assembler language. It deals with concepts of simulation and animation to visualize the flow of program execution. Also, my decision to choose a 3-dimensional visualization scheme fosters the familarity with concepts from that domain. Finally making the LC2 a valuable tool (for instance for using it in environments like a computer cabinet) promotes the usage of concepts from the domain of distributed applications. So, here we have an all-in-one package and implementing all of them using modern technologies and approaches - this is fascinating.

For instance implementing a parser with a tool other than lex and yacc forces to learn tools like boost::spirit and boost::lambda. boost::spirit allows to implement a parser entirely in a syntax that is very similar to an EBNF (A DSL for describing the grammer of a certain class of languages) directly in C++ (so this is a DSEL). Boost::lambda enables the programmer to implement the semantic actions (though this can also be done using phoenix, which is a part of spirit). Thereby lambda expressions let the programmer aggressively avoid using identifiers which is very suitable to this kind of task. This way values can be extracted from recognized patterns in the input text (in my case the LC2 program) and written into internal data storage facilities. It was plain fun to use these two modern techniques but it was only the beginning. Having read "DDD" encouraged me to model the domain logic of the LC2, that is the most imprtant functionality of the LC2 application. This doesn't include visualization, communication, presentation to the user or any other peripheral functionalities. My next goal is to create a running prototype which I can then bed into a whatever kinded application.

Now, the design process of this core functionality has a number of characteristics. First, due to the fact that one of the sources of knowledge is the code of version one its a challenge not to reuse the old design. In parts this is easy because the it "featured"obvious defects like incorrect or non-existing separation of concerns (e.g. simulation and visualization). These are the parts that were easily to be avoided. On the other hand the first design was very dedicated to the usage of design patterns. A developer might reason that this is good because of all the advantages that design patterns do have - understandability, common language, known intention and so on. The problem with this argumentation is that a design pattern is very hard to recognize after its application in a domain specific context. The elements of the pattern will very likely have domain specifiy meanings which cover the roles of these elements in the design pattern. Seen from the other side, if the domain specific meanings were replaced with the roles in the  design pattern then the software will become less understandable. Roles in design patterns are general that no domain knowledge is communicated when the code is read. This is even worse. The core problem here is that there exists only a limited number of design patterns that can be used adequately to transport domain knowledge (This means that their application doesn't obscure the domain model too much). One of the candidates is for instance the Strategy.

So the question is: Should I stick to this aggressive application of design patterns again? And my answer is NO. In parts I have already given the reason. Another important reason is that a developer only thinking in "predefined structures" constrains the solution space too much. Of course it's important to recognize when a pattern should be applied, but this should not be the primary goal. This kind of design process frees the developer from thinking about the real problem.

Having understood the importance of meaning for a sound software design I am glad to be able to attend the OOP conference this year. There I will have the chance to see Mr. Eric Evans speaking about "Strategic design" and to take part in a tutorial covering how DSLs can be created using a tool called GEMS. With these new information I should be able to cultivate my domain modelling skills in the future.

Versus?

It's been this morning in the underground.... I stood there, trying to look "somewhere". In this moment I started thinking about what I would have to do today. And instantly the fact hit my mind that I am currently doing something really nice. I am writing a program in Java. To be more precise: I am writing a set of Eclipse plug-ins. And while thinking about it another thought came to my mind: Only some weeks ago I was dealing exclusively with C++.

While reflecting about this shift I asked myself why so many people try to let one of these fantastic technologies appear better than the other. I think that it's the best choice to use only one - Java or C++ - if the use case demands it. In a lot of other cases I firmly believe that the combination of these two languages can yield very good results. That's why I decided to write a text which emphasizes some really interesting properties of both of them.

Why do I say this? It's because of the properties of these two languages and their environment. There are characteristics that are unique to either of them. And these characteristics make them the tools they are. On the following lines I want to point out some of them. When talking about Java I will narrow my considerations even more - to the Eclipse RCP platform. The properties I am going to talk about are on the C++ side templates and memory management and on the Java (RCP) side reflection and extension points.

Why these properties? It's important to me to point out that polymorphism is not only exhibited in the form of class hierarchies or interfaces. This is so-called bounded  dynamic polimorphism. It says that entities need to expose one certain interface. Which kind of concrete type is responsible for implementing this interface is not important and hidden to the user. The other form - parametric polymorphism - is exposed using C++ templates. There it's not the interface that is written down, but it's done the other way round: The usage of a type is specified. This reveals (in the end) the same effect, but there is need for a base type any longer, which would limit the applicability of the abstraction that uses other abstractions this way. This is feature which is - even with generics - is not offered by the Java platform.

The reason for memory management is clear: This is one of those features of C++ which lets the programmer very strongly influence the performance of a C++ program (namely by correctly deciding when  to allocate memory dynamically and - even more important - when not to do so). The possibility of the programmer to decide which memory is allocated by the runtime (and thus also released by the runtime) and which is not provides maximum control. In this context I would like to point out the importance of automatic variables. The hardcore Java-Coder could say that the GC of the Java runtime is much better because the programmer doesn't have to deal with this kind of low level stuff. In fact there are projects in the Java world going on which move quite into the other direction by also giving the Java programmer control over memory allocation and deallocation. This is because using the GC a great deal of predictability is disappearing. Nevertheless, the fine grained control over memory is a feature that is not matched by the Java platform and thus it complements it very nicely when both, C++ and Java are used together.

The choice of features on the Java side is a bit "belly-driven" because there I don't have too much of experience. Reflection is one of the magic things that let the Java platform expose information about itself. Even better: The Reflection API lets the programmer write code which accesses the program itself, queries information, loads components that are still not known and so on. This extremely dynamic type system even provides a way to cast objects of one type to another one (by using the Class.cast() method). One of the great advantages of this approach is that this runtime type information can be serialized and transfered anywhere. Thus reflection is a very important prerequisite for elegant independency of location.

Finally let me talk about the extension point mechanism (and the plug-in concept) provided by Eclipse RCP. These two concepts solve a big problem in software engineering, especially in the context of CBD (component based design). I am talking about a mechanism which allows a compoent to specify which parameters it takes and what the requirements on these parameters are. All this happens in a declarative way - namely by providing an XML descriptor (the file plugin.xml) - that contains all these information. It's interesting that a framework (one could also say a library) provides this kind of mechanism. In the C++ world I would consider it impossible that this approach would work. There mechanism like this would always be expected to be part of the language. (I think such thoughts are also the reason that there hasn't been made a big progress in the solution of this problem yet.) The extension point mechanism together and the plug-in concept on the other hand appear a good solution. On reason might be that they're very well integrated into the development environment (which actually is based on them). They become ubiquitous. Another very important point is that Eclipse plug-ins can specify which packages they export to other plug-ins. This has two advantages: The first is the very fine grained control over what is accessible and what is not and the second is that - even on binary level - a structure is preserved in the exported abstractions. This is not the case in a C++ environment where a "package  structure" exists - in the best case - in the form of a directory structure on the disk during development time. During runtime no such structure exists anymore.

So, to draw a conclusion, I want to say that currently there isn't any language/platform which provides all of these features. And as long as this is not the case arguments which have the goal to invalidate either of these technologies should be considered erroneous. Finally, let me state that there are of course a lot of other properties of these two languages which are worth pointing out. In fact RCP and Eclipse are not even a part of the language, but they complement it in a very useful way.

Further down the road...

In one of my last news positings the question arose for me what is the "big thing" after C++. Actually the question was wrong, or at least I asked it in a too little scope. The better question is "Object orientation and then?"

Giving an answer to this kind of question is nothing more than guesswork and I am surely not able to give a satisfying answer. Since object orientation is _the_ paradigm used in programming presently it's hard to imagine what's coming next. One way to find an answer is to ask what could be wrong with OO? I don't want to summarize what a number of people have already said. The interested person can have a look at books like "Generative Programming" or "Software Factories".

What's on the mind of people like Charles Simonyi, Andy Evans or Sergey Dmitriev - just to name a few - seems to be a thing called language oriented programming. Others might call it MDSD or Generative Programming. But the names don't matter. The central concepts that people talk about are always comparable.

The consensus is that developers won't be creating _programs_ for the rest of the time. Instead poeple - like those that have been mentioned - envision a paradigm where will create _languages_. These languages will be tailored to very specific application domains. Thus the term domain specific language - or DSL. Using DSLs "users" (stakeholders of the domains) will then be enabled to create there own applications. The advantage of this approach is that the abstraction level of the DSLs is much closer to the one in which the users think - which makes it much easier to create programs.

Now you might ask: Is language creation not a task for real hardcore guru developers? And the answer is: It depends ;-) First and for most it depends of course on the complexity of the domain that is to be covered. Secondly it depends on the ability of the developer to understand the needs of the customer and on his ability to adopt the customers vocabulary. The technical side - and this is what I am sure about - is not so important, because other people - for instance the persons mentioned above - have already thought about the tools.

Honestly - which developer can resist the temptation to package functionality, he or she is writing for one app, into a "framework", hmm? This happens every day and often in cases where not even a little bit of information about requirements for the single app is known. But the will of the developer to create a framework is there. At last a framework is also a kind of a domain specific language because the components are the terminals and non-terminals and the intended usage provides the production rules of the syntax of this language. So, to answer the question which developer creates a language: Every one will try to.

Object Mutation

Despite the fact that I don't have much time. I managed to get my project going a step further.

And indeed I think it's a big step. Firstly it has an official name now - the Mutable Object Framework. Official because the project is now opensource and it's published under the GPL. The official link is here. So far for the formal things.

The second really cool thing is that it works with the CL compiler under Windows and with GCC under Cygwin.

The third - and for now coolest - thing is that the integration of the new object mutation code, which is a generalization of my former object expansion code, now integrates nicely with the object template in AGE. This means that I have reached a state now where the old object expansion code can be removed from AGE and replaced by the new code. This is great.

The next big step is to provide support from the memory allocation side.