4 ms·

Yes, it’s possible for programmers to write bugs.

by louthy 9y ago

lmm 9y ago
Well if you don't care about type safety then there's no point caring about any typesystem features, since you can emulate them by replacing all of your types with "any".
- louthy 9y ago
  Sorry, where on earth did I say I don’t care about type safety? Why do you need to take this point to a total extreme? I simply gave an example of why the comment about mempty was wrong; but now I have to defend C#’s type system? Clearly C#’s lack of type inference, sanctioned ad-hoc polymorphism (even though it can’t be achieved in the way I have shown), and higher kinds makes it less expressive as a language. I’m not going to argue that point. But this kind of language holy war is frankly pathetic. Attacking every detail of an implementation (that works) is unnecessary. Yes, it’s easier to get null reference exceptions in C# compared to Haskell. That is the result of poor decisions made when the language was designed. So, yes, today I will use ad hoc polymorphic techniques and yes I will have to make sure I constrain to structs, that’s life.
  - lmm 9y ago
    > Sorry, where on earth did I say I don’t care about type safety? Why do you need to take this point to a total extreme? I simply gave an example of why the comment about mempty was wrong; but now I have to defend C#’s type system? If you're going to dismiss safety issues in your approach with "Yes, it’s possible for programmers to write bugs." then there's no point having the conversation, because that's an equally good argument for not having a type system at all. > But this kind of language holy war is frankly pathetic. Attacking every detail of an implementation (that works) is unnecessary. It's not a "detail", if you can't do it safely then that undermines the point of doing it at all. If we were willing to be unsafe we could just cast to the desired type. > Yes, it’s easier to get null reference exceptions in C# compared to Haskell. That is the result of poor decisions made when the language was designed. So, yes, today I will use ad hoc polymorphic techniques and yes I will have to make sure I constrain to structs, that’s life. I'd sooner pass the module dictionary explicitly, like one does in ML, than adopt a technique that would normalize having "default(...)" in my codebase.
    - louthy 9y ago
      > If you're going to dismiss safety issues in your approach with "Yes, it’s possible for programmers to write bugs." then there's no point having the conversation, because that's an equally good argument for not having a type system at all. Absolute nonsense. I didn't dismiss safety issues at all. I dismissed your claim that having to specify a `struct` constraint somehow makes the feature unworthy. C# has null, that's a fact of life, it's not dismissive to realise that a (granted, very annoying) part of the job of writing C# is dealing with null. So, using this doesn't make this technique any less safe than any other way of writing code in C#. So, yes, programmers will occasionally write null-dereference bugs in C# - that's the price we pay for bad language implementation decisions. Stating "that's an equally good argument for not having a type system at all." is clearly hyperbolic nonsense. > If we were willing to be unsafe we could just cast to the desired type. But it isn't unsafe! Not specifying a `struct` constraint is a bug. If you provide the constraint then it's safe. Trying to compare that to a dynamic cast where you have no type-system enforcement to one where you do is just idiotic. > I'd sooner pass the module dictionary explicitly, like one does in ML, than adopt a technique that would normalize having "default(...)" in my codebase. At no point was this trying to force you to use this technique. It was a reply to "Once you've got return type polymorphism, you really start to miss it in other languages. The simplest example possible is mempty". I use this technique very successfully a lot, and the exact mechanism (of using `default`) is in the process of being wrapped up into a new type-classes grammar for C# [1]. So, I guess you'd probably prefer to wait for that... [1] https://github.com/MattWindsor91/roslyn/blob/master/concepts/docs/csconcepts.md https://github.com/MattWindsor91/roslyn/blob/master/concepts...
      - lmm 9y ago
        > C# has null, that's a fact of life, it's not dismissive to realise that a (granted, very annoying) part of the job of writing C# is dealing with null. So, using this doesn't make this technique any less safe than any other way of writing code in C#. If using this technique requires breaking one of the rules that you have to follow to avoid getting nulls in C# then the technique is a safety problem. > Not specifying a `struct` constraint is a bug. If you provide the constraint then it's safe. Ok, but how do you enforce that? If you've got a technique that requires manual review and reasoning at a distance to use safely, then again we're no better off than we would be using dynamic casts. > At no point was this trying to force you to use this technique. It was a reply to "Once you've got return type polymorphism, you really start to miss it in other languages. The simplest example possible is mempty". If you don't have a typesystem feature in a safe way, you don't have it.

Yes, it’s possible for programmers to write bugs.

by louthy 9y ago

Yes, it’s possible for programmers to write bugs.

lmm 9y ago

Well if you don't care about type safety then there's no point caring about any typesystem features, since you can emulate them by replacing all of your types with "any".

louthy 9y ago
Sorry, where on earth did I say I don’t care about type safety? Why do you need to take this point to a total extreme? I simply gave an example of why the comment about mempty was wrong; but now I have to defend C#’s type system? Clearly C#’s lack of type inference, sanctioned ad-hoc polymorphism (even though it can’t be achieved in the way I have shown), and higher kinds makes it less expressive as a language. I’m not going to argue that point. But this kind of language holy war is frankly pathetic. Attacking every detail of an implementation (that works) is unnecessary. Yes, it’s easier to get null reference exceptions in C# compared to Haskell. That is the result of poor decisions made when the language was designed. So, yes, today I will use ad hoc polymorphic techniques and yes I will have to make sure I constrain to structs, that’s life.
- lmm 9y ago
  > Sorry, where on earth did I say I don’t care about type safety? Why do you need to take this point to a total extreme? I simply gave an example of why the comment about mempty was wrong; but now I have to defend C#’s type system? If you're going to dismiss safety issues in your approach with "Yes, it’s possible for programmers to write bugs." then there's no point having the conversation, because that's an equally good argument for not having a type system at all. > But this kind of language holy war is frankly pathetic. Attacking every detail of an implementation (that works) is unnecessary. It's not a "detail", if you can't do it safely then that undermines the point of doing it at all. If we were willing to be unsafe we could just cast to the desired type. > Yes, it’s easier to get null reference exceptions in C# compared to Haskell. That is the result of poor decisions made when the language was designed. So, yes, today I will use ad hoc polymorphic techniques and yes I will have to make sure I constrain to structs, that’s life. I'd sooner pass the module dictionary explicitly, like one does in ML, than adopt a technique that would normalize having "default(...)" in my codebase.
  - louthy 9y ago
    > If you're going to dismiss safety issues in your approach with "Yes, it’s possible for programmers to write bugs." then there's no point having the conversation, because that's an equally good argument for not having a type system at all. Absolute nonsense. I didn't dismiss safety issues at all. I dismissed your claim that having to specify a `struct` constraint somehow makes the feature unworthy. C# has null, that's a fact of life, it's not dismissive to realise that a (granted, very annoying) part of the job of writing C# is dealing with null. So, using this doesn't make this technique any less safe than any other way of writing code in C#. So, yes, programmers will occasionally write null-dereference bugs in C# - that's the price we pay for bad language implementation decisions. Stating "that's an equally good argument for not having a type system at all." is clearly hyperbolic nonsense. > If we were willing to be unsafe we could just cast to the desired type. But it isn't unsafe! Not specifying a `struct` constraint is a bug. If you provide the constraint then it's safe. Trying to compare that to a dynamic cast where you have no type-system enforcement to one where you do is just idiotic. > I'd sooner pass the module dictionary explicitly, like one does in ML, than adopt a technique that would normalize having "default(...)" in my codebase. At no point was this trying to force you to use this technique. It was a reply to "Once you've got return type polymorphism, you really start to miss it in other languages. The simplest example possible is mempty". I use this technique very successfully a lot, and the exact mechanism (of using `default`) is in the process of being wrapped up into a new type-classes grammar for C# [1]. So, I guess you'd probably prefer to wait for that... [1] https://github.com/MattWindsor91/roslyn/blob/master/concepts/docs/csconcepts.md https://github.com/MattWindsor91/roslyn/blob/master/concepts...
    - lmm 9y ago
      > C# has null, that's a fact of life, it's not dismissive to realise that a (granted, very annoying) part of the job of writing C# is dealing with null. So, using this doesn't make this technique any less safe than any other way of writing code in C#. If using this technique requires breaking one of the rules that you have to follow to avoid getting nulls in C# then the technique is a safety problem. > Not specifying a `struct` constraint is a bug. If you provide the constraint then it's safe. Ok, but how do you enforce that? If you've got a technique that requires manual review and reasoning at a distance to use safely, then again we're no better off than we would be using dynamic casts. > At no point was this trying to force you to use this technique. It was a reply to "Once you've got return type polymorphism, you really start to miss it in other languages. The simplest example possible is mempty". If you don't have a typesystem feature in a safe way, you don't have it.