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

61–70 of 144 posts

Re: Abstraction is expensive

#61

Post by agentultra »

cloogshicer wrote: post #36
agentultra wrote: post #24

Earlier quoted context omitted.

> it is rarely fully understood I beg to differ. Case in point: type classes, the Monoid type class, and Monoids as the mathematical concept; all well understood, proofs of their existence and properties are stated exactly, and when implemented by a compiler behaves exactly as expected when the program is executed. This is precisely what people mean when they say "abstraction is the essence of progamming"... ... when…

I'm one of those programmers you mentioned. Could you help me? I'm genuinely trying to learn more about this. What is the precise mathematical definition of the term abstraction? Any links to good resources are appreciated.

> Mathematical abstraction is the process of considering and ma­nipulating operations, rules, methods and concepts divested from their refe­rence to real world phenomena and circumstances, and also deprived from the content connected to particular applications.

https://journals.openedition.org/philosophiascientiae/914?la...

Re: Abstraction is expensive

#62

Post by deckard1 »

dlivingston wrote: post #25
ghaff wrote: post #8

Earlier quoted context omitted.

The headline is sort of misleading. It is (appropriately) primarily about inappropriate abstractions. As you say, some abstractions are unavoidable. Even assembly language is an abstraction.

> Even assembly language is an abstraction Is this true? I thought assembly mapped 1-to-1 with actual HW instructions. If so, assembly wouldn't be an abstraction, it would be an interface.

> I thought assembly mapped 1-to-1 with actual HW instructions.

on x86 it's a 1-to-many relationship. There are, for example, many different MOV instructions that can be encoded based on the parameters used. All assemblers I know of hide this from the user, as well as featuring labels, macros, etc. which are not defined by the hardware at all. For the most part, the x86 assembler hides the details of prefix bytes and ModR/M+SIB from the user. Some assemblers are quite advanced and if you took them just a few logical steps beyond where they are you would end up with C.

Re: Abstraction is expensive

#63

Post by auggierose »

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…

GoF = Game of Failure?

Re: Abstraction is expensive

#64

Post by gpderetta »

auggierose wrote: post #63
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…

GoF = Game of Failure?

Gang of Four, as the authors of the Design Patterns book are known (and by extension the book itself).

Re: Abstraction is expensive

#65

Post by cloogshicer »

agentultra wrote: post #61
cloogshicer wrote: post #36

Earlier quoted context omitted.

I'm one of those programmers you mentioned. Could you help me? I'm genuinely trying to learn more about this. What is the precise mathematical definition of the term abstraction? Any links to good resources are appreciated.

> Mathematical abstraction is the process of considering and ma­nipulating operations, rules, methods and concepts divested from their refe­rence to real world phenomena and circumstances, and also deprived from the content connected to particular applications. https://journals.openedition.org/philosophiascientiae/914?la...

Thanks for the link!

Re: Abstraction is expensive

#66

Post by [deleted] »

eterm wrote: post #58
dlivingston wrote: post #25

Earlier quoted context omitted.

> Even assembly language is an abstraction Is this true? I thought assembly mapped 1-to-1 with actual HW instructions. If so, assembly wouldn't be an abstraction, it would be an interface.

If you're not manually setting voltages on different pins then at some level it's an abstraction.

[deleted]

Re: Abstraction is expensive

#67

Post by pclmulqdq »

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 about web frameworks, I would have used those instead.

Re: Abstraction is expensive

#68

Post by travisjungroth »

cloogshicer wrote: post #17

Even though many people call abstraction 'the essence of programming', it is rarely fully understood. Maybe no human on the planet really understands it. I've long had an essay in me about this topic that I really need to put to paper soon. Here is the brief version of that essay: * Programming is about building theories/models of the problem. Source code largely has no value by itself [1] * It is very difficult, if…

I've had similar thoughts. Extremely condensing things, I'd see lots of value in:

* Better code folding, so you can cram more info into source code but also hide it easily.

* Function signatures with "types" that are arbitrary predicates and optional generators.

* Function signatures with properties e.g. this binary function is commutative over type X.

* Combine those and you can name algebraic structures.

* "Enforce" this all through property based testing.

IMO, this would make code that's much easier to reason about than untyped code while being more approachable and flexible than other typing systems.

Re: Abstraction is expensive

#69

Post by pclmulqdq »

dlivingston wrote: post #25
ghaff wrote: post #8

Earlier quoted context omitted.

The headline is sort of misleading. It is (appropriately) primarily about inappropriate abstractions. As you say, some abstractions are unavoidable. Even assembly language is an abstraction.

> Even assembly language is an abstraction Is this true? I thought assembly mapped 1-to-1 with actual HW instructions. If so, assembly wouldn't be an abstraction, it would be an interface.

This is true. Ignoring the labels, macros, and directives, there are many ways in machine code to encode most common x86 instructions (zeroing a register even has many possible assembly instructions!). Assemblers pick the best encoding.
Post reply on HN