Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Funktionale Programmierung - Warum eigentlich?

Funktionale Programmierung - Warum eigentlich?

Kurzvortrag im Rahmen des LambdaHRO-Treffens.

Avatar for Jens Grassel

Jens Grassel

June 13, 2019
Tweet

More Decks by Jens Grassel

Other Decks in Programming

Transcript

  1. Eine spezielle Art von FP Die Programmierung in seiteneffektfreien Funktionen,

    die auch ¨ ubergeben werden k¨ onnen (siehe λ Kalk¨ ul). Wir beschr¨ anken uns hier auf den Fall der funktionalen Programmierung in einer statisch typisierten Programmiersprache1. 1Bei uns speziell Scala. 1
  2. Wie kamen wir zu Scala? I Auch wir (als Firma)

    haben in anderen Gefilden angefangen. • Vorprojekte in PHP, Javascript, Ruby, Python • Entwicklung unserer Suchmaschine in Java • eine Weile waren wir mit Java recht zufrieden • Beginn eines gr¨ oßeren Projektes ⇒ Geht es nicht auch besser? 2
  3. Wie kamen wir zu Scala? II Evaluierung verschiedener M¨ oglichkeiten

    • Wir wollten in der JVM bleiben. • FP war schon immer ein Interesse (Lisp). • Am Ende gab es dann noch Clojure und Scala. Den Ausschlag f¨ ur Scala gaben zwei Punkte: • mehr Bibliotheken (insbesondere Akka) • kein harter Umstieg (imperativ m¨ oglich) 3
  4. Der Weg zu funktionalem Scala I Zu Beginn schrieben wir

    gr¨ oßtenteils imperativen Code mit funktionalem ”Feenstaub” drauf. • Pattern Matching • map und flatMap • zunehmend nicht ¨ anderbare Variablen (immutable) Dies ¨ anderte sich, als wir anfingen Argonaut2 zu nutzen. • basierte auf scalaz3, ohne Kompromisse • zwang uns funktionalen Code zu schreiben 2http://argonaut.io/ 3Zu der Zeit die vorherrschende funktionale Bibliothek f¨ ur Scala. 4
  5. Der Weg zu funktionalem Scala II Wir begannen uns intensiver

    mit der Materie auseinanderzusetzen. • pure Funktionen • Monad, Functor, Applicative, etc.pp. • Rekursionsschemata • Cats statt Scalaz (zwecks besserer Doku und freundlicherem Umgang) • mehr Theorie (ja, auch Kategorientheorie) • Effekte (IO-Monad) 5
  6. Hilfe und L¨ osungen f¨ ur... Einige Dinge sind nun

    einfacher: • erh¨ ohte Wiederverwendbarkeit (h¨ oheres Abstraktionsniveau) • leichteres Testen (Free Monads, Tagless Final Testinterpreter, leichtere Modularisierung) • robusteres Testen (Property based testing, Datengeneratoren) • weniger Testen (Typisierung → mehr Arbeit f¨ ur den Compiler) • Reduzierung des Implementierungsraums (Polymorphismus, Refined Types) • leichteres Refactoring • Konzentration auf ”das Wesentliche” ⇒ Geschwindigkeit 6
  7. Generelle Probleme Schwierigkeiten und H¨ urden, die uns begegnet sind:

    • immer noch imperatives Denken im Kopf (Pr¨ agung) • h¨ oherer Einarbeitungsaufwand f¨ ur Mitarbeiter (Standardausbildung) • Angst vor Neuem bei Kunden (”Unsere Leute verstehen das nicht!”) 7
  8. Scala-spezifische Probleme Auch Scala hat seine Ecken und Kanten: •

    Viele Wege f¨ uhren nach Rom. (Vor- und Nachteil) • m¨ achtiges, aber komplexes Typ-System • teilweise sehr viel Boilerplate notwendig (Free, Tagless Final, Eff) • Zeit zum Compilieren steigt stark bei Nutzung fortgeschrittener Techniken. :-( 8