I think that's a pretty bold claim, that it'd be different every time. I'd think the output would converge on a small set of functionally equivalent designs, given sufficiently rigorous requirements.
And even a human engineer might not solve a problem the same way twice in a row, based on changes in recent inspirations or tech obsessions. What's the difference, as long as it passes review and does the job?
One could argue that's a cynically accurate definition of most iterative development anyway.
But I don't know that I accept the core assertion. If the engineer is screening the output and using the LLM to generate tests, chances are pretty good it's not going to be worse than human-generated tech debt. If there's more accumulated, it's because there's more output in general.
Turn off swipe typing in the keyboard settings, and tap typing works a bazillion times better. It's like toggling a completely different codebase behind the keyboard and resetting it back to when blind-tap and autocorrect actually functioned as expected.
I assume the code that checks for tap vs start-of-swipe is to blame. I have no idea why that would cause word recognition and/or autocorrect to work so differently, but it seemingly does.
I've noticed the iOS keyboard has fundamentally different tap recognition based on whether swipe typing is enabled.
It looks the same but behaves differently enough that I have a hard time believing it shares code. When I turn off swipe, my tap accuracy goes MASSIVELY up, and a lot of the autocorrect screwiness seems to abate considerably. I can go back to blind thumb typing.
That said, swipe is so useful, I’ve left it on, and I deal with the degraded tap behavior. But maybe that’s a trade-off for you to consider.
Yeah, once OS-9 came out we got some decent game ports too. That’s where I discovered Epyx Rogue! It was very late in the lifespan of the system though.
C64/128 was what I was thinking of more than anything re 8-bit competition, keeping in mind I’m talking mid-late 80s by this point. I do also remember Atari 800 (and later) doing considerably better than you imply. But you’re right, Apple captured the early-mid 80s gaming market nicely.
I learned assembly on a 6809 (TRS-80 CoCo) platform. It was only later that I really appreciated how cool of a CPU it really was.
It’s a shame that Tandy missed the boat on including coprocessors for game support in their computers, especially that one. If they’d just included decent audio and maybe something for sprite management it would’ve been highly competitive.
California banned potassium brominate as a food additive last year, but it doesn’t go into effect until 2027.
The FDA finally banned brominated vegetable oil very recently so maybe they’ll get to the rest of it too. Assuming they can make rules anymore, anyway.
I think there's a good reason for the function keyword to be abbreviated.
We know that when people read lines of text, they pay a lot of attention to the beginning and the end and comparatively less attention to the middle. One result is that lines with common prefixes tend to blur together. To get around this, you want the reader to encounter the unique portion of the line ASAP, which makes it desirable that any kind of necessary prefix be brief.
Upshot is you want the function signature to be what you see as you scan down the left side of the page, so it does make sense to keep the function keyword particularly concise.
And even a human engineer might not solve a problem the same way twice in a row, based on changes in recent inspirations or tech obsessions. What's the difference, as long as it passes review and does the job?