<story><title>Lisp can be “hard” real time [pdf] (2000)</title><url>https://franz.com/services/conferences_seminars/jlugm00/conference/Talk14_takeuchi.pdf</url></story><parent_chain><item><author>willis936</author><text>Okay, now prove that your program written in Lisp will not miss cycles regardless of the data sent to it for at least the length of the mission.  The issue is in being able to prove a program is deterministic.  Wildcards like schedulers and garbage collectors sharing resources with code that needs to be real time are notoriously difficult to properly set bounds on behavior.&lt;p&gt;If you aren&amp;#x27;t doing that then it&amp;#x27;s not hard real time.</text></item></parent_chain><comment><author>ajross</author><text>That&amp;#x27;s... not really a correct description of &amp;quot;hard real time&amp;quot;.  All system architectures have performance edge cases.  The idea of a &amp;quot;hard&amp;quot; real time system is that those be known and fully characterized, and that they can be mapped to equally-fully-characterized application requirements.  That way you know all the failure modes ahead of time.&lt;p&gt;Not all aspects of a real time system need latency control like you&amp;#x27;re imagining.  It&amp;#x27;s entirely possible to imagine, say, an aircraft autopilot or self-driving system (something that needs ~100ms round-trip latencies to approximate a human pilot) being implemented using a garbage collected runtime, as long as you can guarantee those GC pauses are acceptably small (lots of such systems exist).&lt;p&gt;The same would be a very hard ask of a piston engine controller, where the timing needs are closer to 100us.  Nonetheless the (again to pick an arbitrary example) logging&amp;#x2F;telemetry subsystem of that engine controller doesn&amp;#x27;t need that.  So as long as you have an OS that can partition the engine tasks from the low priority stuff in a reliable way, you can &lt;i&gt;still&lt;/i&gt; imagine a Lisp&amp;#x2F;Java&amp;#x2F;.NET&amp;#x2F;Go&amp;#x2F;whatever runtime being used there.&lt;p&gt;Real time is a design philosophy, not a tech stack.</text></comment>
<story><title>Lisp can be “hard” real time [pdf] (2000)</title><url>https://franz.com/services/conferences_seminars/jlugm00/conference/Talk14_takeuchi.pdf</url></story><parent_chain><item><author>willis936</author><text>Okay, now prove that your program written in Lisp will not miss cycles regardless of the data sent to it for at least the length of the mission.  The issue is in being able to prove a program is deterministic.  Wildcards like schedulers and garbage collectors sharing resources with code that needs to be real time are notoriously difficult to properly set bounds on behavior.&lt;p&gt;If you aren&amp;#x27;t doing that then it&amp;#x27;s not hard real time.</text></item></parent_chain><comment><author>kaba0</author><text>Why would it be hard? If anything a fat runtime makes it easier - see hard-real time JVMs used in military tech.&lt;p&gt;Hard real time is not too hard in general as it is usually combined with quite low performance-requirements. Boundedness itself is the important property, as opposed to soft-real time which is much more finicky (video games, audio).</text></comment>