-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eleanor McHugh wrote:
| On 16 Apr 2008, at 03:40, Phillip Gawlowski wrote:
|> I wouldn't fly in an aeroplane that relies on the runtime to catch
|> errors.
|
| I wouldn't fly in an aeroplane where a runtime error couldn't be caught.
| That's because there will be runtime errors regardless of how well
| designed and analysed the code is.

Of course. But solely relying on trusting that the runtime will do The
Right Thing isn't the way to go. Error catching and handling is a tool
to the user, not a silver bullet.

|> Take the Space Shuttle as an extreme. Does the language breed perfection
|> in the Shuttle's source, or is it the process NASA uses?
|
| That process includes implementing fail safe conditions for runtime
| errors. Without those the developers would be legally culpable for any
| deaths that occurred as a result of their negligence. Waking up in the
| morning knowing that is surprisingly good at focusing the attention on
| detail...

And introducing large amounts of stress that are counterproductive. ;)

I doubt, however, that there is a single undefined state in the Space
Shuttle's software. No uncaught exception, no reliance on language
features to do the right things, but well understood and diligent
implementation of those, together with rigorous QA.

|
| The court is still out on TDD and BDD. None of my friends in the
| avionics industry has much confidence in these techniques, but the main
| goal there is systems which don't kill people or destroy millions of
| dollars of equipment. The only argument I see in favour of that
| particular brand of agile development is that the problems involved are
| essentially human rather than technical and the code is just a way of
| forcing people to make decisions in a timely fashion.

As I said in another reply in this thread, methodologies are but one
skill set. What works for a billing system doesn't necessarily work for
a cruise missile or the A380. Different problem domains require
different solutions.

And Agile's domain is in the face of changing or evolving requirements.

I suspect that aeronautical problems are well understood, and
requirements (while not easily) determined well before the first line of
code is written.

As far as I understand it, TOPCASED does work like this:
http://www.heise-online.co.uk/open/TOPCASED-System-development-using-Open-Source--/features/110028

| Also whilst QA techniques transfer fairly well between languages, if
| given the choice between two languages with different levels of
| verbosity it is always advisable to use the less verbose language:
| there's less to test, less to go wrong, and less likelihood of muddling
| your (often vague) requirements.

No silver bullets. Picking the right tool for the job is key.

But what use is a less verbose language, if only a handful of people
understand it well enough? Sure, often there is time to train, but
sometimes there is not.

Trade offs are everywhere, and none of them are easy.


- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan

~ - You know you've been hacking too long when...
...you dream you have to write device drivers for your refrigerator,
washing machine, and other major household appliances before you can use
them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgGAlYACgkQbtAgaoJTgL+D8wCfV3C36WahI5nn8mGme3aOzjw+
TaMAn3ocQN5tmE8FebmGbdeE0EvpaZR8
=RCFz
-----END PGP SIGNATURE-----