New Ways in Programming
New Ways in Programming
Join the DZone community and get the full member experience.Join For Free
Atomist automates your software deliver experience. It's how modern teams deliver modern software.
Are grammars actually a good basis for programming languages? Why do we still have to work with files? The object-relational gap? Why is upgrading an application always such a hassle? And do our current tools really support us in an optimal way?
Why are we telling everybody to use MVC, but in the case of programming languages, we still use our "model" (which is plain text) as our view? Shouldn't we instead have a proper model (like an AST)?
Most IDEs already do this in the background, but still they carry the burden of actually editing text files and so text file and model have to be kept in a synchronized state, which is complicated and error-prone. Why are import statements displayed at all? You need them for a well defined compilation, but you do not want to actually see them. You could extend the AST with new Expressions to support DSLs and not have to care about defining a syntax for them that does not interfere with the existing language.
Well, I started thinking about all this sometime back in 2002 and decided to try and find my own solution to these problems. And I called the result SiebenGeisslein.
One main feature is orthogonal persistence, which means that every object is persisted. Every operation is performed within a transaction. In the GUI every event is dispatched in its own transaction, in a Webservice every call would have its own transaction. If the transaction fails, everything is rolled back. So the application always recovers to a consistent state.
But now the next problem is: How to support evolving classes? What happens if you add a new Field, rename a Field, rename the class, change the type of a field? SiebenGeisslein's IDE Feder tracks all changes to classes and automatically creates migration code for these changes. It also allows to specify migration expressions for fields. Later versions will also support creating unit tests to test migration between versions.
There is no file-based source code (otherwise for example distinguishing a "rename field" operation from a remove and following add of a field would be impossible). The editor works directly on the model of the source code. This allows easy integration of queries and supports typesafe lookups of application data as well.
Instead of relying on an RDBMS SiebenGeisslein has its own table structures. These are still very simple, but I believe that it is much easier to solve the object-relational impedance mismatch if you already have persistent objects, since in that case you have only to include those properties of an object in the relational model that you are interested in and simply ignore the properties that do not fit the model.
The result is SiebenGeisslein an open source orthogonally persistent application platform. In SiebenGeisslein you can develop orthogonally persistent, multi-user enabled applications accessible from anywhere in the world using webstart and applications that are hot-deployable (this applies to application clients as well).
SiebenGeisslein is still far from being finished, but I have just released the next alpha version 0.75. Also a 20 minute screencast showing the current state of development is available (make sure to watch the HD version).
What do you think about this? Is this (or something similar) a possible future for application development?
Or will we still use text files in 20 years time?
Opinions expressed by DZone contributors are their own.