A Reddit comment with no academic sources listed should not be considered a meaningful source.
On a similar note, your 2nd source is a blog post about concepts in the book Dune, and contains only a couple references to historic societies - it's not an academic source.
I'm not taking a position on the OP title, but I would find an actual academic study on the possibility of such a phenomenon interesting.
> On a similar note, your 2nd source is a blog post about concepts in the book Dune, and contains only a couple references to historic societies - it's not an academic source.
> Dr. Bret C. Devereaux is an ancient and military historian who currently teaches as a Visiting Lecturer in the Department of History at the University of North Carolina at Chapel Hill. He has his PhD in ancient history from the University of North Carolina at Chapel Hill and his MA in classical civilizations from Florida State University.
That said, it seems like the "hard times create strong men" part of the formulation has been debunked more thoroughly than the "good times create weak men" part.
I don't feel like the title reflects the essay very well -- I almost clicked past it, but I'm glad I read it. It's an interesting question: what, if anything, are you losing by standing on the shoulders of the giants who preceded you? I don't think that the essay is completely correct, though. After all, some current engineers built Electron for others to build on top of. The expertise still exists. I do think it's probably diluted, however. The size of the industry just keeps increasing, and most of that new work is not foundational stuff.
I've worked in a bunch of different parts of the stack over the course of my career. One thing I found is that often the "hard" work of previous decades is largely encapsulated, sometimes it's pretty difficult to make further incremental gains. I'm currently working on a large performance critical C/C++ backend code base, which unfortunately has the problem that most of the bugs are related to memory management. I'd be hard pressed to decide whether all of the defensive coding we've added over the years carries more overhead than a bump-allocated tracing GC or not.
There are hard problems on the frontier, Electron makes it possible to create one app which runs on every platform and every modality. How we manage the complexity of hundreds of different UIs in one app is still largely unsolved (but getting better). Pretty soon we'll have non-JS lang's compiling to WASM as a standard method of developing UI. Managing dependencies which were built to target a POSIX system in WASM is still unsolved, but once we solve it - it'll be possible to do all sorts of crazy things like shipping libtorch to the browser :)
> Lack of expertise? They’ve been building music players for 18 years now!
The developers working on that music player haven’t. Companies are just that, groups of people. Being a part of one doesn’t automatically grant you the powers of every developer there before you.
There are developers there that don’t have the slightest clue what Quartz, AppKit, and UIKit are doing.
There are certainly people outside of Apple that sometimes have more expertise in those spaces than people coming in!
Another example, particularly painful to me personally: Assassin's Creed. The team behind the game changed and instantly from my favourite games of all time it turned to creating games I can't suffer through playing.
There are many other examples, but this one is especially sad for me. Sometimes I wish brands weren't transferable between people.
Apple's Swift project seems to be generating a tremendous second system effect at the company. Although some things are actually better, many (most?) are new veneers on old ideas, with a notable lack of historical perspective. The wheel turns, I suppose.
My counterargument: The real work is not increasing complexity, but boiling down complex concepts into ones that can be worked with and exchanged easily. This is why math is so vital, and why tools that 'hide' layers of abstraction so powerful.
A physical metaphor: Shipping containers don't make things harder to ship, even though untold millions of containers contain a lot of heavy things inside of them. It's not about the box full of stuff, it's the entire vastly more efficient global shipping industry! This is, I assume, why Docker uses the container metaphor.
> Knowledge does not automatically transfer to the next generation.
That's not untrue, but overly simplifies the problem by observing a very narrow slice of a much larger whole. Knowledge does not automatically transfer between people of the same generation, or the same project, or the same team! The misapplication and over-reliance of Taylorism especially in software development projects deserves blame. Ultimately this traces to a root cause in the pedagogy of work evident in the largely uncritiqued popular conception of work methodology itself. Specifically the construction of "collaboration of specializations leads to efficiencies" ignores its creation of systemic forgettance. This oft quoted passage sums it up nicely:
... the relation of the producers to the sum total of their own labour
is presented to them as a social relation, existing not between
themselves, but between the products of their labor.
That is to say that the transfer of knowledge, being one of among myriad social relations, takes a back seat to the relations between software components in this scenario.
One of my favorite talks was named something like "Writing for Engineers" and had a drawing of what we think human knowledge is (a constantly expanding universe of "things" that we discover), versus what human knowledge actually is (a filter upon a greater set of facts out there that represents the collective views of a group of people alive at the time. Things can appear and disappear from it, knowledge gained does not remain in the public consciousness unless someone actively knows and cares about it).
Just reinforces the thought that discovering something is not valuable in and of itself. You have to also make other people care about the thing that you have discovered.
Absolutely! It brings up and makes accessible some really great epistemological questions that we tend to pass by. For me, it's easy to focus on the grand scientific process at the expense of examining how forgettance operates at the small group or even individual level. Forgetting Practices in the Data Sciences[1] for example, helped me start to identify these sites in my own system of work.
I've noticed some times the AppleTV Netflix app, there can be a lag between what I have selected and what the tv thinks I have selected. Clicking on one movie will load the movie next to it, or I'll see the title of one movie with the picture of another. I'm not sure if they're trying to load things asynchronously to improve UI responsiveness or what, but I often wondered about the abstractions or design choices that led to a bug like that when a gallery view should be a problem we solved in the 20th century.
> Docker and Electron […] are just compromised attempts to hide accumulated complexity from developers because it became impossible to deal with.
This is very well put and explains why these tech technologies are both reviled and loved. Many here know both how small and fast these containerized and electron apps could be while also knowing how many years they struggled to internalize the complexities they hide.
Docker is a management layer for images and instances, itcs cli is in effect apis for controlling machines, & we hadnt really had one before. Being able to programmatically talk about machines has vastly increased our capabilities.
Electron isnt hiding anything: it's bringing a well defined & well loved virtual machine with plenty of capabilities to new targets. It's enabling something that already is, to happen on a new place. And adding a toolkit for adding yet more capabilities.
https://www.reddit.com/r/AskHistorians/comments/hd78tv/does_...
https://acoup.blog/2020/02/28/collections-the-fremen-mirage-...