Sure, but this is a engineered solution we're talking about. Don't you think it should use the engineering terminology?
I'm not calling out this person specifically, I'm just hopeful that we can use more precise terms instead of overloading existing ones. I think "streaming API" or "live streaming" is a better fit for these purposes.
If we're going to play that game, then "real time" may never have come to refer to the hard system guarantees as you think of them.
The earliest computers didn't even include an operating system, never mind one with real time guarantees as we think of them today. You submitted your program on paper tape (later, punch card.) and hours later, you'd get the output. This was the batch computing era. The idea of getting a (soft) real time response from the computer (which was the size of a room), was unheard of.
As computers evolved, real time systems came to refer to computers that operated on the opposite of batch computing. The user could interact with the system in "real time", rather than having to wait hours after submitting the job for the results.
Later on came the distinction between systems with hard real time (vs soft) guarantees. Computers didn't have the same CPU speed that we have access to today, so even audio processing required special real time guarantees.
Eventually, "hard real time" was shortened to "real time", which takes us to today.
Systems which have existed since the dawn of computing such as banks back in the 50's, or the IRS, still hold onto the batch vs real time nomenclature, possibly because batch processing systems still exist. Banks still process records nightly in batches, some even still run on newer versions of the same IBM mainframes, though some are starting to move to "soft" real time systems. (If you ever wondered why it can takes days for a check or bank wire transfer to clear, this is why.)
So your argument is that the term "real-time" didn't exist back in the mainframe and batch processing days, so we can't give it a technical meaning now?
Look, this is simple: literally all of our technical textbooks and engineering manuals agree on what "real-time" means.
If people were running around calling their smart phones "desktop computers", or "laptops", or "mainframes" you'd be very confused I think. Sure, smart phones and desktops these systems have a lot in common, even run a lot of the same code, and sure our phones have more computing power than mainframes back in the day, but overloading this term conveys literally no benefit and actually creates confusion.
Of course I'm pissing into the wind here, but whatever, if I've convinced even a couple of people to be more precise with their terminology, I'm fine what that.
> real time systems came to refer to computers that operated on the opposite of batch computing. The user could interact with the system in "real time", rather than having to wait hours after submitting the job for the results.
As someone who grew up with those systems, this is a major mis-statement of the terms.
In the early days the terms were "batch", "online", or online's near-synonym "interactive".
Real-time has always meant bounded-latency and guaranteed execution since the earliest days, to actual computer systems engineers.
It is a true statement that many people use the term differently today - much to the detriment of precise communication between humans. But there was never any confusion about the term until perhaps the 90's and widespread interactive screen-based applications.
I'm not calling out this person specifically, I'm just hopeful that we can use more precise terms instead of overloading existing ones. I think "streaming API" or "live streaming" is a better fit for these purposes.