jungler
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.
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".
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.
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.
Lua is a semantically cleaner alternative but it has relatively less mindshare and hence less third-party support.
Somewhere he explained that he made a custom tool to make and play back a "perfect recording" of his edits.
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.
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.
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.
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.
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.
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.
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.
What gets overlooked in language performance is that you pick a language for what are, in essence, placeholder constructs. The performance matters only in that you need it to be fast enough "off the shelf" that you don't have to start writing a compiler. But you generally aren't prevented from using that approach to boost your existing code, and high performance systems often converge on that strategy in some degree, because it lets you keep maintainable source code and add toggles for debugging and optimization that you won't get from treating the application and compiler code as separate entities.
The Radeon VII is ultimately just a repurposed workstation card given flagship treatment. It's not where AMD's business really is, ever since they went down the route of semi-custom and small dies. While pushing RTX could renew Nvidia's advantages, the only game console they're on these days is the Switch - no raytracing to be seen there. Developers accommodate the Geforce cards for PC releases, but AAA going console-first precludes designing most content around RTX. They've made a lot of moves to try to repurpose high end graphics for other markets, but it looks like it's going to be very rough for Nvidia in the next few years if they can't find a "blue ocean" that needs both speed and programmability.
The "social media loop" that haunts many adults is not really different from whatever cravings kids are going through, and in both cases it can be combated with scheduled activity breaks that involve getting up and doing a bit of housework or going outside for few minutes. It promotes better sleep habits while not really limiting the core activity.
I would definitely not recommend encouraging anyone to go from one sedentary activity(games, Youtube) to another(homework, coding etc.) directly - that's something that makes "screen time" a nebulous timesink.
That is, the act of programming means working on an unfinished thought, something that can reflect some beliefs but compromises on being an exactly true expression of them. And so the weight of philosophical reasoning should appear at design time. What occurs after that is a discovery phase in which you learn all the ways in which your reasoning was fallacious - both bugs and feature decisions.
You will need a solution for producing front end JS/HTML/CSS. This should probably be your starting point in fact - create a site mockup with static pages and no real backend, use that to gain feedback, then build out the real functionality. For JS code Typescript is a very popular option to aid some additional maintainability. There are also many build systems available for compiling finished pages.
When you're ready to have a backend, you can evaluate it separately later. You need a combination of a language, a web server, and a database at minimum. Again, an early site can avoid horizontal scaling and focus on having one good database doing everything and backing everything up reliably. (Focus backend efforts on reliability first!)
Second, design a schedule for yourself that both lets you take out and put away the project. If you aren't hugely inclined to solve programming puzzles that are created by other people's code, it's understandable; the trick is in making it not be the number one priority(because a boring task like this is no longer the fun learning stage of coding), but rather to make it one of many chores on your list. You have a household; there is always something to maintain in it, whether it's dry shoe leather, mildew on the walls, a load of laundry. Allocate 10 minutes each hour to that stuff, then return to the coding with the momentum from that. Huge blocks of screen time never helped anyone. (And yes, overall health matters. Getting more sleep, exercise, correcting a nutritional deficiency, can all be huge for motivation.)
During the coding, aim to finish it badly(placeholder level) and then go back and fix it in steps. These tasks get worse when you have to juggle a whole pile of new abstractions all at once: skip to a preset result and then work backwards from that into something that is configurable. Good code doesn't come out of your forehead fully formed, it takes some iteration.
If you don't have an estimate for how long anything takes, that's also a demotivator. You can calibrate one by finding a similar project, getting its start-to-release dates, and working backwards to get milestone dates. Don't worry about time per task, worry about the overall product coming into shape. Placeholders as milestone goals can help hugely in getting you to dig into the design and make it its best.
But the barriers to entry were high, as well. A state-of-the-art build consistently ran in the $2000 range - you could go cheaper but it often meant being several years in the past at a moment when Moore's Law was steamrolling every assumption in 18 month cycles, and software that kept pace with more and more features. Games in particular heavily targeted the enthusiasts. Many people got into PCs upon experiencing Doom for the first time. And running a server - well, most people were on dial-up lines, and in the early part of the decade, shell accounts, not the PPP connections that gave you full TCP/IP connectivity. If you ran a server, it was most likely part of a school or business connection. And then you had to maintain all of it yourself. The onset of free hosting - first with Geocities style static HTML, and then webpage builders and even PHP scripting, was a kind of early example of Internet commercialization. It allowed lots of folks to make their own web site for the first time, which they promptly filled up with "about me: i am 13 years old and have two dogs. sorry ill finish this later"
There were no real expectations around early Web content, after all. It was whatever you thought you needed to put there, and a consumer-branding mindset hadn't sunk in yet among Web surfers. You explored Web sites because there were no places with upvotes and newsfeeds, just pages you bookmarked and checked regularly in hopes of an update. If you wanted the drip feed of news, mailing lists and Usenet worked better. But gradually publishing and aggregation came into play on the Web, with both traditional news players and the likes of Slashdot, and web forums took up the baton from Usenet of allowing you to engage in topical discussion, except that over time all web forums turned into meta-communities defined by their off-topic discussion.
Then as now, the single most useful thing you could do in most circumstances was to send someone an email.
Since the rise of Minecraft the games themselves have also gradually shifted towards being long-term platforms for streamer content, vs simply providing a fixed experience. Free-to-play economics likewise aim towards maximizing total lifetime value of each user(with a built in expectation of user turnover) instead of marketing towards the initial purchase.
Basically, I now use laptops for games and the desktop for storage/office tasks. The single board desktops are quickly growing out of the RPi-type niche and look increasingly competitive with the traditional ATX platform for this role, and opting for them means that I define my system around the storage and RAM, rather than the multitude of PSU/motherboard/CPU/GPU/case combinations, which is both easier for me and eliminates most instances where components push each other out of their tolerance range. So long as I'm on the same memory and storage, I can replace everything else in the case for <$200. This is really what sold me on the idea; since my existing system fell out of warranty after one year, repair would be the cost of a new board. But if the whole system is the board, then a failure is a forced upgrade.