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

The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to <i>generalization</i>.<p>In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an &quot;abstraction&quot;&#x27;s role in hiding information. But a <i>good</i> abstraction does more than simply hide detail, it <i>generalizes</i> particulars into a new kind of &quot;object&quot; that is easier to reason about.<p>If you keep this in mind, you&#x27;ll realize that having a lot of particulars to identify <i>shared properties</i> that you can abstract away is a prerequisite. The best abstractions I&#x27;ve seen have always come into being only <i>after</i> a significant amount of particularized code had already been written. It is only then that you can identify the actual common properties and patterns of use. Contrarily, abstractions that are built upfront to try and do little more than hide details or to account for potential similarities or complexity, instead of <i>actual</i> already existent complexity are typically far more confusing and poorly designed.

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

Perhaps this is a minor nitpick, but<p>&gt; Abstractions are also the enemy of simplicity. Each new abstraction is supposed to make things simpler—that’s the promise, right?<p>Not exactly, no. The purpose of abstraction is to hide implementation detail, and thereby insulate one part of the codebase&#x2F;application&#x2F;system from variations in another. Graphics APIs for example - yes your code may be simpler for not having to deal with the register-level minutiae of pushing individual triangles, but the core benefit is that the same code should work on multiple different hardware devices.<p>Good abstractions break a codebase up into compartments - if you drop a grenade in one (change the requirements for example), then the others are unaffected and the remedial work required is much less.

I got a piece of advice writing UI code a long time ago: Don&#x27;t marry your display code to your business logic.<p>I&#x27;d like to say this has served me well. It&#x27;s the reason I never went for JSX or other frameworks that put logical code into templates or things like that. That is one abstraction I found unhelpful.<p>However, I&#x27;ve come around to not taking that advice as literally as I used to. Looking back over 25 years of code, I can see a lot of times I tried to abstract away display code in ways that made it exceedingly difficult to detect why it only failed on certain pieces of data. Sometimes this was sheep shaving tightly bound code into generic routines, and sometimes it was planned that way. This is another type of abstraction that adds cognitive load: One where instead of writing wrappers for a specific use case, you try to generalize everything you write to account for all possible use cases in advance.<p>There&#x27;s some sort of balance that has to be struck between these two poles. The older I get, though, the more I suspect that whatever balance I strike today I&#x27;ll find unsatisfactory if I have to revisit the code in ten years.

TCP is great. Long chains of one-line functions that just permute the arguments really suck. These both get called abstraction, and yet they&#x27;re quite different.<p>But then you hear people describe abstraction <i>ahem</i> abstractly. &quot;Abstraction lets you think at a higher level,&quot; &quot;abstraction hides implementation detail,&quot; and it&#x27;s clear that neither of those things are really abstractions.<p>As the OP mentions, we have a great term for those long chains of one-line functions: indirection. But what is TCP? TCP is a <i>protocol</i>. It is not just giving a higher-level way to think about the levels underneath it in the 7-layer networking model. It is not just something that hides the implementations of the IP or Ethernet protocols. It is its own implementation of a new thing. TCP has its own interface and its own promises made to consumers. It is implemented using lower-level protocols, yes, but it adds something that was fundamentally not there before.<p>I think things like TCP, the idea of a file, and the idea of a thread are best put into another category. They are not simply higher level lenses to the network, the hard drive, or the preemptive interrupt feature of a processor. They are concepts, as described in Daniel Jackson&#x27;s book &quot;The Essence of Software,&quot; by far the best software design book I&#x27;ve read.<p>There is something else that does match the way people talk about abstraction. When you say &quot;This function changes this library from the uninitialized state to the initialized state,&quot; you have collapsed the exponentially-large number of settings of bits it could actually be in down to two abstract states, &quot;uninitialized&quot; and &quot;initialized,&quot; while claiming that this simpler description provides a useful model for describing the behavior of that and other functions. That&#x27;s the thing that fulfills Dijkstra&#x27;s famous edict about abstraction, that it &quot;create[s] a new semantic level in which one can be absolutely precise.&quot; And it&#x27;s not part of the code itself, but rather a tool that can be used to describe code.<p>It takes a lot more to explain true abstraction, but I&#x27;ve already written this up (cf.: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30840873">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30840873</a> ). And I encourage anyone who still wants to understand abstraction more deeply to go to the primary sources and try to understand abstract interpretation in program analysis or abstraction refinement in formal verification and program derivation.

This is a great point. Most modern software is riddled with unnecessary complexity which adds mental load, forces you to learn new concepts that are equally complex or more complex than the logic which they claim to abstract away from.<p>I find myself saying this over and over again; if the abstraction does not bring the code closer to the business domain; if it does not make it easier for you to explain the code to a non-technical person, then it&#x27;s a poor abstraction.<p>Inventing technical constructs which simply shift the focus away from other technical constructs adds no value at all. Usually such reframing of logic only serves the person who wrote &#x27;the abstraction&#x27; to navigate their own biased mental models, it doesn&#x27;t simplify the logic from the perspective of anyone else.

&gt; Think of a thin wrapper over a function, one that adds no behavior but adds an extra layer to navigate. You&#x27;ve surely encountered these—classes, methods, or interfaces that merely pass data around, making the system more difficult to trace, debug, and understand. These aren&#x27;t abstractions; they&#x27;re just layers of indirection.<p>“No added behaviour” wrapper functions add a lot of value, when done right.<p>First off, they’re a good name away from separating what you’re doing from how you’re doing it.<p>Second, they’re often part of a set. E.g. using a vector for a stack, push(x) can be just a call to append(x), but pop() needs to both read and delete the end of the vector. Push in isolation looks like useless indirection, but push&#x2F;pop as a pair are a useful abstraction.<p>A consequence of adding these two points together is that, if you have a good abstraction, and you have a good implementation that maps well to the abstraction, it looks like useless indirection.<p>Another consequence is that those pass-through wrapper functions tell you how I think the implementation maps to the domain logic. In the presence of a bug, it helps you determine whether I got the sequence of steps wrong, or got the implementation wrong for one of the steps.<p>Ultimately, the two aren’t completely independent —indirection is one of the tools we have available to us to build abstractions with. Yes, people misuse it, and abuse it, and we should be more careful with it in general. But it’s still a damned useful tool.

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>&gt; a bad one turns every small bug into an excavation.</i><p>I find that I need to debug my abstractions frequently, <i>while I’m first writing my code</i>, then I never need to dig into them, ever again, or they do their job, and let me deal with adding&#x2F;removing functionality, in the future, while not touching most of the code.<p>That’s why I use them. That’s what they are supposed to do.<p>Because they are abstractions, this initial debugging is often a lot harder than it might be for “straight-through” code, but is made easier, because the code architecture is still fresh in my mind; where it would be quite challenging, coming at it without that knowledge.<p>If I decide it’s a “bad abstraction,” because of that initial debugging, and destroy or perforate it, then what happens after, is my own fault.<p>I’ve been using layers, modules, and abstractions, for decades.<p>Just today, I released an update to a shipping app, that adds some <i>huge</i> changes, while barely affecting the user experience (except maybe, making it better).<p>I had to spend a great deal of time testing (and addressing small issues, far above the abstractions), but implementing the major changes was insanely easy. I swapped out an entire server SDK for the “killer feature” of the app.

I don&#x27;t consider TCP an abstraction at all. The abstraction is the unix API over it, and then again, the<p>&gt; ssize_t send (int socket, const void *buffer, size_t size, int flags)<p>is not a nice one. When was the last time you had the data in a buffer, wanted to send it over to the peer at the other side, but didn&#x27;t mind that it&#x27;s not sent in it&#x27;s entirety ? So you have to write a loop over it. Also, is the call blocking or not ? (well, you&#x27;ll have to read the code that created it to know, so that&#x27;s no fun neither).<p>However, it does prove the point the author is trying to make: good abstractions are hard to find!<p>Anyway, I tried to think of a better example of a good abstraction and found the &quot;Sequence&quot; that&#x27;s available in plenty of programming languages. You don&#x27;t need to now what the exact implementation is (is it a list, a tree, don&#x27;t care!) to be able to use it. Other example I found were Monoid and Monad, but that&#x27;s tied to the functional paradigm so you lose most of the audience.

Just thinking on my feet as to how I separate abstractions from indirections and it seems to me that there&#x27;s a relatively decent rule of thumb to distinguish them: When layer A of code wraps layer B, then there are a few cases:<p><pre><code> 1) If A is functionally identical to B, then A is a layer of indirection 2) If A is functionally distinct from B, then A is likely an abstraction 3) If A is functionally distinct from B, but B must be considered when handling A, then A is a leaky abstraction. </code></pre> The idea is that we try to identify layers of indirection by the fact that they don&#x27;t provide any functional &quot;value&quot;.

Pretty easy to give generic advice without examples.<p>“Write more tests, but not too many”<p>“Use good abstractions where appropriate?”<p>“The next time you reach for an abstraction, ask yourself: Is this truly simplifying the system? Or is it just another layer of indirection?”<p>It’s easy to create a strawman here (the FactoryAdaptorMapper or whatever) but in reality this kind of generic advice doesn’t help anyone.<p>Of <i>course</i> people want to use good abstractions.<p>That’s <i>not</i> the problem.<p>The problem is being able to tell the difference between generic arbitrary advice (like this post) and how <i>your specific code base</i> needs to use abstractions.<p>…and bluntly, the only way to know, is to either a) get experience in the code base or b) read the code that others have left there before you.<p>If it’s a new project, and you’re not familiar with the domain you’ll do it wrong.<p>Every. Single. Time.<p>So, picking “good” abstractions is a fools game.<p>You’ll pick the wrong ones. You’ll have to refactor.<p>That’s the skill; the advice to take away; how to peel back the wrong abstraction and replace it with your next best guess at a good one. How to read what’s there and understand what the smart folk before did and why.<p>…so, I find this kind of article sort of arrogant.<p>Oh, you want to be a great programmer?<p>Just program good code. Use good abstractions. Don’t leave any technical debt. Job done!<p>…a few concrete examples would go a long way here…

&gt; That’s the sign of a great abstraction. It allows us to operate as if the underlying complexity simply doesn&#x27;t exist.<p>While I generally agree with the sentiment that current day software development is too indirection heavy, I&#x27;m not sure I agree with that point. All abstractions are leaky and sure good abstractions allow you to treat it like a black box, but at some point you&#x27;d benefit from knowing how the sauce is made, and in others you&#x27;ll be stuck with some intractable problem if you lack knowledge of the underlying layers.

While I too like to marvel at the TCP&#x2F;IP stack as an example of abstraction done right, it would be unwise to think an abstraction is only &quot;good&quot; if you get it right first time.<p>The real point of abstraction is to enable software that is <i>adaptable</i>. If you are ever sure you can write a program the first time and get it perfect then you don&#x27;t need to bother with any of this thinking. We do that all the time when writing ad hoc scripts to do particular tasks. They do their job and that&#x27;s that.<p>But if you ever think software will continue to be used then you can almost guarantee that it will need to change at some point. If it is just a tiny script it&#x27;s no problem to write it again, but that&#x27;s not going to be acceptable for larger programs.<p>So this necessarily means that some layer or layers of your well-architected application <i>will</i> have to change. That does not mean it was a bad abstraction.<p>Abstraction is not about hiding things, it&#x27;s about building higher levels of language. It enables you to work on individual layers or components without breaking the rest of the system. It very much should not be hiding things, because those things are likely to need to change. The bits that really don&#x27;t change much, like TCP, are rarely written into application code.

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&#x27;ve done this before, heck even the Java standard library is guilty of this problem. When a class has a full set of get&#x2F;put&#x2F;has&#x2F;remove methods, it is often not actually hiding the complexity of its component data structures.

How did &quot;abstraction&quot; and &quot;hiding complexity&quot; become perceived as such fundamental virtues in software development? There are actual virtues in that ballpark - reusable, reliable, flexible - but creating abstractions and hiding complexity does not necessarily lead to these virtues. Abstraction sounds no more virtuous to me than indirection.

Abstraction hides detail, but at what coat?<p>A network close call at a high level closes a network socket. But at the tcp level there&#x27;s a difference between close and reset. Which do you want? Your api has removed that choice from you, and if you look you will have no idea if rhe close api does a close or a reset.<p>Is the difference important? If depends. If you have a bunch of half open sockets and run out of file descriptors then it becomes very important.<p>Another example: you call read() on a file, and read 10k bytes. Did you know your library was reading 1 byte at a time unbuffered? This abstraction will&#x2F;can cause massive performance problems.<p>My favorite one is when a programmer iterates over an ORM-enabled array. Yes, let&#x27;s do 50,000 queries instead of one because databases are too complicated to learn.<p>Just like any tool, abstraction has costs and benefits. The problem is that lots of people ignore the cost, and assume the benefit.

I 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&#x27;s <i>everyone else</i> who&#x27;s out there mucking up code bases with layers upon layers of garbage. I mean,<p>&gt; The next time you reach for an abstraction, ask yourself: Is this truly simplifying the system? Or is it just another layer of indirection?<p>Is anyone reading this truly going to alter their behavior? If I could recognize that my abstraction was &quot;just another layer of indirection&quot; as simple as that, obviously I wouldn&#x27;t have added it in the first place!

Let&#x27;s not forget about a particularly frustrating kind of &quot;level of abstraction&quot;: the bespoke interface to a part of the code that has side effect, and that has exactly two implementation : one in the production code, and one in the tests.<p>If I were to create a language tomorrow, that&#x27;s the one aspect where I would try something that I have not yet found elsewhere : can you make it so that you can &quot;plug&quot; test doubles only for test, but keep the production path completely devoid of indirection or late binding.<p>(I&#x27;m curious if you know of a language that already does that. I suppose you can hack something in C with #ifdef, of course...)

While I wholeheartedly agree with the premise, the article doesn&#x27;t really say anything other than &quot;TCP good, your abstraction bad, don&#x27;t use abstraction&quot;.

Reminds me of an old Java Android project I encountered.<p>EVERY class implemented an interface. 98% of interfaces had one implementation.<p>Every programmer was applying a different programming pattern. A lot of abstractions seemed incomplete and did not work.<p>Proguard (mostly used for code obfuscation for Android apps) definitions were collected in the top module even though the project had multiple modules. Half of the definitions were no longer needed and the code was badly obfuscated. Problems were solved by continuesly adding classes and checking what sticks.<p>The UI was controlled by a stateful machine. State transitions were scatter everywhere in the code with lots of conditions in unforeseen places.<p>Legacy code was everywhere because no one wanted to risk a very long debugging session of an unforseen change.<p>No API definitions. Just Maps that get send via REST to URLs.<p>By biggest mistake was to not directly rewrite this project when I entered the team. We did after one year.

Classic post in this genre: <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20151217104831&#x2F;https:&#x2F;&#x2F;zedshaw.com&#x2F;archive&#x2F;indirection-is-not-abstraction&#x2F;" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20151217104831&#x2F;https:&#x2F;&#x2F;zedshaw.c...</a>

The article seems to go with the premise that abstractions are most often carelessly introduced when there is an obvious alternative that is simpler and more performant.<p>Yes, abstractions have a cost that will accumulate as they are layered.<p>But simple elegant solutions are not free. They are hard to come with, so they often need large amount of dedication ahead of any coding. And as long as we don&#x27;t deliver anything, we have no clue what actual requirements we miss in our assumptions.<p>The road to reach the nice simple solutions is more often than not to go through some some clunky ugly solutions.<p>So rather than to conclude with &quot;before running to abstraction think wisely&quot;, I would rather recommend &quot;run, and once you&#x27;ll have some idea of what was the uncharted territory like, think about how to make it more practical for future walks.&quot;

Interesting read, although I don&#x27;t agree with everything. I like the distinction between different qualities of abstractions, made in the beginning. The following bashing of abstractions is too generalized for my taste.<p>The best part comes close to the end:<p>&gt; Asymmetry of abstraction costs<p>&gt; There’s also a certain asymmetry to abstraction. The author of an abstraction enjoys its benefits immediately—it makes their code look cleaner, easier to write, more elegant, or perhaps more flexible. But the cost of maintaining that abstraction often falls on others: future developers, maintainers, and performance engineers who have to work with the code. They’re the ones who have to peel back the layers, trace the indirections, and make sense of how things fit together. They’re the ones paying the real cost of unnecessary abstraction.

While I think it&#x27;s good the pendulum is swinging toward a more restrictive approach to abstractions, we&#x27;ve (and I&#x27;ve) certainly been leaning a bit too much toward just solving every problems by adding a layer of indirection around it, and such onion-layered designs tend to (as the metaphor implies) cause a lot of tears when you cut through them. That said, it&#x27;s not like abstraction itself is bad.<p>A big part of the problem is arguably that IDEs make code navigation easier, which has us adding all these indirections and discover only when it&#x27;s too late what a horrible maze we&#x27;ve built. Being more judicious about adding indirection really does help force better designs.

I wish this article had more examples&#x2F;details; as it is, it is kind of .. abstract

I suggest there are three types of layer that one passes through<p>Abstraction - this thing of rare beauty<p>Decision - often confused for abstraction and wrapper, this is best thought of as a case statement in a function. They are wildly better in my opinion than lots of classes<p>Wrapper - either fluff like getters and setters or placeholders for later decisions (acceptable) or weird classes and instances that the language affords but tend to be confusing - what is called indirection in the article<p>Tools, utils, libraries - these are I classify as handles &#x2F; affordances for other code to use - maybe they add layers but they add a single way in to the nice abstraction above.

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. -Doug McIlroy

Wow... That was a lot of text without much depth to it.<p>[Edit] To make my criticism more precise: The text mostly rephrases it&#x27;s central point a few times and presents these rephrasings as arguments.

I&#x27;m not sure what it&#x27;s called (abstraction vs. indirection) but I dislike when everything needs a class&#x2F;object with some odd combination of curried functions. Some programming languages force this on you more than others I think? As a contrived example &quot;StringManager.SlicingManager.sliceStringMaker(0)(24)(myStr)&quot;, I&#x27;ve seen code that reminds me of this and wonder why anyone uses a language where this not only an acceptable idiom, but a preferred one.

Lots of crud apps add 3-tier architecture that end up something that could be 2 tier.<p>People add it just in case but the case never materializes- for some probably do but ones I worked with not.

I can&#x27;t help but wonder whether the problem is subjective, to each person and what they need to accomplish at the time. What is cognitive load and indirection to one at one time is a simple abstraction to another at another time.<p>And so I wonder if a solution to this is for editors to be able to represent the code differently, depending on what the person&#x27;s needs are at the time.

When discussing the definition of abstraction, Koppel&#x27;s article &quot;Abstraction: Not What You Think It Is&quot; offers a helpful framing and disambiguation.<p><a href="https:&#x2F;&#x2F;www.pathsensitive.com&#x2F;2022&#x2F;03&#x2F;abstraction-not-what-you-think-it-is.html" rel="nofollow">https:&#x2F;&#x2F;www.pathsensitive.com&#x2F;2022&#x2F;03&#x2F;abstraction-not-what-y...</a>

Indirection serves a purpose as well. One that is related to, but not the same as abstractions. When you add a layer of indirection, you make it easier to, say, delete or change every item X instead of iterating through everything.<p>Unnecessary or redundant levels of indirection are bad, just like unnecessary or wrong abstractions are. But when applied correctly, they are useful.

Shameless plug: a while ago I made a video explaining the idea of abstraction in computer science, and it seems to be helpful for beginners: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;_y-5nZAbgt4" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;_y-5nZAbgt4</a>

The goal of an abstraction should be to make reasoning about the code easier, generally that means hiding complexity but that shouldn&#x27;t be the goal.<p>In my opinion a common issue in programming is premature abstraction without understanding the interactions as a whole.

GangBang-Abstractions would be a good name. Abusive, damaging the respective micro-biome ( parts of the code&#x2F;system ) almost irreversibly and passing around the data for brutal telemetric exploitation ...

&gt; When was the last time you had to debug TCP at the level of packets? For most of us, the answer is never.<p>Who are you people who never have to debug TCP problems? I&#x27;ve had to do it on multiple occasions.

Another criticism would be the time spent to compile those abstractions, even if in fine the &quot;zero cost&quot; goal _at runtime_ is reached.

Chuck Moore, the creator of Forth, was famous for implementing solutions without layers of abstraction.

Every problem can be solved by adding a layer of abstraction. Except for the problem of having too many layers of abstraction.

It starts with a strong point that abstraction is not indirection, but then slips back into using the terms interchangeably.

A good abstraction shouldn&#x27;t make its usage shorter, it should make the proof that the usage is correct shorter.<p>This usually means the total amount of assumptions needed to prove everything correct is decreased. (when the code is not actually formally verified, think of &quot;proof length&quot; as mental capacity needed to check that some unit of code behaves as intended)

To me, the value of abstraction is more about making the code flexible than hiding complexity.

The author misses the whole point of abstractions, and that is a layer B that covers layer A so completely that no one using layer B needs to know how layer A works <i>at all</i>, except for those working on the layer A&#x2F;B bridge.<p>For example, binary logic is a perfect abstraction over semiconductor physics. No one doing computer science needs to understand anymore the complexities of voltages and transistors and whatever. TCP is a perfect abstraction over IP. Memory as a big array of bytes is a perfect abstraction over the intricacies of timing DRAM refreshes.<p>And that&#x27;s about it. No one reading this post has written an abstraction ever. (a leaky abstraction is not an abstraction). So yes, actually, abstractions are free, and they don&#x27;t leak. <i>That&#x27;s the whole point</i>. The problem is that what you call an abstraction isn&#x27;t an abstraction.<p>Computer science&#x27;s complete failure to create a new abstraction since like TCP intrigues me. Why don&#x27;t we have a system X that abstracts over memory accesses so well that <i>no one</i> needs to know anymore how caches or memory locality works? Why aren&#x27;t there entire subfields studying this?

Nice to see hacker news return to its roots.

What about java?

Without more details his position rubs me the wrong way.<p>As somebody who has done a huge amount of &quot;fix this bug&quot; and &quot;add this feature&quot; 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&#x27;s own &quot;design pattern&quot; as it is a practice that gets repeated throughout a code base to solve various problems.<p>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&#x27;t find all the copies at first.<p>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&#x27;d been able to get that far.<p>Granted the speed demon won&#x27;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.<p>It is also healthy to have &quot;fear of framework planets&quot;, a horrible example is react-router which has gotten up to incompatible version 7 because (i) it&#x27;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&#x27;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.<p>Those folks will say various versions of react-router support React Native, SSR, etc. We don&#x27;t use any of those where I work, I don&#x27;t care.<p>It is a very good prop bet that you can dramatically speed up so-and-so&#x27;s program by switching from AoS to SoA.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;AoS_and_SoA" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;AoS_and_SoA</a><p>(If it&#x27;s a Java program, you eliminate the overhead of N objects to start with)<p>but it&#x27;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<p><a href="https:&#x2F;&#x2F;duckdb.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;duckdb.org&#x2F;</a><p>would make that harder.

&gt;There’s a well-known saying: &quot;All abstractions leak.&quot; It’s true. No matter how good the abstraction, eventually, you’ll run into situations where you need to understand the underlying implementation details<p>This is false. One can read up on Theorem&#x27;s for Free by Wadler to see that not all abstractions are leaky.