Python showed what relaxed types could do. And we could go a long way as it turns out without types. But there are use cases for types, and even python admitted such when they added type annotations.
However, when I was a kid a would put a firecracker next to an object. I didn't bother running the scenario through a compiler to see if the object was of type Explodable() and had an explode() method that would be called.
> However, when I was a kid a would put a firecracker next to an object. I didn't bother running the scenario through a compiler to see if the object was of type Explodable() and had an explode() method that would be called.
Duck typing: if it quacks like a duck, and it explodes objects next to it, it's a firequacker
I have always felt that it's better to "concentrate" complexity into one key component and make the rest of the codebase simple than to distribute complexity evenly everywhere in some kind of open-coded swamp.
I don't think it is anything to do with complexity, or grouping code/data, its just a natural tendency of people to categorize things together that display a high degree of class inclusion. And some categories are easier to deal with than others.
I don’t think I agree that either typescript nor rust successfully hide the complexity in their type systems.
By the nature of type systems, they are tightly coupled with the code written around them.
Rust has rich features to handle this coupling (traits and derives), but typescript does not.
Python showed what relaxed types could do. And we could go a long way as it turns out without types. But there are use cases for types, and even python admitted such when they added type annotations.
However, when I was a kid a would put a firecracker next to an object. I didn't bother running the scenario through a compiler to see if the object was of type Explodable() and had an explode() method that would be called.
> However, when I was a kid a would put a firecracker next to an object. I didn't bother running the scenario through a compiler to see if the object was of type Explodable() and had an explode() method that would be called.
Duck typing: if it quacks like a duck, and it explodes objects next to it, it's a firequacker
I have always felt that it's better to "concentrate" complexity into one key component and make the rest of the codebase simple than to distribute complexity evenly everywhere in some kind of open-coded swamp.
"Parameterizing complexity" is probably a better way to say it. There's no isolation when it comes to software.
I don't think it is anything to do with complexity, or grouping code/data, its just a natural tendency of people to categorize things together that display a high degree of class inclusion. And some categories are easier to deal with than others.
>The question is first of all whether we have written them down anywhere
The only hard thing in software: papers please (easily accessible documentation)
complexity has to live somewhere, code anxiety was a real thing for me
[flagged]