Share via

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

  • Article

 

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. <fsharpforfunandprofit.com/posts/cycles-and-modularity-in-the-wild/>

p.p.s. <fsharp.org/testimonials>

Comments

  • Anonymous
    June 23, 2013
    The comment has been removed

  • Anonymous
    June 26, 2013
    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.

  • Anonymous
    July 01, 2013
    The comment has been removed