6 ms·

"However, type errors are also a class of error that is very very infrequently encountered as to a problem." As someone working every day in Python, this seems

"However, type errors are also a class of error that is very very infrequently encountered as to a problem." As someone working every day in Python, this seems mind-bogglingly divorced from reality. I don't know if you mean something far more restricted by "type error" but most of the errors I encounter - in my code, the code of my team, and the code of those on other teams, across several projects - are errors that would have been caught by the type checker in Haskell had I been writing similar code. Many of them would have been caught by the type checker in C.

mpdehaan2 12y ago
Hmm, that's curious, though I don't think it's ever a good idea to tell someone they are divorced by reality :) I think some types of developers are more likely to make type error mistakes, and it's likely I make other mistakes, sure. I've done a wide about of massively-open source projects, and it doesn't really come up. The times I pass the wrong object type simply doesn't happen. Do you use keyword arguments? These help a TON with argument order, and may be why you are having that problem.
- dgreensp 12y ago
  When I write code and tests in JavaScript, typically the tests turn up a few typos and "brain-os" in the code (that don't keep it from parsing). Many or most of these would be caught by the type-checker in statically-typed language. Maybe you don't "see" type errors because you consider them to be failures of test coverage, or you say, "That's not a bug, it's more of a typo?" Or you don't work on a shared codebase?
  - mpdehaan2 12y ago
    Neither. I don't make them often, and I do work in quite shared codebases - one of them had over 1000 contributors. I won't pretend I'm a better developer, I surely make other classes of mistakes, usually it's "I didn't consider the user scenario where this file didn't exist or the error path when this file has invalid contents should really raise a better exception than a generic stacktrace".
    - dllthomas 12y ago
      A static type checker could be of some help in both of those cases, if you use it well.
- dllthomas 12y ago
  "I don't think it's ever a good idea to tell someone they are divorced by reality :)" My statement was about the claim and about me - I meant to express (colorfully) the distance between the claim and my experience. I did not intend to cast aspersions on the claimant; I certainly apologize if I caused offense, though you seem to have taken it in good spirits regardless :) Back to the topic at hand: It sounds like you probably do consider a substantially narrower class of things "type errors" than I do. It is quite rare that I mix up arguments to a function. More commonly I see bad assumptions about the contents of a map, which is often a type error. The most common form of exception I see in Sentry seems to be "NoneType object has no attribute...", which is always a type error.
task_queue 12y ago
This. Python is strongly typed but the only runtime "checking" you get is the exception raised you try an operation on an object that doesn't implement an assumed interface. GvR supports optional type checking in Python and has written a few documents laying out its defense, so it is in the works.

mpdehaan2 12y ago

Hmm, that's curious, though I don't think it's ever a good idea to tell someone they are divorced by reality :) I think some types of developers are more likely to make type error mistakes, and it's likely I make other mistakes, sure. I've done a wide about of massively-open source projects, and it doesn't really come up. The times I pass the wrong object type simply doesn't happen. Do you use keyword arguments? These help a TON with argument order, and may be why you are having that problem.

dgreensp 12y ago
When I write code and tests in JavaScript, typically the tests turn up a few typos and "brain-os" in the code (that don't keep it from parsing). Many or most of these would be caught by the type-checker in statically-typed language. Maybe you don't "see" type errors because you consider them to be failures of test coverage, or you say, "That's not a bug, it's more of a typo?" Or you don't work on a shared codebase?
- mpdehaan2 12y ago
  Neither. I don't make them often, and I do work in quite shared codebases - one of them had over 1000 contributors. I won't pretend I'm a better developer, I surely make other classes of mistakes, usually it's "I didn't consider the user scenario where this file didn't exist or the error path when this file has invalid contents should really raise a better exception than a generic stacktrace".
  - dllthomas 12y ago
    A static type checker could be of some help in both of those cases, if you use it well.
dllthomas 12y ago
"I don't think it's ever a good idea to tell someone they are divorced by reality :)" My statement was about the claim and about me - I meant to express (colorfully) the distance between the claim and my experience. I did not intend to cast aspersions on the claimant; I certainly apologize if I caused offense, though you seem to have taken it in good spirits regardless :) Back to the topic at hand: It sounds like you probably do consider a substantially narrower class of things "type errors" than I do. It is quite rare that I mix up arguments to a function. More commonly I see bad assumptions about the contents of a map, which is often a type error. The most common form of exception I see in Sentry seems to be "NoneType object has no attribute...", which is always a type error.

task_queue 12y ago

This. Python is strongly typed but the only runtime "checking" you get is the exception raised you try an operation on an object that doesn't implement an assumed interface. GvR supports optional type checking in Python and has written a few documents laying out its defense, so it is in the works.