© Zühlke 2011

Januar 2011

Dr. Klaus Alfert Dr. Bernd Löchner

Folie 1

Jenseits von Fakultät und Fibonacci: Architektur Funktionaler Programme

Dr. Klaus Alfert Dr. Bernd Löchner

© Zühlke 2011

Januar 2011

Dr. Klaus Alfert Dr. Bernd Löchner

Folie 3

Warum ist Funktionale Programmierung in vieler Munde?

Sun T 2 »Niagara 2« 2007, 8 Cores × 8 Threads

Intel i7 »Nehalem« 2008, 4 Cores × 2 Threads

IBM POWER 7, 2010, 8 Cores × 4 Threads

Oracle T 3 »Rainbow Falls« 2010, 16 Cores × 8 Threads

Intel Cloud Computing on a Chip 2009, 48 Cores (Prototyp)

© Zühlke 2011

Januar 2011

Dr. Klaus Alfert Dr. Bernd Löchner

Folie 9

Warum ist Nebenläufigkeit mit Objekten schwierig?

Objekte haben eine Identität

:2 :3

:1

Objekte haben einen (lokalen) Zustand

:2 :3

:1

Objekte haben Verhalten

:2 :3

:1

Multithreading erfordert Locks

:2 :3

:1

Ein hoher Grad an Nebenläufigkeit wird leicht unübersichtlich

:2 :3

:1

Ein hoher Grad an Nebenläufigkeit wird leicht unübersichtlich

:2 :3

:1

Wie kann funktionale Programmierung hier helfen?

© Zühlke 2011

Januar 2011

Dr. Klaus Alfert Dr. Bernd Löchner

Folie 17

Was unterscheidet FP von OOP?

© Zühlke 2011

Zu den Programmbeispielen

Beispiele in Haskell & Erlang

• Haskell ist puristisch elegant

• Erlang hat Industrial-Strength

Die Beispiele sind aber alle übertragbar in andere funktionale Programmiersprachen. F#

© Zühlke 2011

A LISP programmer knows the value of everything, but

the cost of nothing.

–Alan J. Perlis Epigrams of Programming

© Zühlke 2011

Werte, Variablen, Veränderliche

Was sind imperative Variablen?

• Namen für Adressen von Speicherzellen

• Abstraktionsniveau: Assembler

• Objekte haben eine Identität: Entspricht einer Adresse von Speicherzellen

Was sind funktionale Variablen?

• Namen für Werte: „Sei x beliebig, aber fest“

• Variablen werden an Werte „gebunden“

• Abstraktionsniveau: Mathematik

• Notwendig: Effiziente Abbildung auf Speicherzellen durch Laufzeitsystem

42

42

x

x

Objekte versus Werte

:1 42 :1 42 :1 42

Funktionen erzeugen aus alten Werte neue!

:2 42 42 42

Copy Gleich, aber nicht identisch

Gleich und identisch

© Zühlke 2011

© Zühlke 2011

Rekursion statt Iteration: Hyper-Fakultät (Sloane: A Handbook of Integer Sequences)

Fakultät ist für Kinder – Hyper-Fakultät ist für Erwachsene

H(n) = 1, 1, 4, 108, 27648, 86400000, 4031078400000, 3319766398771200000, 55696437941726556979200000, 21577941222941856209168026828800000, 215779412229418562091680268288000000000000000, 61564384586635053951550731889313964883968000000000000000, …

n

k

kknH1

)(

© Zühlke 2011

Rekursion statt Iteration: Hyper-Fakultät (Sloane: A Handbook of Integer Sequences)

Imperativ: Zuweisungsorientiert

hfac(n): r := 1; while n > 0 do r := r * n^n; n := n – 1; od return r;

Rekursiv: Werteorientiert

hfac(n)-> if n == 0 then 1 else n^n * hfac(n-1)

© Zühlke 2011

Rekursion statt Iteration: Hyper-Fakultät (Sloane: A Handbook of Integer Sequences)

Imperativ: Zuweisungsorientiert

hfac(n): r := 1; while n > 0 do r := r * n^n; n := n – 1; od return r;

Berechnung: hfac(3)

3 n

? r 1 27

2

108

1

108

0

© Zühlke 2011

Rekursion statt Iteration: Hyper-Fakultät (Sloane: A Handbook of Integer Sequences)

Imperativ: Zuweisungsorientiert

hfac(n): r := 1; while n > 0 do r := r * n^n; n := n – 1; od return r;

Rekursiv: Werteorientiert

hfac(n)-> if n == 0 then 1 else n^n * hfac(n-1)

© Zühlke 2011

Rekursion statt Iteration: Hyper-Fakultät (Sloane: A Handbook of Integer Sequences)

Berechnung:

Rekursiv: Werteorientiert

hfac(n)-> if n == 0 then 1 else n^n * hfac(n-1)

if n == 0 then 1 else n^n * hfac(n-1)

3 n fun

hfac(3)

if n == 0 then 1 else n^n * hfac(n-1)

2 n fun

if n == 0 then 1 else n^n * hfac(n-1)

1 n fun

hfac(2)

hfac(1)

hfac(0)

if n == 0 then 1 else n^n * hfac(n-1)

0 n fun

1 1

1

4

108

Komplexe Werte sind oft baumartig

D11

D112 D111

C D A B

C1 C2

C21 C22 D12

D122 D121

D1

{ vorname : „Martin“, nachname : „Mustermann“, anschrift : { strasse : „Hauptstrasse 23“, ort : { plz : „76541“, stadt : „Neustadt“ } }, kurse : [ { id : „Mo1“, title: „Tutorial C#“ }, { id : „Ndo4“, title: „Architektur“ } ] }

Wie ändert man komplexe Werte?

5

8 3

15

20

21 18

26

27 25

28

35

41 33

24

update (Tree, Value) Tree

Update: Ersetze 41 durch 42

5

8 3

15

20

21 18

26

27 25

28

35

41 33

24

28

24

35

42

Alter Baum Neuer Baum

Beide Bäume existieren gleichzeitig!

© Zühlke 2011

Pattern Matching

sum ([]) -> 0; sum ([X | Xs]) -> X + sum (Xs).

abs (N) when N >= 0 -> N; abs (N) -> -N.

length [] = 0 length (x:xs) = 1 + length xs

zip [] _ = [] zip _ [] = [] zip (x:xs) (y:ys) = (x,y) : zip xs ys

© Zühlke 2011

Higher-order Funktionen, Polymorphie und Lambda-Ausdrücke

map :: (a -> b) -> [a] -> [b]

map f [] = []

map f (x:xs) = f x : map f xs

map abs [-2 .. 2]

>> [2, 1, 0, 1, 2]

map (\x -> x*x) [-2 .. 2]

>> [4, 1, 0, 1, 4]

© Zühlke 2011

Algebraische Datenstrukturen

data Tree a = Empty

| Node (Tree a) a (Tree a)

mapTree :: (a -> b) -> Tree a -> Tree b

mapTree f Empty = Empty

mapTree f (Node l x r) =

Node (mapTree f l) (f x) (mapTree f r)

data Color = Green | Red | ...

autumn t = mapTree change t

where change Green = Red

change c = c

© Zühlke 2011

Erlang hat Closures – und Clojure auch (und Scala, F#, …)

mk_mul_abs (M) -> fun (N) when N > 0 -> M * N; (N) -> M * (-N) end.

Ma3 = mk_mul_abs (3). lists:map(Ma3, [-2, -1, 0, 1, 2]).

>> [6, 3, 0, 3, 6]

when N > 0 -> M * N; M * (-N)

3

N fun

mk_mul_abs M

Ma3

© Zühlke 2011

Haskell erlaubt Partial Application

parabola a b c x = a*x^2 + b*x + c

p1 :: Double -> Double

p1 = parabola 4.2 -2.0 3.5

y = p1 1.0

linear = parabola 0.0

l1 = linear 3.0 2.1

a*x^2 + b*x + c

3.5 x fun

fun c

p1 fun b

a fun

-2.0

4.2

a*x^2 + b*x + c

x c b a fun

© Zühlke 2011

Programmierung im Großen

Verantwortlichkeiten bündeln

• Module, APIs und Interfaces

• Kontrakte: Daten, Funktionen, Eigenschaften

Information Hiding

• Sichtbarkeiten, Namespaces

• Implementierungsinterna verbergen

Wie in OOP:

Benötigt Augenmaß und Disziplin

Beispiel: Pattern Matching

Werteorientierung und Higher-order Funktionen

ermöglichen andere Schnittstellen und Kontrakte

Funktionale Programmierung = Werteorientierung & Higher-order Funktionen

Welche Auswirkungen hat Funktionale Programmierung auf Architektur und Design?

Eoin Wood: Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be canceled.

Grady Booch: Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

ANSI/IEEE 1471-2000 The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

ANSI/IEEE 1471-2000 The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

High-Level Architektur

Architektur auf Marketing-Niveau: Ein typisches „Marchitecture“-Diagramm

DB

System im Fokus

DWH

CRM Server

Auftrags-verwaltung

Kunden-verwaltung

Pricing Logistik

Enterprise Architektur: Funktionalität bleibt lokal, Kommunikation über Werte

DB

System im Fokus

DWH

CRM Server

Auftrags-verwaltung Kunden-

verwaltung

Pricing Logistik HTML

JSON/REST

QuerySet

AMQP

SOAP

Service Bus

Portal Server

MQ SOAP

Host

SOAP

© Zühlke 2011

High Level Architektur: Grobzerlegung bleibt bestehen

Treiber:

• Primär fachliche Zerlegung in Aufgaben- und Verantwortlichkeitsgebiete

• Reflektiert auch die Organisation (Conway’s Law)

Konsequenzen

• Architektur auf dieser Ebene ist unabhängig von der Implementierungstechnologie

• Interna der Komponenten/Subsysteme sind irrelevant

• Kommunikation erfolgt über Werte, Funktionen bleiben lokal und werden nicht transportiert

Mittlere Architektur

Mittlere Architektur: Geprägt von nicht-funktionalen Systemanforderungen

Portabilität Wartbarkeit

Funktionalität

Zuverlässig- keit

Bedienbarkeit

Effizienz Dokumentation

Machbarkeit

Gliederung gemäß ISO/IEC 9126

Enterprise Java

© Zühlke 2011

Ein Blick auf Enterprise Java

Historisch:

• Transaktionsmonitor für verteilte Objekte

• Anbindung an (Legacy)-Datenbanken

Ausgelegt für

• Informationssysteme

• Hohen Durchsatz

• Skalierbarkeit

PortabilitätWartbarkeit

Funktionalität

Zuverläs-sigkeit

Bedienbarkeit

EffizienzDoku-

mentationMachbarkeit

© Zühlke 2011

Struktur: N-Tier-Schichtenarchitektur

http://download.oracle.com/javaee/6/tutorial/doc/bnaay.html

© Zühlke 2011

Einfluss von Java

Everything is an Object

• Auch für Dinge, die eigentlich keine Objekte sind (Stateless Session Beans, MDB, Backing Beans, Servlets, Transaktionen)

Transparente Remote-Aufrufe (RMI)

Thread-Management nur im Container

• Das Lock-Model von Java erlaubt keine Komposition von Concurrent Libraries

Interfaces anstatt abstrakter Klassen

Erlang/OTP

To Iterate is Human, to Recurse Divine – L. Peter Deutsch

© Zühlke 2011

Ein Blick auf Erlang/OTP

Historisch:

• Soft-Realtime Systeme, PBX, Telco

Ausgelegt für

• (sehr hohe) Zuverlässigkeit und Fehlertoleranz

• Skalierbarkeit mit massiver Parallelität

• Kommunikationssysteme

Anwendungsbeispiele

• Diverse Telco-Systeme von Ericsson

• Ejabberd, RabbitMQ, CouchDB PortabilitätWartbarkeit

Funktionalität

Zuverläs-sigkeit

Bedienbarkeit

EffizienzDoku-

mentationMachbarkeit

OTP besteht aus lose gekoppelten „Anwendungen“ …

Anwendung Web Server

odbc

crypto

gen_tcp

uses

… und aus Supervisor-Prozesshierarchien

Anwendung

Supervisor

Worker Supervisor

Worker Worker überwacht

© Zühlke 2011

Einfluss von Erlang auf OTP

Erlang stellt die Basismechanismen bereit

• Pure Funktionen, Datenstrukturen sind immer Werte

• Nebenläufigkeit durch Prozesse – Prozesse sind referenzierbar Entitäten im Sinne von Domain Driven Design

– Halten lokalen State, teilen sich aber keinen State!

• Massive Parallelität durch leichtgewichtige Prozesse und asynchrones Messaging

• Monitoring von Prozessen über VM-Grenzen hinaus

• Hot-Code Swapping: Updates im laufenden System

Nachbau in Scala: Akka (www.akka.io)

© Zühlke 2011

Mittlere Architektur: Domäne der Blue-Print-Architekturen

Standardarchitektur für eine bestimmte Systemklasse

• Anwendungsdomäne und -typ sind relevant

• Abgestimmt auf Hardware und Infrastruktur

Geprägt von den nicht-funktionalen Anforderungen

• Priorisierung und Balancierung der Qualitätsattribute

Das technisch Machbare bestimmt den Lösungsraum

• Programmiersprachen

• Laufzeitsysteme

• Bibliotheken PortabilitätWartbarkeit

Funktionalität

Zuverlässig-keit

Bedienbarkeit

EffizienzDokumentation

Machbarkeit

PortabilitätWartbarkeit

Funktionalität

Zuverlässig-keit

Bedienbarkeit

EffizienzDokumentation

Machbarkeit

Kleinteilige Architektur

© Zühlke 2011

© Zühlke 2011

Peter Norvig: Design Patterns in Dynamic Languages (1998) Analyse der Design Patterns aus Lisp/Dylan-Sicht

• GoF verwendet C++ und Smalltalk

Unterscheidung von Implementierungsebenen

• Unsichtbar: Wird von der Sprache abgedeckt

• Informell: Wird jedes mal neu implementiert

• Formell: Implementierung mit Template oder Macro

Norvigs Fazit für die 23 GoF Patterns:

• 16 werden deutlich einfacher oder unsichtbar

© Zühlke 2011

GoF Command Pattern

http

://e

n.w

ikip

edia

.org

/wik

i/Co

mm

and_

patte

rn

© Zühlke 2011

Ein Command ist eine Closure

shutdown_command(Receiver) -> fun() -> Receiver ! {shutdown, now} end.

@Client: MyMachine = …, Cmd = shutdown_command(MyMachine),

add_action(Cmd, Target),

@Target: ... Cmd().

Receiver ! {shutdown, now}

MyMachine

() fun

fun Receiver

Cmd

© Zühlke 2011

Commands mit Undo sind Closures mit Pattern Matching

start_command(Receiver) -> fun(do) -> Receiver ! {start, now}; (undo) -> Receiver ! {shutdown, now} end.

@Client MyMachine = …, Cmd = start_command(MyMachine),

@Target ... Cmd(do), ... Cmd(undo).

Receiver ! {start, now}

MyMachine

(do) fun

fun Receiver

Cmd

Receiver ! {shutdown, now}

(undo)

GoF Visitor Pattern

Ein Composite

http

://e

n.w

ikip

edia

.org

/wik

i/Vi

sito

r_pa

ttern

“Languages that support double- or multiple dispatch lessen the need for the Visitor pattern.

(CLOS actually supports multiple dispatch).” [GoF: p.339]

Composite = Algebraischer Datentyp Visitor = Durchlauf der Struktur

data CarElement = Car [CarElement] | Wheel String | Body | Engine

toString Body = ["Visit Body"] toString Engine = ["Visit Engine"] toString (Wheel s) = ["Visit Wheel " ++ s] toString (Car es) = concat (map toString es) ++ ["Visit Car"]

doCar Body = ["Moving my Body"] doCar Engine = ["Starting my Engine"] doCar (Wheel s) = ["Kicking Wheel " ++ s] doCar (Car es) = concat (map doCar es) ++ ["Starting my Car"]

Die Java Implementierung bei Wikipedia braucht dafür ca. 100 Zeilen

© Zühlke 2011

Charakteristik der GoF Patterns (1)

Creational Patterns

• Factories und Builder lösen allgemeine Probleme, unabhängig von OO, auch in C, Modula2, Haskell, Erlang

• Prototypen und Singletons verschwinden

Structural Patterns

• Interface-Probleme und -Lösungen sind sprachunabhängig (Facade, Bridge, Adapter, Proxy)

• Composite und Decorator werden unsichtbar

© Zühlke 2011

Charakteristik der GoF Patterns (2)

Behavioral Patterns

• Können durch Lambdas, Pattern Matching, … anders realisiert werden.

• Einige werden unsichtbar, andere sind nicht immer offensichtlich umzusetzen.

Generelle Beobachtung:

• Patterns, die auf Objektidentitäten basieren, müssen ganz anders umgesetzt werden.

© Zühlke 2011

Januar 2011

Dr. Klaus Alfert Dr. Bernd Löchner

Folie 69

Funktionale Patterns

http://www.flickr.com/photos/robbie73/

© Zühlke 2011

Standardisierte Rekursion

Listenfunktionen in Haskell:

sum [] = 0 sum (x:xs) = x + sum xs

product [] = 1 product (x:xs) = x * product xs

allTrue [] = True allTrue (x:xs) = x && allTrue xs

Extrahiere das Rekursionsschema

foldList startVal combFct [] = startVal foldList startVal combFct (x:xs) = combFct x (foldList startVal combFct xs)

sum = foldList 0 (+)

product = foldList 1 (*)

allTrue = foldList True (&&)

© Zühlke 2011

Standardisierte Rekursion

Mit foldList können viele Listenfunktionen implementiert werden

length [] = 0 length (x:xs) = 1 + length xs

map f [] = [] map f (x:xs) = f x : map f xs

length = foldList 0 cFct where cFct x len = 1 + len

map f = foldList [] cFct where cFct x ys = f x : ys

© Zühlke 2011

Standardisierte Rekursion für Algebraische Datentypen

Generalisiere für andere Datenstrukturen data Tree a = Empty

| Node (Tree a) a (Tree a)

foldTree eVal cFct Empty = eVal

foldTree eVal cFct (Node l x r) =

cFct (foldTree eVal cFct l) x (foldTree eVal cFct r)

sumTree = foldTree 0 cFct where cFct sl x sr = sl + x + sr

mapTree f = foldTree Empty cFct where cFct ml x mr = Node ml (f x) mr

heightTree = foldTree 0 cFct where cFct hl x hr = 1 + max hl hr

© Zühlke 2011

Auch im Visitor findet sich strukturierte Rekursion

data CarElement = Car [CarElement] | Wheel String | Body | Engine

visit :: (CarElement -> a) -> CarElement -> [a] visit f (Car es) = concat (map (visit f) es) ++ [f (Car es)] visit f x = [f x]

printCar car = visit toString car where toString Body = "Visit Body" toString Engine = "Visit Engine" toString Wheel s = "Visit Wheel " ++ s toString Car es = "Visit Car"

Separation of Concerns

© Zühlke 2011

Recursion is the goto of functional programming.

–Erik Meijer

© Zühlke 2011

Leichtgewichtige Threads

Erlang Prozesse sind nebenläufige, meist rekursive Funktionen

CalcProc = spawn(fun() -> calc_loop(0))

calc_loop(Acc) -> NewAcc = receive {mul, X} -> Acc * X; {add, X} -> Acc + X; clear -> 0; {get, Pid} -> Pid ! {result, Acc}, Acc; _IgnoredMsg -> Acc end, calc_loop(NewAcc).

Auswahl der Nachrichten durch Pattern Matching

Funktioniert dank Tail Call Optimization

Nebenläufige Endliche Automaten durch Prozesse, Funktionen und Messaging statt State-Pattern

Idle

Ringing Dial

Connected off_hook

on_hook

incoming off_hook

idle() -> receive {Number, incoming} -> start_ringing(), ringing(Number); off_hook -> start_tone(), dial() end. ringing(Number) -> receive {Number, off_hook} -> stop_ringing(), connected(Number); {Number, other_on_hook} -> stop_ringing(), idle() end.

other_ on_hook

Cesarini/Thompson: Erlang Programming 2009

© Zühlke 2011

Lazy Evaluation und unendliche Datenstrukturen

Lazy Evaluation:

(Teil-)Ausdrücke werden nur ausgewertet, wenn sie benötigt werden

head (x:xs) = x

Mit Lazy Evaluation gilt:

head [42.0, 1.0/0] == 42.0

Essentiell, um eigene Kontrollstrukturen zu definieren

unless cond x y = if !cond then x else y

Ideal für DSLs

© Zühlke 2011

Lazy Evaluation und unendliche Datenstrukturen

Mit Lazy Evaluation werden (potentiell) unendliche Datenstrukturen möglich

nats = [0 ..] take 5 nats == [0, 1, 2, 3, 4]

Wurzel-Berechnung nach Newton-Raphson:

sqrtSequence n = iterate (next n) n where next n x = (x + n/x)/2.0

sqrtSequence 2

>> [2.0, 1.5, 1.4166666666666665, 1.4142156862745097, 1.4142135623746899, 1.414213562373095, 1.414213562373095, 1.414213562373095, 1.414213562373095, …

iterate f n = [n,f(n),f2(n),f3(n), …]

http

://w

ww

.flic

kr.c

om/p

hoto

s/ro

bbie

73/

© Zühlke 2011

Pipes and Filters

Die Mächtigkeit der Unix-Shell kommt durch Pipes&Filters Konstruktionen cat *.txt | tr –sc A-Za-z '\n' | tr a-z A-Z | sort | uniq –c | sort –nr | head

Allgemein

prg1 –p1 <arg | prg2 –p2 | prg3 –p3 | prg4 –p4

Dies geht auch mit lazy Lists und Funktionskomposition

fct4 p4 . fct3 p3 . fct2 p2 . fct1 p1 $ arg

Idiomatisch in Haskell

Partial Application

Listen als Transfer-Container

Funktions- komposition

enspricht Pipe

Funktions- applikation enspricht <

Map/Reduce

Berechnung der (unabhängigen)

Zwischenergebnisse

Zusammenfassung

zum Endergebnis

Inspiration für s Map-Reduce-Framework (C++)

x1

x2

.

.

.

xn

f(x1)

f(x2)

.

.

.

f(xn)

map f reduce y = f(x1) … f(xn)

© Zühlke 2011

Was es sonst noch gibt

Eine Reihe weiterer Themen müssen wir auslassen

• Memoization

• Kombinatoren

• Monaden

• Macros

• Typeful Programming

• Continuations

• Co-Algebraische Konstruktionen

• …

Fazit

© Zühlke 2011

Funktionale Programmierung

Andersartiger Programmierstil

• Neue Abstraktionen und Kombinationsmöglichkeiten

• Andere Zerlegung von Problemen

• Andere Denkweisen und Idiome

Einfachere Strukturen machen das Leben leichter

• Keine (kaum) Seiteneffekte

• Pure Functions

• Testen und Parallelität werden sehr viel einfacher

© Zühlke 2011

Auswirkungen auf Architektur

Vieles bleibt gleich

• Architekturtreiber sind weiterhin die Qualitätsattribute

• Patterns werden zur Kommunikation für die Entwickler benötigt

Kreativität und Augenmaß bleiben zwei wichtige Eigenschaften der Architekten

• Gutes Design

• Klare Verantwortlichkeiten