CC mit FP

[Rainer Schuster]

Hallo zusammen,

ich beschäftige mich ja auch seit mehreren Jahren mit Funktionaler Programmierung. Angefangen hatte es mit Scheme, dann F# und letztendlich Clojure. 

Meine Erfahrung ist, das viele der Prinzipien, die ich in der OOP diszipliniert und aus Gründen der Hygiene einhalten muss fallen hier einfach weg - nachdem ich erstmal, wie auch in der OOP die Grundlagen der FP verstanden und angewendet haben.

Was mir an F# z.B. im Funktionalen Bereich sehr gefällt ist die gute Lesbarkeit und meiner Meinung nach deutlich verminderten LoC (Lines of Code). In Punkto OOP ist F# ähnlich rauschanfällig wie C#.

Dry und Kiss kann ich in der FP genauso anwenden. OCP und LSP sind etwas anderes, da die Idee in der FP anders ist Daten zu bearbeiten. Was mir an Clojure gefällt, und was mich immer wieder dorthin geführt hat sind die Datenstrukturen. Beispiel:

Die nativen Datenstrukturen in Clojure verhalten sich wie ein Repository in Git. Füge hinzu und jede neue Version ist das hinzufügen der Änderung auf die bestehenden Daten. Danach wird per commit der Pointer (HEAD) auf die neueste Änderung umgesetzt. Die Datenstrukturen in der FP sind aber besser geschützt und lassen sich nicht kaput machen wie bei git :-)...

Wenn Daten also nur eine Zustandsänderung hinweg über Zeit sind und immer nur Änderungen hinzugefügt werden, ist also alles was aktuell oder älter ist garantiert in einem atomaren unveränderlichen Zustand. Somit kann ich Problemlos Daten in der Welt herumschicken und sie in Funktionen stecken, die wissen was sie mit den Daten anfangen kann, ohne Gefahr zu laufen irgend etwas kaput zu machen. Beim wem klingelt es da? Das ist nichts anderes als Rx und die Dualität von IObservable und IEnumerable.

Komposition funktioniert hier also anders und macht viele Prinzipien, die wir im Clean Code befolgen schlichtweg überflüssig, weil implizit vorhanden oder nicht notwendig.

• Mich würde interessieren wie eure Erfahrung mit der FP ist, wenn vorhanden in welcher Form? 
• Wenn nicht vorhanden, was dich davon abhält? 
• Was für Gründe habt ihr für ein Pro oder Contra?

[BeoXTC]

Du hast mir jetzt Lust auf clojure gemacht.

Ich kann die Fragen nicht beantworten da ich zu wenig Erfahrung mit FP habe.

--
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "Clean Code Developer" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an clean-code-devel...@googlegroups.com.
Wenn Sie in dieser Gruppe einen Beitrag posten möchten, senden Sie eine E-Mail an clean-code...@googlegroups.com.
Gruppe besuchen: http://groups.google.com/group/clean-code-developer
Weitere Optionen finden Sie unter https://groups.google.com/d/optout.

[Ralf Westphal]

Wenn Daten also nur eine Zustandsänderung hinweg über Zeit sind und immer nur Änderungen hinzugefügt werden, ist also alles was aktuell oder älter ist garantiert in einem atomaren unveränderlichen Zustand. Somit kann ich Problemlos Daten in der Welt herumschicken und sie in Funktionen stecken, die wissen was sie mit den Daten anfangen kann, ohne Gefahr zu laufen irgend etwas kaput zu machen. Beim wem klingelt es da? Das ist nichts anderes als Rx und die Dualität von IObservable und IEnumerable.

Na, da klingelt bei mir vor allem die EventSourcing Glocke :-)

Weder IObservable noch IEnumerable haben etwas mit solchen Datenstrukturen zu tun. Beide bieten ja nur Iteratoren: einmal per Pull (IEnum) und einmal per Push (IObs).

 

Komposition funktioniert hier also anders und macht viele Prinzipien, die wir im Clean Code befolgen schlichtweg überflüssig, weil implizit vorhanden oder nicht notwendig.

• Mich würde interessieren wie eure Erfahrung mit der FP ist, wenn vorhanden in welcher Form? 
• Wenn nicht vorhanden, was dich davon abhält? 
• Was für Gründe habt ihr für ein Pro oder Contra?

Für mich gibt es kein entweder-oder. Flow-Design enthält Elemente aus der FP. Aber ist andererseits Zustand - in welcher Form auch immer - nicht abgeneigt. Immutability ist orthogonal zu Flow-Design. Wer die aber mag/braucht, der soll sie gern einsetzen.

Ich empfinde keinen großen Druck, auf FP/F# umzustellen. Dennoch reizt mich F# ab und an wg seiner knapperen Syntax und einer etwas besseren Unterstützung von Flow-Design. Naja, und die Ausdrucksstärke für Domänenmodelle ist größer.

Wichtiger ist mir jedoch erstmal FD, also der Fokus auf Funktionen/Funktionalität statt Struktur. Da reichen mit die FP-Features von C#. Damit kann ich auch Leute erreichen, die heute schon C# machen. Wenn es nur besser wird mit einer FP-Sprache, dann gibt es wenige, die mitgehen wollen.