Less Code and Less Bugs : with Functional Programming languages

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

Functional Programming (FP) insider know that, because they have personally experienced it. This can be tweeted and blogged many times, but how can others believe this? How do you prove it?

That problem inspired me to do some investigation. We need facts. What I’ve found so far are two studies that show this from a data analysis side. There is some evidence that both is true, according to these newer papers from 2014, based on data analysis of source code and its history from Github and from Rosetta Code :

Functional languages have a smaller relationship to defects than other language classes where as procedural languages”
– [1] A Large Scale Study of Programming Languages and Code Quality in Github
Functional and scripting languages provide significantly more concise code than procedural and object-oriented languages.”
– [2] A Comparative Study of Programming Languages in Rosetta Code


In [2] the data analysis covers 8 widely used languages representing the major programming paradigms
- procedural: C and Go;
- object-oriented: C# and Java;
- functionalF#  and  Haskell;  
- scripting:  Python  and  Ruby


I think the “less code” property is underestimated, because the too easy Lines of Code (LOC) counting is ridiculed. Looking beyond the LOC of the code base to the more important depending consequences :

less code  ->  less to read (more often than write!) and understand   -> 
less to review ->  less to communicate ->  less to refactor -> 
less to test  ->  less bugs  -> 
less to maintain  ->  less cost!!!

Btw. less code -> more time to think -> better solution -> more fun!


References

Other related analysis about software quality metrics, especially circular dependencies can be found here:
- “Comparing F# and C# with dependency networks
- “Cycles and modularity in the wild – Comparing some real-world metrics of C# and F# projects”

[1] A Large Scale Study of Programming Languages and Code Quality in Github
Baishakhi Ray, Daryl Posnett, Vladimir Filkov, Premkumar T Devanbu, Department of Computer Science, University of California, Davis, CA, 95616, USA
2014 http://dl.acm.org/citation.cfm?id=2635922


[2] A Comparative Study of Programming Languages in Rosetta Code
Sebastian Nanz, Carlo A. Furia, Department of Computer Science, ETH Zurich, Switzerland
2014 http://arxiv.org/abs/1409.0252



Videos zum Thema Funktionale Programmierung (FP)

Hier sind einige neue interessante und zum anders Denken anregende Videos zum Thema Funktionale Programmierung (FP). Warum sich jeder Software Entwickler mit FP befassen muss!

Weckruf – rüttelt an dem wie man bisher Software entwickelt(e).

Titel: Functional Programming: What? Why? When? Aussage: The Failure of State Autor: Robert C. Martin Titel: Programming in Interesting Times Aussage: YOUR PROGRAMMING LANGUAGE IS GOING TO DIE Autor: Russ Olsen Titel: One Hacker Way, a Rational Alternative to Agile Aussage: With Scrum we talk too much about code, instead of writing code. Uses the F***-word Autor: Erik Meijer Titel: Type Systems – The Good, Bad and Ugly Aussage: Not relying on type safety is unethical (if you have an SLA) Autor: Paul Snively and Amanda Laucher

   

Zeigt die Möglichkeiten von F#

Titel: FSLAB: DOING DATA SCIENCE WITH F# Aussage: How to get knowledge from data? Autor: Tomas Petricek Title: MBrace: large-scale programming in F# Aussage: Cloud Computing is easy with F# Autor: Eirik Tsarpalis

Der Wert von F# – The Value of F# (FSharp)

Zu meinem Tweet, der aus einer simplen Handskizze bestand, ergab sich Interessantes Feedback (nebst Re-Tweets, Favorites und als Bild in F# Weekly #38, 2014) Value of FSharp F#

Zu meinem Tweet

Den Wert von etwas erkennt man am besten (und schmerzhaftesten) dann, wenn man es nicht mehr hat. Den Wert der eine Programmiersprache einem Softwareentwickler geben kann ist NICHT zu unterschätzen.
  • Bevor man F# anwendet erkennt man deren Nutzen anhand einiger Features die einem gefallen und sofort erkennbaren Nutzen versprechen.
  • Während man F# nutzt und anderst zu denken beginnt (das ist etwas positives) erkennt man den wahren Wert; und es ist mächtig, man findet immer Neues und ist fasziniert.
  • Wenn man F# nicht mehr nutzt (nutzen darf, wie auch immer) erkennt man erst richtig all die kleinen mächtigen Dinge die man hatte. Und ohne diese ist man weniger produktiv und Fehler anfälliger.

Feedback auf den Tweet

Man lese diese Blogs, um zu verstehen, wie es anderen ergangen ist. Und ich wünsche allen denen es so ergangen ist, dass sie zurück in die F# Welt kommen können. Ihr macht das! Viel Glück!  

Die Strukturierung von F# Quellcode

Eine neue Seite zum Thema der Strukturierung von F# Code ist dazugekommen. Es geht um: – warum F# Code so kompakt ist – wie einem die Type-Inferenz behilflich ist sich auf das wesentliche zu Konzentrieren - und wie man dadurch weniger Fehler macht weiterlesen…..