Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Isolating complexity is the essence of successful abstractions

v5.chriskrycho.com

Post reply on HN
Print view View original

21–30 of 87 posts

Re: Isolating complexity is the essence of successful abstractions

#21

Post by timewizard »

> Complexity has to live somewhere. If you are lucky, it lives in well-defined places.

This whole section makes me think of construction which has similar abstraction and hidden complexity problems. It strikes me that they solve it by having design be entirely separate from implementation. Which is usually the corner where all our luck as software developers inevitably runs out.

Our methods are still rather "cowboy." We have cool "modernized cowboy" languages that make it hard to shoot your foot off, but at the end of the day, we're still just riding old horses and hoping for the best.

Re: Isolating complexity is the essence of successful abstractions

#23

Post by acchow »

est wrote: post #22

I think "types" is the solution of two completely different problems: 1. how to specify memory layout for faster execution 2. how to give hint when I press . in IDEs if you use typing outside these two scopes you'd probably find many troubles.

> if you use typing outside these two scopes you'd probably find many troubles.

- encoding invariants and define valid evolutions of the codebase

- memory safety without a garbage collector (see Rust’s Affine type system)

Re: Isolating complexity is the essence of successful abstractions

#24

Post by grues-dinner »

est wrote: post #22

I think "types" is the solution of two completely different problems: 1. how to specify memory layout for faster execution 2. how to give hint when I press . in IDEs if you use typing outside these two scopes you'd probably find many troubles.

Types imbue pure data with meaning. That's pretty much it, and the other uses of types flow from that.

Whether you use that meaning to produce IDE hints (say, via Python type annotations, though I am aware Python typing isn't only that), or you feed it to a compiler that promises that it will ruthlessly statically enforce the invariants you set via the types, or anything else, is up to you, your goal and the language you use.

Re: Isolating complexity is the essence of successful abstractions

#25

Post by hnlmorg »

est wrote: post #22

I think "types" is the solution of two completely different problems: 1. how to specify memory layout for faster execution 2. how to give hint when I press . in IDEs if you use typing outside these two scopes you'd probably find many troubles.

3. Compile time safety.

That’s what I use types mostly for. I don’t care about compiler hints, well structured code with sane naming conventions solves that problem without the need for types. But I do want my program to fail to compile (or in JIT-land, fail unit tests / CICD) when I do something stupid with a variable.

The former is about typing speed and I already type faster than I think. The latter is about guardrails protecting me from my own human error. And that is a far more realistic problem than my IDE performance.

Re: Isolating complexity is the essence of successful abstractions

#26

Post by wmwragg »

timewizard wrote: post #21

> Complexity has to live somewhere. If you are lucky, it lives in well-defined places. This whole section makes me think of construction which has similar abstraction and hidden complexity problems. It strikes me that they solve it by having design be entirely separate from implementation. Which is usually the corner where all our luck as software developers inevitably runs out. Our methods are still rather "cowboy."…

I've often thought this. It feels like there should be two languages, one for the implementation of the parts, and another to design/architect the software using the parts, allowing the design/architect language to focus on the high level architecture of the software and the implementation language to focus on the parts. We currently use the same language for both, and mix the two areas as we program

Re: Isolating complexity is the essence of successful abstractions

#28

Post by grues-dinner »

hnlmorg wrote: post #25
est wrote: post #22

I think "types" is the solution of two completely different problems: 1. how to specify memory layout for faster execution 2. how to give hint when I press . in IDEs if you use typing outside these two scopes you'd probably find many troubles.

3. Compile time safety. That’s what I use types mostly for. I don’t care about compiler hints, well structured code with sane naming conventions solves that problem without the need for types. But I do want my program to fail to compile (or in JIT-land, fail unit tests / CICD) when I do something stupid with a variable. The former is about typing speed and I already type faster than I think. The latter is about guard…

Not only compile time, but run/debug time. Just being able to say "I have an object here, so I must have some consistent state meaning XYZ" is very helpful.

Of course, it's on you to make that happen - if you have a Between6And10 type and you implement as struct with an int that someone comes and writes 15 into it, it's bad news for your assumptions.

If you can make it compile time safe, then great, but even when you can't, if you know the invariants are holding, it's still something powerful you can reason about.

Re: Isolating complexity is the essence of successful abstractions

#29

Post by cjfd »

saghm wrote: post #8
bb88 wrote: post #5

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 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

Duck typing. If it quacks like a duck and swims like a duck it might be a duck. But it might also be a nuclear submarine doing a duck impersonation. The question is whether you want a nuclear submarine in your pond.
Post reply on HN