3 ms·

That's understandable. Personally after embracing strong typing I find it hard to go back, and I feel like my time and energy is wasted without good feedback fr

That's understandable. Personally after embracing strong typing I find it hard to go back, and I feel like my time and energy is wasted without good feedback from the LSP and reliably understanding what types I'm dealing with or what errors may occur. Dynamic typing isn't free either. As far as the origins of dynamic typing goes, the amount of compute we can dedicate to tooling today, and the development of language servers in particular, radically changes the tradeoffs we can make. Strongly typed languages are better positioned to leverage tooling, and in my view this has completely upended the landscape of language ergonomics. Strong typing might not be free, but it does buy you a lot. Does that view really make me naive or disingenuous? Perhaps we've just had different experiences. To be frank, when you say something that I solve in a blink of the eye is a serious friction, I have a similar reaction.

scott_w 2y ago
> To be frank, when you say something that I solve in a blink of the eye is a serious friction, I have a similar reaction. So you're telling me that the following: data = requests.get(some_link).json()['the_field_i_care_about'] do_something_with(data) is just as much effort as defining the types and dealing with the error case (depending on the language). You're either vastly more intelligent—and a faster typist—than pretty much every human being I've ever interacted with or, more likely, you're lying to me and/or yourself.
- maxbond 2y ago
  I'm sorry that I made you feel disrespected. That wasn't my intention. I'm not any more intelligent or a faster a typist than the next guy. Which is why I place such an emphasis on tooling (like code completion). If you haven't given VSCode or another editor with LSP capabilities a try, you won't regret it.
  - scott_w 2y ago
    I use VSCode and it helps but there's three points here: 1. It doesn't remove all friction—it can't magic type definitions out of thin air. 2. The fact that tooling exists means it's there to remove friction. Ergo, that friction exists. 3. Following 2: this tooling isn't appropriate in all environments. There's situations where opening vim and sketching out an idea is the fastest way.

scott_w 2y ago

> To be frank, when you say something that I solve in a blink of the eye is a serious friction, I have a similar reaction. So you're telling me that the following: data = requests.get(some_link).json()['the_field_i_care_about'] do_something_with(data) is just as much effort as defining the types and dealing with the error case (depending on the language). You're either vastly more intelligent—and a faster typist—than pretty much every human being I've ever interacted with or, more likely, you're lying to me and/or yourself.

maxbond 2y ago
I'm sorry that I made you feel disrespected. That wasn't my intention. I'm not any more intelligent or a faster a typist than the next guy. Which is why I place such an emphasis on tooling (like code completion). If you haven't given VSCode or another editor with LSP capabilities a try, you won't regret it.
- scott_w 2y ago
  I use VSCode and it helps but there's three points here: 1. It doesn't remove all friction—it can't magic type definitions out of thin air. 2. The fact that tooling exists means it's there to remove friction. Ergo, that friction exists. 3. Following 2: this tooling isn't appropriate in all environments. There's situations where opening vim and sketching out an idea is the fastest way.