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

That's not an abstraction, that's a layer of indirection

fhur.me

Post reply on HN
Print view View original

141–150 of 240 posts

Re: That's not an abstraction, that's a layer of indirection

#141

Post by bluGill »

0x696C6961 wrote: post #122
mattmanser wrote: post #104

Earlier quoted context omitted.

No. Just no. This is the exact thought process that leads to unnecessary abstraction. This is the attitude that the article is criticizing. A good rule of thumb is never abstract unless you genuinely have done the same thing twice already. i.e. only write an abstraction after you've written the boring, simple, concrete, implementation twice and are about to write it a third time.

The rule of three should obviously not be applied to well known data structures and algorithms ...

If the well known data structures and algorithms are not provide by your language get a better language.

There are exceptions. If you are implementing the language it is your job to write them. It is useful as a student to implement the basics from scratch. Your language may decide something is not allowed and thus not implement it (a doubly linked list is almost always a bad idea in the real world. Likewise you don't need to provide all the sorting algorithms)

Re: That's not an abstraction, that's a layer of indirection

#142

Post by Sesse__ »

astrobe_ wrote: post #79
voidhorse wrote: post #43

The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to generalization . In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an "abstraction"'s role in hiding information. But a good abstraction does more than simply hide detail, it generalizes particulars into a new kind of…

Yes, abstraction and generalization are properties you'd rather look for the second time around . Someone was already warning about this 25 years ago [1]: You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the…

Have you ever looked at how useless Chuck Moore's stuff is? Like, the chip designs are of the type “384 independent Forth chips with tiny amounts of RAM and mediocre interconnects, and if you want to actually do anything with them, you'll need to use 128 of them to program your own DDR3 controller”. Or, he demonstrates how awesome Forth is by showing that you can do “the guts of a disk driver” in five lines, except that it's the dog-slow PIO mode.

It turns out that if you can just change the problem statement, then sure, you can write very simple things. But if you have a real problem to solve (and you can't just say “no, I want to solve a simpler problem”), the Chuck Moore way of thinking doesn't really produce, well, good solutions. It simply doesn't scale to anything large, and not everything can be made small.

https://yosefk.com/blog/my-history-with-forth-stack-machines... (2010) is a fairly interesting experience from someone on the outside trying to work in the same way. It… didn't work that well.

Re: That's not an abstraction, that's a layer of indirection

#143

Post by SleepyMyroslav »

jcelerier wrote: post #130
mattmanser wrote: post #104

Earlier quoted context omitted.

No. Just no. This is the exact thought process that leads to unnecessary abstraction. This is the attitude that the article is criticizing. A good rule of thumb is never abstract unless you genuinely have done the same thing twice already. i.e. only write an abstraction after you've written the boring, simple, concrete, implementation twice and are about to write it a third time.

At no point in my life my code has been made worse because I've used an existing sort function instead of writing a buggy one

If we ignore 'buggy' part I think you projecting current good state back into not so good old times. I am pretty sure you will not replace radix sort that uses domain knowledge of reduced value range with qsort circa C++98.

Things became much better after relatively recent improvements in generalist sorting libraries: when pattern defeating quick sort variants became norm, when mostly sorted cases got covered ...

Tbh I do have a case from 2013-16 when I regret not doing it for one AAA project on ps4.

Re: That's not an abstraction, that's a layer of indirection

#144

Post by rauljara »

I wish articles like this had more examples in them. In between “this thin wrapper adds no value but a lot of complexity”, and “this thin wrapper clarified the interface and demonstrably saved loads of work last time requirements changed” is an awful lot of grey area and nuance.

I did like the advice that if you peak under the abstraction a lot, it’s probably a bad one, tho even this I feel could use some nuance. I think if you need to change things in lots of places that’s a sign of a bad abstraction. If there is some tricky bit of complexity with changing requirements, you might find yourself “peeking under the hood” a lot. How could it be otherwise? But if you find yourself only debugging the one piece of code that handles the trickiness, and building up an isolated test for that bit of code, well, that sounds like you built a wonderful abstraction despite it being peaked at quite a bit.

Re: That's not an abstraction, that's a layer of indirection

#145

Post by PaulHoule »

Without more details his position rubs me the wrong way.

As somebody who has done a huge amount of "fix this bug" and "add this feature" on existing code bases I think excessive use of cut and paste is the worst problem in the industry. Cut-and-paste is the devil's own "design pattern" as it is a practice that gets repeated throughout a code base to solve various problems.

When it comes to bugs repetition means a bug might have 13 copies throughout the code and you could easily get the ticket sent back 2 or 3 times because you didn't find all the copies at first.

Repetition (together with poorly chosen abstractions) also causes features that should add in complexity to multiply, as if I have 3 versions of a function and now something can vary 5 ways I now have 15 functions. In a good design you might pass one of 8 functions to a 9th function. Repeat this a few times and one guy has 98 functions and the other guy would have had 13200 if he'd been able to get that far.

Granted the speed demon won't like all that function calling, right now I am thinking about writing a big switch statement for a CPU emulator, I get it, for you there is code generation.

It is also healthy to have "fear of framework planets", a horrible example is react-router which has gotten up to incompatible version 7 because (i) it's the kind of thing you can write in an afternoon (it would take more time to write good documentation but... take a look at that documentation) and (ii) the authors never liked any of the frameworks they created. More than once I have dug into a busted app written by a fresher where there was a copy of react-router and there were some use's from it in use but they had bypassed react-router and parsed document.location directly to figure out what to display. The very existence of a bad framework creates a kind of helplessness.

Those folks will say various versions of react-router support React Native, SSR, etc. We don't use any of those where I work, I don't care.

It is a very good prop bet that you can dramatically speed up so-and-so's program by switching from AoS to SoA.

https://en.wikipedia.org/wiki/AoS_and_SoA

(If it's a Java program, you eliminate the overhead of N objects to start with)

but it's tricky to implement arbitrary algorithms, my mental model to do it is to build programs out of relational operators (even in my head or on paper) SQL is one of the greatest abstractions of all time as I can write a SQL query and have it be run AoS or SoA or some hybrid as well as take advantage of SIMD, SMT, GPU and MP parallelism. 10 years ago I would have said I could have beat any SQL engine with hand-optimized code, today products like

https://duckdb.org/

would make that harder.

Re: That's not an abstraction, that's a layer of indirection

#146

Post by mightyham »

mrkeen wrote: post #118
mightyham wrote: post #6

I forget which programming talk I watched which pointed this out, but one extremely common example of this in Java is recreating subsets of the Collections API. I've done this before, heck even the Java standard library is guilty of this problem. When a class has a full set of get/put/has/remove methods, it is often not actually hiding the complexity of its component data structures.

Good example of a bad abstraction. If you're speaking the language (or "abstraction") of sets, you should see certain terminology: union, intersection, disjunction. These words are not part of the Java Set interface.

I would actually argue that the Collections API itself is a pretty good abstraction. It is often the case that conceptually I just want to work with multiple things and properties like order, duplicates, random access, etc. are not particularly important (in fact, requiring them adds inherent complexity). It's very useful that a vast amount of the standard library data structures conform to this interface or can create data views that conform to it.

Re: That's not an abstraction, that's a layer of indirection

#147

Post by agentultra »

masklinn wrote: post #49
chii wrote: post #38

Earlier quoted context omitted.

> some good ol’ fashioned information hiding and separation of concerns. that's exactly what you do to implement an abstraction isnt it?

In the same way wood is used to build a house. That you used wood doesn’t mean you built a house.

Abstractions require theorems/laws/properties/rules… whatever you want to call them.

Indirection is about providing a common language, and interface if you will, for talking to different implementations.

Separating concerns is another strategy altogether for managing resources.

Re: That's not an abstraction, that's a layer of indirection

#148

Post by mkoubaa »

rauljara wrote: post #144

I wish articles like this had more examples in them. In between “this thin wrapper adds no value but a lot of complexity”, and “this thin wrapper clarified the interface and demonstrably saved loads of work last time requirements changed” is an awful lot of grey area and nuance. I did like the advice that if you peak under the abstraction a lot, it’s probably a bad one, tho even this I feel could use some nuance. I t…

The way to tell whether an abstraction is good or bad is to develop good taste. Engineers with good taste have intuition about these things.

You are not going to acquire good taste from reading an article.

Re: That's not an abstraction, that's a layer of indirection

#149

Post by 29athrowaway »

astrobe_ wrote: post #82
29athrowaway wrote: post #52

Earlier quoted context omitted.

Computers are to manipulate data. Data = representations = abstractions This article is so fundamentally lost that it forgets what computers are for. Computers exist to implement abstractions.

You are confusing too many things. "10" is the representation of a data; "0xA" is another representation of the same data. Not being able to touch something doesn't make it an abstraction. Light is not an abstraction, a contract is not an abstraction. 10 is not an abstraction, it is an ordinal [1]. "Isomorphism" is an abstraction. It doesn't name a particular data or value, but a class of functions that share common…

Number notations and the glyphs and conventions used in them are abstractions.

10 in a database record of a warehouse system may be an abstraction for 10 items of a given type in a warehouse.

Re: That's not an abstraction, that's a layer of indirection

#150

Post by mkoubaa »

havkom wrote: post #127

I have seen tons of ”abstractions” in recently created code bases from ”senior developers” which in actual fact is only titanic-grade mess of complicated ”indirection”. Many people nowadays are unfortunately not fit to work in software development.

I disagree with nowadays. It has always been the case.
Post reply on HN