3 ms·

> You seem to put it on developers coming to dynamically typed languages from statically typed languages having a "gap" in their approach. Gap was a bad choice

> You seem to put it on developers coming to dynamically typed languages from statically typed languages having a "gap" in their approach. Gap was a bad choice of words. I just meant a different approach. I've worked with both dynamic and statically typed languages, as well as Elixir which I consider the right "in between" balance. In the environments that I've worked in, the devs who were comfortable with dynamically typed languages were extremely productive. The ones that preferred static typing who tried to work in the dynamic languages regularly complained about the lack of static typing and were typically not as productive. The in the static typing environments, you'd see the reverse. The devs who were more comfortable with dynamic typing were regularly frustrated by the steps they saw negatively impacting their productivity while the devs who preferred the static environment typically seemed happy and complaint free. I really think it just boils down to how people think about problems. This is entirely anecdotal of course.

bmitc 4y ago
Interesting stuff to hear, but I still think we're not getting down to what I've referred to as it being a necessary thing and not just a preference. When developers are working inside a dynamically typed code base, they have types in their head, do they not? The runtime system certainly does. Why not just write them down? Why are people so afraid of or unwilling to write down stuff they know or think they know? And again, I'd wager that "productive" people in dynamically typed languages are more comfortable than productive if one considers bugs introduced by assumptions of types and the unavoidable overhead in reading code implementations to understand call uses. I have seen countless bugs that would have been prevented or at least lessened by typespecs. If that's just a "statically typed perspective", what other process is catching these very real bugs and mistakes in the code? I have paired with people seemingly comfortable with not having typespecs and when asked questions like "how do you know ___?", the answer was usually "I don't" or "I think". Once we figure out the actual types and expected values, again, why not just right them down? Why throw out that knowledge? The way that I view things is that statically inferred types are a huge boon to the majority of a program abut can be a real pain at I/O boundaries, message passing, and other wings and edges of the software design. With dynamic types, they are a major boon to these I/O boundaries, message passing, and other wings and edges, but they are a major pain point in the rest of the program. My perspective is that whatever type of language you are using, you need to accept but account for its deficiencies.

bmitc 4y ago

Interesting stuff to hear, but I still think we're not getting down to what I've referred to as it being a necessary thing and not just a preference. When developers are working inside a dynamically typed code base, they have types in their head, do they not? The runtime system certainly does. Why not just write them down? Why are people so afraid of or unwilling to write down stuff they know or think they know? And again, I'd wager that "productive" people in dynamically typed languages are more comfortable than productive if one considers bugs introduced by assumptions of types and the unavoidable overhead in reading code implementations to understand call uses. I have seen countless bugs that would have been prevented or at least lessened by typespecs. If that's just a "statically typed perspective", what other process is catching these very real bugs and mistakes in the code? I have paired with people seemingly comfortable with not having typespecs and when asked questions like "how do you know ___?", the answer was usually "I don't" or "I think". Once we figure out the actual types and expected values, again, why not just right them down? Why throw out that knowledge? The way that I view things is that statically inferred types are a huge boon to the majority of a program abut can be a real pain at I/O boundaries, message passing, and other wings and edges of the software design. With dynamic types, they are a major boon to these I/O boundaries, message passing, and other wings and edges, but they are a major pain point in the rest of the program. My perspective is that whatever type of language you are using, you need to accept but account for its deficiencies.