5 ms·

I think in the long run, python, ruby, js, etc are all bad ideas. You are solving high level problems with these languages, correctness should be the main prior

by foxes 7y ago

I think in the long run, python, ruby, js, etc are all bad ideas. You are solving high level problems with these languages, correctness should be the main priority. Realising that type checking is a good thing, then bolting it on, I feel is a crappy solution, when you should just use something designed better from the start. I completely disagree that there is a "productivity toll". If you dont know how to speak a language then obviously it seems difficult. I think you save time in the long run not dealing with all the type errors.

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.
        7y ago
  - 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.
h8hawk 7y ago
Type system's of typescript , mypy and julia are far better than type syatem's of java/c#/c++/go . Null safety, type inference, sanner generics, Union types, structural typing are come to mind. I think the reason is that these type systems should catch up expressiveness of their host language.
- sa46 7y ago
  > Type system's of typescript [...] are far better than type systems [than java] TypeScript's type system is far more powerful than Java's but I'm not sure that's a good thing. A lot of the concepts in TypeScript are necessary to paper over gratuitously dynamic APIs in JavaScript. While Java certainly has warts in its type system (no generics over primitives, arrays), Java's type system straight-forward compared to TypeScript. TypeScript stuffs a staggering amount of functionality into the type system. To name a few of the more esoteric features: literal types, const assertions, asserts modifier for type predicates.
  - dlbucci 7y ago
    I don't think literal types are esoteric at all, they are one of the most useful features of the type system, especially when combined with Union and intersection types. That functionality alone is why I miss TS so much when I switch over to Java land.

by foxes 7y ago

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.
        7y ago
- 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.

h8hawk 7y ago

Type system's of typescript , mypy and julia are far better than type syatem's of java/c#/c++/go . Null safety, type inference, sanner generics, Union types, structural typing are come to mind. I think the reason is that these type systems should catch up expressiveness of their host language.

sa46 7y ago
> Type system's of typescript [...] are far better than type systems [than java] TypeScript's type system is far more powerful than Java's but I'm not sure that's a good thing. A lot of the concepts in TypeScript are necessary to paper over gratuitously dynamic APIs in JavaScript. While Java certainly has warts in its type system (no generics over primitives, arrays), Java's type system straight-forward compared to TypeScript. TypeScript stuffs a staggering amount of functionality into the type system. To name a few of the more esoteric features: literal types, const assertions, asserts modifier for type predicates.
- dlbucci 7y ago
  I don't think literal types are esoteric at all, they are one of the most useful features of the type system, especially when combined with Union and intersection types. That functionality alone is why I miss TS so much when I switch over to Java land.