3 ms·

Real-time means something specific: every operation has a hard limit for upper bounded time. I'm working on an embedded system right now; they typically cannot

Real-time means something specific: every operation has a hard limit for upper bounded time. I'm working on an embedded system right now; they typically cannot use garbage collection, because any GC pauses will utterly destroy the project's real-time guarantees. This board's microprocessor has an external hardware watchdog, which reboots the whole system unless I reset a timer every 2.5 msec or less. This is a reasonable limit, because if the program is unresponsive for too long, people may die. (It's automotive hardware.) I think calling anything running in Javascript and across a network "real-time" is a bit misleading. What you mean is "soft real-time", which is far more forgiving.

starwed 14y ago
The phrase "real-time" means something very different to most people. When you try to "correct" them by invoking a narrow definition only used within a particular domain, it just comes across as pointless pedantry.
- silentbicycle 14y ago
  I agree it sounds pedantic, but think about how muddled discussions areabout what "object-oriented programming" means. "real-time" is a well-established term and actually means something really specific. Diluting it doesn't benefit anyone.
  - deleted 14y ago
    [deleted]
  - lobo_tuerto 14y ago
    So there can only be one meaning? No different meaning depending on the context? ... http://en.wikipedia.org/wiki/Real-time http://en.wikipedia.org/wiki/Real-time I'd say this is real-time in the context of the interwebs, against the usual request-response cycle.
pilgrim689 14y ago
Sys admins have been weeping but slowly getting over the abuse of "cloud" for a while now... safety-critical software engineers will have a shoulder to cry on! In all seriousness, there's a range of of real-time systems (soft to hard) and systems that contain a mix of these requirements. You can argue that these new "real-time!" javascript systems are soft real-time systems. i.e. they contain a soft real-time constraint for state to propagate to clients before a deadline, after which the system starts losing its quality.
mayop100 14y ago
(Firebase founder here) I used to work for an RTOS company, so I do understand where you are coming from. Real-time has different meanings in different contexts though. For an operating system it means hard guarantees on response times. Over a public network this is impossible, so it instead means that data is being pushed to clients as quickly as possible. The "soft real-time" phrasing might be accurate, but it is a distinction that is probably not helpful, as I think it would confuse more people than it would help, and people in the RTOS world know the difference anyways.
- forgotAgain 14y ago
  ... this is impossible, so it instead means ... The lack of engineering rigor in that statement taken with the inherent security issues in re-broadcasting messages from a public client to other public clients would make me very leery of using your product.
  - mrkurt 14y ago
    Is "engineering rigor of statements" always a big part of your criteria for using products?
    - alinajaf 14y ago
      It is when it comes from the founder of a company that sells itself as a 'scalable realtime backend for your web-app'.
    - forgotAgain 14y ago
      Yes, always. Isn't it for you?
hising 14y ago
I get your points for the category of software you are referring to, however I am pretty sure that there will be a common understanding round the subject of "real-time web" and from my point of view I dont see how that can in any way interfere or make things harder for people writing real-time software using non-web-tech. I find it unlikely that the big web developer community will use a new terminology to describe what they are building in order to please the old-school real-time developers.
sitkack 14y ago
I am trying to promulgate a neologism of near-time, like real but a little more relaxed. Like the version of time in the CAP theorem. Soon but not like, soon within a bounds. Soon. Real-time needs to be taken within a context. Your realtime is probably way sloppy for like say laser that starts fusion reactions. If I were baking a pizza, my watchdog could be set to 5 seconds and be ok (provided the thermal inertia of the oven wasn't ridiculous and my heat source wasn't the said laser). Near-time. The future is in the near.
tripzilch 14y ago
Your definition is correct, but Real-time can mean different things in different contexts. For instance, I never hear anyone argue when a Demoscene production is called "real-time" (as they nearly always are), that it should in fact be called "soft real-time" (which is what they really are in the context you're talking about--framerates can drop). So while you're technically correct (the best kind of correct), failing to acknowledge it's perfectly acceptable to use the term "real-time" in other contexts as well, is just going to make you pedantically correct (which is not a very good kind of correct).

starwed 14y ago

The phrase "real-time" means something very different to most people. When you try to "correct" them by invoking a narrow definition only used within a particular domain, it just comes across as pointless pedantry.

silentbicycle 14y ago
I agree it sounds pedantic, but think about how muddled discussions areabout what "object-oriented programming" means. "real-time" is a well-established term and actually means something really specific. Diluting it doesn't benefit anyone.
- deleted 14y ago
  [deleted]
- lobo_tuerto 14y ago
  So there can only be one meaning? No different meaning depending on the context? ... http://en.wikipedia.org/wiki/Real-time http://en.wikipedia.org/wiki/Real-time I'd say this is real-time in the context of the interwebs, against the usual request-response cycle.

pilgrim689 14y ago

Sys admins have been weeping but slowly getting over the abuse of "cloud" for a while now... safety-critical software engineers will have a shoulder to cry on! In all seriousness, there's a range of of real-time systems (soft to hard) and systems that contain a mix of these requirements. You can argue that these new "real-time!" javascript systems are soft real-time systems. i.e. they contain a soft real-time constraint for state to propagate to clients before a deadline, after which the system starts losing its quality.

mayop100 14y ago

(Firebase founder here) I used to work for an RTOS company, so I do understand where you are coming from. Real-time has different meanings in different contexts though. For an operating system it means hard guarantees on response times. Over a public network this is impossible, so it instead means that data is being pushed to clients as quickly as possible. The "soft real-time" phrasing might be accurate, but it is a distinction that is probably not helpful, as I think it would confuse more people than it would help, and people in the RTOS world know the difference anyways.

forgotAgain 14y ago
... this is impossible, so it instead means ... The lack of engineering rigor in that statement taken with the inherent security issues in re-broadcasting messages from a public client to other public clients would make me very leery of using your product.
- mrkurt 14y ago
  Is "engineering rigor of statements" always a big part of your criteria for using products?
  - alinajaf 14y ago
    It is when it comes from the founder of a company that sells itself as a 'scalable realtime backend for your web-app'.
  - forgotAgain 14y ago
    Yes, always. Isn't it for you?

hising 14y ago

I get your points for the category of software you are referring to, however I am pretty sure that there will be a common understanding round the subject of "real-time web" and from my point of view I dont see how that can in any way interfere or make things harder for people writing real-time software using non-web-tech. I find it unlikely that the big web developer community will use a new terminology to describe what they are building in order to please the old-school real-time developers.

sitkack 14y ago

I am trying to promulgate a neologism of near-time, like real but a little more relaxed. Like the version of time in the CAP theorem. Soon but not like, soon within a bounds. Soon. Real-time needs to be taken within a context. Your realtime is probably way sloppy for like say laser that starts fusion reactions. If I were baking a pizza, my watchdog could be set to 5 seconds and be ok (provided the thermal inertia of the oven wasn't ridiculous and my heat source wasn't the said laser). Near-time. The future is in the near.

tripzilch 14y ago

Your definition is correct, but Real-time can mean different things in different contexts. For instance, I never hear anyone argue when a Demoscene production is called "real-time" (as they nearly always are), that it should in fact be called "soft real-time" (which is what they really are in the context you're talking about--framerates can drop). So while you're technically correct (the best kind of correct), failing to acknowledge it's perfectly acceptable to use the term "real-time" in other contexts as well, is just going to make you pedantically correct (which is not a very good kind of correct).