On 15 Apr 2008, at 13:28, Michael Neumann wrote:
> You will never ever be able to use Ruby for aviation software, neither
> Lua, Python, Perl etc.

You provide the budget, I'll provide the code ;) Having designed and  
implemented avionics systems I see nothing in Ruby or any other  
scripting language that would stand in the way of using it to do the  
same thing. In fact Lua began its life as a language for device  
control. That's not to say that MRI is particularly suited to the  
task, but the necessary changes could be made if anyone wanted to  
without having to change the language syntax and semantics.

> It's not about slowness. Realtime systems can be slow as long as  
> they meet their deadlines. Indeed, a lot of real-time systems are  
> very slow.
> They use 20 year old technology, no caches, no speculation etc.,  
> just because in real-time systems, you always have to calculate with  
> the
> longest possible execution time, and modern processors only improve  
> average execution time.

It's true that realtime execution is easier when you get the execution  
windows balanced, but it's mostly about coding defensively and knowing  
how to handle failure states and recover when calculations exceed  
their desired execution budget. The latter is particularly important  
as many calculations have unpredictable run-time characteristics.

as for the reason 20 year old technology is so popular, you don't have  
to look much further than the low cost of that generation of  
processors and the low computational requirements of many problems: a  
PIC17C42 for example has all the grunt you could ever want for  
steering a light aircraft, and a Dragonball is more than adequate for  
real-time GPS navigation. Chucking even a Pentium at these jobs would  
be overkill unless you want to run a Windows kernel.

> Well, in the case of safety critical software, you don't want to  
> have runtime exceptions. This software must not have errors, at  
> least it's desirable ;-)

There's nothing wrong with runtime exceptions so long as you figure  
out what the correct fail-safe behaviour of the system is and make  
sure it takes it. In fact for high-spec aviation systems where there's  
a statistical risk of cosmic ray interference flipping bits at run- 
time I'd want to see the fail-safe strategy before I even considered  
the rest of the system desing (although admittedly that was a  
consideration that always made me laugh when I was doing my CAA  
certifications ;).

> Duck-typing doesn't guarantee you anything at compile-time.

True. But nothing guarantees you anything at run-time, including 100%  
compliance at compile-time. That's why most CS and IS degrees have  
lectures explaining the difference between Verification (what your  
compiler does) and Validation (what you do before you start coding).

As a rule of thumb even the highest-quality systems will have one bug  
for every 30000 lines of source code (that's only 1% of the bug  
density in standard shrink-wrap applications) which can amount to tens  
of thousands of defects. These are not 'errors' in the sense that a  
compiler understands them, but genuine misunderstandings of the  
problem space in question that will lead to actively dangerous  
software states.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason