Isolating complexity is the essence of successful abstractions
v5.chriskrycho.com
Isolating complexity is the essence of successful abstractions
1–10 of 87 posts
Re: Isolating complexity is the essence of successful abstractions
#2complexity has to live somewhere, code anxiety was a real thing for me
Re: Isolating complexity is the essence of successful abstractions
#3>The question is first of all whether we have written them down anywhere
The only hard thing in software: papers please (easily accessible documentation)
Re: Isolating complexity is the essence of successful abstractions
#4[flagged]
Re: Isolating complexity is the essence of successful abstractions
#5Python 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.
Re: Isolating complexity is the essence of successful abstractions
#6I 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.
Re: Isolating complexity is the essence of successful abstractions
#7"Parameterizing complexity" is probably a better way to say it. There's no isolation when it comes to software.
Re: Isolating complexity is the essence of successful abstractions
#8Python 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 calle…
> 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
Re: Isolating complexity is the essence of successful abstractions
#9"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.
Re: Isolating complexity is the essence of successful abstractions
#10I 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.