Samstag, 11. Februar 2012


Artikel

März 2009 | Artikel

„Nur echte Entwickler, die echten Code schreiben, lösen Probleme“ Fortsetzung, Teil 2

Teil 1   Teil 2   Teil 3   

Eclipse Magazin: Wie schätzt du die heutige Rolle der OMG und ihrer Modeling-Standards ein?

Ed Merks: Ich denke, die OMG muss nach vorne schauen. Die Welt verändert sich schnell. Open Source entwickelt eine große Kraft und die Personen, die Open Source vorantreiben, werden mehr Einfluss haben als erwartet. Referenzimplementierungen sagen mehr als Worte. Sie sind übrigens auch „grüner“, d.h. sie fällen viel weniger Bäume, weil niemand in Versuchung gerät, sie auf Papier zu drucken. Standardisierte Apparate tappen nur allzu leicht in die Falle, sich zu sehr mit politischen Bemühungen von Komitees, die voller Kompromisse sind, auseinanderzusetzen und letztendlich nur Kompromisslösungen zu produzieren. Schlimmstenfalls können Standards zur Waffe gegen Innovationen werden, indem die kleinen, agilen Mitspieler ausgeschlossen werden und Mittelmäßigkeit produziert wird. Standards sollten darauf konzentriert sein, Best Practices festzulegen. Meiner Meinung nach ist Open Source das Werkzeug, innovative Best Practices zu etablieren und die Zuverlässigkeit und Effizienz der entwickelten Standards zu demonstrieren.

Eclipse Magazin: Es scheint, dass Innovation im Modeling-Umfeld nun von Projekten vorangetrieben wird, die echten Code abliefern, so wie z.B. EMF, und nicht von Organisationen, die sich um Standards kümmern. Siehst du eine generelle Verlagerung von Spezifikationen zu Code?

Ed Merks: Ja, das ist genau der Punkt. Genauso wie es das Pferd ist, das den Karren zieht, kommt zuerst die Innovation und dann folgen die Standards. Bei einem Treffen mit Leuten, die daran interessiert waren, eine Industry Vertical Working Group bei Eclipse aufzubauen, schlug ich vor, sich darauf zu konzentrieren, eine lebendige, funktionierende Referenzimplementierung zu bauen, um einen De-facto-Standard zu etablieren. Dafür sollten sie lieber ihre fähigsten Softwareingenieure schicken als ihre besten politischen Ingenieure. Echte Entwickler, die echten Code schreiben, werden sich auf echte Probleme konzentrieren und diese wirklich lösen. Was dringend nötig ist, ist ein Realitäts-Check.

Eclipse Magazin: Kürzlich ist Microsoft der OMG beigetreten. Gleichzeitig investieren die Redmonder in irgendetwas namens "Oslo", das sehr wie die .NET-Version von Eclipse Modeling aussieht. Was hältst du von diesen Initiativen? Wie kann Oslo EMF beeinflussen oder umgekehrt?

Ed Merks: Ich warte immer noch darauf, mit diesen Leuten von Microsoft wie Don Box und Douglas Purdy eine Diskussion zu beginnen. Auf dem Eclipse Summit Europe hatte ich das Glück, Steve Sfartz zu treffen, der mich anschließend beim MD-Day in Paris Jean-Marc Prieur vorstellte. Jean-Marc und ich haben die Gelegenheit genutzt, uns über unser gemeinsames Interesse an Modeling zu unterhalten, und er demonstrierte mir ausführlich Microsofts grafische DSL-Technologie. Die Bemühungen von Microsoft und Eclipse möchte ich wie folgt vergleichen: Microsofts grafische DSL-Technologie ist das Gegenstück von generierten EMF-Modellen, angereichert durch GMF. So wie ich es verstehe, existiert das Microsoft Domain Metamodell nur in Development Time, nicht in Runtime, also gibt es keinen Reflection Support wie bei MOF. Microsofts textuelle DSL-Technologie ist das Gegenstück von Xtext (d.h. MGrammar), Ecore (d.h. MSchema) und EObject (d.h. MGraph). Während wir also bei Eclipse Ecore/EMOF als das allgemeine, standardbasierte Metamodell bieten, um sowohl grafische als auch textuelle DSLs zu unterstützen und deshalb modellbasierte abstrakte Reflection für alle Domainmodelle bereitstellen, gibt es bei Microsoft zwei verschiedene Technologien, um diese beiden eng miteinander verbundenen Aspekte abzudecken. Ich bin davon überzeugt, dass Eclipse so mit einer soliden technischen Grundlage ausgestattet ist, die nur schwer zu schlagen ist.

Letztendlich ist der Erfolg der Modellierung eines meiner persönlichen Ziele, sodass ich sehr glücklich wäre, wenn Microsofts Anstrengungen von Erfolg gekrönt wären. Ich glaube, das würde helfen, die Aufmerksamkeit des amerikanischen Marktes wieder mehr auf das Modeling zu lenken. Jetzt schon stellen Analysten Fragen nach der etablierten Eclipse-Technologie, wenn sie mit Reviews über Microsofts neuste Entwicklungen beginnen. Viele von uns glauben fest daran, dass Modeling eine Schlüsseltechnologie ist, um die Softwareindustrie vorwärts zu bringen. Also sollten diejenigen von uns, die diese Vision teilen, zusammenarbeiten.

Eclipse Magazin: Wenn wir heute über modellgetriebene Softwareentwicklung sprechen, geht es stets vor allem um pragmatische Ansätze. Wie können Leute lernen, wann MDSD Sinn macht und wann nicht?

Ed Merks: Es ist definitiv wie bei dieser alten Weisheit: Man sollte für jede Aufgabe das richtige Werkzeug benutzen! Ich hätte Schwierigkeiten, mir etwas wirklich Wichtiges vorzustellen, bei dem Modeling nicht wenigstens eine kleine Rolle spielen würde. Ich sage das nicht, weil ich ein Fanatiker bin – obwohl einige da wohl nicht zustimmen würden –, sondern weil alle Daten modelliert werden können, ich würde sogar sagen: sollten. Aus der Tatsache, dass die meiste Software es mit Datenmanipulation zu tun hat, folgt, dass Modelle überall eine wichtige Rolle spielen. Wenn Praktiker Erfahrungen durch die ihnen zur Verfügung stehenden Werkzeuge und Technologien sammeln, lernen sie, diese immer effektiver einzusetzen. Es ist besser, etwas zu versuchen und aus den gemachten Fehlern zu lernen, als niemals einen Versuch zu starten. Durch unsere Fehler lernen wir genauso viel wie durch unsere Erfolge.

Eclipse Magazin: Was die Produktivität in der Softwareentwicklung angeht, sehen wir momentan einen großen Trend in Richtung textueller Domain Specific Languages. Wie verhalten sich deiner Meinung nach DSLs und die Welt der Modelle zueinander?

Ed Merks: Ich sehe nur Modelle! Auf dem Eclipse Summit Europe konzentrierte sich Dave Thomas in seiner provokativen Keynote auf viele Dinge, die er als technologische Barrieren ansieht, die unsere Industrie ausbremsen würden. Beispielsweise schimpfte er über die Komplexität des Modeling und die Schrecken des Meta-Meta-Nonsens, und er sprach auch über DSLs als den Schlüsseltechnologien, die uns in eine "Schöne Neue Welt" führen würden. Ich fand das unangebracht, deshalb fragte ich ihn anschließend: "Was ist der Unterschied zwischen einem Modell und einer DSL?" Er antwortete: "Sie sind das Gleiche." Verflixt, ich dachte, ich hätte ihn in die Falle gelockt, aber er ist zu schlau für mich!

Ich erinnere mich, dass mir vor ein paar Jahren jemand bei IBM sagte: "Ecore ist keine Sprache, sondern nur ein Modell." Ich war verblüfft und fragte deshalb: "Warum ist Ecore keine Sprache?" Man sagte mir: "Weil es keine konkrete Syntax hat, und die XML-Serialisierung zählt nicht." Er nahm meine nächste Frage vorweg! Nach dieser Argumentation wäre Ecore also eine Sprache, sobald Chris Daly die Emfatic Syntax für Ecore definieren würde. Das scheint mir ein ziemlich oberflächlicher Standpunkt zu sein.

Auf dem MD-Day gab ich den Kommentar ab, dass XML eine sehr dürftige Entschuldigung für eine menschenlesbare Syntax sei und deshalb nichts tauge. XML sei großartig für den maschinellen Austausch und es sei großartig, dass Entwickler das Schreiben von Lexern und Parsern vermeiden könnten. Aber wir sollten nicht das menschliche Element in all dem vergessen! Die Leute applaudierten, ich bin also offenbar nicht der einzige, der so denkt. Deshalb bin ich so froh, Projekte wie Xtext und Oslos MGrammar auftauchen zu sehen und ich kann nur hoffen, dass wir uns von dem nuklearen XML-Winter entfernen, der diesen Planeten heimgesucht hat. Wir sollten das Ziel verfolgen, Menschen zufriedenzustellen, nicht Maschinen.

Ich liebe Sprachen sehr, das habe ich immer getan. Ich liebe auch XML, aber ich denke, es ist fast zu Tode geliebt worden. Ich bin davon überzeugt, dass Modeling-Technologien wie Xtext uns helfen werden, schnell all die spezialisierten Sprachen zu entwerfen, die wir brauchen.

Teil 1   Teil 2   Teil 3   

Kommentare