JS Programming in C# - Immutability

Enough! JavaScript had us in its grip for long with its foot guns. The first time I heard the term Hoisting, I had no idea about it and misheard as hosting. You declare variables using var happily, and you have to come to peace with yourself that it is okay to hoist the vars (lift’em all to the top-most scope). I can’t believe JS convinced the rest of us that it was okay. Then came ES6 and saved us. let fixed the scoping. const provided immutability. At least now, you can say JavaScript supports functional programming.

JavaScript got feathers on its hat - let and const.

Even a kid would tell you that the top 2 facets of functional programming are immutability and functions as first-class citizens viz. Higher Order Functions (HOF). The other facets are equally important but without the top two, there is no functional programming.

From day one, C# has supported the ability to treat functions as first-class citizens through delegates. Yes, the concept of HOF wasn’t at its best in C# until the introduction of anonymous delegates or better lambdas later. But, hey, you were able to pass functions around as data.

That was one side of the coin - HOF. What about the other side - immutability? As you should know by now, Immutability is not a light subject.

It is a shame that even after 15+ years, C# doesn’t yet support immutability … fully.

C# supports (compile-time) constants (const), and a partial or rather peculiar support for immutable variables (readonly). With readonly, you can only declare immutable member variables. It cannot be used with local variables or method parameters. But here’s the peculiar part.

A readonly is still mutable within the constructor.

I wonder why.

Selling Immutability

I am a big fan of immutability. The confidence that an immutable variable provides is irreplacable. Once you start declaring immutable variables - assignable only once, the complexity of your code / logic untangles and assembles itself in steps. Individual steps of your logic wire smoothly in a chain / pipeline allowing each step to be tested independently.

Immutability for C#

I have not read (any) proposals myself but heard rumors, once or twice, of adding support for immutable variables in C#. Like I said, I haven’t looked into the proposals, so I am dreaming here.

There are several ways to get C# support immutable variables.

New Keywords/Quantifiers

Reuse Existing Keywords/Quantifiers

Other side of the fence

Languages that started out as functional first like Scala, F# and others are well-off; as far as immutability is concerned. On some level, I would say C++ too has got it covered; nevertheless beware of quirks.

It shouldn’t be exaggerating to say that JavaScript has by far the largest community behind it; the support of which blessed it with let and const.

Let us take a moment to interrogate the arch rivals we created - C# and Java.

Java started out with support for immutability but not HOF; until the introduction of lambdas in version 8. So now, you can do functional programming in Java; or so they say.

On the other hand, C# started out with (a little crude) support for HOF and is still limping its way towards supporting immutability. No wonder, they are arch rivals. What an odd world we live in.

Needless to say, there should be other good options. Love to hear.

C# is a very carefully designed language. There is abundant written material to prove that. At the same time, it is man-made. So any limitations or shortcomings one should see should be seen with some love.

It is unfortunate that each language starts out with a certain flavor - imperative, OO, functional or whatever, and later finds itself struggling or unable to support other flavors.

A reasonable language should support and allow picking from a variety of widely practiced paradigms, techniques and styles of programming and yield to the reasonable programmer to implement a solution that fits the problem.

Or so did Bjarne Stroustoup say (something similar), of course quoting C++. He was right in every way.