3 ms·

y tho. you can have safety and expressivity...

milesvp 9y ago
it's often not about expressivity, it's about conciseness. It's much easier to say a correct statement than it is to prove the statement correct. This seems to be the main cost to stongly typed static languages, all the time spent proving to the compiler that this thing is actually compatible with that thing.
- bad_user 9y ago
  What strongly typed static languages are you talking about? > proving to the compiler that this thing is actually compatible with that thing I used to have this opinion, but nowadays I think that time is actually spent proving to myself that I'm right, which is always a good thing. Having a compiler to do the hand holding is not such a bad thing, because the alternative is println-development. What happens in a dynamic language is that you have to load in your head the shape of the data your working with, the API and everything really. Your head can't hold that much for anything that is bigger than a simple script, so you have to constantly execute and verify (in the REPL, in the browser, with a unit test, etc) each line of code that you write, before writing the next line of code. This is why people complain about compilation speed in Scala, Haskell, etc, even if they miss they point, because even a slow, static compiler will improve efficiency, since you no longer have to compile and execute each line of code before you write the next one. And yes, in my experience this is exactly what happens in big code bases built in dynamic languages, short of being really sloppy and introducing lots of bugs.
- kibwen 9y ago
  As opposed to the main cost to dynamically-typed languages, all the time spent proving to the test suite and proving to your teammates that this thing is actually compatible with that thing. And I say this as someone who adores Python! Dynamic typing does not magically make problems go away, it just makes them easier to ignore (whether deliberately or accidentally).
  - mpweiher 9y ago
    > proving to the test suite and proving to your teammates that this thing is actually compatible with that thing. I really don't know where that canard comes from. My test suites rarely if ever explicitly test compatibility. They test for specific values: if I do this and that, do I get the value that I expect. The type "test" gets covered implicitly, because if it's not the correct type, it will also not be the correct value.
    - lkitching 9y ago
      The problem is that without knowing the type in question you don't know the values you're testing with cover all of the possible cases. When interfacing with an external dynamically-typed function this requires attempting to reverse-engineer the types from the definition (and recursively for all the functions it calls).

it's often not about expressivity, it's about conciseness. It's much easier to say a correct statement than it is to prove the statement correct. This seems to be the main cost to stongly typed static languages, all the time spent proving to the compiler that this thing is actually compatible with that thing.

bad_user 9y ago
What strongly typed static languages are you talking about? > proving to the compiler that this thing is actually compatible with that thing I used to have this opinion, but nowadays I think that time is actually spent proving to myself that I'm right, which is always a good thing. Having a compiler to do the hand holding is not such a bad thing, because the alternative is println-development. What happens in a dynamic language is that you have to load in your head the shape of the data your working with, the API and everything really. Your head can't hold that much for anything that is bigger than a simple script, so you have to constantly execute and verify (in the REPL, in the browser, with a unit test, etc) each line of code that you write, before writing the next line of code. This is why people complain about compilation speed in Scala, Haskell, etc, even if they miss they point, because even a slow, static compiler will improve efficiency, since you no longer have to compile and execute each line of code before you write the next one. And yes, in my experience this is exactly what happens in big code bases built in dynamic languages, short of being really sloppy and introducing lots of bugs.
kibwen 9y ago
As opposed to the main cost to dynamically-typed languages, all the time spent proving to the test suite and proving to your teammates that this thing is actually compatible with that thing. And I say this as someone who adores Python! Dynamic typing does not magically make problems go away, it just makes them easier to ignore (whether deliberately or accidentally).
- mpweiher 9y ago
  > proving to the test suite and proving to your teammates that this thing is actually compatible with that thing. I really don't know where that canard comes from. My test suites rarely if ever explicitly test compatibility. They test for specific values: if I do this and that, do I get the value that I expect. The type "test" gets covered implicitly, because if it's not the correct type, it will also not be the correct value.
  - lkitching 9y ago
    The problem is that without knowing the type in question you don't know the values you're testing with cover all of the possible cases. When interfacing with an external dynamically-typed function this requires attempting to reverse-engineer the types from the definition (and recursively for all the functions it calls).