3 ms·

Are you sure all statically typed languages are slower to develop in than comparable dynamic ones? I used to be thoroughly convinced this was true, but 3 things

Are you sure all statically typed languages are slower to develop in than comparable dynamic ones? I used to be thoroughly convinced this was true, but 3 things are now making me doubt it: 1) Statically typed languages with inference don’t require time spent writing signatures. 2) I know I’ve spent time chasing down bugs in dynamically typed software that would have been caught by a type checker. 3) I also know I’ve spent time writing tests for conditions in dynamically typed code that wouldn’t pass a type checker.

greymalik 4y ago
> 1) Statically typed languages with inference What are some strong examples of this? Haskell does an amazing job with it. Java technically supports some amount of inference, but it doesn’t reduce verbosity by all that much. Apart from those I haven’t run into it.
- sanedigital 4y ago
  Swift and Kotlin both do a fantastic job here. You think in types but don’t have to spend much time typing them.
- aranchelk 4y ago
  Haskell and PureScript are the ones I’ve used.
- albntomat0 4y ago
  Off the top of my head, Rust and OCaml do as well. Ive had to occasionally specify a type, but it works well in practice.
moffkalast 4y ago
> bugs that would have been caught by a type checker Type checking also introduces its own set of additional bugs by the virtue of object incompatibility, that do not exist at all in dynamically typed languages (or are handled correctly every time by the compiler/interpreter automatically). Take as an example exchanging objects over sockets, rest, files, etc. Whenever the object definition changes in another piece of the software stack the statically typed parts will crash upon receiving the updated objects, even if it's just one new param added that would've been fine otherwise if dynamically typed (or say change from a float to a double which can be irrelevant). A nightmare in systems with lots of moving parts. One might say that's working as intended, and it of course is, but it also forces you to fix and recompile all of that for no real net gain. Hence the longer dev time I mentioned. I've spent years working with statically typed languages, and I honestly don't think I'll ever go back to them in any professional capacity.
- ReactiveJelly 4y ago
  > exchanging objects over sockets, rest, files, etc. Whenever the object definition changes in another piece of the software stack the statically typed parts will crash upon receiving the updated objects, even if it's just one new param added that would've been fine otherwise if dynamically typed Anecdotally, this is not true for C++ using JSON or msgpack, since those are self-describing formats where extra fields are safe to ignore. And it's not even true for Rust using serde, which writes the serializing / de-serializing code for you. serde_json will also ignore unknown fields when parsing, and you can preserve the original object as a `serde_json::Value` in case you want to pass unknown fields downstream as opaques. Protocol buffers and Flat Buffers also have solutions to this, and all 4 of these formats are pretty popular in both static and dynamic languages. Even if you write a custom TLV format, this is not that hard to deal with. Was this common in the static code you worked with? You weren't just casting objects to `char *` and doing a `memcpy`, I hope?
  - yen223 4y ago
    The protocol buffers approach is quite interesting. With proto3, there's basically no such thing as a "required" field anymore. All fields are now optional. Now, being able to assert that a field is present in an object is a basic and valuable use-case for static typing. However, the developers felt that even this basic level of static type checking added too much friction whenever they had to update systems. https://capnproto.org/faq.html#how-do-i-make-a-field-required-like-in-protocol-buffers https://capnproto.org/faq.html#how-do-i-make-a-field-require...
- josephcsible 4y ago
  > Whenever the object definition changes in another piece of the software stack the statically typed parts will crash You appear to completely misunderstand what static typing means. Runtime crashes due to type mismatches are exactly what static typing prevents.
  - yen223 4y ago
    You can't typecheck across system boundaries - that's the OP's point. (Well you could, but then you'll be introducing a whole set of problems if the other system has a static type system that behaves differently from your application's static type system)

greymalik 4y ago

> 1) Statically typed languages with inference What are some strong examples of this? Haskell does an amazing job with it. Java technically supports some amount of inference, but it doesn’t reduce verbosity by all that much. Apart from those I haven’t run into it.

sanedigital 4y ago
Swift and Kotlin both do a fantastic job here. You think in types but don’t have to spend much time typing them.
aranchelk 4y ago
Haskell and PureScript are the ones I’ve used.
albntomat0 4y ago
Off the top of my head, Rust and OCaml do as well. Ive had to occasionally specify a type, but it works well in practice.

moffkalast 4y ago

> bugs that would have been caught by a type checker Type checking also introduces its own set of additional bugs by the virtue of object incompatibility, that do not exist at all in dynamically typed languages (or are handled correctly every time by the compiler/interpreter automatically). Take as an example exchanging objects over sockets, rest, files, etc. Whenever the object definition changes in another piece of the software stack the statically typed parts will crash upon receiving the updated objects, even if it's just one new param added that would've been fine otherwise if dynamically typed (or say change from a float to a double which can be irrelevant). A nightmare in systems with lots of moving parts. One might say that's working as intended, and it of course is, but it also forces you to fix and recompile all of that for no real net gain. Hence the longer dev time I mentioned. I've spent years working with statically typed languages, and I honestly don't think I'll ever go back to them in any professional capacity.

ReactiveJelly 4y ago
> exchanging objects over sockets, rest, files, etc. Whenever the object definition changes in another piece of the software stack the statically typed parts will crash upon receiving the updated objects, even if it's just one new param added that would've been fine otherwise if dynamically typed Anecdotally, this is not true for C++ using JSON or msgpack, since those are self-describing formats where extra fields are safe to ignore. And it's not even true for Rust using serde, which writes the serializing / de-serializing code for you. serde_json will also ignore unknown fields when parsing, and you can preserve the original object as a `serde_json::Value` in case you want to pass unknown fields downstream as opaques. Protocol buffers and Flat Buffers also have solutions to this, and all 4 of these formats are pretty popular in both static and dynamic languages. Even if you write a custom TLV format, this is not that hard to deal with. Was this common in the static code you worked with? You weren't just casting objects to `char *` and doing a `memcpy`, I hope?
- yen223 4y ago
  The protocol buffers approach is quite interesting. With proto3, there's basically no such thing as a "required" field anymore. All fields are now optional. Now, being able to assert that a field is present in an object is a basic and valuable use-case for static typing. However, the developers felt that even this basic level of static type checking added too much friction whenever they had to update systems. https://capnproto.org/faq.html#how-do-i-make-a-field-required-like-in-protocol-buffers https://capnproto.org/faq.html#how-do-i-make-a-field-require...
josephcsible 4y ago
> Whenever the object definition changes in another piece of the software stack the statically typed parts will crash You appear to completely misunderstand what static typing means. Runtime crashes due to type mismatches are exactly what static typing prevents.
- yen223 4y ago
  You can't typecheck across system boundaries - that's the OP's point. (Well you could, but then you'll be introducing a whole set of problems if the other system has a static type system that behaves differently from your application's static type system)