3 ms·

To tack on to this: Typing is never the limiting factor in my work. Like, if I had to type even double to accomplish the same program, I don't think that would

To tack on to this: Typing is never the limiting factor in my work. Like, if I had to type even double to accomplish the same program, I don't think that would actually slow me down. Given that, the major time difference between using static vs dynamic typing is the investment needed to go from 'throwing things at a wall and seeing what sticks' to understanding what you need to do and doing it.

woojoo666 5y ago
I've found that "throwing things at the wall" can be very helpful sometimes. It isn't necessarily a linear path from designing a solution -> implementing it in code. Sometimes writing some preliminary code can help flesh out the design. It's a symbiotic process. I've wasted countless hours before trying to design a solution on paper when writing the code out and iterating on the code proved much faster. And as for how this relates to static v dynamic typing, when I'm roughing out an implementation I much prefer to leave out types.
- BobbyJo 5y ago
  I find I can hack on things faster with static typing. I'm inevitably picking up new libraries, and using a new library is much easier when it's inputs and outputs are clear. I can see how dynamic would help if you're writing most things yourself, but static definitely has a huge return when interfacing with anything someone else wrote.
  - woojoo666 5y ago
    totally agree. That's why I think libraries and other mature code should use static typing, whereas I like to use dynamic typing for code that I am prototyping. This is why I love Typescript, you can have both :)
blacktriangle 5y ago
Anybody who thinks that avoiding extra typing is the point of dynamic langauges, or that working in a dynamic language is simply throwing things at a wall to see what sticks is completely missing the point. The whole point of dynamic languages is that your problem space is in fact dynamic. In many domains your data simply defies any ontology you try and force it into. Static typing systems themselves are somewhat acknowleging this problem internally with the differences between nominal and structural based typing system. Dynamic langauges are about changing your view on data where instead of shoving all your data into and out of boxes that don't fit, you just see entities as arbitrary collections of attributes and thus typing them makes little sense.
- kaba0 5y ago
  You do refer to specific attributes in the code, doesn’t you? So all in all you at least use a structural type with some given attributes. Even if you only ever use those attributes, you are already better off with regards to future changes, refactors, etc.
- IceDane 5y ago
  I'm sorry, but this is wrong. See alexis king's takes(which could be taken right out of my mouth, just more eloquent): https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... The gist is basically that a dynamic type system doesn't afford you any more power or "dynamicism" than a statically typed language. At any point in time, when writing code, you always know something about your data. Even if it was quite literally totally unstructured JSON data with no rhyme or reason to its structure other than it being any valid JSON, then at least you know that much, and you can reify this in the type system: `data JSONVal = Map String JSONVal | [JSONVal] | JSONString String | ..` It is impossible to write code that works on "any kind of data" because your code, and what it does with the data, makes the same kinds of assumptions about the shape of the data as static typing does. The only difference is that a static type system will let the compiler help you find obvious bugs at compile-time, while dynamic typing will force you write tests up the wazoo and the end result will still be something that is less robust wrt. refactoring than a statically typed language. The statically typed language just gives you this all for free.
  - blacktriangle 5y ago
    Great blog post, great blog in general, but here's the highlight of all that for me: "In contrast, most static type systems do not allow such free-form manipulation of records because records are not maps at all but unique types distinct from all other types. These types are uniquely identified by their (fully-qualified) name, hence the term nominal typing. If you wish to take a subselection of a struct’s fields, you must define an entirely new struct; doing this often creates an explosion of awkward boilerplate." That is exactly the space I want to work in. I want to treat entities as anonymous entities without having to name them them since at that point I approach a 1:1 mapping of names to things in my system. I want to use generic data operations to merge and slice my entities which are just collections of facts about a thing. Structural typing is a step towards this programming model but still requires that you shove your data into some ontology. EDIT: Actually I take that back, that blog post is totally missing the point. She asserts that the type system just makes explicit the implicit requirements of your code. The problem is in HOW the type system does that. By focusing on the function itself, the author ignores the real problem further upstream. If there's some type, then I have to shove my dynamic data into your type in order to use the function. And if you're trying to use interfaces, there's still some concrete type that you've created to attach that interface too. Either way, you haven't managed to support dynamic data through your system.

woojoo666 5y ago

I've found that "throwing things at the wall" can be very helpful sometimes. It isn't necessarily a linear path from designing a solution -> implementing it in code. Sometimes writing some preliminary code can help flesh out the design. It's a symbiotic process. I've wasted countless hours before trying to design a solution on paper when writing the code out and iterating on the code proved much faster. And as for how this relates to static v dynamic typing, when I'm roughing out an implementation I much prefer to leave out types.

BobbyJo 5y ago
I find I can hack on things faster with static typing. I'm inevitably picking up new libraries, and using a new library is much easier when it's inputs and outputs are clear. I can see how dynamic would help if you're writing most things yourself, but static definitely has a huge return when interfacing with anything someone else wrote.
- woojoo666 5y ago
  totally agree. That's why I think libraries and other mature code should use static typing, whereas I like to use dynamic typing for code that I am prototyping. This is why I love Typescript, you can have both :)

blacktriangle 5y ago

Anybody who thinks that avoiding extra typing is the point of dynamic langauges, or that working in a dynamic language is simply throwing things at a wall to see what sticks is completely missing the point. The whole point of dynamic languages is that your problem space is in fact dynamic. In many domains your data simply defies any ontology you try and force it into. Static typing systems themselves are somewhat acknowleging this problem internally with the differences between nominal and structural based typing system. Dynamic langauges are about changing your view on data where instead of shoving all your data into and out of boxes that don't fit, you just see entities as arbitrary collections of attributes and thus typing them makes little sense.

kaba0 5y ago
You do refer to specific attributes in the code, doesn’t you? So all in all you at least use a structural type with some given attributes. Even if you only ever use those attributes, you are already better off with regards to future changes, refactors, etc.
IceDane 5y ago
I'm sorry, but this is wrong. See alexis king's takes(which could be taken right out of my mouth, just more eloquent): https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... The gist is basically that a dynamic type system doesn't afford you any more power or "dynamicism" than a statically typed language. At any point in time, when writing code, you always know something about your data. Even if it was quite literally totally unstructured JSON data with no rhyme or reason to its structure other than it being any valid JSON, then at least you know that much, and you can reify this in the type system: `data JSONVal = Map String JSONVal | [JSONVal] | JSONString String | ..` It is impossible to write code that works on "any kind of data" because your code, and what it does with the data, makes the same kinds of assumptions about the shape of the data as static typing does. The only difference is that a static type system will let the compiler help you find obvious bugs at compile-time, while dynamic typing will force you write tests up the wazoo and the end result will still be something that is less robust wrt. refactoring than a statically typed language. The statically typed language just gives you this all for free.
- blacktriangle 5y ago
  Great blog post, great blog in general, but here's the highlight of all that for me: "In contrast, most static type systems do not allow such free-form manipulation of records because records are not maps at all but unique types distinct from all other types. These types are uniquely identified by their (fully-qualified) name, hence the term nominal typing. If you wish to take a subselection of a struct’s fields, you must define an entirely new struct; doing this often creates an explosion of awkward boilerplate." That is exactly the space I want to work in. I want to treat entities as anonymous entities without having to name them them since at that point I approach a 1:1 mapping of names to things in my system. I want to use generic data operations to merge and slice my entities which are just collections of facts about a thing. Structural typing is a step towards this programming model but still requires that you shove your data into some ontology. EDIT: Actually I take that back, that blog post is totally missing the point. She asserts that the type system just makes explicit the implicit requirements of your code. The problem is in HOW the type system does that. By focusing on the function itself, the author ignores the real problem further upstream. If there's some type, then I have to shove my dynamic data into your type in order to use the function. And if you're trying to use interfaces, there's still some concrete type that you've created to attach that interface too. Either way, you haven't managed to support dynamic data through your system.