[linux-l] Programmieren in Perl 1 (was: python)

[Steffen Dettmer]

* Oliver Bandel wrote on Mon, May 20, 2002 at 19:26 +0200:
> > > Zum Schluss hatte mein Perl-Prog 1100 Zeilen Code und
> > > ich bin nicht mehr durch gestiegen bei den debugging.
> > 
> > Na, für Spaghetti-Code kann ja auch Perl nix.
> 
> das ist richtig.
> Aber wieso glaubst du, ohne den Code gesehen zu haben,
> daß es Spaghetti-Code ist?

Weil Olaf schrieb, daß er da nicht mehr durchsieht. Wenn man bei
eigenen, nagelneuen Programmen nicht mehr durchsieht, macht man
zwangsläufig was falsch. Ich meine, wenn das ein 2 Jahre alter
nebenbei-Hack wäre, wär's ja nicht so schlimm. Aber ein wenige
Wochen altes, kleineres Programm sollte man doch wenigstens noch
selbst verstehen...

> Es gibt zwar viele Leute, die Spaghetti-Code schreiben,
> aber irgendwie kommst Du ganz schön überheblich rüber.

Ja, stimmt, hört sich vielleicht so an. War natürlich nicht so
gemeint. Ich möchte nur darauf hinaus, daß man eben sauber
arbeiten sollte und so. Ich fand es überraschend, daß man in
Mitten eines Projektes mal so eben die Programmiersprache
wechselt, weil man seinen eigenen Code nicht mehr versteht.
Sollte ich das falsch verstanden haben, ist meine Kritik
natürlich auch falsch. Ansonsten aber berechtigt, denke ich.

Programmieren muß man lernen, und wenn man sich das selbst
beibringt, ist das nicht einfach. Oft werden Quellen verwendet,
die kaum erklären, warum man selbst über eine "simple Schleife"
nachdenken sollte; für den Autor des Werkes ist das eben
selbstverständlich, ergibt sich aus der Erfahrung. Aber für den
Lernenden ist das vielleicht noch nicht so klar. Da mag es
helfen, wenn man von außen - also z.B. durch meine Mails - ein
paar Anregungen sammelt. Das finde ich aber überhaupt nicht
schlimm, sondern soll ja nur bißchen helfen. Dafür ist ja so ne
Liste auch irgentwie da. Das man eben Erfahrungen austauscht. 

> > Wenn man schon bei 1100 Zeilen nicht mehr durchsieht, hat man
> > meist wirklich viel falsch gemacht.
> 
> Oh, oh...

Was denn?

> Wenn man mit weniger Zeilen auskommt als mit 1100 und einem
> eine andere Programmiersprache dabei hilft, dann sollte man
> eben jene andere Sprach nehmen.

Wenn man sie beherrscht, ja. Zumindestens zum Anfang. Kommt
natürlich drauf an, wie weit man ist. Wenn das Projekt auf 1500
Zeilen Perl insgesammt kommt, würde ich bei 1100 nicht mehr
wechseln, wenn vermeidbar - vor allem nicht, wenn es an solchen
Gründen liegt (daß man den defined Operator nicht kennt, aber
benötigt, obwohl es meistens schönere Konstruktionen gibt). Das
ist natürlich nicht nur bei Perl so. Perl ist jedoch ziemlich
groß und flexibel. Das macht es zwar schwer erlernbar, aber auch
sehr leistungsfähig. Jedenfalls ist so eine Schleife nun kein
Grund, die Sprache zu wechseln. Aber Perl ist wirklich keine
Einsteigersprache, weil zu umfangreich.

> Perl ist eben nicht immer optimal für eine Problemlösung.

Aber gerade Menüpunkte aus einer Liste zu lesen, kann man damit
prima. Sicherlich ist es oft nicht ideal. Aber meistens braucht
man auch nicht die ideale Sprache, sondern eine geeignete. Ich
würde das vermutlich auch ganz anders anpacken und aus anderen
Gründen systemnah implementieren, aber das ist ein anderes Thema.
Das kann man auch ohne tiefere Einsichten schlecht sagen.

> > > (und ich habe alle Register gezogen: use strict, use
> > > diagnostics...)
> > 
> > Na ja, Qualität kann man schlecht im Nachhinein einbauen. Man
> > sollte sinnvolle Funktionen verwenden, das klar strukturieren
> > etc., dann klappts auch mit dem Nachbarn.
> 
> Warum setzt Du voraus, daß alle außer Dir keinen guten code
> schreiben?

Dsa setze ich nicht vorraus. Es gitb sehr viele, die guten Code
schreiben. Aber use strict und sowas ist für micht nicht "alle
Register ziehen". Ich finde es wichtiger, saubere Funktionen oder
Objekte zu haben, und diese bzw. die Module mit guten
Testtreibern zu testen, damit diese dann stabil sind. In der
Praxis reicht jedoch selbst das kaum aus. Jedenfalls macht es oft
(immer?) mehr Arbeit, eine Funktion zu testen, als sie zu
schreiben. Das ist Anfängern meistens nicht klar. Genau durch
solche Erfahrungen aber kann die Erkenntnis entstehen, in Zukunft
doch eben z.B. Testtreiber zu bauen. Jedenfalls ist es verdammt
schwierig, bestehende Code aufzuräumen. Ich hab bei meiner Arbeit
öfter mal das Problem, daß man schwer verständlichen Code
benutzen "soll". Ich schreib den dann öfter mal komplett neu,
kommt meistens schneller was oder mehr bei raus. Das ist einfach
eine subjektive Erfahrung. Die Aussage, Qualität kann man nicht
nachträglich einbauen, ist jedoch allgemein akzeptiert.

> > Programmieren/Entwickeln fängt eben mit Zettel und Stift an...
> 
> Ja, das ist sehr löblich, dieser Ansatz.

Anders geht es einfach nicht. Viele Probleme sehen erstmal
einfach aus. Aber dann sind sie es oft doch nicht. Stellt man
z.B. fest, daß man ne Statemachine intern braucht, weil vieles
vom Zustand von irgentwas abhängt, kann man nur selten die Logik
"anpassen"; meistens braucht man eine komplett neue. Das
"Umschreiben" sollte also nicht Logiken betreffen, diese sollte
man dann lieber neu machen. Für den Anfänger ist das oft
schwierig, schließlich hat er an der "alten" Logik lange
gearbeitet, und möchte die jetzt nicht "wegschmeißen". Natürlich
ist die "alte" Logik eigentlich nur ein Schritt in Richtung der
Erkenntnis, und deshalb auch nicht umsonst, aber für ein Anfänger
ist jeder Zeile Code, die "irgentwie" funktioniert, "etwas wert",
und möchte erstmal erhalten werden. Na ja, und wenn man mit
Zettel und Stift anfängt, und es nicht zu oberflächlich macht
(ich mache es meistens zu oberflächlich), minimiert man die
Gefahr, daß man Code wirklich wegschmeißen muß. 

> > In Perl nimmt man da foreach:
> [...]
> 
> Ja.
> Das geht damit wunderbar.
> 
> Sowas solltwe aber auch in Python machbar sein.

Sicher; würde mich nicht wundern, wenn es da sogar genauso geht
(von Syntax mal abgesehen). Problematisch wird das in Sprachen,
die keine Listen als Sprachelemente/syntax kennen. Da braucht man
dann sogenannte Iteratoren in irgendeiner Form (C, C++, Java).
Aber die Möglichkeit, sowas ohne Iteratoren zu schreiben, ist ja
gerade eine Stärke von z.B. Perl.

> Letztendlich kann man aber nur über Code urteilen, den man
> schon mal gesehen hat - oder habe ich die 1100 Zeilen der Mail
> mit dem Code übersehen?

Natürlich was das spekulativ. Aber es ging ja mehr um allgemeines
Zeug. Das ist so oder so richtig - nur vielleicht unpassend.
Vielleicht war ihm das alles klar, dann war es Schade um meine
Zeit, aber mehr auch nicht. Man kann ja nur dazulernen :)

Außerdem interessiert der Code erstmal nicht so, wichtiger ist
ja, wie man das Problem anpackt. Wenn z.B. Anfänger sich selbst
event-basiertes Programmieren beibringen, und dazu nebenbei noch
OO lernen, kommt dabei vermutlich erstmal (!) nur wenig
vernüftiges dabei raus. Hier würde ich dann lieber empfehlen,
nicht ereignisorientiert zu entwicklen, auch wenn ich das Problem
ereignisorientiert implementieren würde, weil die Technik eben
nicht so einfach ist.

Aber wenn man seinen eigenen Code nicht mehr versteht, macht man
doch eigentlich immer was falsch. Ich kann mir jedenfalls keinen
wirklichen Grund denken. Natürlich gibt es etliche Fälle, wo das
das kleinere Übel ist, z.B. wenn man ein Einmal-Script schreibt,
was man nicht wieder braucht. Aber bei Anwendungen, die ne Weile
benutzt werden, sollte man sich offen halten, diese anpassen zu
können.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.