Discussion about FP

Hallo Roman,

Ich möchte Bezug nehmen auf deinen Post,
http://functionalsoftware.net/less-code-and-less-bugs-with-functional-programming-languages-589/
den ich auf Twitter als "Oversimplified" (https://twitter.com/pro_cessor/status/714422810081435652)
bezeichnete. Ich möchte beschreiben, was ich damit meine - was auf Twitter ja nur zu Tränen und Mißverständissen führen würde. Daher möchte ich dir ehrliches Feedback zu deinem Artikel geben.

Die Studien die du zitierst finde ich klasse, besonders die erste hat es in sich. Sie sieht (soweit ich das beurteilen kann), methodisch sauber aus, ist aber nicht so einfach zu interpretieren, wie ich es deiner Darstellung entnehme.

Disclaimer
----------

Als Disclaimer möchte ich dazusagen, dass ich intuitiv glaube, dass du recht hast - weniger Code ist besser und erleichtert die kognitiven Ressourcen, allerdings finde ich deine Formulierung sehr überspitzt und deine Schlussfolgerung zu reduktiv, daher würde ich dazu gerne meinen Senf geben.

Erstmal finde ich es gut, wie du argumentierst: nämlich indem du zwei Studien anführst, die deinen Punkt untermauern. Das machen viele in der Wirtschaft / Industrie einfach nicht und viele Diskussionen werden nach Gutdünken, Wunschdenken und "Weil ichs schöner finde" geführt. Dadurch, dass du deine Diskussionspunkte so klar darlegst, machst du dich natürlich angreifbar, aber so entstehen nunmal sehr fruchtbare Diskussionen!

Leider führst du *nur* zwei Studien an, während der Sachverhalt sehr viele Variablen hat. Die Studie
"A Large Scale Study of Programming Languages and Code Quality in Github" ist schon gut gemacht, allerdings muss man beim Schlussfolgern darüber beachten, dass die Studie in ihrer Validität etwas beschränkt ist.

Github
------

Ich möchte erklären warum: Github wird gerne als Datenquelle betrachtet, allerdings ist Github sehr eingeschränkt. Github ist modern, das bedeutet dass ältere Software eventuell nicht beachtet wird, weil die Entwickler beispielsweise SourceForge o.ä. verwenden. Ausserdem ist nicht klar, wie repräsentativ GH ist, immerhin wird sehr viel Code hinter verschlossenen Türen geschrieben. Daher lassen sich die gefundenen Effekte nicht ohne weiteres generalisieren, sondern wohl nur eingeschränkt auch für andere Sprachen, Menschen und Projekte.

Methodik
--------

Weiterhin sind die Linearen Modelle mit denen Sie rechnen zwar sauber, aber zeigen nur sehr kleine Effekte, und es ist schwierig, die einzelnen Modelle bzw. Variablen darin mit einander zu vergleichen. Durch eine angemessene Abstraktion (Fehlertyp bzw. Kategorie) finden die Autoren dann eben diese kleinen Effekte raus - allerdings halte ich die Kategorien für sehr fragwürdig.

Hier kommt meine erste Kritik an deinen Aussagen, da du besonders die Vorteile funktionaler Programmierung und besonders der Sprachen hervorhebst. Ich programmiere sehr gerne Python und bevorzuge hier einen funktionalen Stil (nicht aber "Pure" - Funktionale Sprachen), allerdings wurde Python als "Scripting Language" kategorisiert. In Python kann man beides:

	# Imperativ, Prozedural?
	items = []
	for item in raw_list:
    	if item.is_class():
			items.append(item)

oder

    # Funktional? - Geht auch mit map und fold, etc.
    items =	[item for item in raw_list if item.is_class()]

(Die list comprehensions hat Python bei Haskell geklaut)

Daher ist die Zuordnung sehr arbiträr, weil Python sehr wohl als funktionale Sprache, wohl aber auch als OO Sprache betrachtet werden kann. Somit ist allein die Reduktion auf die "Sprache" und nicht etwa auf den "Schreibstil" etwas reduktiv, wobei natürlich bestimmte Sprachen problematisch werden (OO in C ist grottig und FP-artiger Stil geht in Java auch nicht wirklich).

Deine Aussage würde ich auch hier nicht abtun. Du hast recht, weniger Code ist besser. Das zweite, funktionale Beispiel hat weniger Code und weniger Wiederholung und sollte daher eigentlich ****grundsätzlich**** besser sein, aber so einfach ist das nicht und das wird auch aus den Studien nicht klar.

Du selbst zitierst:
 > "Functional and scripting languages provide significantly more concise code than procedural and object-oriented languages."

und hast "Functional" hervorgehoben, dabei sind in der Kategorie der Scripting Languages Python und Ruby vertreten, während Python eine multiparadig Sprache ist (wie auch C#). Meine Vermutung ist daher, dass es auch auf den Stil ankommt, in der Programme geschrieben sind. Die Schlussfolgerung, dass nun aufgrund der Datenlage eine funktionale Sprache bevorzugt werden sollte...

 > With a FP language many problems can be solved with elegantly less code and less-code leads to less-bugs.

...halte ich daher für falsch. FP hat Vorteile, aber sollte nicht wie ein Hammer auf eine Schraube angesetzt werden. So konklusiv sind die Daten nicht. Besonders die zweite Studie hebt hervor, dass Scripting Languages genauso in der Lage sind, weniger Code zu produzieren. Die erste Studie spricht von besonders kleinen Effekten (Signifikanz ist eine Nullaussage) und auch hier finden sich im Detail Daten, die so pauschalisiert nicht valide sind. Beispielsweise scheinen in Tabelle 8 die Koeffizienten von Haskell leicht negativ auszufallen (In Haskell werden also wohl mehr Bugs gefixt), während in Erlang eher positive Koeffizienten vorherrschen (wobei auch hier nur sehr kleine Effekte vorherrschen). In der "Application Domain" scheint sogar Scala eher der Verbrecher zu sein, mit 52% Defect Density.

Von Seiten der Interpretation bleiben nicht nur die Daten zu beanstanden. Es wird hier ja lediglich gemessen, was das Verhältnis aus Commits zu "Bugfix-Commits" ist. Hier bleibt unklar, was nun ein positiver Wert (viele Commits sind Fixes) aussagt, bzw. auf welchem realweltlichen Phänomen die Daten basieren. Die Werte können nun dadurch entstehen, dass in einer Sprache oder Sprach-Klasse die Programmierer

- Besonders viele Fehler machen.
- Besonders oft Fehler-Fixes Committen
- Besonders gut Fehler entdecken
- Besonders oft Fehler beheben

Andersrum könnte man die Werte in Studie 1 für die FP-Sprachen deuten durch Programmierer die:
- Besonders wenige Fehler commiten
- Besonders wenige Fehler entdecken
- Besonders wenige Fehler beheben

Es wird nicht klar, ob besonders viele Fehler gemacht werden, oder ob es viele Fehler gibt, die nur nicht entdeckt werden. Vielleicht macht man mit FP ja Fehler garnicht weniger oft, vielleicht wird es einfach schwieriger, sie zu entdecken. Sollte das die korrekte Interpretation sein, so finde ich die geringen Effektstärken eher beruhigend.

Schlussfolgerung
----------------

Auch ich tendiere aus dem Bauch heraus, weniger Code als besseren Code zu beschreiben. Zu viel Code heißt meiner Erfahrung nach, dass Duplikation und unklare Konzepte vorherrschen. Viel Code ist also nicht das Problem, wohl aber oft das Symptom. Ich pflichte dir also bei:

Weniger Code - Weniger Kosten.
Weniger Code - Weniger Bugs.

Für invalide halte ich jedoch:

FP -> Weniger Code
FP -> Weniger Kosten
FP -> Weniger Bugs

Auch hier fehlt mir die Erklärung, bzw. habe ich in meiner Studie zeigen können, dass "less to read" nicht unbedingt das beste Argument ist:

https://github.com/cessor/bachelor-thesis

Zusammengefasst: Semantikeffekte überwiegen die absolute Kürze von Bezeichnern im Code, stabil gemessen mit mittlerem Effekt auf engstem Raum (3 x 6 x 15 SLOC, das ist nicht viel Code, aber ein recht klarer Effekt im mittleren Bereich).


Statement.Add(senf)
-------------------

Hier kommt auch schon mein Erklärungsansatz, der nicht als Ersatz oder Widerspruch deiner Aussage gelten soll, sondern eher als bestätigende Erweiterung fungieren möchte:

Weniger Code wirkt sich positiv auf die Programmierung aus, weil so die kognitiven Ressourcen entlastet werden.

 > "Less to think about -> More time to think -> Better solution"

Finde ich richtig. Mir fehlt das warum, aber das finde ich ist auch nicht weit weg:

Weniger Code:
 - Weniger Bezeichner
 - Weniger Konzepte
 - Weniger Komplexität (Datenfluss, Ablaufpfade)
 - Entlastete kognitive Ressourcen
 - Bessere Chunks (vgl. meine BA-Studie)

Im FP gibt es tonnenweise schöne Beispiele. Seiteneffekte sind so ein Ding. In Nicht-FP Sprachen macht man ja gerne globale Variablen etc. auf, hat Seiteneffekte aus Funktionen und Loops. In FP hat man das nicht und braucht sich nicht permanent den (mutable) Zustand des Systems merken oder muss ihn durch Debugging + Profiling tracken. Hier entlastet FP klar das Gedächtnis. Auch bietet FP oft ein angemessenes Abstraktionsniveau (map, fold, pattern matching, etc.) um komplexe Operationen sauber zu beschreiben. Allein hier sehe ich viel Potential, wie FP den Geist entlasten kann.

Auf der anderen Seite haben konkrete FP-Sprachen viel Belastung durch komplexe Operatoren, verschachtelte Konstrukte, implizite (durchs Typsystem) gefrühstückte Daten-Verhältnisse, abstrakte Konzepte, die schwierig zu begreifen sind (etwa Rekursion oder Monaden, letztere sind kein Hexenwerk, aber um sie zu verstehen, muss man sie verstehen), und auch so bieten FP-Sprachen viel Potential, um ordentlich beschissenen Code zu schreiben. Selbst das ausgezeichnete Lisp, das ja nun ohne alles an Operator-Shite auskommt, ist voll von wirrem Zeug. Je nach Dialekt kann man den CAR (head) und CDR (tail) Operator ja kombinieren und hat dann (caddaaaaddar list). Und das macht das Code-Lesen nun wirklich nicht geiler.

Die Studie 1 zeigt das ja auch: "88,53 %" sind generische Programmierfehler. Und die lassen sich leider fast nicht durch die Sprache erklären, sondern sind teils domänenspezifisch bzw. durch die linearen Modelle nur mit verschwindend geringer Aussagekraft ausdrückbar.

In deine Aussage, dass weniger Code besser ist, stimme ich mit ein.
Ich bin ein großer Fan von Funktionaler Programmierung (weniger von pure-fp Sprachen, aus diversen Gründen) und benutze FP-Konzepte wo ich kann. Dennoch bin ich sehr sensibel gegenüber "FP IST BESSER WEIL $GRÜNDE" Statements. Genau wie alte C-Hasen sich dann gegenüber Objektorientierung wehren, verfällt man nämlich auf diese Weise sehr schnell in die Religiösität, und verpasst so eventuell, das richtige Werkzeug für den richtigen Job zu finden.

Wie steht es daher beispielsweise mit Nemerle? Eine .NET basierte, multi-Paradigm Sprache, die mal so mir-nix-dir-nix FP mit OO verbindet und vielleicht einen interessanten Kompromiss darstellt.

http://nemerle.org/About

Ich freue mich über die Diskussion und Feedback zu meinem Feedback!

lg

Johannes