6 ms·

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 compatibi

by 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...

by melling 10y ago

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...