[Python-de] "Funktionalitaet" von Python

[Dinu Gherman]

Thilo Ernst <Thilo.Ernst at dlr.de>:

> In meinen Augen ist der eigentliche Hintergrund der, daß Python mehr 
> und mehr Terrain auf Gebieten gewinnt, in denen traditionell den "ech-
> ten" funktionalen Sprachen wie Lisp und Scheme die Alleinherrschaft 
> zukam - und zwar häufig nicht, weil sie funktional sind, sondern weil 
> sie bis vor einigen Jahren die einzigen leistungsfähigen dynamischen
> Sprachen waren. 

Das ist ein Punkt, den man zurecht hervorheben sollte!

> Auf einmal gibt es nun Sprachen wie Python, die mit den etablierten 
> funktionalen Sprachen sehr viele Vorteile teilen (schneller Entwick-
> lungszyklus, Introspektion, vergleichbar hohes Abstraktionsniveau, 
> usw.) ohne deren Nachteile (eher kryptische Syntax, höherer Ressour-
> cenbedarf im Gehirn, akademisch-praxisferne Reputation) mitzubringen. 

Funktionale Sprachen sind halt Ausdruck von Mathematikern, die ihre Pro-
pleme moeglichst mathematisch zu formulieren versuchen, was voellig 
opportun ist - nur: bekanntlich ist nicht jedes Problem in einer ge-
schlossenen mathematischen Formel darstellbar oder auch nur entscheid-
bar!

> In bezug auf praktische Aspekte wie Verfügbarkeit leistungsfähiger 
> Bibliotheken, Standardisierung  und Portabilität hat Python Sprachen 
> wie Lisp und Scheme inzwischen  weit hinter sich gelassen und ist 
> dabei, das zu schaffen, was Lisp in vierzig Jahren nicht geschafft 
> hat - zu einer "Mainstream"-Sprache zu werden.

Dein Wort in Gottes Ohr (und in das der Buch-Verleger und -Kaeufer)!
Lisp waere heute auch wesentlich verbreiteter, wenn sich die Community 
nicht so frueh gespaltet haette! Richard P. Gabriels lesenswertes Buch 
"Patterns of Software" gibt darueber sehr schoenen (und traurigen) Auf-
schluss... Aehnliches mag man evtl. von Smalltalk behaupten.

> Und das ist natürlich nicht so erfreulich für die "funktionale Gemein-
> de", die folglich versucht zu zeigen, daß Python (und im übrigen alle 
> modernen Sprachen) erstens fast alle interessanteren Features von Lisp 
> abgeschaut hat, zweitens aber erhebliche Mängel besitzt, die dazu 
> führen dass es ihren bevorzugten Sprachen weit unterlegen bleiben muss 
> - es ist ja nicht "wirklich funktional". In der Tat muß man als Python-
> 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, 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.

> 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!? 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()

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.

Dinu