3 ms·

It feels like a few of those could actually be prevented with different language features/by the compiler: - `null` related errors: through algebraic data type

It feels like a few of those could actually be prevented with different language features/by the compiler: - `null` related errors: through algebraic data types like `Maybe` in Haskell or `Option` in Rust - Unused arguments in string formatting methods: I don't get why the compiler doesn't see this as an error

lmm 10y ago
I'd go further: that probably applies to all their checks. If you can formalize it enough to put it in an automated checker, why not put it in the language type system? Often these automated checkers end up having to keep track of a bunch of assertions about the input/output of the methods, sometimes even specified with annotations or magic comments - basically a second shadow type system. Just use in the types!
- thomasz 10y ago
  The appeal of those tools is that they allow you to retrofit more sophisticated safety features into existing lanugages, where a giant heap of existing code prohibits breaking changes.
  - lmm 10y ago
    I find it more effective to make the porting explicit - make a new language that has a really good FFI into the old language, and gradually migrate to that. (I tried to use the checkers framework for a few years, then instead started using Scala, which was much more effective)
    - emodendroket 10y ago
      Porting the C# compiler to Scala doesn't seem like it would constitute a real vote of confidence in the technology.
      - lmm 10y ago
        Porting it to F# would probably be more aligned to their business interests, and have much the same effect. Actually MS has been pretty good at cherry-picking parts of F# and including them in newer releases of C#, so simply "porting" it to "modern C#" would provide at least some of the benefits (though there's only so much that can be achieved without a willingness to outright deprecate features that now have a better replacement). (You still need a linter to check for use of deprecated features, but that can be a very simple thing; what I'm saying doesn't make sense is sophisticated (and expensive) static analysis tools)
- legulere 10y ago
  Static analyzers often also find issues that look suspicious and indicate that there's an error but don't have to really be an error. For instance here the check for variables that are always true. Another issues is that some analyses of static analyzers are too costly to do by the compiler.

lmm 10y ago

I'd go further: that probably applies to all their checks. If you can formalize it enough to put it in an automated checker, why not put it in the language type system? Often these automated checkers end up having to keep track of a bunch of assertions about the input/output of the methods, sometimes even specified with annotations or magic comments - basically a second shadow type system. Just use in the types!

thomasz 10y ago
The appeal of those tools is that they allow you to retrofit more sophisticated safety features into existing lanugages, where a giant heap of existing code prohibits breaking changes.
- lmm 10y ago
  I find it more effective to make the porting explicit - make a new language that has a really good FFI into the old language, and gradually migrate to that. (I tried to use the checkers framework for a few years, then instead started using Scala, which was much more effective)
  - emodendroket 10y ago
    Porting the C# compiler to Scala doesn't seem like it would constitute a real vote of confidence in the technology.
    - lmm 10y ago
      Porting it to F# would probably be more aligned to their business interests, and have much the same effect. Actually MS has been pretty good at cherry-picking parts of F# and including them in newer releases of C#, so simply "porting" it to "modern C#" would provide at least some of the benefits (though there's only so much that can be achieved without a willingness to outright deprecate features that now have a better replacement). (You still need a linter to check for use of deprecated features, but that can be a very simple thing; what I'm saying doesn't make sense is sophisticated (and expensive) static analysis tools)
legulere 10y ago
Static analyzers often also find issues that look suspicious and indicate that there's an error but don't have to really be an error. For instance here the check for variables that are always true. Another issues is that some analyses of static analyzers are too costly to do by the compiler.