Wow, not the kind of engineering room I'd want to be in. You have to be able to make claims that the other party does not have a complete picture of the situation, and an external critic is indeed going to be vulnerable to the same criticism.
Maybe you would have a point if it were a Linus-style "only a fucking idiot would" rant. But responding to a sincere attempt to defend a design decision as if it were an insult is some prima donna behavior.
I'm moving towards an approach of batch processing more things. What this means in practice is that more of my tasks use limited interactivity - e.g. "draft and redraft" vs "draft and edit". This has the effect of the "yes and" in improv, where I make errors but have to keep going regardless. Working within that mode also means that I can activate on a reflexive, pre-flow state level where I flex the project-management muscles,
not the problem-solving muscles. Flow means I am challenging myself, and with so many years of experience, challenging myself means that I am overcomplicating it.
As well, I'm more likely to treat looking up docs as a research project where I copy relevant snippets of the text into one place for easier reference.
I'm still unhappy with a lot of aspects of how I code, but most of it isn't on the end of the day-to-day editing, but rather things like, "oh, I switched languages again - time to relearn the string library".
The more I think about the "boredom is good" concept, the more I suspect it's flawed. Bored kids get into trouble, especially as they get older. By 18, a very bored kid left to chance will have found an unhealthy outlet like drinking or property theft.
We have a lot of screens now. But it's what one sees and does with the screen that matters. There is an element of media as pollution in this, but it's contrasted against our notion of "the classics". We always end up with a youth that is a mixture of the misspent and the classics.
I've been converted to the "add peripherals" side, personally. The standards are developed enough and the selection is broad enough to dial in whatever balance of price, portability, ergonomics and device features is desired - at the extreme end, a USB OTG hub connecting your full size mechanical keyboard, MMO mouse, graphics tablet, game controllers, and flash drives, and at the other, pocket folding Bluetooth keyboards and mini mice. It turns a phone or tablet into "just a screen" - a viable entry level workstation only held back by software and processing capacity.
"high-performance" is a qualifier worthy of question, though.
If the goal were to write one algorithm to be the fastest implementation, performance would usually equate to having low level control.
If the goal were to do automatic optimization of a wide variety of similar algorithms, then we're in the "actually writing a compiler" territory and then there is little to be gained from defaulting to low-level control.
And there are some options. You could achieve barebones VM protections with Pawn(the language enforces very little otherwise, though). You could use something ref-counted like a TCL implementation, which would allow you to design around linear allocation times. The vast majority are using some kind of tracing collector of course, but I wouldn't say this is a total loss for achieving a combination of real time and memory protection.
My main minus to this is not that it's JS(I'm building a JS fantasy computer too) but that it's a node/react piece, which inspires zero confidence that it will have anything resembling foundational stability in the future.
It was definitely a thing to run multiple screens in a "one-per-task" kind of setup - the real difference is that hardly anything back then networked or multitasked, and so you had to design the workflow you wanted to use specifically around the idea of using all your displays. In the context of any specific application(coding, document editing, CAD etc.) the possibility of a custom tailored solution existed - it just wasn't the highest priority most of the time. You could get a lot of multitasking mileage out of more antiquated technologies like printed documents and pens in tandem with your computer. "Code review" meant literally printing it out and going over it with highlighters like an exam grader. I'm sure it still does in some shops.
My reaction to customizations that shave off seconds is: "so what, it'll be blown away the next time the tech stack changes." I do automate, but there's a subtle difference in goals.
If I automate my personal toolset, I follow the same procedure I use around automation anywhere else: don't start off doing it to save time, do it to increase reliability. I will write small scripts, sometimes one-liner scripts, sometimes largish hundreds-of-lines scripts. But the outcome I am aiming for is that I have a procedure that is documented and puts all the configuration in a place where I can see it, so that when the situation changes, it is fixable. A productivity boost is a frequent byproduct of successfully automating, but it's usually a side component to "reliable and documented". The boost is perceived as reduced friction and increased conceptual integrity: fewer things to check or to accidentally get out of sync, and thus less stress involved.
Focusing on UI being both shiny and fast is likewise often missing the point - which is the case when discussing new hardware. There are order-of-magnitude thresholds for human attention that are important to keep in mind, but hitting a lower attention threshold usually doesn't solve a productivity problem. It creates a case of "wrong solution faster", drawing the user into a fast but unplanned and reactive feedback loop.
See for example the case of writers who like the Alphasmart, a device that makes doing editing so tedious that you don't do it, you just write the draft and edit later.
Game design allows for a rich exploration of design from a philosophical standpoint.
That is, while most games are utilitarian products first(just as most architecture is made to be inhabited and most software is made to be used) the premise of a "game world" or "magic circle" shares something in common with any fiction - that the contents can be decided in a pragmatic fashion, with arbitrary rules.
Most game designs use this power timidly, just reproducing an existing rule set with a new scenario and more product features, but the most engaging stuff aligns all elements towards a coherent concept[0].
And the real tension of game design comes from the negotiation of what the player thinks the game is about(e.g. "what do I do in this game") and what the resulting product actually enables or encourages. Where we recognize "progress" in games it's generally along the lines of shifts from completely symbolic ideas(e.g. lives, score, turn taking) towards fine-grained representations with fast feedback that corresponds to our expectation of reality(texture mapped 3D, immersive VR, physics sims, etc.), but there's a toolbox of symbolic ideas that tends to stick around regardless.
As one SF Chronicle article put it in describing CA Governor Newsom, SF politics are a lion's den that produces strong candidates for the national stage.
Which in perspective says not that SF functions well, but rather that it functions so poorly that you have to have immense skill to survive.
And like other established cities with some history, there is a vein of the upper crust - people whose parents owned property, went to the local prep schools and now own some property themselves. That's a thing that contributes to the quagmire, since it creates more complex entanglements than the basic economics would suggest. A lot of the tech billionaires have made moves to muscle in on this scene, which has perhaps helped it from getting too stagnant, but contributes to its overall incoherence.
In the back of my mind I always hope that a new technology I'm using will fail in a spectacular, obvious fashion as soon as I use it wrongly, because that means that a great number of resources will soon appear to cover all the gotchas.
It's the ones where spotting and debugging the source of the problem depends on fine-grained conceptual understanding, that leads to documentation that gives you a metaphorical blank stare and shrug.
I like to dub this phenomenon the "unnamed skills". There are skills that are categorized and standardized: you can teach someone the poses and movements, the steps to follow, and the concepts to look for. But you can't teach them very much about putting it together into a whole and to apply some techniques in some ways and not others. Direct experience does that, and yet the way in which people interpret their experience leads to the sharp differences in style and overall ability.
Often this comes up in written fiction: authors will describe the characters and their thoughts and motivations in a mode natural to how they perceive things: some authors spin up plots and intrigues at every turn, others focus on raw emoting.
So I tend to view smarts as a personality trait, when we're dealing with healthy folks with no other issues(and realistically, most people are battling something else most of the time without necessarily being aware of it). There's a limited degree of smarter-is-smarter that shows up in testing, and then after that it starts being about personality-driven specializations, the ways in which they overcome problems. The archetypes are easy to spot in school: the student who seems to ignore any lecture or materials and rushes to get help from the teacher or study buddies, versus the student who quietly reads the text and never asks a single question. Both types can get perfect scores in some subjects, but usually not across the board, effortlessly. And as projects grow in scope and cover more skills, awareness of personality-driven limitations becomes more essential to success.
If you haven't yet, try both vitamin D3 and magnesium supplements. They're correlated with generalized mental health issues and some deficiency in both is common.
Comparing difficulty between FM and SID is a bit apples to oranges. The SID has analog variance in its filter, and no two are exactly the same, so a pure DSP implementation has to do rather heavy math to approximate the filter. As a result most people lean on a handful of SID emulation cores because otherwise their emulation is just wrong.
OTOH the things that tend to differentiate implementations of Yamaha's FM are the sample rates, bit depths, and envelopes used, plus any output distortion(YM2612 for example has a well known distortion in its implementation that adds a harsher edge). The core algorithms they use are something a high school student could pick up and do something with, and emulation quality issues are more a matter of it being easy to write an emulation that gets it 98% correct without covering the last steps, since those are details that really need error-for-error reproduction of the original ASICs and boards, including any timing issues - things which frustrate emulator writers everywhere.
The MT-32 sound module(also a Roland creation) was the target device of a lot of PC games circa 1988-1992. The more sophisticated soundtracks would reprogram the built in patches, also using sysex for this operation. Not only that, they would put text messages on the MT-32's display!
With the gaming scenario some distinction between display latency and network latency is worth reviewing. Network latency is something that software can cover for in some degree(to create online experiences there's always some kind of synchronization of different wallclock timelines going on). Display latency is universal, though. A faster display will let the game give you feedback faster, so long as we are talking about feedback in the local experience(so: aiming, movement are commonly predicted on the client, while hit registration often uses a server roundtrip). This separation of responsibilities allowed people to play Counter-Strike 1.x on 200ms dial-up connections back in the 2000's.
When it's a pure video feed you get the impact of all the latency all the time, and that means the problem has to be solved with brute force reduction of bottlenecks everywhere.
So how much latency is enough for responsiveness? This is pretty easy to derive from the common target framerates: for 30hz display, you need 33.3ms. For 60hz, 16.6ms, for 120hz, 8.3ms. Since perceptual latency is known to keep improving up through 144hz it's reasonable to say that we should be looking for only 5-6ms at most, while most broadband connections are still achieving pings in the 20-100ms range, depending on the game and the specific connection. On the very best connections, that is, we can assume a "30hz transparent" video stream, which is fine for casual experiences but severely impacts competitive ability when tested. In many current popular titles this manifests in mechanics that are both latency sensitive and require a server roundtrip, e.g. building in Fortnite.
Maybe you would have a point if it were a Linus-style "only a fucking idiot would" rant. But responding to a sincere attempt to defend a design decision as if it were an insult is some prima donna behavior.