7 ms·

But with a statically typed language, you don't need to go through that code -> launch -> test cycle as often because everything is type-safe.

deleted 9y ago
[deleted]
hpcjoe 9y ago
Uh ... no. Type safety is rarely a problem from my personal experience (YMMV) in code dev. The issues I run across have to do with whether or not the code is an accurate reflection of the algorithm in question, or even if the algorithm itself is correct, if core assumptions are correct, dealing with corner cases, etc. Types rarely have anything constructive to add to this mix, regardless of whether or not I am working in a weakly/non-typed language, or strongly typed language. I personally tend to do something much closer to TDD, and break my code out so I test each part with its own test rig. So I see when I do dumb things that need re-work. Again, typing is pretty much never an issue there. While this is all anecdotal, I personally have found that enforcing boilerplate type defs actually increases my coding error rate. More LOC gives you more opportunities for errors. FWIW, Julia (http://julialang.org http://julialang.org) is IMO Python done right, and it is strongly typed. But done in such a way as to not actually get in your way most of the time. Like Python it has a great REPL, fantastic FFI, rapidly growing module list, very active development. Unlike Python, it has no issues with whitespace[1], is compiled (JIT for now, though static is planned from what I understand), is very fast, has multiple dispatch and a strong typing system. The real point the article was making is, programmer time is the most valuable thing to optimize for. I completely agree with this, even though I disagree that Python is the right tool for (most) every job. There are better tools IMO, which allow me to be far more productive, and spend as little time as possible on worrying about types ... which are rarely ever a concern for me. I thought his comment about string processing was interesting, though he completely ignored Perl in the mix. I've found string processing in Perl to be almost trivial. Its harder (far more verbose boilerplate) in Python, and gets worse in other languages. Perl6 lets you embed grammars and write parsers without resorting to external modules (Marpa::* in Perl5). Takes building string processing, parsers, etc. to a whole new level, while making you even more productive. But, as the author had noted, he is a pythonista. Everyone has their biases (including me). I want to code correctly quickly, and not have things that shouldn't get in my way, get in my way. Including type systems, massive boilerplate/odd syntax rules, etc. [1] It is 2017 ... structure by indentation is somehow, still a thing. It shouldn't be IMO.
- marcosdumay 9y ago
  I was about to ask you what kind of statically typed languages you were using that gave you this impression. But... "boilerplate type defs". Yeah, C++ typing system sucks. Just don't think this generalizes to other languages.
  - falcolas 9y ago
    Well, let's see. Go: map[string]int64 Java: HashMap<String, long> Rust: HashMap<&str, i64> I think Haskell is one of the only statically typed languages which doesn't really care about algebraic typing. And yes, if you're talking about static typing, you get the baggage of dealing with algebraic typing to go with it as a rule. You can't arbitrarily separate the two until more languages follow Haskell's route.
  - hpcjoe 9y ago
    It's not just C++ though. If I have to add logic to my code to handle explicit type changes (casting, et al.) for something that, honestly, is not important to my algorithm, then this increases the likelihood that I will make a type/casting/conversion error. OTOH, a language smart enough to (correctly) infer this (Perl, Julia, etc.) generally won't have a problem with this, and will handle these issues for you. Julia still allows you to be very explicit on type, and force a hard type specialized code. The benefit in this case, with type specialization, is that it can generate far more efficient code for the specific logic. That latter argument is, to me, the only real benefit of typing systems that I've personally encountered. I know people throw studies around claiming "fewer errors with stronger type systems", but ... to be honest ... I have not experienced this. Rather, in stronger typed languages, I spend more time hunting down type impedance issues than logic issues. This seems to not be a positive benefit to me. I may be alone in this regard, or not. I don't know. I do know that, like programming languages, editors, operating systems, this view point (pro/anti strong typing) tends to take on a religious overtone in the sense of people taking a position and digging their heels in over this. Elevating this aspect as an important point in an overall platform decision process (what should we develop in), when, maybe, it shouldn't be. In an odd way, I've seen this in the industry for a while. There were previous incarnations of this. Like Dijkstra's famous "goto" comments[1]. I don't necessarily agree with this, and I argue that people can write bad code in any language. Typing systems ostensibly are there to help us write less bad code (all code is bad and buggy, anyone telling you otherwise is trying to sell you some swampland). But once they get in your way, and you start spending inordinate amounts of time dealing with typing issues, you have to ask whether or not they are helping or inhibiting. Put another way, anything that helps should, actually help, without adding significantly to the burden. Apart from what Julia does, and other dynamic languages do ... that some people write great code in ... I've not seen/used many other systems that strive to get out of your way while working. Typing systems do not automatically make code better. Absence of typing systems do not automatically make code worse. This is a function of the algorithm, the implementation logic, etc. How disciplined are you as the developer in making sure your code is clear, concise, and actually reflective of the problem you are attempting to solve ... things that help with that are welcome. [1] http://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf http://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pd...
hellofunk 9y ago
You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed. Languages that have a sophisticated contract system* (like Clojure's Clojure.spec library) have a bit of a leg up in my opinion. You can much more precisely explain and control and test for the specifics of all values flowing through your system well beyond merely what type they are. -- * Clojure's devs don't refer to spec as a contract system because it is quite a bit more versatile than that, and some are actually using it for compile-time checks, compile-time generative testing, and other nifty things that aren't covered by a "contract" system.
- LeonidasXIV 9y ago
  > You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Of course it can. The idea behind a decent type system is to make illegal states unrepresentable. You define a type which contains a value between 0 and 1 (lets name it `probability`) and make a function `float -> probability` which checks the range. That way, everytime you'll see `probability` in your code, you will know it is in the right range. The problem with spec is that it can only verify what it sees on run time, whereas a static type system by definition has 100% coverage over your entire program.
  - hellofunk 9y ago
    You are talking about a function (at runtime), not a type, verifying the range. And you can do that in any language, regardless of its stance on typing.
    - Jtsummers 9y ago
      http://www.adaic.org/resources/add_content/standards/05aarm/html/AA-3-5-7.html http://www.adaic.org/resources/add_content/standards/05aarm/... Compile-time and run-time floating point numbers constrained by precision and range. It's been a long time so I'm just going to include the examples in that document: type Coefficient is digits 10 range -1.0 .. 1.0; type Real is digits 8; type Mass is digits 7 range 0.0 .. 1.0E35; subtype Probability is Real range 0.0 .. 1.0; These will be checked (to the limits of the ability of the system) at compile-time, and by default enforced at run-time. You can disable the run-time checks if you want for the sake of performance. The compile-time checks will "fail" to detect things where computations beyond the compiler's ability to reason might produce an invalid value.
msla 9y ago
That falls down because most static languages have "representational types", not "semantic types". Here's a post of mine on the topic: https://news.ycombinator.com/item?id=15144364 https://news.ycombinator.com/item?id=15144364
simonh 9y ago
I do occasionally get problems in Python due to typing issues, but it's pretty infrequent. Nowhere near often enough to care about all that much.
kazinator 9y ago
I recently found and fixed a 5 1/2 year old bug that was caused by a caller assuming that an integer parameter is an absolute quantity, but the function treated it as a delta. (The really funny thing is that the commit which introduced this bug introduced both that function and the incorrect call to it; and then, for the next 5 1/2 years after that, subsequent new uses of the function elsewhere in the code all correctly use its argument!) The expressions x - y and y - x often have exactly the same type tree, but calculate a different value. Same with f(x, y) and f(y, x) when the parameter types are the same. To actually catch real bugs such as this with types, you have to make such a fine grained use of types that programming becomes nigh intractable. If x has type minuend<integer> and y has type subtrahend<integer> then, x - y is well typed, whereas y - x isn't. Problem is, the values come from some other context in which their minuend and subtrahend are meaningless (and, in any case, are not involved). The kinds of errors that are found by static typing in practice are those that, under dynamic typing, will only sneak into production if the code is not tested at all. I.e. if the code had been executed even once with any inputs, the problem would have showed up. Plus, if you assume that "dynamically typed" language means "language with no static checks", you're arguing against a strawman of dynamic typing. That is even more ridiculous if you're pitting True Scotsman's state-of-the-art static typing against this dynamic strawman. (Of course, some dynamic languages in widespread use do more or less look like that strawman; however, the best examples of dynamic typing are languages which are considerably informed about type prior to executing a program, like the SBCL dialect of Common Lisp, for instance.)
- AstralStorm 9y ago
  This is why we should really push for automatic logic checkers and proper support of programming by contract.
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]

deleted 9y ago

[deleted]

hpcjoe 9y ago

Uh ... no. Type safety is rarely a problem from my personal experience (YMMV) in code dev. The issues I run across have to do with whether or not the code is an accurate reflection of the algorithm in question, or even if the algorithm itself is correct, if core assumptions are correct, dealing with corner cases, etc. Types rarely have anything constructive to add to this mix, regardless of whether or not I am working in a weakly/non-typed language, or strongly typed language. I personally tend to do something much closer to TDD, and break my code out so I test each part with its own test rig. So I see when I do dumb things that need re-work. Again, typing is pretty much never an issue there. While this is all anecdotal, I personally have found that enforcing boilerplate type defs actually increases my coding error rate. More LOC gives you more opportunities for errors. FWIW, Julia (http://julialang.org http://julialang.org) is IMO Python done right, and it is strongly typed. But done in such a way as to not actually get in your way most of the time. Like Python it has a great REPL, fantastic FFI, rapidly growing module list, very active development. Unlike Python, it has no issues with whitespace[1], is compiled (JIT for now, though static is planned from what I understand), is very fast, has multiple dispatch and a strong typing system. The real point the article was making is, programmer time is the most valuable thing to optimize for. I completely agree with this, even though I disagree that Python is the right tool for (most) every job. There are better tools IMO, which allow me to be far more productive, and spend as little time as possible on worrying about types ... which are rarely ever a concern for me. I thought his comment about string processing was interesting, though he completely ignored Perl in the mix. I've found string processing in Perl to be almost trivial. Its harder (far more verbose boilerplate) in Python, and gets worse in other languages. Perl6 lets you embed grammars and write parsers without resorting to external modules (Marpa::* in Perl5). Takes building string processing, parsers, etc. to a whole new level, while making you even more productive. But, as the author had noted, he is a pythonista. Everyone has their biases (including me). I want to code correctly quickly, and not have things that shouldn't get in my way, get in my way. Including type systems, massive boilerplate/odd syntax rules, etc. [1] It is 2017 ... structure by indentation is somehow, still a thing. It shouldn't be IMO.

marcosdumay 9y ago
I was about to ask you what kind of statically typed languages you were using that gave you this impression. But... "boilerplate type defs". Yeah, C++ typing system sucks. Just don't think this generalizes to other languages.
- falcolas 9y ago
  Well, let's see. Go: map[string]int64 Java: HashMap<String, long> Rust: HashMap<&str, i64> I think Haskell is one of the only statically typed languages which doesn't really care about algebraic typing. And yes, if you're talking about static typing, you get the baggage of dealing with algebraic typing to go with it as a rule. You can't arbitrarily separate the two until more languages follow Haskell's route.
- hpcjoe 9y ago
  It's not just C++ though. If I have to add logic to my code to handle explicit type changes (casting, et al.) for something that, honestly, is not important to my algorithm, then this increases the likelihood that I will make a type/casting/conversion error. OTOH, a language smart enough to (correctly) infer this (Perl, Julia, etc.) generally won't have a problem with this, and will handle these issues for you. Julia still allows you to be very explicit on type, and force a hard type specialized code. The benefit in this case, with type specialization, is that it can generate far more efficient code for the specific logic. That latter argument is, to me, the only real benefit of typing systems that I've personally encountered. I know people throw studies around claiming "fewer errors with stronger type systems", but ... to be honest ... I have not experienced this. Rather, in stronger typed languages, I spend more time hunting down type impedance issues than logic issues. This seems to not be a positive benefit to me. I may be alone in this regard, or not. I don't know. I do know that, like programming languages, editors, operating systems, this view point (pro/anti strong typing) tends to take on a religious overtone in the sense of people taking a position and digging their heels in over this. Elevating this aspect as an important point in an overall platform decision process (what should we develop in), when, maybe, it shouldn't be. In an odd way, I've seen this in the industry for a while. There were previous incarnations of this. Like Dijkstra's famous "goto" comments[1]. I don't necessarily agree with this, and I argue that people can write bad code in any language. Typing systems ostensibly are there to help us write less bad code (all code is bad and buggy, anyone telling you otherwise is trying to sell you some swampland). But once they get in your way, and you start spending inordinate amounts of time dealing with typing issues, you have to ask whether or not they are helping or inhibiting. Put another way, anything that helps should, actually help, without adding significantly to the burden. Apart from what Julia does, and other dynamic languages do ... that some people write great code in ... I've not seen/used many other systems that strive to get out of your way while working. Typing systems do not automatically make code better. Absence of typing systems do not automatically make code worse. This is a function of the algorithm, the implementation logic, etc. How disciplined are you as the developer in making sure your code is clear, concise, and actually reflective of the problem you are attempting to solve ... things that help with that are welcome. [1] http://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf http://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pd...

hellofunk 9y ago

You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed. Languages that have a sophisticated contract system* (like Clojure's Clojure.spec library) have a bit of a leg up in my opinion. You can much more precisely explain and control and test for the specifics of all values flowing through your system well beyond merely what type they are. -- * Clojure's devs don't refer to spec as a contract system because it is quite a bit more versatile than that, and some are actually using it for compile-time checks, compile-time generative testing, and other nifty things that aren't covered by a "contract" system.

LeonidasXIV 9y ago
> You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Of course it can. The idea behind a decent type system is to make illegal states unrepresentable. You define a type which contains a value between 0 and 1 (lets name it `probability`) and make a function `float -> probability` which checks the range. That way, everytime you'll see `probability` in your code, you will know it is in the right range. The problem with spec is that it can only verify what it sees on run time, whereas a static type system by definition has 100% coverage over your entire program.
- hellofunk 9y ago
  You are talking about a function (at runtime), not a type, verifying the range. And you can do that in any language, regardless of its stance on typing.
  - Jtsummers 9y ago
    http://www.adaic.org/resources/add_content/standards/05aarm/html/AA-3-5-7.html http://www.adaic.org/resources/add_content/standards/05aarm/... Compile-time and run-time floating point numbers constrained by precision and range. It's been a long time so I'm just going to include the examples in that document: type Coefficient is digits 10 range -1.0 .. 1.0; type Real is digits 8; type Mass is digits 7 range 0.0 .. 1.0E35; subtype Probability is Real range 0.0 .. 1.0; These will be checked (to the limits of the ability of the system) at compile-time, and by default enforced at run-time. You can disable the run-time checks if you want for the sake of performance. The compile-time checks will "fail" to detect things where computations beyond the compiler's ability to reason might produce an invalid value.

msla 9y ago

That falls down because most static languages have "representational types", not "semantic types". Here's a post of mine on the topic: https://news.ycombinator.com/item?id=15144364 https://news.ycombinator.com/item?id=15144364

simonh 9y ago

I do occasionally get problems in Python due to typing issues, but it's pretty infrequent. Nowhere near often enough to care about all that much.

kazinator 9y ago

I recently found and fixed a 5 1/2 year old bug that was caused by a caller assuming that an integer parameter is an absolute quantity, but the function treated it as a delta. (The really funny thing is that the commit which introduced this bug introduced both that function and the incorrect call to it; and then, for the next 5 1/2 years after that, subsequent new uses of the function elsewhere in the code all correctly use its argument!) The expressions x - y and y - x often have exactly the same type tree, but calculate a different value. Same with f(x, y) and f(y, x) when the parameter types are the same. To actually catch real bugs such as this with types, you have to make such a fine grained use of types that programming becomes nigh intractable. If x has type minuend<integer> and y has type subtrahend<integer> then, x - y is well typed, whereas y - x isn't. Problem is, the values come from some other context in which their minuend and subtrahend are meaningless (and, in any case, are not involved). The kinds of errors that are found by static typing in practice are those that, under dynamic typing, will only sneak into production if the code is not tested at all. I.e. if the code had been executed even once with any inputs, the problem would have showed up. Plus, if you assume that "dynamically typed" language means "language with no static checks", you're arguing against a strawman of dynamic typing. That is even more ridiculous if you're pitting True Scotsman's state-of-the-art static typing against this dynamic strawman. (Of course, some dynamic languages in widespread use do more or less look like that strawman; however, the best examples of dynamic typing are languages which are considerably informed about type prior to executing a program, like the SBCL dialect of Common Lisp, for instance.)

AstralStorm 9y ago
This is why we should really push for automatic logic checkers and proper support of programming by contract.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]