5 ms·

The author really needs to be complemented on rewriting swathes of code from Python to Haskell. In Google, in my project, we've had runtime errors in Python co

The author really needs to be complemented on rewriting swathes of code from Python to Haskell. In Google, in my project, we've had runtime errors in Python code, due to wrongly spelled variables(although that is a different problem), and type error, something a compiler would have caught. Strong type checking is something that I truly like about Haskell and OCaml, I'm reasonably convinced that once my program has passed the typechecker, it is logically correct. Though debugging in Haskell is truly a different ballgame altogether (I'm a Haskell noob). I'll stop here lest this turns into a flame war.

16s 14y ago
pylint can help with misspelled variables and type errors. I started using it recently and love it. I still love my C++ compiler though and would not trade it for anything else.
- riffraff 14y ago
  pyflakes also detects typos easily, and it's quite useful. In languages that don't catch anything you can usually still use tools for static verification. As another example, Java may let you get NullPointerException, but FindBugs detects a lot of those.
  - afrozenator 14y ago
    Wow thanks, I didn't know pyflakes. I knew pylint, but will make it more of a point to run it. I only occasionally need to code in Python, but when I have to, it is legacy code that I modify.
    - riffraff 14y ago
      glad to be helpful. Depending on your editor of choice, you can get integrated pyflakes/pyling/flake8, e.g. I use vim and the syntastic plugin which is great. This way, you get a bit of on the fly static checking without needing to remember command line tools/using vcs hooks, which is much more productive.
      - afrozenator 14y ago
        Will keep this in mind the next time around! Thanks again.
kingkilr 14y ago
I'm reasonably convinced that once my program has passed the typechecker, it is logically correct Yup, this is one of my favorite things about Haskell, that's how I know that http://bpaste.net/show/32033/ http://bpaste.net/show/32033/ is a totally correct program.
- dons 14y ago
  If you're hoping to catch a specification error, don't use a type like `Integer -> Integer`, which doesn't capture the specification except in a most general sense. Just as you should write good tests, that actually test for useful properties, so you should write good types -- and get useful proofs back from the compiler as a result.
  - kingkilr 14y ago
    I wasn't trying to catch the error of "program author is a moron who doesn't know the difference between Fibonacci and factorial". Were I trying to catch that error I would have been aware of it, and then much less likely to write the bug in the first place. This is a truism that is well accepted by testing proponents: which tests you write are incredibly important, and you need to write your tests first in order to avoid a curve fitting problem (so to speak). Any non-trivial test would have shown my function to be very broken, what type would you have used to represent that so it wouldn't compile?
    - dons 14y ago
      Numerical algorithms suffer from a paucity of types. So either you enrich your numerical type hierarchy, or you prove an implementation matches a model, e.g. for fibonacci http://stackoverflow.com/a/8434107/83805 http://stackoverflow.com/a/8434107/83805
      - kingkilr 14y ago
        I don't have a response to that, other than to say, now you know why I decided to write compilers instead of pursue a graduate degree in computer science.
pyre 14y ago
> we've had runtime errors in Python code, due to [...] > type error, something a compiler would have caught Are wrongly spelled variable names and type errors the only runtime errors that you get? If not what percentage are they? Personally, I think that people tend to obsess about the specific type of errors because the 'solution' (static-typing) is something that already exists, whereas there is not easy solution to other types of flaws.
- Peaker 14y ago
  In Python, there are a lot of errors like "NoneType has no attribute '...'", and those disappear too. Missing imports and redundant imports also go away. Lots of lots of invariants in the program can be encoded as types, too, so any bugs relating to them go away too. When you want parallelism, you get useful guarantees about not changing the deterministic result you had before you added parallelism. I used to use Python, but after Haskell, there's no way I'd go back...
  - pyre 14y ago
    > "NoneType has no attribute '...'" C is statically typed, but I can still attempt to dereference a null pointer. Static typing doesn't save me here, nor does the compiler, as it's possible for these issues to happen at runtime. This may be something that Haskell doesn't allow, but it's not something inherent to static-typing.
    - afrozenator 14y ago
      In static-typing's defense, C isn't as strictly typed as Haskell, a pointer (and therefore null) is just basically an integer. But I totally agree, static typing is no cure for a wrong program. With power/expressiveness also comes a great ability to goof up.
    - Peaker 14y ago
      Static typing can alleviate that, and that's how Haskell does. The problem with C is that nullability is not statically typed.

16s 14y ago

pylint can help with misspelled variables and type errors. I started using it recently and love it. I still love my C++ compiler though and would not trade it for anything else.

riffraff 14y ago
pyflakes also detects typos easily, and it's quite useful. In languages that don't catch anything you can usually still use tools for static verification. As another example, Java may let you get NullPointerException, but FindBugs detects a lot of those.
- afrozenator 14y ago
  Wow thanks, I didn't know pyflakes. I knew pylint, but will make it more of a point to run it. I only occasionally need to code in Python, but when I have to, it is legacy code that I modify.
  - riffraff 14y ago
    glad to be helpful. Depending on your editor of choice, you can get integrated pyflakes/pyling/flake8, e.g. I use vim and the syntastic plugin which is great. This way, you get a bit of on the fly static checking without needing to remember command line tools/using vcs hooks, which is much more productive.
    - afrozenator 14y ago
      Will keep this in mind the next time around! Thanks again.

kingkilr 14y ago

I'm reasonably convinced that once my program has passed the typechecker, it is logically correct Yup, this is one of my favorite things about Haskell, that's how I know that http://bpaste.net/show/32033/ http://bpaste.net/show/32033/ is a totally correct program.

dons 14y ago
If you're hoping to catch a specification error, don't use a type like `Integer -> Integer`, which doesn't capture the specification except in a most general sense. Just as you should write good tests, that actually test for useful properties, so you should write good types -- and get useful proofs back from the compiler as a result.
- kingkilr 14y ago
  I wasn't trying to catch the error of "program author is a moron who doesn't know the difference between Fibonacci and factorial". Were I trying to catch that error I would have been aware of it, and then much less likely to write the bug in the first place. This is a truism that is well accepted by testing proponents: which tests you write are incredibly important, and you need to write your tests first in order to avoid a curve fitting problem (so to speak). Any non-trivial test would have shown my function to be very broken, what type would you have used to represent that so it wouldn't compile?
  - dons 14y ago
    Numerical algorithms suffer from a paucity of types. So either you enrich your numerical type hierarchy, or you prove an implementation matches a model, e.g. for fibonacci http://stackoverflow.com/a/8434107/83805 http://stackoverflow.com/a/8434107/83805
    - kingkilr 14y ago
      I don't have a response to that, other than to say, now you know why I decided to write compilers instead of pursue a graduate degree in computer science.

pyre 14y ago

> we've had runtime errors in Python code, due to [...] > type error, something a compiler would have caught Are wrongly spelled variable names and type errors the only runtime errors that you get? If not what percentage are they? Personally, I think that people tend to obsess about the specific type of errors because the 'solution' (static-typing) is something that already exists, whereas there is not easy solution to other types of flaws.

Peaker 14y ago
In Python, there are a lot of errors like "NoneType has no attribute '...'", and those disappear too. Missing imports and redundant imports also go away. Lots of lots of invariants in the program can be encoded as types, too, so any bugs relating to them go away too. When you want parallelism, you get useful guarantees about not changing the deterministic result you had before you added parallelism. I used to use Python, but after Haskell, there's no way I'd go back...
- pyre 14y ago
  > "NoneType has no attribute '...'" C is statically typed, but I can still attempt to dereference a null pointer. Static typing doesn't save me here, nor does the compiler, as it's possible for these issues to happen at runtime. This may be something that Haskell doesn't allow, but it's not something inherent to static-typing.
  - afrozenator 14y ago
    In static-typing's defense, C isn't as strictly typed as Haskell, a pointer (and therefore null) is just basically an integer. But I totally agree, static typing is no cure for a wrong program. With power/expressiveness also comes a great ability to goof up.
  - Peaker 14y ago
    Static typing can alleviate that, and that's how Haskell does. The problem with C is that nullability is not statically typed.