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

131–140 of 144 posts

Re: Abstraction is expensive

#131

Post by a_c »

pclmulqdq wrote: post #67
nine_k wrote: post #5

Lack of abstraction is also expensive: try writing something large in assembly. I'd say that lack of a language / system of notions adequate to the subject area is expensive. The desire to describe things in a way that's efficient for a particular class of problems leads to invention of various frameworks. Say, Rails makes you hugely productive at solving a particular type of problems (see [Shopify]), though it's les…

I wrote the piece. The argument I tried to get across is: "You must use abstractions. Find the ones whose values align with your interests." I find people frequently torturing their problems into abstractions they like rather than finding abstractions that work for their applications, and this is very much wrong. Edit: By the way, the examples are fairly low-level databases because that's what I know about. If I knew…

The same can be said about organization. Too much abstraction, managers and teams, is harming performance. Too little abstraction is hard to coordinate. Putting abstraction in front of problem, throwing problem to previously arbitrarily setup team with or without the right mix of expertise for the current problem. Spinning up libraries/framework automatically when starting a new project, forming teams that worked for previous company. Abstraction that's so leaky that either require code change to the library or "octopus" code that link up functionality from 7 different other libraries, team formed without regarding a problem boundary where each problem need cross team coordination of seven department. Software engineering and organization design have very much in common

Re: Abstraction is expensive

#134

Post by TurboHaskal »

BlargMcLarg wrote: post #49
fdgsdfogijq wrote: post #46

I think its a meme now to hate abstraction. In big tech I see it as a justification to build parallel systems that do almost the same thing. Abstraction done well is where technical leverage comes from. Abstraction done poorly is where technical debt/bad technology comes from. Management prefers the safe route of gating their engineers from abstraction to get the work done with certainty, the trade off being less tec…

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…

I blame GoF for giving us the two worst decades in software. But in my experience, the average loud dev has mutated into the TDD + DDD fanatic. These insufferable simpletons won't only criticize your end result when it doesn't align well with their preferred abstractions but also tell you _how_ to reach that end.

Something is also brewing with functional concepts and category theory trickling down... and it doesn't smell good.

Re: Abstraction is expensive

#135

Post by dandelany »

btilly wrote: post #80
pclmulqdq wrote: post #67

Earlier quoted context omitted.

I wrote the piece. The argument I tried to get across is: "You must use abstractions. Find the ones whose values align with your interests." I find people frequently torturing their problems into abstractions they like rather than finding abstractions that work for their applications, and this is very much wrong. Edit: By the way, the examples are fairly low-level databases because that's what I know about. If I knew…

One point about abstractions that you might want to make in a future article is that developers tend to discount the cost of all abstractions that they have internalized. Therefore when they get to a new environment, they immediately try to recreate and incorporate the abstractions that they used previously. However these abstractions are not free. They are not free for performance. They are not free for debugging. A…

Hard agree. On the flipside, devs also tend to overestimate the cost of already-implemented abstractions that they haven’t yet internalized, leading to complaints and lengthy refactors when they could have just spent the time to learn the abstraction…

Re: Abstraction is expensive

#136

Post by Arch-TK »

falcolas wrote: post #101
Arch-TK wrote: post #43

Earlier quoted context omitted.

It's unfortunate that you have only ever experienced abstractions which grow in size over time. The best abstractions out there are ones which operate well together to solve a large set of problems in the smallest amount of complexity (local to any given abstraction) as well as the smallest amount of total complexity at any given abstraction layer, as well as the smallest amount of total solution complexity. Now yes,…

You're right, I have never seen an abstraction which hasn't grown with time. I think that's because either an abstraction project either ends, or receives constant feature requests. Kind of a grow-or-die mentality as applied to software development.

It rarely happens in for-profit situations but people are slowly wisening up to the cost of technical debt for longer term projects especially.

Re: Abstraction is expensive

#137

Post by nequo »

a1369209993 wrote: post #116
garethrowlands wrote: post #114

Earlier quoted context omitted.

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?

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

Re: Abstraction is expensive

#138

Post by agentultra »

a1369209993 wrote: post #108
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.

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

`Integer` would be better but is still somewhat finite because computers.

Re: Abstraction is expensive

#140

Post by PeterCorless »

vlunkr wrote: post #117
adamrezich wrote: post #79

Earlier quoted context omitted.

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.

Here's an example of a database abstraction choice: the data model.

Do you treat data as a series of normalized row-based data tables with joins optimized for strongly consistent OLTP? [PostgreSQL]

Or as a denormalized row-based key-key-value single table optimized for eventually consistent OLTP? [ScyllaDB]

Or as a denormalized column-based single table optimized for OLAP? [Pinot]

Or as a denormalized key-value optimized for in-memory caching? [Redis]

And so on for document stores, or property graphs, etc.

Each of these design choices then gives way to the abstractions of implementation.

Post reply on HN