5 ms·

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 fairl

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.

vvanders 10y ago
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.
- JamesLeonis 10y ago
  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.
melling 10y ago
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?
- beefydude 10y ago
  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.
- hacker_9 10y ago
  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 https://gist.github.com/olmobrutall/31d2abafe0b21b017d56
  - smoothdeveloper 10y ago
    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 :)
  - hvidgaard 10y ago
    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.
- ktRolster 10y ago
  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.
  - melling 10y ago
    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?
    - ktRolster 10y ago
      I can't think of any change in C# that I would make that would really be worth the effort.
      - louthy 10y ago
        Non-nullable references (by default), as mentioned above. That would be huge, and worth any amount of hit.
        ktRolster 10y ago
        > 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?
        louthy 10y ago
        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 https://en.wikipedia.org/wiki/Cyclomatic_complexity
- xenadu02 10y ago
  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.
  - pjmlp 10y ago
    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-generics-history-some-photos-from-feb-1999/ https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...
AnimalMuppet 10y ago
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.
- euyyn 10y ago
  Viewed from the other side, someone at Microsoft was probably pretty upset with you guys when he found out :)
  - jug 10y ago
    Given the NT code leak comments... yes ;)
- flukus 10y ago
  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.

vvanders 10y ago

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.

JamesLeonis 10y ago
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.

melling 10y ago

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?

beefydude 10y ago
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.
hacker_9 10y ago
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 https://gist.github.com/olmobrutall/31d2abafe0b21b017d56
- smoothdeveloper 10y ago
  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 :)
- hvidgaard 10y ago
  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.
ktRolster 10y ago
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.
- melling 10y ago
  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?
  - ktRolster 10y ago
    I can't think of any change in C# that I would make that would really be worth the effort.
    - louthy 10y ago
      Non-nullable references (by default), as mentioned above. That would be huge, and worth any amount of hit.
      - ktRolster 10y ago
        > 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?
        louthy 10y ago
        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 https://en.wikipedia.org/wiki/Cyclomatic_complexity
xenadu02 10y ago
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.
- pjmlp 10y ago
  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-generics-history-some-photos-from-feb-1999/ https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...

AnimalMuppet 10y ago

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.

euyyn 10y ago
Viewed from the other side, someone at Microsoft was probably pretty upset with you guys when he found out :)
- jug 10y ago
  Given the NT code leak comments... yes ;)
flukus 10y ago
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.