[Python-de] "Funktionalitaet" von Python

Thilo Ernst Thilo.Ernst at dlr.de
Fri Aug 30 14:38:46 EDT 2002


Dinu Gherman schrieb:

>
> > Nutzer wohl dauerhaft auf echte Closures und "hygienische" Makros ver-
> > zichten. Wie schwer dieser Verzicht allerdings wiegt, muß jeder Nutzer
> > für sich (oder per Projekt) entscheiden.
>
> Zu den "wirklichen" Vorteilen funktionaler Sprachen zaehle ich weniger
> solche Features,

Naja, dass sich echte Closures, persistent speicherbar wie alle anderen Objekte,
gerade im Kontext von Webapplikationen _sehr_ gut machen, glaube ich Paul G.
unbesehen (The Other Road Ahead).  Das muss '97 echt ein unfairer Wettbewerbs-
vorteil  für seine Firma gewesen sein :-)

> als zwei unmittelbare Konsequenzen des Fehlens von Sei-
> teneffekten: 1. eine viel einfachere Modularisierbarkeit und 2. eine
> viel einfachere parallele Ausfuehrung. Beides bekommt man offenbar ge-
> schenkt, wenn man den Gurus glauben darf auch mit schnellen Compilern.

Bezüglich feingranularer Parallelität hat  zwar das funktionale Dogma wohl den
genannten Vorteil, aber a) wer braucht die wirklich und b) wer mag dafür schon
immer 100% seiteneffektfrei programmieren (müssen)?

Das Modularisierbarkeitsargument kaufe ich nicht. Jede lumpige imperative
Hochsprache bietet volle Kontrolle darüber, was über Modulgrenzen
hinweg passiert, ohne dass Compiler/Interpreter damit ein Riesenproblem
hätten. (OK, fast jede.)


>
> > Die Artikel von Paul Graham (www.paulgraham.com) belegen recht anschau-
> > lich diese durch den Siegeszug der imperativen dynamischen Sprachen aus-
> > gelöste Sinnkrise in der Lisp-Community. Lisp wird dort z.B durch folgen-
> > de Argumentation "gerettet": Höheres Abstraktionsniveau erlaubt kompak-
> > teren Code (maximalen semantischen Gehalt pro Codezeile), und Code-Kom-
> > paktheit muss immer das übergeordnete Optimierungsziel sein. Man darf
> > folglich in einer modernen Sprache auf kein einziges leistungsfähiges
> > Abstraktionsmittel (wir z.B. Lisp-Makros) verzichten. (Probleme wie die
> > Lesbarkeit und Wartbarkeit solcher "maximal-kompakten" Programme werden
> > allerdings nicht näher betrachtet :-)
>
> Nix gegen kompakten Code, gell!?

Kommt drauf an. Der ausgiebige Gebrauch eines so mächtigen Mechanismus wie
es Lisp-Makros sind kann m.E. durchaus 'obfuscated code' bewirken. Man braucht
so etwas wie ein (halbwegs statisches!) mentales Grundgerüst eines Programms,
wenn man daran produktiv arbeiten will. Wenn aber die Hälfte davon bei jedem
Lauf erst einmal dynamisch generiert wird, und das jedesmal anders...

> Der Unterschied ist, ob ich dabei ma-
> thematische Konzepte "maximal-komprimiere" oder anwendungsbezogene (die
> vermutlich seltener rein mathematischer Natur sind). Fuer mich ist fol-
> gendes auch ultrakompakt und dennoch sehr lesbar und leistungsfaehig
> (wenn auch leider noch nicht ausfuehrbar)! ;-)
>
>   from robots import *
>   from flat import *
>
>   class Hoover(CleaningRobot):
>     def clean(self, room):
>       try:
>         assert self.isCharged()
>       except AssertionError:
>         self.gotoRechargingStation()
>       self.goto(room)
>       self.clean()
>       self.gotoRechargingStation()
>

Täusch Dich nicht, solche Dinger gibt es schon; sowohl Staubsauger als auch Rasenmäher.
Nur  noch etwas "expensiv". (Was insbesondere insofern eine Schweinerei darstellt,
dass man annehmen muss, dass sie nicht-rekursiv arbeiten . Andererseits werkeln sie
wohl auch nicht immer nur in demselben Raum.)

>
> Um die oben genannten zwei Punkte (triviale Modularisierung und Paral-
> lelisierung) irgendwie durch die funktionale Hintertuer zu erreichen,
> muesste Guido nochmal auf die Welt kommen. Stackless versucht zumin-
> dest letzteres ohne diesen "workaround"! ;-)
>
> Mehr und mehr "funktionale Schmankerl" einzubauen, comprehensions,
> closures und ich weiss nicht was, bringt Python letztlich nicht sehr
> viel, ausser, dass man Idiome zur Reduktion von 2-3 Zeilen auf eine
> bekommt... soooo viel ist das eigentlich nicht.

Tja wie gesagt, closures finde ich so übel nicht. (Auch list comprehensions
haben für mich ihre Reize. Und so findet sich halt immer irgend jemand.)

"Idiome zur Reduktion"... ah, für Dich ist Kompaktheit also auch nicht alles :-)

>
>
> Dinu

Gruß, TE





More information about the Python-de mailing list