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

Abstraction is expensive

specbranch.com

Post reply on HN
Print view View original

111–120 of 144 posts

Re: Abstraction is expensive

#111

Post by trashtester »

BlargMcLarg wrote: post #55
fdgsdfogijq wrote: post #51

Earlier quoted context omitted.

Call me blunt, but ive come to the conclusion most people arent intelligent enough to create complex abstractions

I don't think intelligence or lack thereof is the problem. Rather, it seems people are paralyzing themselves by enjoying the endless discussions, stakeholder indecision, or boredom. All leading to these grotesque things which lack words in the right places, but have plenty in the wrong places. The average web dev CRUD job isn't interesting enough to warrant that much intelligence.

Intelligence is definitly a factor. In fact, more often than not when I encounter a person or team that seem to spend their time on everything else except addressing their most important problems, the reason for the apparent procastination is that they simply do not even know how to START solving the problem.

This is not exclusive for developers. It happens in management, too. Which is a second source of the problems you describe.

Re: Abstraction is expensive

#113

Post by feoren »

Reading the article and most of these comments, I've concluded that no two people are using the word "abstraction" exactly the same. I don't really understand what the author's definition of an "abstraction" is. He seems to call a poor database schema an "abstraction misalignment"; is anything not abstraction misalignment? It feels like we're in an old-folks home where everyone is talking but nobody is conversing. Nobody is agreeing on what "abstraction" means. A better title for this article is "mistakes are expensive", or possibly "bad design is expensive". But of course then nobody reads it, because everyone loves to hate on whatever they've decided "abstraction" means for them.

Re: Abstraction is expensive

#114

Post by garethrowlands »

agentultra wrote: post #103
a1369209993 wrote: post #78

Earlier quoted context omitted.

> Case in point: type classes, the Monoid type class, and Monoids as the mathematical concept; [...] when implemented by a compiler behaves exactly as expected when the program is executed. Not true in general. For some specific instances (such as fixed-size Int under addition or multiplication[0]), it works[1], but in the general case (eg Integer under add or mul, [Foo] under concat) `a b` can fail with out-of-memor…

Isn't this why fixed, signed integer types don't have a Monoid instance? https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-... For arbitrary sized `Integer` type, which is basically a libgmp arbitrary integer, we also don't have a Monoid.

The main reason Haskell does not define Monoid instances for numbers is that there are two equally valid instances: with 1 and * or with 0 and +. So, instead, there are two newtypes defined:

* `Sum` whose `mempty` (identity) is `Sum 0` and `` (combining operator) is multiplication; and * `Product` whose `mempty` is `Product 1` and `` is addition

You have to choose one explicitly. That is, you can't say `2 3` and expect 6 (or is it 5?). Instead you have to say `Product 2 Product 3`

Re: Abstraction is expensive

#115

Post by civopsec »

fdgsdfogijq wrote: post #51
BlargMcLarg wrote: post #49

Earlier quoted context omitted.

I wish it was a meme. The things people complained about decades ago are still happening today, and the practitioners are all too eager to turn a 100 line program into a 1000 line one, while taking weeks to test if it does what it should. The average loud dev is a GoF fanatic in love with inaccessible reflection. Double points if their tools are still stuck in a time where stack traces weren't extended to deal with s…

Call me blunt, but ive come to the conclusion most people arent intelligent enough to create complex abstractions

Call me blunt, but this statement feels about as hard-hitting and impactful as someone shouting in a crowd that they like pastrami sandwiches.

Re: Abstraction is expensive

#116

Post by a1369209993 »

garethrowlands wrote: post #114
agentultra wrote: post #103

Earlier quoted context omitted.

Isn't this why fixed, signed integer types don't have a Monoid instance? https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-... For arbitrary sized `Integer` type, which is basically a libgmp arbitrary integer, we also don't have a Monoid.

The main reason Haskell does not define Monoid instances for numbers is that there are two equally valid instances: with 1 and * or with 0 and +. So, instead, there are two newtypes defined: * `Sum` whose `mempty` (identity) is `Sum 0` and ` ` (combining operator) is multiplication; and * `Product` whose `mempty` is `Product 1` and ` ` is addition You have to choose one explicitly. That is, you can't say `2 3` and ex…

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

... Uhh?

Re: Abstraction is expensive

#117

Post by vlunkr »

adamrezich wrote: post #79
vlunkr wrote: post #27

Earlier quoted context omitted.

Agreed, they should probably include their definition of 'abstraction' in the post.

I would've thought that everyone who has done any programming at all would be familiar with the term as used in the article—why would this not be the case?

Choosing the right database technology for your application has nothing to do with abstractions as far as I understand the term. Even if you're just going with the dictionary definition, that doesn't makes sense. An ORM is an abstraction, not a database.

Re: Abstraction is expensive

#118

Post by pickingdinner »

But it's all abstractions. The only issue is who gets to decide. The programmer controls the abstractions they're allowed to code, but everything predefined that they are forced to work with are "specs" that someone else abstracted for them. But even the programmers who worked on the specs are dealing with their own set of "specs" forced upon them by someone else. And these form the abstraction layers.

And if you're working on accounting software, then many of the abstractions you're working with are defined by accounting practices and the IRS. Your job becomes to translate them, and the logic, into software that can automate them, etc.

Whenever you're forced to deal with something, it's expensive. Whenever you're forced to do something, it's expensive, especially when considering the cost of getting it wrong.

Re: Abstraction is expensive

#119

Post by akira2501 »

BurningFrog wrote: post #23

I find this seemingly trivial insight very useful: Everything has costs and benefits, and they need to be weighed against each other. If you look for it, you'll see tons of arguments like "this has costs, so it's bad" and "this had benefits, so it's good". Both are missing half of the analysis!

I've often described the type of Engineering I do as "the art of compromise."
Post reply on HN