Abstraction is expensive • Hacker News Board

Re: Abstraction is expensive

#141

Post by manv1 » Thu, Dec 08, 2022, 5:42 PM UTC

"You can't delegate understanding." - Charles Eames

Abstraction means you don't have to think about details. Unfortunately, details matter in software.

As a simple example, how many projects use Hibernate, then run into massive performance problems? Pretty much all of them...because the devs don't bother to learn how their data store works. Then they iterate over 150,000,000 rows with their ORM instead of using, you know, SQL.

It's always a tradeoff, but again, "you can't delegate understanding."

Re: Abstraction is expensive

#142

Post by grey-area » Thu, Dec 08, 2022, 7:37 PM UTC

danielmarkbruce wrote: post #96

danShumway wrote: post #92

Earlier quoted context omitted.

> But the content is mostly about making good/consistent choices given the situation. That's what I'm saying though. You need to make good/consistent choices about the given situation because abstractions are expensive, not free. If they were free, we'd just throw them everywhere with no thought.

What you are saying isn't wrong, but when someone reads "abstraction is expensive", they immediately assume the implication "and hence you shouldn't use it". To make an analogy: people shouldn't buy a sports car if they want to take their family of 5 skiing every weekend. A person might reasonably write an article on all the factors one should consider when buying a car. They shouldn't title said article "Cars are ex…

You shouldn’t use any abstraction unless you have a good reason to do so.

Why? Because it has costs which are most heavily paid by those who come after you and read or modify the code later.

A small amount of the right abstraction helps understanding, too many irrelevant abstractions just gets in the way (BeanFactoryFactory etc).

I’ve only seen people use too much abstraction, not too little, so the title makes perfect sense as it is to me and has the right message IMO.

Re: Abstraction is expensive

#143

Post by a1369209993 » Thu, Dec 08, 2022, 10:59 PM UTC

agentultra wrote: post #138

a1369209993 wrote: post #108

Earlier quoted context omitted.

> Isn't this why fixed, signed integer types don't have a Monoid instance? No. Integers (signed or unsigned, fixed or arbitrary-precision) don't have Monoid instances since Haskell requires a single class instance per type, and it's ambigous which instance should be the "canonical" one. The types `Num a => Sum a` and `Num a => Product a` have Monoid instances, but it's not clear whether the "canonical" instance for a…

Ah ok that makes sense, and if you choose to use `Sum Int` you'd be technically implementing the Monoid abstraction for that type. In practice because the `Int` type is a signed, fixed-size integer it would break the laws for all integers . In that case it would still be a useful abstraction but you would have to be aware that your `Int` will wrap around for large values which kind of makes `Int` a poor choice. `Inte…

> In practice because the `Int` type is a signed, fixed-size integer it would break the laws for all integers.

No. `Sum Int` (unlike, pedantically, `Sum Integer` or `[a]`) is a valid (non-leaky-abstraction) monoid. It adds `Int`s, which is a monoidal operation that satisfies `(ab)c==a(bc)` for all (2^(3*MACHINE_BIT_WIDTH) distinct triplets (a,b,c) of) Ints, due to 2s-complement truncation on overflow.

> your `Int` will wrap around for large values

Yes, that's what `Int` means.

> `Integer`

will fail to terminate when adding sufficiently large values (in theory with a out of memory error, although in practice operations just get slower and slower until you abort them with ^C or a timeout), a property not shared by addition of `Int`.

Re: Abstraction is expensive

#144

Post by a1369209993 » Thu, Dec 08, 2022, 11:03 PM UTC

nequo wrote: post #137

a1369209993 wrote: post #116

Earlier quoted context omitted.

> * `Sum` whose [` `] is multiplication; and * `Product` whose [...] ` ` is addition ... Uhh?

Parent probably wanted to create two bullet points with the two asterisks.

I was actually questioning the "Sum is multiplication, Product is addition" part, although now that you mention it, the lack of a line break is also a (less significant) problem.