So I should be pretty happy right? Well in the general sense actually I am, but as a developer, I have the feeling that I am operating on the wrong level of abstraction. A lot of the time I am working directly on the code level. Writing getters, setters, exception handling, logging. There are some areas, where the abstraction level moved considerable upwards in the last years. Persistence comes to the mind. Hibernate is pretty reasonable, although it has it’s problems, and it’s enemies. Another one might be rules engines, I haven’t tried those. But other then that …? Of course there has been progress. A lot of progress. We have hundreds of languages, many with very interesting features. We have a large choice of databases with innovative concepts to choose from, and of course a pletorea of java libraries for almost every purpose. We have IDEs so smart, I sometimes wonder if they are really just another piece of code. So what am I complaining about?

I think it is about time for the next paradigm shift. Why are we still coding objects? An example: I want to build the ubiquitous shopping system. I take a jar I found somewhere on the web to get started. Of course I have my own little idea, about how this thing should work, so I want to tweak the shopping cart a little. So what do I do?

public class MyCart extends somebody.elses.Cart {
    public void setRealyCoolFeature() { ...

But most of the time, this doesn’t work. Because the new attribute doesn’t get saved in the database. Or maybe it does, but the repository returns only Cart’s and not MyCart’s. The gui doesn’t show the new attribute, actually the gui of the component is for swing, but I want a web gui. No problem I can write that, but now I have tons of fireProperty noise in the code, that really nobody cares about. Of course it’s better than the other way round, because it is extremely tricky get fireProperty calls into a class without changing the source files.

Hold on a second I know what you are thinking: You fix that with a little AOP here, and this won’t be a problem if the component was cleanly designed in the first place. Agreed. But my point is: I want to use the concept of a shopping system. I don’t want to deal with technical detail like AOP, IoC and similar. Or from the perspective of the component provider: I want to code the concept of a shopping system, and I do not care, how the users want to store it, how they want to show it, and how they want to extend it. That is what I’d call a new paradigm.

Of course I am not the first calling for the next paradigm since OOP. Actually there are many alternatives out there on various levels: AOP, Functional Programming, Meta Programming on the very technical side. Business Process Modeling, Rule Engine, and Components pretend to operate on a higher level, but sometimes I get the feeling they’re just a glorified version of Basic. None of those come even close, to what I imagine. And I don’t even use drugs to get there. Still there might be a solution in sight. Imagine something along these lines:

If you write a component, you use a language that is much more expressive than java, possibly like groovy but two steps further and with a strong type checking (I’m a fan of strong type checking). In this language you specify the structure (the relationships) of you component. Using the equivalent of annotations on stereoids you specify things like transactional behavior, logging behavior, GUI representation, concurrency options, but on a very high abstraction level. For example for concurrency you don’t specify locks, latches and stuff like that, instead you specify data that is related and there for needs protection against concurrent access.

All this is not compiled into a single jar (or whatever we will call it), but actually ends up in separate ajars (Aspect Jars). So as a user, I can take the differnt pieces, and create a extension, specifying the various aspects in the same way, thereby extending all the aspects I need to extend. This is possible, since the aspects are still separated, and not compiled in one big blob. And the original developer separated those, because it was the easiest thing to do.

The guy actually using the component, somebody else created, and extended be  me, uses the components in a high level DSL, that allows him to glue pieces together. For example he could specify which kind of order and invoice component should get created from the cart component. And although the three components come frome completely distinct developers, they would be joined automatically using domain information from the semantic internet. This joining would of course need some tweaking but it should give you a head start. I think this sounds extremely nice, doesn’t it?

Will it happen? Most certainly not. The description is to specific to fit whatever comes, yet way to vague for anybody to actually implement it. BUT I am pretty optimistic something along these lines will actually happen in the next 10 years. DSLs and AOP and new languages that allow Aspects to be written as easily as a for loop will be key players at it.

So if you are a genius with lots of time and a strong developer team at hand, get into contact with me to exchange ideas. If you just a stupid enterprise application developer as I am that needs a job for the next 30-40 years to come, get used to AOP, watch the new languages and don’t worry to much about concurrency.

Ich denke im ersten Schritt wird das, was schon seit jeher zu den Best Practices gehört wichtiger: Lang laufende Aktionen werden in ihren eigenen Thread ausgelagert, damit der Benutzer nicht auf die Abarbeitung warten muss. Aber dies lastet die Prozessoren noch nicht besser aus, denn die lang laufenden Aktionen laufen lange, weil auf Ressourcen gewartet wird: Die Antwort vom Web Service, von der Datenbank oder vom Filesystem. Das ganze wird nur fixer, weil man auf drei Dinge gleichzeitig warten kann. Aber warten kann schon eine CPU mit einem Kern ziemlich gut auf ziemlich viele Dinge.Die eigentliche Frage: Was tun mit den andere Prozessoren / Kernen bleibt also. Ich sehe zur Zeit zwei Alternativen:

•  Wir finden keine gute Antwort auf die Frage. Dies wäre in der Tat fatal, denn das Moorsche Gesetz treibt die gesamte IT Industrie! Warum soll ich mir einen neuen Rechner kaufen, wenn die Software so schnell läuft wie auf dem alten? Warum soll ich mir neue Software kaufen, wenn die auch nicht mehr kann als die alte, da sie die gleichen Ressourcen zur Verfügung hat wie die alte? Ich halte diese Bedrohung für durchaus ernst und wundere mich, dass ich diesen Gedanken noch nirgends so gelesen habe.
• Wir tun komplexere Dinge. Der größte Teil der der Anwendungen, die wir schreiben ist doch erschreckend banal: Benutzer gibt Daten ein, wir schubsen die Daten von hier nach da, drehen sie auf links und schreiben sie schließlich in eine Datenbank. Wirklich komplexe Aufgaben wie Optimierungsprobleme oder Simulationen, anspruchsvolle 3D-Visualisierungen von Daten, stehen bei den meisten Entwicklern nur sehr selten im Pflichtenheft. Das hat zweierlei Gründe. Einerseits sind nur wenige Entwickler von ‘Enterprise Applications’ in der Lage solche Probleme zu lösen, andererseits ist die Hardware schon mit den einfachen Dingen komplett ausgelastet. Aber letzteres wird sich ändern. Auf einem normalen PC werden wir schon bald ein Dutzend Prozessorkerne haben, die nicht richtig ausgelastet sind. Wenn wir dem Kunden neue Versionen unserer Software verkaufen wollen, müssen wir ihm zeigen, dass wir mit dieser Rechenleistung etwas anfangen können. Berechnungen und Optimierungen, die wir bisher als nicht handhabbar abgetan haben, und dem Benutzer überlassen haben, müssen wir uns krallen, in parallel verarbeitbare Algorithmen gießen, nett visualisieren und in die Anwendung integrieren.

Daher meine apokalyptische Prophezeiung: Wer als Software Entwickler in 10 Jahren noch einen Job haben will, sollte hoffen dass Java sich zum nächsten Cobol entwickelt, und für Leute mit veraltetem Wissen viel Geld bezahlt wird, oder sie sollte sich schon mal an nicht triviale Algorithmen herantasten.