26 ms·

Thanks for this. After ~30 years of professional software development in pretty much every major language created, I prefer dynamic languages to statically typ

Thanks for this. After ~30 years of professional software development in pretty much every major language created, I prefer dynamic languages to statically types ones for a whole host of reasons, none of which amount to me being a n00b or uneducated, which is frequently implied by the static types die-hard folks.

tines 4y ago
Language researcher here, would you be willing to list out some of those reasons you mentioned? Always interested in hearing these perspectives!
- diffxx 4y ago
  Not the OP, but most compilers for languages with static type systems are too slow for my taste. I have a workflow for writing lua programs in which I embed all of my tests in the same file that contains all of the runtime logic. Whenever that file changes, I have a monitor script that runs the program and validates my tests. This process typically happens in less than 20ms, so I've configured my editor to save my lua files whenever I type a single keystroke. It's like having a living REPL session that is persistently stored in the file. When you develop in this style, you tend not to write type errors because you are constantly validating your program inputs and outputs, which the tight feedback loop encourages. Most statically typed languages have slow compilers. It is not uncommon for an incremental compile to take at least 1s, which is 50-100x slower than what I'm used to. Indeed, I find it distracting when compilation is that slow so with such a language I will still use a monitor script for iteration but I will manually save when I want validation. This means that I am not only getting slower feedback, I am getting less of it, which ultimately makes me less confident in my program. If I were making lots of type errors, maybe it would be worth it to have a type checker, but I'm generally not.
- claytongulick 4y ago
  Sure, thanks for asking! I think it's mostly about time to market and reduced total LOC. I find that in strongly typed languages, frequently up to 30% or more of the total lines of code are dedicated to nothing but type satisfaction. Sometimes this formalism is warranted, depending on the problem domain (banking, air craft systems, etc) but most of the time I find that the type systems are merely mental abstractions that are created to assist the developer in modeling the solution. There's value in that. As I've gained more experience, trivialities like the compiler catching junior programmer level silly type mistakes has become less valuable. Type systems don't address logic errors. The flexibility of duck typing with loose contracts reduces total time to market for applications where that's a primary constraint. This happens to be true in a vast class of problem domains, where having something quickly is more important than performance or formal correctness. Since I tend to live in the startup space where TTM and MVPs are critical to business success, I'm inclined towards languages that support this. I typically don't have to deal with large team coordination issues or extremely complex interdependence, and my systems are normally fairly basic - crud with business rules and a fancy UI. In this case, things like type errors present themselves immediately in the UI and are easy to catch during development, reducing the value of compile time error detection.

tines 4y ago

Language researcher here, would you be willing to list out some of those reasons you mentioned? Always interested in hearing these perspectives!

diffxx 4y ago
Not the OP, but most compilers for languages with static type systems are too slow for my taste. I have a workflow for writing lua programs in which I embed all of my tests in the same file that contains all of the runtime logic. Whenever that file changes, I have a monitor script that runs the program and validates my tests. This process typically happens in less than 20ms, so I've configured my editor to save my lua files whenever I type a single keystroke. It's like having a living REPL session that is persistently stored in the file. When you develop in this style, you tend not to write type errors because you are constantly validating your program inputs and outputs, which the tight feedback loop encourages. Most statically typed languages have slow compilers. It is not uncommon for an incremental compile to take at least 1s, which is 50-100x slower than what I'm used to. Indeed, I find it distracting when compilation is that slow so with such a language I will still use a monitor script for iteration but I will manually save when I want validation. This means that I am not only getting slower feedback, I am getting less of it, which ultimately makes me less confident in my program. If I were making lots of type errors, maybe it would be worth it to have a type checker, but I'm generally not.
claytongulick 4y ago
Sure, thanks for asking! I think it's mostly about time to market and reduced total LOC. I find that in strongly typed languages, frequently up to 30% or more of the total lines of code are dedicated to nothing but type satisfaction. Sometimes this formalism is warranted, depending on the problem domain (banking, air craft systems, etc) but most of the time I find that the type systems are merely mental abstractions that are created to assist the developer in modeling the solution. There's value in that. As I've gained more experience, trivialities like the compiler catching junior programmer level silly type mistakes has become less valuable. Type systems don't address logic errors. The flexibility of duck typing with loose contracts reduces total time to market for applications where that's a primary constraint. This happens to be true in a vast class of problem domains, where having something quickly is more important than performance or formal correctness. Since I tend to live in the startup space where TTM and MVPs are critical to business success, I'm inclined towards languages that support this. I typically don't have to deal with large team coordination issues or extremely complex interdependence, and my systems are normally fairly basic - crud with business rules and a fancy UI. In this case, things like type errors present themselves immediately in the UI and are easy to catch during development, reducing the value of compile time error detection.