Does the language you use make a difference? – Code metrics for "functional-first" v. "object-first" code


 

This post is a very interesting study of the differences between “functional-first” (F#) and “object-first” (C#) design for medium-sized software, by comparing software metrics for a number of C# and F# projects.

Here are the conclusions, #3 and #4 are the most important I think.

  1. Project complexity. For a given number of instructions, a C# project is likely to have many more top level types (and hence files) than an F# one — more than double, it seems.
  2. Fine-grained types. For a given number of modules, a C# project is likely to have fewer authored types than an F# one, implying that the types are not as fine-grained as they could be.
  3. Dependencies. In a C# project, the number of dependencies between classes increases linearly with the size of the project. In an F# project, the number of dependencies is much smaller and stays relatively flat.
  4. Cycles. In a C# project, cycles occur easily unless care is taken to avoid them. In an F# project, cycles are extremely rare, and if present, are very small.

To me, this is good evidence that functional-first programming offers fundamental improvements in taming the complexity of software systems. Honestly, would you prefer to work on software with cyclic dependencies involving 50-200 components (C#) or 1-3 components (F#)?

I’d be interested to know what people think of this study and, if they disagree with the results, how they would refute it.  And if the results are valid, then what does it mean for software engineering and programming languages?

 

 

Cheers,

Don 

p.s. http://fsharpforfunandprofit.com/posts/cycles-and-modularity-in-the-wild/

p.p.s. http://fsharp.org/testimonials

 

 

Comments (3)

  1. Bryan Edds says:

    Absolutely, absolutely, absolutely!!

    I think the most important skill a programmer can possess is the ability (and will!) to tame the complexity of the artifacts of the code he writes.

    As Rich Hickey says, it's not about the shape of the code or how quickly you can hack it out; it's the amount of interleaving taking place among the various components you create that make life so hard for your team – http://www.infoq.com/…/Simple-Made-Easy

    It's the complecting, stupid! :)

  2. Tom says:

    Metrics like these are definitely helpful (which is why I lurk around your blog), but I really wish the speakers at Build 2013 were mentioning F# once in awhile — even as they talk on other topics.

    I would love to tap the benefits of "functional-first" programming. I'm increasingly convinced that F# really does have real (and real-world) advantages in taming the complexity of software systems.

    But because we have had to deal with legacy code in fading languages before, F# would be a far easier sell inside my organization if Microsoft talked about it much more often, especially when talking to developers.

    It is unnerving to want to recommend we take a real leap into F# when we don't hear anyone talking about it at an event as developer-rich as Build 2013.

  3. Ralph Becket says:

    God, I miss declarative programming languages now I'm in industry.  Even worse, I'm currently wallowing in JavaScript, a celebration of bad things.

    I remember chatting to Don over a decade ago after playing around in OO languages seriously.  Don's comment was, "OO languages make you stupid."  The shame is that, as far as I can tell, commercial programmers are generally more concerned with defending what they know rather than genuinely trying something different.