[linux-l] eine wunderbare scriptsprache: groovy

[Volker Grabsch]

On Tue, Oct 11, 2005 at 02:46:18PM +0200, Ivan Villanueva wrote:
> On Mon, Oct 10, 2005 at 03:42:57PM +0200, Volker Grabsch wrote:
> > Es gibt auch Jython, das wie Python arbeitet, nur eben auf die Java-API
> > zugreifen kann. Jython vs. Groovy vermag ich aber nicht zu beurteilen.
> 
> Mein Hauptgrund, mich für Groovy entscheiden zu haben, ist, dass ich viel Zeit
> spare, weil ich keine andere neue Sprache (und API) lernen muß.

Genau das macht Groovy für mich ATM uninteressant. :-)

Die Java-API kenn ich schon, und das Programmierkonzept auch. Wenn ich
ein Python für Java brauche, werde ich mal Jython und Groovy nebeneinander
halten.

> > Jedoch seit "subprocess" hat Python was Ordentliches, und die API
> > ist dennoch schön einfach:
> > 
> > 	http://python.org/doc/2.4.2/lib/node235.html
> 
> Das erinnere mich an eine andere Kritik von mir zu Python:
> die Doku ist sehr verwirren. Oft weiß man nicht, was für ein Objekt eine
> Funktion zurückgibt.
>
> Am Anfang eine Erklärung, was diese Klasse sein soll und wie man sie benutzen
> kann, und dann alles andere sehr genau beschrieben. Und wenn ich nicht weiß was
> etwas ist, klicke ich einfach drauf, oder besser drucke ich Enter, da ich w3m
> als Browser für Dokus benutze.

All das gibt es in Python theoretisch auch ... theoretisch ... :-(

> > Was ich z.B. an der Java-API kontra-intuitiv finde: Wenn p dein Prozess-
> > Objekt ist, und du willst dessen Standard-Ausgabe anzapfen, dann hast
> > du "p.getInputStream()" ... in Python heißt das einfach "p.stdout".
> 
> Geschmackssache. getInputStream sagt mir, dass ich ein Stream bekomme, von dem
> ich lesen kann.

Ja, eben. Und genau das interessiert mich eigentlich gar nicht.
Jedenfalls nicht so sehr, dass ich es in meinem Programmcode wieder und
wieder wiederholen möchte. Ich finde es viel wichtiger (und deshalb auch
einprägsamer), dass der Methodenname bzw. der Attributsname angibt, was
dieses Objekt *inhaltlich* bedeutet (nämlich die Standardausgabe des
Sub-Prozesses), und nicht den *formalen Typ* (also ein InputStream).
Gerade in Java, wo das doch eh feststeht, halte ich das für besonders
sinnlos. In der Java-Doku steht dann, dass "getInputStream()" einen
InputStream zurückliefert. Diese Aussage transportiert keinen Sinn.

Würde dort hingegen stehen, dass die Methode "getStdOut()" einen
InputStream zurückliefert, wäre das schon viel besser und
selbsterklärender.

Ich denke, genau dieser Typus von Schwächen in der Java-API macht es
einem unnötig schwer, die Sachen einfach mal im Kopf zu behalten und
intuitiv anzuwenden. Man könnte fast meinen, die Java-Docs sind ein
Workaround für unnötige Verkomplizierungen und schlechte Wahl von
Methodennamen.

Pythons Doku-Schwäche ist natürlich schlimmer, weil sie zwar einfacher
und selbsterklärender ist, aber durch viele sinnlose Füllwörter aufgebläht
wurde. Dass hinter der Python-Doku extra bezahlte Leute stehen, macht
die Sache nur noch peinlicher ... man könnte fast den Eindruck bekommen,
diese Leute werden nach Wortanzahl bezahlt. Davon aber abgesehen ist
Python immer noch eines der am besten dokumentierten OS-Projekte. Und
die APIs sind meist so einfach, dass man sich bloß die Beispiele ansehen
braucht, um das zu verstehen und sofort loszulegen. IMHO sollte in
Python viel mehr Arbeit in bessere Beispiele und Tutorials gesteckt
werden, dann könnte es seine Stärken gegenüber Java viel besser
entfalten.

Mir persönlich ist eine etwas schlechtere Doku, die man kaum benötigt,
sehr viel angenehmer als eine exzellente Doku, an die man ständig
gefesselt wird. Aber wie immer: YMMV

> > javax.swing.* ist dermaßen nervig.
> 
> Ich kenne mich mit anderen GUI nicht aus. Aber ich habe gelesen, andere sind
> noch schlimmer. Vielleicht
> http://en.wikipedia.org/wiki/Swt
> ist besser.

Swt kam erst nach meinem Projekt auf. Sicher gibt es dort zahlreiche
Verbesserungen. Insgesamt jedoch ergab ein Überfliegen, dass es meinem
Projekt genauso wenig geholfen hätte.

Davon abgesehen: Selbst wenn ich nochmal in Java programmieren würde,
würde ich nur den GNU-Classpath benutzen, und kaffee-kompatibel bleiben.
Schon allein wegen der Geschwindigkeit und weil ich dann wieder freie
Software einsetzen kann, von der ich *weiß*, wo sie unterstützt wird.
Da man GTK auch in Java verwenden kann, wäre dies dann wohl die GUI
meiner Wahl.

Gibt's eigentlich auch wxWindows für Java?

> > Nicht nur bei größeren Programmen, sondern vorallem bei kleinen Scripten
> > finde ich die Java-API alles andere als empfehlenswert. Weder für den
> > Programmierer, noch für den, der das später nochmal lesen soll.
> 
> Wie gesagt, wenn man Java kennt, weiß man sehr schnell, wo alles ist: java.net,
> java.io, java.util.Math, etc.

Ja, 

> Und die Art wie die Java Doku geschrieben ist,
> finde ich wunderbar. Jede Parameter ist ein Link zu seiner Doku.

Ja, das gibt's für Python theoretisch auch - PyDoc - ziemlich gutes
Werkzeug. Viele Pakete nutzen das. Subprocess ist zwar ein hervorragendes
Beispiel, wo das nicht soo viel Sinn machen würde, aber ein Großteil der
Standard-Lib sollte davon erzeugt werden. Wird er aber nicht wirklich. :-(


Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR