3 ms·

> I find dynamic typing similar to how unit testing is a forcing function for writing composable code, it acts as a forcing function to writing simple code; sim

> I find dynamic typing similar to how unit testing is a forcing function for writing composable code, it acts as a forcing function to writing simple code; simple to read and simple to comprehend. If this were broadly true for most developers using dynamically typed languages, it would be a very compelling argument indeed. But I think there’s pretty strong evidence the opposite is generally true: actual types produced to document real world dynamic code tend to be vastly more complex than the equivalent functionality implemented with static types from the outset. In the TypeScript ecosystem, DefinitelyTyped is an excellent source of countless case studies. The types they provide are typically definitely not, as you put it, “used in a simple way”. That’s not complexity inherent to the type system, or the type definitions as provided; it’s complexity inherent to the dynamic code they describe. Equivalent packages which were statically typed from the outset tend to have much simpler interfaces because the types are defined upfront rather than retconned onto existing APIs. That doesn’t necessarily mean their interfaces are absolutely simple, but they’re typically relatively simple by comparison. I’d go so far as to say that you can’t know how simple or complex an interface is without specifying it. If “the code is the documentation” (which I agree is a great ideal!), then interfaces without code specifying them are under-documented by definition. The further the code specifying the interface is from the interface itself, the more obscured your documentation is.

hparadiz 3y ago
Dynamically typed language have very clear rules. It's not magic. If you know these rules nothing about dynamically typed code is inherently problematic. It's the difference between logic being in the code versus in the run time. You accept hundreds of rule sets built into the run time all the time.
- MrJohz 3y ago
  All programming languages - all computers even - have very clear rules. The complexity in software development usually has less to do with getting a computer to understand its own rules, and more to do with the boundaries between humans and those rules: for example, encoding human ideas into rigid computer rules, or trying as a human to understand the computer rules that someone else has written. So when you say "if you know these rules nothing about dynamically typed code is inherently problematic", my intuition says "I probably don't know these rules". That goes for some of the basic rules like "the first argument to this function is the haystack, the second is the needle", but it also goes from some of the more complex rules like "functions that take a user ID can also take a user object and extract the ID from that" or "the allowed states for this FSM are X, Y, and Z, and are always written in capital letters". More importantly, a lot of the rules for my difference will not have been written by me, they'll have been written by my colleagues, or else they were written by me, but it was more than six months ago and my memory is a bit hazy on the details. The point the previous poster was making, I think, was that while the rules may be very explicit (this is, after all, what any programming language is: explicit rules for a computer to follow), they can also be very complex. And, more specifically, the DefinitelyTyped examples show that the rules for dynamic software often tend to be very complex, or at least, complex enough to present difficulties when being modelled by a type system explicitly designed to model dynamic code.
gls2ro 3y ago
> But I think there’s pretty strong evidence the opposite is generally true I could not find good research that will decisively settle this dispute about static vs dynamic. So when you say "strong evidence" what are the sources for this strong evidence? Not asking to push against, I am gathering a list of articles and papers about this topic.
- eyelidlessness 3y ago
  I’m only responding to the claim that dynamic types act as a forcing function to produce simpler code, not the static vs dynamic distinction more broadly. It’s possible there are papers on the topic, but I’m not aware of them. The evidence I’m speaking to is the complexity of the respective types themselves, ie either: - those produced in the course of developing a given software package with static types as an explicit part of the development process, versus - those produced post hoc to document the apparent interfaces of an equivalent package which has been produced without explicit types One might call foul, by saying that this criterion favors static types by evaluating the complexity in terms of static types. But the reason I think it’s a fair comparison is because the dynamic interface does have a static type representation, even if it has to be conjured into notation post hoc… in much the same way as a data store model does have a schema even if it’s not formally specified as such.

hparadiz 3y ago

Dynamically typed language have very clear rules. It's not magic. If you know these rules nothing about dynamically typed code is inherently problematic. It's the difference between logic being in the code versus in the run time. You accept hundreds of rule sets built into the run time all the time.

MrJohz 3y ago
All programming languages - all computers even - have very clear rules. The complexity in software development usually has less to do with getting a computer to understand its own rules, and more to do with the boundaries between humans and those rules: for example, encoding human ideas into rigid computer rules, or trying as a human to understand the computer rules that someone else has written. So when you say "if you know these rules nothing about dynamically typed code is inherently problematic", my intuition says "I probably don't know these rules". That goes for some of the basic rules like "the first argument to this function is the haystack, the second is the needle", but it also goes from some of the more complex rules like "functions that take a user ID can also take a user object and extract the ID from that" or "the allowed states for this FSM are X, Y, and Z, and are always written in capital letters". More importantly, a lot of the rules for my difference will not have been written by me, they'll have been written by my colleagues, or else they were written by me, but it was more than six months ago and my memory is a bit hazy on the details. The point the previous poster was making, I think, was that while the rules may be very explicit (this is, after all, what any programming language is: explicit rules for a computer to follow), they can also be very complex. And, more specifically, the DefinitelyTyped examples show that the rules for dynamic software often tend to be very complex, or at least, complex enough to present difficulties when being modelled by a type system explicitly designed to model dynamic code.

gls2ro 3y ago

> But I think there’s pretty strong evidence the opposite is generally true I could not find good research that will decisively settle this dispute about static vs dynamic. So when you say "strong evidence" what are the sources for this strong evidence? Not asking to push against, I am gathering a list of articles and papers about this topic.

eyelidlessness 3y ago
I’m only responding to the claim that dynamic types act as a forcing function to produce simpler code, not the static vs dynamic distinction more broadly. It’s possible there are papers on the topic, but I’m not aware of them. The evidence I’m speaking to is the complexity of the respective types themselves, ie either: - those produced in the course of developing a given software package with static types as an explicit part of the development process, versus - those produced post hoc to document the apparent interfaces of an equivalent package which has been produced without explicit types One might call foul, by saying that this criterion favors static types by evaluating the complexity in terms of static types. But the reason I think it’s a fair comparison is because the dynamic interface does have a static type representation, even if it has to be conjured into notation post hoc… in much the same way as a data store model does have a schema even if it’s not formally specified as such.