Obviously the authors of the Arduino book were reprinting it because they'd seen it somewhere else, where, in turn, it had been copied because someone else had seen it in another source, etc.
But I thought it was extremely poetically true to put that illustration in the Arduino book. That made sense to me.
I try to remember that this decades cool hip software trends might become the next decade's enterprise Java.
And that's the outcome for the successful stuff!
(Doesn't mean you shouldn't get into it though -- if I'd jumped on enterprise java 20 years ago, I'd probably be richer than I ended up by just working on the software I was interested in)
15-25 years ago, there were hip-for-the-time tech influencer bloggers who would write all sorts of stuff about whatever new frameworks and tech were available in the Java world.
If you take all the scary Java Enterprise buzzwords in one of the previous posts on this thread, and look them up, you'll find that they all came about, roughly, between 1999 and 2007.
I don't fully remember what all the hip influencer tech blogs were during that era (I recall "Joel on Software" having been important), but I do remember that people who paid more attention to such things were really into "Enterprise Java Beans" at the time.
So the JVM world might suffer from a bit of an analogous problem. But that world's complexity explosion was decades ago.
My feeling is that backend has always been complex, depending on the scale you were trying to operate at (and how much scale your framework and ecosystem forced you to think about whether you wanted to or not). The best you can do to mitigate it is continually ask "Do I really need my backend to handle the scale I'm designing it for?" and "Is all of the complexity in my preferred stack still necessary, or can some of it be hidden/automated?"
It's a fairly simple algorithm to implement, but there is some wicked-cool analysis behind how fast it is.
It's a super good thing to have in your toolbox for any time you want to do any sort of "simultaneous flood-fill everywhere" or "partition everything" task.
I am primarily a C++ developer. I used to alternate between emacs and eclipse depending on whether I needed IDE functionality or not (you can argue about whether one "needs" an IDE, but when browsing unfamiliar code, "find where this function is used" or "go to where this function is defined" are incredibly useful, and grep doesn't always cut it).
Then a coworker introduced me to this thing called "rtags". You run a daemon that understands clang and (some set of build tools) and it handles your IDE functionality for C++. You then get the right rtags plugin for your particular editor, and use that to glue your rtags to whatever editor you use.
I still use emacs for this, but I am actively looking at the family of more modern emacs-inspired editors, such as sublime, and atom, that represent newer iterations on the old idea of a simple GUI editor with a rich extensible scripting environment.
I am very excited about the idea of a future in which your "IDE" isn't a standalone monolithic piece of software, but something you cobble together out good, minimalist, scriptable editor and a grab bag of services and plugins. I'm almost wondering whether things like Eclipse and Visual Studio actually look a lot like this concept if one looks "under the hood"
I am idly curious, by the way, about things that are like rtags, but for statically-typed languages other than C++.
Obviously the authors of the Arduino book were reprinting it because they'd seen it somewhere else, where, in turn, it had been copied because someone else had seen it in another source, etc.
But I thought it was extremely poetically true to put that illustration in the Arduino book. That made sense to me.
Now form a band!