[Grails eXchange] Panel Discussion (Grame Rocher, Guillaume Laforge, Dierk König, Scott Davis)

Das sollte jetzt mal eine interaktive Session werden - und hochkarätig, haben sich doch da vorne große Namen niedergelassen: Graeme Rocher, Project Lead des Grails-Projektes; Guillaume Laforge, Project Lead des Groovy-Projektes; Dierk König, Groovy- und Grails-Comitter und Autor von GinA; Scott Davis, Entwickler von aboutgroovy.org.

Inwiefern sei Grails mehr als ein Webframework? Graeme hatte soetwas bei der gestrigen Keynote gesagt. Graeme erklärt, dass Grails viele Dinge beinhaltet, die man auch außerhalb von Grails sehr gut einsetzen kann, beispielsweise GORM oder SpringBuilder.

Wie bringt man Javaentwickler das Arbeiten mit Groovy bei? Einerseits kann man (fast) jedes Javaprogramm auch in Groovy ausführen und dann Stück für Stück groovyfizieren. Die Lernkurve ist zudem sehr günstig. In Grails läßt sich viel arbeiten, ohne allzu tief in Groovy einzutauchen. Man muß nicht alles wissen, was hinter den Kulissen passiert, z.B. bei den Buildern. Groovy ist zudem Java und hat daher auch den gleichen Mindshare. DSLs sind ein weiteres Mittel, um die Benutzbarkeit von Grails einfach zu halten. Dierk weißt darauf hin, dass Javaentwickler meist Probleme mit der Magic haben. Dem kann ich zustimmen.

Noch zu den DSLs: Graeme ist stolz drauf, dass bislang Grails' DSLs immer noch ohne Annotations auskommen :-)

Reloading von Grails wird angesprochen und gelobt. Graeme meint, dass war eines der hartesten Implementierungen innerhalb von Grails, weil es extrem schwierig sei. Eine JVM lädt normalerweise eine Klasse - und gibt sie nicht mehr frei. Das im Hinterkopf habend erklärt, warum Reloading innerhalb eines Webcontainers nicht so einfach ist, was aber nichts desto trotz gemanaged wurde von Grails.

Warum sollte man Groovy nehmen, wenn man auch Javascript hätte nehmen können? Kurz: Weil Groovy die bessere Syntax hat, demnach ausdrucksfähiger ist. Als Beispiel werden Closures ausgeführt, die bei Javascript viel umfangreicher ausgedrückt werden müssen als in Groovy. Allerdings wird auch darauf hingewiesen, dass immer auch der Kontext der Anwendung und der Entwickler in Betracht gezogen werden muss. Grame meint, dass Javascript ganz nett sei, jedoch nicht so mit Liebe auf den ersten Blick bei den Entwicklern daherkomt. Es sei etwas, an das man sich langsam gewöhnt und zu schätzen lernt. Dierk wirft ein, dass man aus Sicherheitsgründen doch eher eine Sandbox haben möchte - die Javascript so nicht bieten kann. Scott spricht sich gegen Javascript aus, weil es außer den ersten vier Buchstaben nicht viel gemein hat mit Java.


G2One ist gegründet worden. Inwiefern wird das die Groov-&-Grails-Welt beeinflussen? Die Community wird davon profitieren, sei es im besseren Marketing, in der besseren Dokumentation, der beschleunigten Entwicklung. Es werden vergleiche angestellt zwischen G2One und Interface12 (Spring) oder RedHat, Suse, Novell (Linux). G2One wird weiterhin die Community brauchen und wird diese auf keinen Fall ersetzen.

Die Rolle von Sun bei Groovy wird besprochen. Nichts Neues: Einerseits ist Sun interessiert in Groovy (wie in dynamische Sprachen generell), andererseits investiert Sun auch viel Ruby. Es scheint weiterhin ein spannendes Thema zu sein.

Und natürlich viel Kleinkram, den ich nicht mitschreibe(n möchte).

Nett, nichts dolles.