[linux-l] eine wunderbare scriptsprache: groovy

Volker Grabsch vog at notjusthosting.com
Mo Okt 10 15:42:57 CEST 2005


On Mon, Oct 10, 2005 at 02:39:17PM +0200, Ivan Villanueva wrote:
> On Sun, Oct 09, 2005 at 11:41:02PM +0200, Oliver Bandel wrote:
> > On Sun, Oct 09, 2005 at 07:40:16PM +0200, Ivan Villanueva wrote:
> > > Ich habe:
> > > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/438119
> > > gefunden. Den Code gefällt mir nicht besonders.
> >
> > Ja, wieso denn?
> > WAS an dem Code gefällt Dir nicht?
> 
> Um nur einen Befehl auszuführen um dessen Ausgabe zu verarbeiten ...
> muss man in Python viel schreiben. Man sieht sofort, Python ist kein
> Ersatz für einen Shell-Script.

... dieses Teil ist IMHO komplett veraltet. Ich versuche mal, Python
in ein etwas realistischeres Bild zu rücken.

> Aber ich glaube mein Ding gefunden zu haben. Da ich schon die Java API gut
> kenne, und die Dokumentation finde ich großartig, warum sollte ich eine andere
> API lernen. Es gibt Groovy ! 
> - Object Orientiert
> - Die gesamte Sprache paßt auf eine A4-Reference-Card (=> in zwei Tage gelernt)
> - Die gesamte JAVA API steht zur Verfügung !
> - Variablen werden bei ausführen überprüft (wie in Python)
> - Benutzt closures.
> - Regular Expressions. z.B.
>     if "abcd" ==~ "b?d" ...

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.

Wenn ich aber typische Shell-Scripte *sauber* implementieren will, würde
ich auf jeden Fall Python bevorzugen, und zwar wegen der API.
Deinen dritten Punkt von Groovy emfinde ich daher nicht gerade als
Vorteil für das gegebene Thema.

> Ein Beispiel, um die Ausgabe von "ls" zu schreiben:
> 
>     #!/usr/local/java/groovy/bin/groovy
> 
>     stream = Runtime.getRuntime().exec("ls").getInputStream()
>     println(stream.getText())

Seit Python-2.4 gibt's das Modul subprocess, welches die schönste
mir bekannte Methode darstellt, auf "shell-script"-like zu arbeiten,
und zwar *sauber*.

Zur Veranschaulichung ein Analogon zu deinem Code:

	#!/usr/bin/python2.4

	from subprocess import *

	stream = Popen("ls", stdout=PIPE).stdout
	print stream.read()

Was wäre Python ohne die sauberen Namespaces? Wenn das Script droht,
anzuwachsen, sollte man deshalb in der 3. Zeile lieber schreiben:

	from subprocess import Popen, PIPE

Das subprocess-Modul ist IMHO sehr gut designt, weil dort alles
Wesentliche ordentlich zusammengefasst ist. Das war in Python nicht
immer so, wie die Relikte "exec", "popen", "popen2", ... zeigen.
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

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".

Okay, das allein ist nicht so gravierend, und wenn ich eh die Java-API
brauche, würde ich mich nicht gegen Groovy wehren. Aber eben diese
Feinheiten häufen sich, und insgesamt machen sie Python-Code sehr viel
übersichtlicher, leichter verständlich, leichter erlernbar und vorallem
leichter "merkbar".
YMMV, aber *ein* größeres Java-Projekt reicht mir voll und ganz. Gerade
javax.swing.* ist dermaßen nervig. Ich habe beim Programmieren letztlich
ständig die Browser nebenbei offen gehabt, um immer wieder irgendwelche
Trivialitäten herauszusuchen. Ich bin froh, dass diese Zeiten vorbei sind.

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.


Viele Grüße,

	Volker

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



Mehr Informationen über die Mailingliste linux-l