for example where type inference is used, like in Haskell or
F# (or to some extent in C# 3.0)
IIRC D is capable of doing some type inferencing too. But D is still
on my to-be-learned list.
On Wed, 2008-04-16 at 17:45 +0900, Matt T. wrote:
I’d much rather be damn sure and also have exception handling for what
I don’t expect.
You know, because exceptions to the rules of life can happen and they
aren’t always what you expect. Because life isn’t always as linear as
we’d hope.
Is there any (serious) language made after, say, 1985 that doesn’t have
exception handling? Static typing or dynamic typing, strong typing or
weak typing – they pretty much all have some kind of exception handling
mechanism.
On 16 Apr 2008, at 10:15, Michael T. Richter wrote:
Is there any (serious) language made after, say, 1985 that doesn’t
have exception handling? Static typing or dynamic typing, strong
typing or weak typing – they pretty much all have some kind of
exception handling mechanism.
It’s not enough to have the mechanism, you also have to code the
system to use it intelligently otherwise you won’t fail-safe.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
raise ArgumentError unless @reality.responds_to? :reason
On 16 Apr 2008, at 03:40, Phillip G. 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.
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…
I bet you dollars to doughnuts that it is the process, with
more-than-due-diligence in writing and testing the software. That the
requirements are clear cut and well understood is another bonus.Languages don’t matter. Compilers don’t matter. Process, however,
does.Or methodology. TDD has its benefits, as does BDD. Without these, the
Agile way wouldn’t work. QA is the key, not that language.
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.
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.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
raise ArgumentError unless @reality.responds_to? :reason
On Wed, Apr 16, 2008 at 4:27 AM, Rick DeNatale [email protected]
wrote:
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).Amen, Sister! And languages which rely on static typing have a
tendency to do much more random things when things go wrong. Language
like Ruby tend to have a more vigilant runtime.
Reminds me of the old story about Donald Knuth (I do not know if it is
actually true) who was lecturing formal code proves and was asked by a
student if the code actually worked now. He replied:
I do not have any idea I only proved it correct I never tested it.
Although most of you know this story I believe that it is particularly
of interest in this context.
Cheers
Robert
–
http://ruby-smalltalk.blogspot.com/
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein
On Wed, Apr 16, 2008 at 2:39 PM, Robert D. [email protected]
wrote:
Reminds me of the old story about Donald Knuth (I do not know if it is
actually true) who was lecturing formal code proves and was asked by a
student if the code actually worked now. He replied:
I do not have any idea I only proved it correct I never tested it.
Although most of you know this story I believe that it is particularly
of interest in this context.Cheers
Robert
FYI: Knuth: Frequently Asked Questions - see last
question on page.
Regards,
Sean
On Wed, 2008-04-16 at 22:09 +0900, Eleanor McHugh wrote:
I’d much rather be damn sure and also have exception handling for
what
I don’t expect.
Is there any (serious) language made after, say, 1985 that doesn’t
have exception handling? Static typing or dynamic typing, strong
typing or weak typing – they pretty much all have some kind of
exception handling mechanism.
It’s not enough to have the mechanism, you also have to code the
system to use it intelligently otherwise you won’t fail-safe.
Well, yeah. But Matt made it sound like exception handling was a rare
beast and a major decision criterion for selecting languages. I can
only think of one language left in wide, common use that doesn’t have
exception handling: C. (I’m sure others will immediately jump up and
list others, but that’s just life.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eleanor McHugh wrote:
| On 16 Apr 2008, at 03:40, Phillip G. 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:
| 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 G.
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-----
On 16 Apr 2008, at 15:06, Michael T. Richter wrote:
It’s not enough to have the mechanism, you also have to code the
system to use it intelligently otherwise you won’t fail-safe.Well, yeah. But Matt made it sound like exception handling was a
rare beast and a major decision criterion for selecting languages.
I can only think of one language left in wide, common use that
doesn’t have exception handling: C. (I’m sure others will
immediately jump up and list others, but that’s just life.
And I’ve seen a lot of C programmers code their own with longjmp
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
raise ArgumentError unless @reality.responds_to? :reason
On Wed, Apr 16, 2008 at 3:48 PM, Sean O’Halpin [email protected]
wrote:
FYI: Knuth: Frequently Asked Questions - see last
question on page.
I stand gladly corrected, and need a memory extension
So he added at the end of a paper:
"Beware of bugs in the above code; I have only proved it correct, not
tried it.‘’
Thx
Robert
–
http://ruby-smalltalk.blogspot.com/
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein
On 16 Apr 2008, at 14:42, Phillip G. wrote:
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.
It’s a lovely idea, but ponder the impact of Gödel’s Incompleteness
Theorems or Turing’s proof of the Halting Problem. In practice there
are program states which can occur which cannot be identified in
advance because they are dependent on interactions with the
environment, or are artefacts of the underlying problem space.
That’s why run-time error handling and fail-safe behaviour are so
important regardless of the rigour of Q&A processes.
requirements (while not easily) determined well before the first
line of
code is written.
Never rely upon suspicions when talking with people who actually know
for sure. As I pointed out earlier in this thread I’ve written and
certified cockpit systems (for both civilian and paramilitary use) and
requirements have tended to be just as amorphous as in any other
industry I’ve subsequently worked in. The main difference has been one
of management realising in the former case that good systems rely on
good code and that this is something a small percentage of developers
can produce, whereas in the latter there’s a belief that any two
coders are interchangeable so long as the process and tools are right.
Personally I’ll always bet on a small team of motivated hackers
determined to understand their problem domain over a larger team of
professional developers with the latest tools and methodologies but a
less consuming passion.
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.
If I have a large safety-critical or mission-critical codebase that
needs maintaining I’m more interested in finding developers who
understand the problem domain than who understand the language it’s
developed in. Any half-competent developer will pick up a new language
in a matter of weeks, but learning a problem domain can take years.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
raise ArgumentError unless @reality.responds_to? :reason
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eleanor McHugh wrote:
| It’s a lovely idea, but ponder the impact of Gödel’s Incompleteness
| Theorems or Turing’s proof of the Halting Problem. In practice there are
| program states which can occur which cannot be identified in advance
| because they are dependent on interactions with the environment, or are
| artefacts of the underlying problem space.
|
| That’s why run-time error handling and fail-safe behaviour are so
| important regardless of the rigour of Q&A processes.
Sure. But to know these states, the software should be tested as
thoroughly as possible. I somehow doubt that anybody using something
mission-critical to flying or medical health wants to call the hotline
during the final approach of a plane or when a surgical robot gets
fantasies of being SkyNET.
Anyway, this problem is (AFAIK, anyway), countered by using redundant
implementations of the hardware and software (well, as far as possible,
anyway), to minimize the effect of unknown states.
I don’t think that I ever heard of a pilot encountering an unhandled
exception during normal operation, for example. I guess we mean the
same, after all.
(At least I don’t see a contradiction in our arguments?)
|
| Never rely upon suspicions when talking with people who actually know
| for sure. As I pointed out earlier in this thread I’ve written and
| certified cockpit systems (for both civilian and paramilitary use) and
| requirements have tended to be just as amorphous as in any other
| industry I’ve subsequently worked in. The main difference has been one
| of management realising in the former case that good systems rely on
| good code and that this is something a small percentage of developers
| can produce, whereas in the latter there’s a belief that any two coders
| are interchangeable so long as the process and tools are right.
How does that rebuke my assertion that requirements are well understood
nonetheless? Requirements can change for many reasons, and not all are
related to the actual software, but possibly its implementation?
I mean, we pretty much know the physics that make flight work, for
example. That a different airframe needs different software to work is
obvious (can’t trim a fighter the same as a jumbo, for example).
However, the math stays the same, “just” the implementation changes
(Which, as I fully recognize, is a challenge in itself). And, sooner or
later, the requirements have to, for want of a better term, gel into
something that doesn’t change anymore (or at least not as easy as in
more conventional development situations)?
Mind you, I’m not discounting your expertise in the matter at all.
| Personally I’ll always bet on a small team of motivated hackers
| determined to understand their problem domain over a larger team of
| professional developers with the latest tools and methodologies but a
| less consuming passion.
Same here.
|
| If I have a large safety-critical or mission-critical codebase that
| needs maintaining I’m more interested in finding developers who
| understand the problem domain than who understand the language it’s
| developed in. Any half-competent developer will pick up a new language
| in a matter of weeks, but learning a problem domain can take years.
Well, I kind of assumed that as a given.
I’d be interested in the kinds of trade offs have to be made in this
particular problem domain (since I can’t speak from experience, and
never claimed to, either, and didn’t mean to imply as much).
I haven’t worked on anything more mission critical than CRUD style apps,
and I can only infer from my knowledge what kind of problems development
teams face.
Still, it seems to be that no level of genius can create software as is
necessary for the Space Shuttle or a more average airplane, without the
level of testing the NASA or Boeing brings to bear for their software.
After all, smart people should recognize the difficulties they face when
working on mission critical software?
Phillip G.
Twitter: twitter.com/cynicalryan
Rule of Open-Source Programming #48:
The number of items on a project’s to-do list always grows or remains
constant.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgGL+UACgkQbtAgaoJTgL/sUwCgggZ5KbDmLs5/SFnvDVQOoU6p
njsAoJxX7yJj8idpx7kPybDLCTR+pCZN
=PKTz
-----END PGP SIGNATURE-----
Phillip G. wrote:
[…]
Anyway, this problem is (AFAIK, anyway), countered by using redundant
implementations of the hardware and software (well, as far as possible,
anyway), to minimize the effect of unknown states.
This solves some problems but not all of them. If the software and
hardware are designed based on flawed specifications you get a rocket
explosion (Ariane V first test flight: the 3 redundant systems all
failed one after the other because some flight patterns constraints were
reused from Ariane IV but weren’t applicable to the new rocket…).
I don’t think that I ever heard of a pilot encountering an unhandled
exception during normal operation, for example. I guess we mean the
same, after all.
I think it happened at least once on an Airbus where a pilot had to
switch to manual controls or deactivate a safety measure because the
autopilot was going to bring the plane to stall (sensors reporting
incorrect measures). I could’t find the reference for this specific
instance, but google brought other problems :
Unforeseen conditions leading to autopilot misbehaving :
http://shippai.jst.go.jp/en/Detail?fn=0&id=CA1000621
Software glitches putting aircraft in danger :
several incidents, look for the “Cause” lines to filter the problems
caused by flight systems.
http://www.airsafety.com/aa587/faa_fltcont.pdf
|
| Never rely upon suspicions when talking with people who actually know
| for sure. As I pointed out earlier in this thread I’ve written and
| certified cockpit systems (for both civilian and paramilitary use) and
| requirements have tended to be just as amorphous as in any other
| industry I’ve subsequently worked in. The main difference has been one
| of management realising in the former case that good systems rely on
| good code and that this is something a small percentage of developers
| can produce, whereas in the latter there’s a belief that any two coders
| are interchangeable so long as the process and tools are right.
In my experience this latter case is widespread in companies with no
real inside CS knowledge believing they can manage IT projects
themselves (with pointy-haired bosses :-)). It’s hard to realize that
you need sharp minds to produce good code when your own view of software
building is limited to playing with Lego systems… This is a recurrent
problem for CS people : making other people aware of the inherent
complexities of software design.
I mean, we pretty much know the physics that make flight work, for
example. That a different airframe needs different software to work is
obvious (can’t trim a fighter the same as a jumbo, for example).
If only you could have advised Arianespace 
Lionel
“ThoML” [email protected] wrote in message
news:[email protected]…
for example where type inference is used, like in Haskell or
F# (or to some extent in C# 3.0)IIRC D is capable of doing some type inferencing too. But D is still
on my to-be-learned list.
AFAIK the type inferencing for D is similar to that for C# 3.0. IOW you
can
omit the type on a declaration if you can infer the type from the
initializer. Sounds trivial but it does save typing if the datatype is
quite
complex. Where it will really save time is in combination with object
initializer syntax, to provide anonymous types. I don’t know enough
about
it, but I’m guessing that such anonymous types would then fit in well
with
the lambda expressions also showing up in C# now.
AHS
“Eleanor McHugh” [email protected] wrote in message
news:[email protected]…
without having to change the language syntax and semantics.
[ SNIP ]
I know nothing of avionics software, but I’d assume
Avionics software - Wikipedia is reasonably accurate.
Half
of the stuff in that article is what you’d like to do on any project if
you
didn’t have impossible deadlines and shabby processes, and the other
half is
simply extra rigour because errors are much less acceptable.
What I don’t see is any particular emphasis on specific languages.
Considering that there seems to be no shortage of avionics software
written
in C/C++, I don’t immediately see why Ruby or Python wouldn’t work
either,
especially considering the intense process the software goes through.
I tend not to discount any particular language prima facie. I recall
over
ten years ago having a colleague demonstrate a responsive, reliable (as
near
as I could tell) and feature-rich moving map display program for small
boat
navigation, and I asked him what it was written in. He replied, Visual
Basic. He later went on to sell it commercially.
I’m inclined to think that 90%+ of software reliability comes from
training,
experience and above all, process. Not the programming language.
AHS
On Wed, Apr 16, 2008 at 6:23 PM, Eleanor McHugh
[email protected] wrote:
program states which can occur which cannot be identified in advance because
they are dependent on interactions with the environment, or are artefacts of
the underlying problem space.
I am not sure but on a first approach I believe that neither Gödel nor
Turing apply because they are talking about systems describing
themselves. IIRC it is a theorem in TNT(1) making an assumption about
TNT in the first case and a turing machine reading the description of
a turing machine on its tape in the second case.
I do not believe that Aircraft Control Systems have this degree of
self awareness, but I can stand corrected if I am wrong, because
although I have been taught a lot about TM and TNT I do not know a lot
about Aircraft Control.
That’s why run-time error handling and fail-safe behaviour are so important
regardless of the rigour of Q&A processes.
That however I agree with!
(1) Typographical Number Theory - Wikipedia
Cheers
Robert
http://ruby-smalltalk.blogspot.com/
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein
In article [email protected],
Eleanor McHugh [email protected] wrote:
advance because they are dependent on interactions with the =20
environment, or are artefacts of the underlying problem space.
I’m not sure how the Halting Problem relates to presence or
absence of undefined states. What does it mean to call a state
“undefined” anyway, in this context? Presumably there’s always
a finite number of states, which may be extremely large for most
programs that perform useful calculations. If we start with very
small, simple (and not useful) programs, we can enumerate all
the states. Are any of these undefined? As we increase the size
of the program, the number of states increases, presumably at
an alarming rate. At what point do we become unable to identify
program states?
An example of a simple program that does a barely useful task
is one that reads an input level from a 16 bit A/D, say, and
writes half that value to a 16 bit D/A. Can we be confident we
can write a 100% reliable and correct program to perform this
task? If not, why not? If so, let us increase the complexity
of the task progressively in small increments. At what point
are we forced to admit that we cannot be sure our program does
what it is meant to do?
I’m not trying to prove you wrong; I just want to get a better
handle on the problem.
Francis
On Apr 16, 2:39 pm, “Arved Sandstrom” [email protected]
wrote:
What I don’t see is any particular emphasis on specific languages.
Considering that there seems to be no shortage of avionics software written
in C/C++, I don’t immediately see why Ruby or Python wouldn’t work either,
especially considering the intense process the software goes through.I tend not to discount any particular language prima facie. I recall over
…
I’m inclined to think that 90%+ of software reliability comes from training,
experience and above all, process. Not the programming language.
But that still leaves 10%-. For example, as noted here (http://
www.praxis-his.com/sparkada/pdfs/spark_c130j.pdf), an analysis of
safety-critical code written in three languages (C, Ada and SPARK),
all of which was already certified to DO-178B Level A (the most
stringent level), it was found that the SPARK code had one tenth the
residual error rate of the Ada code, and the Ada code had only one
tenth the residual rate of the C code. That’s a 100:1 difference in
residual error rates in code all of which was certified to the highest
aviation standards. Would anybody argue that putting out safety-
critical software with an error rate 100 times greater than the
current art allows is a good thing? In fact, would anybody argue that
it is not grossly negligent?
Oh, and the anecdote about the compiler finding in minutes a bug that
had defied testing for a week should not be lightly dismissed either.
On 16 Apr 2008, at 17:57, Phillip G. wrote:
Still, it seems to be that no level of genius can create software as
is
necessary for the Space Shuttle or a more average airplane, without
the
level of testing the NASA or Boeing brings to bear for their software.
Oh definitely. Testing that code performs correctly is essential to
any embedded development process, as is validating that the code
written solves the correct problem. The latter is by far the more
difficult though.
The guidelines for developing civilian aviation software are
documented in RTCA-DO178B (see DO-178B - Wikipedia)
which is abstract, non-prescriptive and an excellent alternative to
sleeping pills. Numerous concrete processes have emerged to suit how
various teams work, but in general the more critical the software then
the more that testing will result in hand-analysis of both source and
object code. Unit testing will be heavy on white boxing so the
majority of tests are likely to be disposable with unit changes but
there’s lots of fun to be had with unglamorous and time-consuming old-
school software engineering (SLOCs, cyclomatic complexity, various
forms of test partitioning) that’s independent of implementation
language or life-cycle methodology.
The maintenance of a clear audit trail on requirements and requirement
changes is essential for civil certification, so processes which lack
effective change control mechanisms are inappropriate. However I’ve
used RAD and Agile approaches (especially evolutionary prototyping)
successfully and had them pass certification so the myth that aviation
development is always monolithic waterfall is definitely unfounded.
In terms of the actual tradeoffs in mission critical systems (aviation
or otherwise) most come down to smoothing interaction with external
stimuli and breaking up costly computations and database queries into
discrete manageable chunks. There’s very little genius required, just
careful attention to detail and an ability to analyse problem spaces:
that’s probably why so many physicists, chemists and applied
mathematicians end up in this particular discipline.
For a theoretical foundation I recommend “Cybernetics” by Norbert
Wiener although it’s a dense read.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
raise ArgumentError unless @reality.responds_to? :reason
On 16 Apr 2008, at 19:40, Arved Sandstrom wrote:
I tend not to discount any particular language prima facie. I recall
over
ten years ago having a colleague demonstrate a responsive, reliable
(as near
as I could tell) and feature-rich moving map display program for
small boat
navigation, and I asked him what it was written in. He replied, Visual
Basic. He later went on to sell it commercially.
Much kudos to your friend. Twelve years ago I did the same thing in VB
for helicopters and whilst it was pushing the hardware at that time,
it was still usable. Of course these days most mobile phones have more
computational grunt and memory than that
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
raise ArgumentError unless @reality.responds_to? :reason