5 ms·

>> “ I think you save time in the long run not dealing with all the type errors.” Have you written and deployed production code in the languages you mention ab

by jtdev 7y ago

>> “ I think you save time in the long run not dealing with all the type errors.” Have you written and deployed production code in the languages you mention above? Did you encounter a substantial number of type errors?

staticassertion 7y ago
There is no good definition of a type error. It certainly goes beyond TypeError(Exception). Is a '.close()' method being called twice a type error? It is in a language that can express states in the type system. Is SQL injection a type error? It is when you use refined types in your sql library interface. The vast, vast majority of errors I run into are errors that, with effort and the right type system, I could turn into type errors. The point being that asking "would those be type errors?" is a really big question that is, when answered simply, "yes".
- mixmastamyk 7y ago
  There aren't any mainstream languages that have the ability to detect the ultra high-level errors you describe. Maybe typescript is getting better. Pyflakes and unit tests will detect the great majority of potential errors. Mypy gets you closer to zero.
  - staticassertion 7y ago
    Rust can express state machines just fine, as well as refinement types (Python can do refinement types too), but yes, I agree that there's room for languages to build more ergonomic but advanced type systems.
  - yawaramin 7y ago
    There are very usable, well-supported languages out there right now that do have such type systems. Saying they're out of consideration because they're not mainstream is a circular argument.
    - coldtea 7y ago
      >Saying they're out of consideration because they're not mainstream is a circular argument. No, it's a pragmatic argument. There's no circularity it. If they're not mainstream, then they're neither "very usable" or "well-supported" to any extend that a mainstream language would be.
      - yawaramin 7y ago
        Here's the circularity: - There are no mainstream languages with powerful and convenient type systems - But there are less mainstream ones - But I won't use those - There are no mainstream languages with powerful and convenient type systems
        coldtea 7y ago
        That's circularity alright, but not as in a "circular argument" though. It's a feedback loop. That's however a totally legitimate engineering choice. Engineers picking on a language shouldn't bet on less mainstream incomplete environments with less tooling and libs and options and devs, just so that they can raise them into the mainstream. That might be a "tragedy of the commons" thing, but it's not an engineering obligation to be an early adopter.
        yawaramin 7y ago
        They're not obligated to by early adopters, but then you hear comments like: > There aren't any mainstream languages that have the ability to detect the ultra high-level errors you describe. And it's like, well there are great languages that can do that, but if you restrict yourself to that tiny 'mainstream' subset, you'll never know it. And moreover I think engineers (or rather, companies) are way too conservative about this stuff–picking 'mainstream' tech can be a touch-and-go proposition at any time. Just because something is mainstream, doesn't mean it's the right choice for your project.
  - viraptor 7y ago
    close() is partially handled by any language with scoped resources. There's lots of them. Injections are handled by any language with taint, although that became less popular. Perl had it. Anything with typed orm also has something similar (for example Esqueleto in Haskell)
- mantap 7y ago
  Both of those errors can also be addressed by better code, e.g. you can use lambdas to make sure things get autoclosed if there's no with/using construct. And you can avoid SQL injection by using query string interpolation instead of string concatenation, or parameter bindings.
  - staticassertion 7y ago
    I don't really see your point. Types can prove the absence of those bugs. "Writing good code" is not... anything.
    - mantap 7y ago
      Neither of the examples given need types if good interfaces to those functions are chosen. Since types are part of the interface then why wouldn't you just change the interface to not exhibit those bugs rather than using types to prop up a bad one?
      - staticassertion 7y ago
        How would an interface guarantee that close is not called twice, or that you have escaped a string exactly once?
        mantap 7y ago
        I have rarely needed to escape a SQL string since the days of PHP4, nowadays it is standard to use parameter binding such as "SELECT * FROM table WHERE row = ?" - it's also faster since the query doesn't need to be recompiled every time, but if you really have a desire to escape SQL then you can write a string interpolation function that does it automatically e.g. sql_format("SELECT * FROM table WHERE foo = %s", s). Indeed, JavaScript supports this via custom templated string literals. As for closing resources, you can use a pattern such as using(open("file.txt"), (f) => { ... }) if your language doesn't already support such a construct.
        7y ago
patrec 7y ago
In my case: Yes and yes. Wildly guessing, about 90% of the errors I find at runtime with dynamic languages would would be caught by a sane type system at compile time. If I'm comparing a completely mis-engineered statically typed language such as C++, the compilation overhead may be so bad that for code I'm writing right now feedback can still be faster with the dynamically typed language. But if we're talking interfacing a few bits of unfamiliar and not great dynamically typed code: well I've literally spent several weeks on a project that would have taken me half a day with even bad static typing.
- mixmastamyk 7y ago
  Pyflakes and a test or two will weed out trivial errors right away. Getting to zero errors takes more work however and that's where mypy has a place.
  - viraptor 7y ago
    Unfortunately tests in dynamic languages often don't help. I've run into too many issues where dependencies were mocked with parameters the dev thought were expected. (Or were expected in previous version of some library) With time, it all falls apart without real interface checks.
    - mixmastamyk 7y ago
      Mypy can apply to tests as well. I don't have any noticeably buggy Python programs and have written more than I can count. All this tooling is a great help but is no substitute for minimum of competence and attention. It's when you want to add features to a codebase you don't understand, when these features shine.

by jtdev 7y ago

staticassertion 7y ago

There is no good definition of a type error. It certainly goes beyond TypeError(Exception). Is a '.close()' method being called twice a type error? It is in a language that can express states in the type system. Is SQL injection a type error? It is when you use refined types in your sql library interface. The vast, vast majority of errors I run into are errors that, with effort and the right type system, I could turn into type errors. The point being that asking "would those be type errors?" is a really big question that is, when answered simply, "yes".

mixmastamyk 7y ago
There aren't any mainstream languages that have the ability to detect the ultra high-level errors you describe. Maybe typescript is getting better. Pyflakes and unit tests will detect the great majority of potential errors. Mypy gets you closer to zero.
- staticassertion 7y ago
  Rust can express state machines just fine, as well as refinement types (Python can do refinement types too), but yes, I agree that there's room for languages to build more ergonomic but advanced type systems.
- yawaramin 7y ago
  There are very usable, well-supported languages out there right now that do have such type systems. Saying they're out of consideration because they're not mainstream is a circular argument.
  - coldtea 7y ago
    >Saying they're out of consideration because they're not mainstream is a circular argument. No, it's a pragmatic argument. There's no circularity it. If they're not mainstream, then they're neither "very usable" or "well-supported" to any extend that a mainstream language would be.
    - yawaramin 7y ago
      Here's the circularity: - There are no mainstream languages with powerful and convenient type systems - But there are less mainstream ones - But I won't use those - There are no mainstream languages with powerful and convenient type systems
      - coldtea 7y ago
        That's circularity alright, but not as in a "circular argument" though. It's a feedback loop. That's however a totally legitimate engineering choice. Engineers picking on a language shouldn't bet on less mainstream incomplete environments with less tooling and libs and options and devs, just so that they can raise them into the mainstream. That might be a "tragedy of the commons" thing, but it's not an engineering obligation to be an early adopter.
        yawaramin 7y ago
        They're not obligated to by early adopters, but then you hear comments like: > There aren't any mainstream languages that have the ability to detect the ultra high-level errors you describe. And it's like, well there are great languages that can do that, but if you restrict yourself to that tiny 'mainstream' subset, you'll never know it. And moreover I think engineers (or rather, companies) are way too conservative about this stuff–picking 'mainstream' tech can be a touch-and-go proposition at any time. Just because something is mainstream, doesn't mean it's the right choice for your project.
- viraptor 7y ago
  close() is partially handled by any language with scoped resources. There's lots of them. Injections are handled by any language with taint, although that became less popular. Perl had it. Anything with typed orm also has something similar (for example Esqueleto in Haskell)
mantap 7y ago
Both of those errors can also be addressed by better code, e.g. you can use lambdas to make sure things get autoclosed if there's no with/using construct. And you can avoid SQL injection by using query string interpolation instead of string concatenation, or parameter bindings.
- staticassertion 7y ago
  I don't really see your point. Types can prove the absence of those bugs. "Writing good code" is not... anything.
  - mantap 7y ago
    Neither of the examples given need types if good interfaces to those functions are chosen. Since types are part of the interface then why wouldn't you just change the interface to not exhibit those bugs rather than using types to prop up a bad one?
    - staticassertion 7y ago
      How would an interface guarantee that close is not called twice, or that you have escaped a string exactly once?
      - mantap 7y ago
        I have rarely needed to escape a SQL string since the days of PHP4, nowadays it is standard to use parameter binding such as "SELECT * FROM table WHERE row = ?" - it's also faster since the query doesn't need to be recompiled every time, but if you really have a desire to escape SQL then you can write a string interpolation function that does it automatically e.g. sql_format("SELECT * FROM table WHERE foo = %s", s). Indeed, JavaScript supports this via custom templated string literals. As for closing resources, you can use a pattern such as using(open("file.txt"), (f) => { ... }) if your language doesn't already support such a construct.
        7y ago

patrec 7y ago

In my case: Yes and yes. Wildly guessing, about 90% of the errors I find at runtime with dynamic languages would would be caught by a sane type system at compile time. If I'm comparing a completely mis-engineered statically typed language such as C++, the compilation overhead may be so bad that for code I'm writing right now feedback can still be faster with the dynamically typed language. But if we're talking interfacing a few bits of unfamiliar and not great dynamically typed code: well I've literally spent several weeks on a project that would have taken me half a day with even bad static typing.

mixmastamyk 7y ago
Pyflakes and a test or two will weed out trivial errors right away. Getting to zero errors takes more work however and that's where mypy has a place.
- viraptor 7y ago
  Unfortunately tests in dynamic languages often don't help. I've run into too many issues where dependencies were mocked with parameters the dev thought were expected. (Or were expected in previous version of some library) With time, it all falls apart without real interface checks.
  - mixmastamyk 7y ago
    Mypy can apply to tests as well. I don't have any noticeably buggy Python programs and have written more than I can count. All this tooling is a great help but is no substitute for minimum of competence and attention. It's when you want to add features to a codebase you don't understand, when these features shine.