And to add to the confusion, the term "responsive" was co-opted to mean "adaptive layout".
So now it's perfectly possible to have this conversation:
- This site is not responsive.
- Sure it is, try resizing your browser.
- No, I mean that it takes too long to react to user input.
- Oh, you mean it should be real time?
- No, nothing even close to real time -- I'd be happy if something happened in less than 1 second when I click this button...
- So, real time then.
If we stick with the video game example, it has a real time goal: having frames displayed at the target framerate. The "soft" aspect comes from the fact it's tolerable for a game to fail some deadlines. It's certainly undesirable, but a few minutes of frame-y gameplay is not game-breaking.
Depending on the particular system, there will be tolerances of how frequently and in which ways a realtime deadline can be missed without constituting an overall failure of the system.
The idea of deterministic jitter might be foreign to those who've never done real time embedded work. By this I mean the idea that, for example, a certain output or result is specified to happen at 100us +/- 1.2us from a condition being met. Here +/- 1.2us being the acceptable response jitter. Very often you find yourself using NOP's to balance both sides of a conditional in machine language in order to control jitter.
From experience I'd say that the exact definition of "real time" is project dependent. This definition is very different in, for example, a control panel processor vs. a 5 axis milling machine capable of rigid tapping.
The trick was we noticed that the OS (RBM or Real-Time Batch Monitor from SDS, later Xerox) would mask all interrupts for short periods of time. This would delay the timer interrupt by an amount that would lead to an error in the voltage read (e.g., the rapid upward spike of the QRS wave) that would be significantly more than the quantization error.
Thus, with each release of the OS, I would have to track down the instructions that would mask the three classes of interrupts, and change the code so as not to mask the timer interrupt. This was, of course, delivered in a form of 80 column cards.
Not everyone gets to work on problems of this sort. To adapt the NASA list to JS seems a bit of a stretch.
I've started working on similar types of technology recently, but purely by wandering into it by accident.
The fields that come to mind when I think of real-time outside of HFT, though, are control systems and digital signal processing (DSP). While DSP doesn't necessarily need to be real-time if you're doing it for analysis, doing DSP live definitely requires real-time programming knowledge since signals are often expressed in the time domain and any delay in computation of a discrete element will propagate in how the signal is interpreted. For example, if the signal you're processing is a sound signal (like music), and you are doing software-based DSP on the signal before it reaches the playback device, it better be real-time or any delay spikes will ruin the playback. This is why OS X is so popular with the music industry and especially DJ's; the Mach kernel has really good real-time support and a pretty good real-time software based DSP library for building apps.
https://oracleus.activeevents.com/2014/connect/fileDownload/...
Also check out Real-Time Java: https://en.wikipedia.org/wiki/Real_time_Java
"Correct" execution doesn't just mean error free, but it also means that code needs to execute deterministically both in terms of near-complete referential transparency as well as execution time. This is what is referred to as "real time computing" in CS, a term that has recently been made homonymous by UI/UX/front-end designers to describe responsiveness in high-latency systems like the web.
All of the inferences about how these rules aid static analyzers are good and correct, but a lot of these rules are also important to achieving deterministic execution time; memory management being the big one due to its complete lack of determinism both in computation result and computation time. Sticking code in a real-time OS doesn't really matter unless the code itself is also real-time kosher.
I don't bring this up to gripe, but only bring it up because it wasn't something I was familiar with until I started working on torque controlled walking robots a few years ago where the feedback loop has a real-time constraint, and it has since taken over my life and I find it to be a very fascinating aspect of computer science that almost nobody ever talks about. Achieving real-time deadlines in a program can be quite challenging and very often making something "faster" than its deadline is not even close to the same thing as making sure it always makes its deadline. It really changes the way you think about performance, execution time, program optimization, etc.