Ein paar Anmerkungen zum Artikel von Christian Neumann:
Neue Programmiersprachen zu lernen um den Horizont zu erweitern, wie im letzten Kapitel empfohlen, ist sicher eine gute Idee.
In Frage zu stellen ist aber, ob die Umsetzung in einer Programmiersprache wie Java, die dieses Paradigma nicht unterstützt, unbedingt eine gute Idee ist.
Den im Abstract genannten Vorteil funktionaler Programmiersprachen, kürzer zu sein, ist fast immer auch durch andere Typsysteme verursacht. Wenn diese nicht sowieso dynamisch getypt sind, so ermöglicht es Typinferenz doch mit weniger Deklarationen bei gleicher Typsicherheit auszkommen. Dies hat aber auch Einschränkungen: Scala zum Beispiel kennt keine Interfaces.
Weitere Vorteile funktionaler Programmiersprachen, etwa die implizite Parallelisierbarkeit durch die Freiheit von Seiteneffekten hat man so in Java nicht.
Die Verwendung des fremden Programmierparadigmas bringt jedoch auch Nachteil mit sich, auf die der Autor nicht eingeht:
1) Die vermeintliche Eleganz erkauft sich der Programmierer mit jeder Menge Objektinstanziierungen. Für Applet-Programmierer kann sogar die Vielzahl zu ladender Klassen problematisch sein.
2) Der Code ist für einen neuen Programmierer, der die Zusatzklassen nicht kennt, schwerer und nicht etwa leichter zu verstehen.
3) Auch das Debugging dieser Konstrukte ist kein Vergnügen.
4) Die unkritische Übernahme der funktionalen Terminologie kann für Verwirrung sorgen: Was macht eigentlich reduce? Die Begründung für die Namenswahl sind technische Details, nicht das, was man aus Fachsicht hier machen will.
5) Auch some und every sind nicht sofort verständlich. Hier läßt sich evtl noch etwas durch eine Umbenennung verbessern.
6) Dem Problem der Exception-Behandlung stellt sich die vorgestellte Lösung aber sowas von überhaupt nicht. Wer die vorgestellten Klassen benutzen will, muß die Exceptions lokal behandeln und u.U. in unchecked Exceptions verpacken.
Da schmeckt es schon nach arg unangebrachtem Eigenlob wenn von "fehlerfreiem" "qualitativ hochwertigem Programmcode" die Rede ist. Die Beispielimplementierungen lösen nur die allereinfachsten Probleme und sind so nicht alltagstauglich.
Trotz allem, es kann durchaus Sinn machen. Wer sich durch JDBC-Code bewegt, dem wird häufig schon die Abfolge "Query ausführen", "Abklappern des ResultSet" und häufig fehlerhafte Ausnahmebehandlung aufgefallen sein. Dies schreit nach Abstraktion und man wundert sich, warum entsprechendes nicht von Anfang an in JDBC enthalten ist. Auch hier setzt Java mit dem Problem der Exception-Behandlung allerdings Grenzen.
Eines noch: Die Verwendung von varargs um einen(!) Parameter optional zu machen und falsche Verwendung erst zur Laufzeit als per RuntimeException zu melden, verdient eigentlich die Erwähnung auf www.thedailywtf.com.
Summa summarum: Wer funktional programmieren will, sollte eine funktionale Programmiersprache verwenden.
Neue Programmiersprachen zu lernen um den Horizont zu erweitern, wie im letzten Kapitel empfohlen, ist sicher eine gute Idee.
In Frage zu stellen ist aber, ob die Umsetzung in einer Programmiersprache wie Java, die dieses Paradigma nicht unterstützt, unbedingt eine gute Idee ist.
Den im Abstract genannten Vorteil funktionaler Programmiersprachen, kürzer zu sein, ist fast immer auch durch andere Typsysteme verursacht. Wenn diese nicht sowieso dynamisch getypt sind, so ermöglicht es Typinferenz doch mit weniger Deklarationen bei gleicher Typsicherheit auszkommen. Dies hat aber auch Einschränkungen: Scala zum Beispiel kennt keine Interfaces.
Weitere Vorteile funktionaler Programmiersprachen, etwa die implizite Parallelisierbarkeit durch die Freiheit von Seiteneffekten hat man so in Java nicht.
Die Verwendung des fremden Programmierparadigmas bringt jedoch auch Nachteil mit sich, auf die der Autor nicht eingeht:
1) Die vermeintliche Eleganz erkauft sich der Programmierer mit jeder Menge Objektinstanziierungen. Für Applet-Programmierer kann sogar die Vielzahl zu ladender Klassen problematisch sein.
2) Der Code ist für einen neuen Programmierer, der die Zusatzklassen nicht kennt, schwerer und nicht etwa leichter zu verstehen.
3) Auch das Debugging dieser Konstrukte ist kein Vergnügen.
4) Die unkritische Übernahme der funktionalen Terminologie kann für Verwirrung sorgen: Was macht eigentlich reduce? Die Begründung für die Namenswahl sind technische Details, nicht das, was man aus Fachsicht hier machen will.
5) Auch some und every sind nicht sofort verständlich. Hier läßt sich evtl noch etwas durch eine Umbenennung verbessern.
6) Dem Problem der Exception-Behandlung stellt sich die vorgestellte Lösung aber sowas von überhaupt nicht. Wer die vorgestellten Klassen benutzen will, muß die Exceptions lokal behandeln und u.U. in unchecked Exceptions verpacken.
Da schmeckt es schon nach arg unangebrachtem Eigenlob wenn von "fehlerfreiem" "qualitativ hochwertigem Programmcode" die Rede ist. Die Beispielimplementierungen lösen nur die allereinfachsten Probleme und sind so nicht alltagstauglich.
Trotz allem, es kann durchaus Sinn machen. Wer sich durch JDBC-Code bewegt, dem wird häufig schon die Abfolge "Query ausführen", "Abklappern des ResultSet" und häufig fehlerhafte Ausnahmebehandlung aufgefallen sein. Dies schreit nach Abstraktion und man wundert sich, warum entsprechendes nicht von Anfang an in JDBC enthalten ist. Auch hier setzt Java mit dem Problem der Exception-Behandlung allerdings Grenzen.
Eines noch: Die Verwendung von varargs um einen(!) Parameter optional zu machen und falsche Verwendung erst zur Laufzeit als per RuntimeException zu melden, verdient eigentlich die Erwähnung auf www.thedailywtf.com.
Summa summarum: Wer funktional programmieren will, sollte eine funktionale Programmiersprache verwenden.
Comment