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.
Donnerstag, 15. Februar 2007
Dienstag, 13. Februar 2007
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.
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.
