4 ms·

> As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take. How do you come to such a conclusion when there ha

by mekoka 6y ago

> As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take. How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? > If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases. "Over-engineering" means drawing blueprints when the job is to change a bulb. It does not mean that blueprints are useless. It's about the job and the tools picked to do it. I can conceive of many jobs that fit the scope of a dynamic language and where bringing the big typed cannons could be seen as over-engineering.

luuio 6y ago
> there have been many languages whose success was specifically tied to the fact that they were dynamically typed Language success does not mean product success. A language is just one of the many things in your toolbox. There's a reason why when many products grew larger, they all are migrating to statically/strictly typed languages.
lmm 6y ago
> How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? The pain point was always tedium, not difficulty. At least that's how it was sold. We haven't seen a new major dynamic language since type inference went mainstream (and existing dynamic languages are putting a lot of effort into enabling static typing), and I don't think that's coincidence.
eyelidlessness 6y ago
> How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? How do you come to the pain point conclusion about static types, rather than prior art static type systems, when the vast majority of tooling around the most popular dynamically typed language explicitly dedicates resources and visibility to its most popular static type system?

by mekoka 6y ago

luuio 6y ago

> there have been many languages whose success was specifically tied to the fact that they were dynamically typed Language success does not mean product success. A language is just one of the many things in your toolbox. There's a reason why when many products grew larger, they all are migrating to statically/strictly typed languages.

lmm 6y ago

> How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? The pain point was always tedium, not difficulty. At least that's how it was sold. We haven't seen a new major dynamic language since type inference went mainstream (and existing dynamic languages are putting a lot of effort into enabling static typing), and I don't think that's coincidence.

eyelidlessness 6y ago

> How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? How do you come to the pain point conclusion about static types, rather than prior art static type systems, when the vast majority of tooling around the most popular dynamically typed language explicitly dedicates resources and visibility to its most popular static type system?