Anmerkungen:

- Da die Differentiation eine Operation ist, die, bildlich gesprochen, den Funktionsverlauf "aufraut" und auch kleine Unregelmaessigkeiten stark verstaerken kann, ist es meiner Meinung nach eine ziemlich bloede Idee, eine generelle numerische Differentiationsroutine fuer beliebige Funktionen zu schreiben, die keinerlei adaptive Schrittweitensteuerung, am besten mit Fehlerabschaetzung, verwendet, wenn einem die numerische Stabilitaet des Resultates nicht voellig egal ist. Auch wenn man die Steigung am Mittelpunkt eines Intervalles berechnet, wie LanX- es vorschlaegt, ist das noch keine Loesung fuer das Stabilitaetsproblem, auch wenn die Naeherung dadurch in der Tat besser wird. Und das mindeste ist, dass man bei einer numerischen Berechnung die Fehlergrenzen mit zurueckliefert oder bei Ueberschreitung bestimmter Grenzen warnt oder einen Fehler erzeugt.

- Wenn man eine Subroutine schreibt, die eine Codereferenz als Parameter nimmt, ist der Prototyp & oft praktisch und spart Schreibarbeit.

- Currying ist zwar bisweilen eine praktische Sache, ich schrecke aber meist davor zurueck, es gleich in eine Funktion mit einzubauen, weil mir die verlorene Fehlerueberpruefungsmoeglichkeit bei der Parameterueberhabe nicht behagt (Ist es gewolltes Currying, oder hat hier jemand vergessen, einen Parameter zu uebergeben? Sollte die Funktion wirklich komplett evaluiert werden, oder steht da ein Parameter zu viel?). Gerade bei einer schwach typisierten Sprache passt mir das nicht -- aber andererseits hat Perl sowieso keine eingebaute Ueberpruefung der Argumentlistenlaengen, solange man keine Prototypen benutzt ;-)