Forem: Igal Tabachnik

Your C# is already functional, but only if you let it

Igal Tabachnik — Mon, 09 Mar 2020 06:19:08 +0000

A few days ago I tweeted a C# code snippet, showing a FizzBuzz implementation using some of the new features in C# 8.0. The tweet "went viral", as the kids say, with several people admiring the terse and functional aspect of it, while others asked me why I wasn't writing it in F# in the first place?

First time writing C# in 4 years :P pic.twitter.com/m7kM9j9skN
— Igal Tabachnik (@hmemcpy ) March 4, 2020

It has been over 4 years since I last wrote C#, and being exposed to functional programming clearly affected how I write code today. The snippet I wrote seems very neat and natural, however, some people expressed concerns that it doesn't feel like C# code --- "It looks too functional."

You keep using that word...

Depending on who you ask, the word functional means different things to different people. But rather than debating semantics, I'd like to offer an explanation of why this tiny FizzBuzz snippet feels functional.

But first, let's unpack the snippet (with few tweaks to the above image):

public static void Main(string[] args)
{
    string FizzBuzz(int x) =>                // Local function, defined as an expression-bodied method
        (x % 3 == 0, x % 5 == 0) switch {    // Tuple definition  
            (true, true) => "FizzBuzz",      // Pattern-matching on the tuple values
            (true, _)    => "Fizz",          // Discard (_) is used to omit
            (_, true)    => "Buzz",          // the values we don't care about
            _            => x.ToString()     
        };

    Enumerable.Range(1, 100)                 // Make a range of numbers from 1 to 100
        .Select(FizzBuzz).ToList()           // Map each number to a corresponding FizzBuzz value
        .ForEach(Console.WriteLine);         // Print the result to the console  
}

The novelty here lies in using a tuple (pair) to capture the result of both equations together (x % 3 == 0 and x % 5 == 0). This allows using pattern matching to deconstruct the tuple and examine both values together. If none of the cases match, a default (_) case will always match, returning the string value of the number.

However, none of the many "functional" features used in the snippet (including LINQ-style foreach loops) is what makes this approach in itself functional. What makes it functional is the fact that except for the final printing to the console, all of the methods used in this program are expressions.

Expression-oriented programming

Simply put, an expression is a question that always has an answer. In programming terms, an expression is a combination of constants, variables, operators, and functions, evaluated by the runtime to compute ("return") a value. To illustrate the difference with statements, let's write a more common C# solution to FizzBuzz:

public static void Main(string[] args)
{
    foreach (int x in Enumerable.Range(1, 100)) {
        FizzBuzz(x);
    }
}

public static void FizzBuzz(int x)
{
    if (x % 3 == 0 && x % 5 == 0)
        Console.WriteLine("FizzBuzz");
    else if (x % 3 == 0)
        Console.WriteLine("Fizz");
    else if (x % 5 == 0)
        Console.WriteLine("Buzz");
    else
        Console.WriteLine(x);
}

Obviously, this snippet could be tweaked to remove duplication, but I doubt anyone would argue this does not look like C#. And yet, upon closer inspection of the FizzBuzz method, it reveals several design issues (even in a program as simple as FizzBuzz).

First of all, this program violates the Single Responsibility principle. It mixes both "business logic" of calculating the output value based on the number with the act of printing this value to the console. As a consequence, it violates the Dependency Inversion principle by tightly-coupling to the console output. Finally, we cannot reuse and test this program in isolation without introducing a few indirections. For such a trivial program like FizzBuzz we would never do this, but taken to the extreme, it's easy to end up with Enterprise FizzBuzz.

All of the problems stated above can be solved by separating the act of producing a FizzBuzz value and printing it to the console. Even without using fancy language features, the simplest act of returning a value to the caller frees us from the responsibility of doing something with that value:

public static string FizzBuzz(int x)
{
    if (x % 3 == 0 && x % 5 == 0)
       return "FizzBuzz";
    else if (x % 3 == 0)
        return "Fizz";
    else if (x % 5 == 0)
        return "Buzz";
    else
        return x.ToString();
}

This might not look like a dramatic change (and it could be implemented in various ways, here using the most naive way for illustration), but few things happened here:

The FizzBuzz method is now an expression, given some numeric input produces a string output
It has no other responsibilities or side-effects, making it a pure function
It can be tested and reused on its own, without any additional dependencies or setup
The caller of this function is free to do whatever it wants with the result -- not our responsibility

And here lies the essence of functional programming - all functional code is made up of expressions, producing some value and returning it to their callers. These expressions are usually stand-alone, completely specified by their input parameters. At the very top, the entry point (or, sometimes known as "the end of the world") these values are gathered and interacted upon with the rest of the world. In object-oriented jargon, this is sometimes called the "Onion architecture" (or "Ports and Adapters") - a pure core comprised of business logic and the imperative outer shell that is responsible for interactions with the external world.

C# (and Java and Python and ...) can be functional

Using expressions instead of statements in the small is at the core of nearly all programming languages today. C# evolved over time to introduce features to make it easier to work with expressions: LINQ, expression-bodied methods, pattern matching and more. These features are oftentimes called "functional" because they are --- in languages such as F# these features are used all the time, allowing the data to flow from the inside-out. Other functional languages, such as Haskell, make it nearly impossible to have anything other than expressions.

In fact, this style of programming is now encouraged by the C# team. In a recent talk given at NDC London, Bill Wagner urges you to change your (imperative) habits and embrace modern techniques:

C# (and other imperative languages, like Java) can be used functionally, but it requires a high level of diligence. These languages make the functional style the exception, not the norm. I urge you to explore other languages, where expression-oriented programming is the default, making it a first-class citizen.

This was originally posted on my blog.

Becoming Foolish

Igal Tabachnik — Sat, 21 Oct 2017 06:15:30 +0000

This post was originally published on my blog.

The book The Pragmatic Programmer: From Journeyman to Master by Andy Hunt and Dave Thomas suggests that as developers, we should "learn at least one new language every year." (pg. 14)

When I recently asked a roomful of developers, if there's anyone who had learned a new language this year, only very few hands went up. A year ago today, that would have been me in the audience, keeping my hands down.

I had been a happy C# developer for over a decade, starting professionally sometime before .NET 2.0 was released. During my career I had the privilege of working in a very specialized field - building tools for other developers, mainly in form of extensions to Visual Studio itself. My job often required from me to understand the code better than the compiler, in fact, I often had to take a peek under the hood to understand what the compiler, MSIL, JIT, and sometimes native code were doing, all long before tools like Roslyn even existed. I knew implementation details of the runtime that were not documented anywhere. I knew most of the corner cases and language gotchas. But overall, my language, C#, was a very powerful hammer, capable of handling any kind of nail.

Which caused me to pretty much ignore any other languages out there, which weren't relevant to my day job. Whenever people from the F# camp were boasting their lack of nulls, pattern matching, or not needing semicolons or braces, I would typically shrug it away. I have spent years of my career learning to use productivity tools, such as ReSharper and IntelliJ IDEA, to the point where every bit of boilerplate was one keystroke away. I simply didn't care! Having a few nice features was never a good enough reason for me to switch a programming language -- why would I even bother, when my language that I'm an expert in, could kinda-sorta do that too? Why would a different syntax make a difference in how I write software? After all, doesn't it all compile down to the same thing?

Because when you really get down to it, (almost) all programming languages are, essentially, this:

public static void main(String[] args)
{
    ...
}

In most programming languages that we've ever experienced, the world as we know it lives and dies in the confines of the opening and closing brace of the main function, which is the entry point to our application. Everything that happens in our program, the universe our program interacts with, happens between those two braces. By its very definition, our program returns an exit code, specifying whether it succeeded or not, and everything else happens as a side-effect.

The implication, that all the work is done between the two braces of the main method, is what drives everything we know about this model - every design pattern, every practice, every discipline, every tool, library, or framework - were created to let us manage this model of our world that exists between those two braces. We have decades of knowledge in how to do this properly in almost any language.

For me, this was the core, the very foundation on which all the software is built! It was the one thing that was the ultimate truth, regardless of the programming language.

And it was like this, until Haskell ruined it for me!

I will not go into details - I inadvertently did that in my previous post. But during watching a talk on seemingly unrelated topic, the speaker managed to sneak some Haskell in there! Until that moment, I haven't really seen any Haskell code before - I've always dismissed it as irrelevant - and there it was, staring me in the face.

main :: IO () -- reads as 'main, having the return type of IO ()'

What I saw being explained is that Haskell doesn't actually do any work inside of its main function. Instead, the program "describes" in a declarative way what is going to have happen when your program executes, and this "description" will be returned into the Haskell runtime, and exactly what was described will happen - with no possible side-effects or surprises. It flips the entire idea of execution on its head - the work, the actual execution of effects is not being done inside of main - it's done on the outside!

Seeing this for the first time, trying to wrap my head around it, had created a bug inside my head. It had conflicted with what I knew - that all languages worked the same, and the difference was merely syntax! But here, I was seeing something that just worked differently, and did not fit my world view! I struggled with trying to understand it, and it took me a couple of more re-watches, until one day, it finally clicked!

In one single moment, I suddenly understood the idea of Haskell, of why it works the way it does. Everything just clicked into place and I finally "understood monads"! To me, it felt like Neo finally coming to terms with the fact that there is no spoon, and only then he's able to bend it.

I am thankful for Andrea Magnorsky's excellent keynote talk, Inviting Everyone to the Party, which helped me realize that not only what I had experienced had a name, it was, in fact, a textbook definition of the phenomenon: what I had experienced is called a paradigm shift.

The term "paradigm shift", coined by Thomas Kuhn in his 1962 book The Structure of Scientific Revolutions, describes a process where if an established model no longer fits the world view, it is rejected and simultaneously replaced by another. Kuhn says:

The decision to reject one paradigm is always simultaneously the decision to accept another, and the judgment leading to that decision involves the comparison of both paradigms with nature and with each other.
Thomas Kuhn, The Structure of Scientific Revolutions: 50th Anniversary Edition (pg. 78)

I had two conflicting ideas, and when finally that other idea started making sense, my mind accepted it, and immediately switched to that new idea - the switch was instantaneous! I was able to see things from a different perspective, understanding a whole new world model, which is precisely the definition of Kuhn's "paradigm shift".

But something else happened -- I realized just how little I knew about software, there was an entire world out there that was unknown to me! What I knew until that moment, all my expertise in a narrow field was just a tip of the iceberg. And this realization removed a barrier I had that prevented me from trying to learn new languages and experimenting with new things. Where previously I would dismiss these things as irrelevant, I suddenly gained interest in things that I never had interest in before. In the past year alone I've used Haskell, Clojure, and Rust. I've looked at Erlang, Elm and PureScript. I am working my way through SICP and learning Category Theory. I've done all that because for the first time in a long time, I am genuinely curious about what these languages/paradigms can teach me! I really don't remember the last time I was this excited about learning. Genuinely proud of being able to say - "I don't know everything!" - is incredibly liberating!

This exact sentiment is also echoed in Bret Victor's fantastic, and highly entertaining keynote talk, The Future of Programming, where he pretended he was a software developer in 1973, and speculated about the next 40 years of programming. The last 5 minutes of that talk has some of the best advice I ever heard, and I wish I understood it sooner. He said,

...you have to say to yourself - "I don't know what I'm doing. We, as a field, don't know what we're doing. We don't know what programming is, we don't know what computing is, we don't even know what a computer is." And once you truly understand that, once you truly believe that -- then you're free, and you can think anything.
Bret Victor - The Future of Programming

Stay hungry. Stay foolish. Be free!