Hacker News Reader

Comment by ktRolster | Hacker News Reader

It's worth mentioning that another reason C# is popular is because of the strong commitment to backwards compatibility. I can write something in C# and be fairly confident that it will still work a decade from now. That kind of reliability makes me willing to invest significant capital into C# development.

View on HN

So we had this security app that needed to know what version of Windows it was running on. And the Windows detection worked flawlessly... until Microsoft came out with a new version. Our program detected the new Windows as the previously-most-recent version, even though we were calling the standard Microsoft-approved which-version-are-you function.

Turns out Microsoft detected that our specific app was asking, and lied to it, because telling it the truth broke the previous version of our app (because the previous version didn't know about the new version of Windows). It was annoying, and yet still incredibly impressive that Microsoft knew who we were and was going out of their way to try not to break us.

Viewed from the other side, someone at Microsoft was probably pretty upset with you guys when he found out :)

Given the NT code leak comments... yes ;)

I've heard of nvidia doing similar things lately, patching their driver because of a bug in a game. I'm really not a fan of this approach, it's coupling on a global scale and adding a lot of complexity.

Yup, that's always been Microsoft's strength.

I remember hearing epic stories from ex-MS coworkers about the internals of CreateFile/Read/etc. All sorts of convolutions to keep back compat with things from the win31 and earlier days. Painful to work on as a developer but great for customers.

I can sing the praises of Microsoft's backwards compatibility twice! The first is the little graphics library that is abused by µTorrent since the 9x days, and HTML Applications that lets me run Javascript with full system access. That team is the unsung heroes of computing while (IMO) I'm breaking stuff all the time.

How much cruft is in the language because of backwards compatibility?

Java couldn't do generics right, for example, because they didn't want to break compatibility. C# seems to be adding a lot of improvements, but would it be better if they could break compatibility?

Luckily, very little.

The reason is that C# had a chance to learn from the experience of others and is still a relatively new language.

There is a little bit of cruft here and there. For example, ,NET had good threading support from the start, but the idioms that are used nowadays for concurrent and parallel programming have evolved, and while the old APIs are still there, developers now use APIs that are more up to date.

Probably the big one is non-nullable types [1], aka 'The Billion Dollar Mistake', which would break everything.

[1] https://gist.github.com/olmobrutall/31d2abafe0b21b017d56

Cobra language solved this and compiles to C#, they can introduce non nil references, but yes they can't scrap the BCL which is nil ridden.

Seems to go against null propagation operator though :)

If that is to be done, there needs to be some legacy settings for the compiler. I'll happily, trade inconvience for the ability to completely abolish null from my code. I already use a Maybe pattern to avoid returning null, but I cannot avoid checking for null because it's so ingrained in the standard lib.

It's kind of a tradeoff, right? How many years worth of work are you willing to rewrite, just to get rid of a little cruft? Choose your language wisely and you'll have no problems.

You are assuming that the changes would take years. Doesn't it really depend on the changes? Some could be automated? Perhaps a switch/flag could be set within the language itself. If C# became safer, for example, how would you weigh the tradeoffs?

I can't think of any change in C# that I would make that would really be worth the effort.

Non-nullable references (by default), as mentioned above. That would be huge, and worth any amount of hit.

   > That would be huge, and worth any amount of hit.

I'm open to the idea that non-nullable references (by default) could 'be worth any hit', but I'd like to see the evidence. Have you tested converting a large codebase to non-nullable, and seen a reduction in errors as a result?

I have. Obviously it's not possible to do this completely in C#, but my team has moved over to using Option, Try, and Either types for values that might be null or throw exceptions. We've noticed a reduction in what we all knew was the single most common bug: null reference exception. It also reduces cyclomatic complexity [1], which is a fairly well understood measure of complexity and therefore bugs.

Anecdotally I've noticed a reduction in these kinds of issues when using languages that use non-nullable references by default (F#. Haskell, etc.). I find I am much more confident as a programmer when nullable references aren't the default. Actually a few days ago we had our first null reference error in F#, and it was because the record type passed to an F# function was instantiated in C#.

If you think about it, the idea that a statically typed system lies to you about the contract that a value will honour is always going to be a source of bugs. It takes static languages back into the realm of dynamic languages.

[1] https://en.wikipedia.org/wiki/Cyclomatic_complexity

We've noticed a reduction in what we all knew was the single most common bug: null reference exception

Well yes, I'm sure you have, but were those replaced by other bugs, leaving the bug count the same?

Good job.

Microsoft took the hit and revamped the runtime when generics landed. I'm sure they would take another hit if such a critical feature presented itself and there wasn't a good way to retrofit it.

The only two warts that strike me off-hand are covariant arrays and System.Nullable being value-type only.

Overall Microsoft has done a great job of building on earlier decisions. Including functions as first-class types (System.Delegate) in V1 is probably the biggest and was a deliberate break with Java's approach. It has enabled a ton of features: lambdas, LINQ, Expression, etc. The fact that LINQ can be turned into an AST with Expression<T> means you can also construct code dynamically at a much higher level than IL.Emit() while delegates mean you can get the JIT to provide the equivalent of a function pointer to the native code.

Actually they had it "almost" done before 1.0, but they didn't want to delay the release any longer.

https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...

Reply on news.ycombinator.com