[deleted]
That's not an abstraction, that's a layer of indirection
211–220 of 240 posts
Re: That's not an abstraction, that's a layer of indirection
#212Earlier quoted context omitted.
IMO, I dislike that kind of mixing several concepts into the same name that software engineering is full of. Abstraction means removing details from the thing you present. Generalization means making the same representation valid for several different things. Are abstractions that don't generalize valuable? Well, maybe there is something better to be found, but those are the bread-and-butter of software engineering;…
I would warn against conflating the concept of an interface with an abstraction just as much as I would against conflating generalizations and abstractions. An interface often accompanies an abstraction, sometimes even represents one. But if we get down to definitions, an interface is merely something that you interact with: a function, a class, a network endpoint etc. If you write in machine code, you might not thin…
I agree with what you're saying, and I would phrase it as "write the abstractions that reflect the essential complexity". The whole program should minimally reflect the essential complexity of the problem. Of course actually doing that isn't easy, but the result is obviously a simple solution for a given problem. It becomes another challenge to maintain and refactor: the question of changing problem constraints and being able to minimally change a program to match.
Why are ADTs like stacks, queues, and hashmaps so popular? Why are languages like C or Forth so highly praised for a high ceiling for performance and efficiency? Because they are usually "about as good as it gets" to solve a problem, "what you would've more or less done anyways". Maybe on a GPU, a language like C isn't quite fit, because the problem has changed. Make tools (e.g. CUDA) that reflect that distinct complexity.
Re: That's not an abstraction, that's a layer of indirection
#213Earlier quoted context omitted.
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 t…
Useless? Like the RTX2000 which landed on a comet kind of useless? Or do you mean some other kind of useless. Maybe the controlling radio telescopes kind of useless. That must be it.
[dead]
Re: That's not an abstraction, that's a layer of indirection
#214Earlier quoted context omitted.
While this is how the term is often used, I think it's cavalier use of language and confuses abstraction for modularity , and this linguistic confusion is one of the reasons a lot of programmers write bad "abstractions". Organizing your code into components that are as independent as possible is a good practice and is the pursuit of modularity. A proper abstraction on the other hand, is a generalization that simplifi…
I don't like the mental image of layers. It's not wrong, but it's terribly inclusive of everything that is bad about bad abstractions. Even the worst abstractions will often look kind of nice from the layers angle. I prefer the concept of orthogonality: you have an entire plane where your domain requirements can move in, but the way you make persistence reliable is completely orthogonal to that plane. It should be im…
To add on to your great comment, I've read a few papers that justify your remarks, but some have paywalls and I'll try to condense them anyways.
Parnas' criteria for when to split code into modules[0] is very compelling: modules should enforce information hiding, where the information of each module is how a key decision is implemented. Key decisions should be orthogonal: e.g., encryption shouldn't inform filesystem access and vice versa. This fits in nicely with practices for determining solutions for a given problem: nail down key decisions (or uncertainties around them) early on and encode them through modules and interfaces.
A logical application of Parnas' module criteria is, naturally, in network stacks. According to [1], although coarse program flow generally follows the OSI layers, the fine control flow may hop around quite a bit. For some time people tried to keep the OSI layers as inspiration and use hacks like upcalls to selectively violate layering, which is a sure sign that the layers are unhelpful. Instead, modules should reflect functionality like encryption, NIC interfacing, and routing. Aim for a flatter, horizontal architecture like a B-tree, not a contrived vertical tower with hacks to cross layers "incorrectly". There will be hierachies and layers, but they should be obviously necessary now. Layering is not the end or even the means but merely how things are.
A program's capability (functionality) is determined by the capabilities of its dependencies, and splitting up functionalities well is important. I use this language to relate it to capability-based security[2]. After all, "security" is basically just a stricter form of program "correctness", and just as a terminal emulator's input text handling capability shouldn't have much to do with its window event handling capability because malicious input shouldn't cause dangerous graphics bugs, there isn't much logical reason to have overlap regardless. They govern separate devices, protocols, and purposes. Capabilities along the lines of capability-based security reify the interfaces and provide strict enforcement.
Lastly, flexibility around protocols should be added or discard as given by the precise problem at hand. Don't preemptively choose some extreme, but instead be informed by what is actually desired. It will yield substantial implementation complexity and performance detriments[3] to over-generalize, and of course over-specializing is just inadequate.
[0] https://prl.khoury.northeastern.edu/img/p-tr-1971.pdf
[1] https://ieeexplore.ieee.org/document/662046
[2] https://en.wikipedia.org/wiki/Capability-based_security
[3] https://ieeexplore.ieee.org/document/208098Re: That's not an abstraction, that's a layer of indirection
#215Earlier quoted context omitted.
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 t…
Useless? Like the RTX2000 which landed on a comet kind of useless? Or do you mean some other kind of useless. Maybe the controlling radio telescopes kind of useless. That must be it.
> Like the RTX2000 which landed on a comet kind of useless?
Yeah, in 1983 he designed a chip that was further developed by others for space usage.
> Maybe the controlling radio telescopes kind of useless.
Yeah, which he did in 1970.
Note a pattern here? That this design paradigm holds up pretty well in a primitive computing world when things are simple and demands are low, and is thoroughly useless to keep on promoting today?
Re: That's not an abstraction, that's a layer of indirection
#216To me, the value of abstraction is more about making the code flexible than hiding complexity.
Perhaps, but isn't it flexible because complexity was hidden?
Re: That's not an abstraction, that's a layer of indirection
#217I found this to be a pretty poor article. The article lacks concrete examples and speaks in generalities to explain its core thesis. But without specificity, a reader can nod along, sure in the knowledge that they already are wise and follow this advice and it's everyone else who's out there mucking up code bases with layers upon layers of garbage. I mean, > The next time you reach for an abstraction, ask yourself: I…
I don't know. Sure, examples could be nice. But an article can be imperfect and still be interesting or useful. Also, it's easy to say come up with examples, but I find it hard sometimes.
In any case, I find it a nice article. Will it change how I write code? Maybe, maybe not. But it will change how I review code and talk about abstraction.
Re: That's not an abstraction, that's a layer of indirection
#218>There’s a well-known saying: "All abstractions leak." It’s true. No matter how good the abstraction, eventually, you’ll run into situations where you need to understand the underlying implementation details This is false. One can read up on Theorem's for Free by Wadler to see that not all abstractions are leaky.
Theorems for Free tells you that some abstractions satisfy some mathematical properties (for free!) under some circumstances. If you write down a function with signature {T : Type} -> T -> T then it must be the identity function, if you do not use "malicious" extensions of the type system. But what is the performance of the identity function? Here is an identity function: lambda T, lambda t, if (2 + 2 = 4) then t els…
The point of the abstractions I'm talking about is not to abstract away the computation part of a program, it's to abstract away the types and complexities of the semantics.
Re: That's not an abstraction, that's a layer of indirection
#219Earlier quoted context omitted.
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 t…
Useless? Like the RTX2000 which landed on a comet kind of useless? Or do you mean some other kind of useless. Maybe the controlling radio telescopes kind of useless. That must be it.
Harris RTX2000 is a 8Mhz machine with 16-bit data-path, paged program memory, and 1MB addressable memory. This is really an example of "small machine".
Philae had to choose this CPU because there are very few rad-hard low-power CPUs available (and it's not even that low power by modern standarts, 5 mA/MHz), but I am sure they'd choose something bigger if they could.
As for radio telescope, I am not sure which ones are you talking about, but those environments are not particularly challenging compared to spaceflight, so those run whatever hardware designers like. I am sure some of them used to run tiny 16-bit CPUs, but I'd be surprised to hear new designs run something that old.
Re: That's not an abstraction, that's a layer of indirection
#220Earlier quoted context omitted.
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 t…
The real time visual mixing console that produced many music videos that ran endlessly on MTV back when they actually played music videos, and special effects for blockbuster films like RoboCop and Total Recall, wasn't a "simple thing". https://news.ycombinator.com/item?id=29261868 DonHopkins on Nov 18, 2021 | prev | next [–] Coco Conn and Paul Rother wrote this up about what they did with FORTH at HOMER & Assoc, who…
8 bit, 32KB of RAM (or was it 64?). That's not a large system by any means