Fwd: Re: [Python-de] Noch eine php-Beobachtung

Diez B. Roggisch deets at web.de
Mit Mai 19 20:22:56 CEST 2004


Hi,

> Das Problem ist das die Ausnahme immer
> nur zur Laufzeit festgestellt werden kann. Wenn das Prog startet
> heist es nicht, das es das tut was ich erwarte. Wenn ich Blöcke

Aeh, seit wann tut den ein compilat aus einer typstrengen sprache das? Der 
nachweis, das etwas durchcompiliert hat ja nur sehr begrenzten Wert - genau 
diese Erkenntnis steckt ja in der test-getriebenen Philosophie die von vielen 
Python-Protagonisten und auch Anderen (Stichwort XP) vertreten wird.

Sich in eine Situation zu manoevrieren, in der man sein Programm vor den Augen 
anderer zum ersten mal aurprobiert ist immer gefaehrlich, unabhaengig von der 
Sprache.

> falsch setze, Klammernvergesse, unbekannte Namensräume benutze,
> bricht der Interpreter sofort ab. Ist ja auch sinnvoll. Niemand
> würde auf die Idee kommen zu sagen "Lass doch den Interpreter weiter
> laufen. Wenn der Programmierer ein Fehler macht, ist das halt sein
> Problem und nicht das von Python." 

Es gibt mit pychecker da ja eine durchaus sinnvolle Moeglichkeit, durch eine 
batchlauf vor Programmstart die groebsten Schnitzer zu vermeiden. Und auch 
dieses Argument hat nix mit python/dynamisch usw. zu tun - schliesslich 
compiliert man seinen code ja auch nicht vor den Augen der interessierten 
Anwesenden, um dann festzustellen das es nich geht.

> Und wozu diese Typenfreiheit? 
> Was ist der Vorteil? Ganz im Gegenteil: der Interpreter könnte ohne
> Typenfreihei sogar noch schneller sein. Der Preis ist (mir) auf die
> Dauer zu Hoch.

Hier hast du aber was massiv missverstanden- python ist alles andere als 
typfrei. Das sind Sprachen wie php und perl. Was du meinst ist 
statisch-dynamische typisierung, und orthogonal dazu starke und schwache 
typisierung.

Statische Typchecks in Sprachen wie java/c# koennen sicher eine Reihe von 
Fehlern aufdecken - aber eben laengst nicht alle, das sieht man schon an der 
riesen Menge Classcast-Exceptions die vorkommen. Und sie fuehren dazu , das 
der Entwickler hohen Aufwand treiben muss, um wiederverwendbares typgenau 
auszufaktorisieren _bevor_ er seine Bibliothek veroeffentlicht - siehe zB die 
Wahnsinns Typhierarchie bei Java im Bereich der IOStreams... Das verlaengert 
allen die Entwicklungszeit, und die ist meistens teuer.

>
> Wenn Sun seine Java-Politik nicht ändert, denke ich das Mono quasi zur
> "Killer-Sprache" wird und das bieten kann, wo von Sun immer erzählt.
> Aber warten wir es ab...

Mono ist keine Sprache, sondern eine Laufzeitumgebung - so wie die JVM, fuer 
die man ja auch andere Sprachen bekommt, uA jython, aber auch andere. 
Irgendwo gabs mal ne Uebersicht.

Unter dem Strich kann ich fuer mich selbst sagen, das ich in python wesentlich 
schneller und flexibler arbeite als mit java, was ich wirklich bis zum 
erbrechen betrieben habe. Und als Konsequnz sehe ich statische Typisierung 
als ein Mittel an, das zur Optimierung wertvolle Beitraege leisten kann und 
somit auch Sinn machen - aber nicht viel mehr. Und wenn man sieht, wie lange 
es gebraucht hat bis java stabile jit compiler bekekommen hat, dann denke ich 
das man python und zB psyco da noch etwas Zeit geben kann. Mal ganz ab davon, 
das performancekritisches 

a) selten genug vorkommt
b) wenn doch, dann halt mit pyrex oder C in eine Extension ausgelagert wird.

MfG Diez