Re: Ada ad in Embedded Systems Programming stinks

[ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)]

gijs@mbase97.xs4all.nl (Maarten Landzaat) writes:
>But seriously: I think you are exaggerating. Programmers should write
>'good' code. One of the virtues of good code is that it uses constructs
>that anybody can understand. It's the same as with natural language:
>difficult sentences sound bombastic and don't get the message across.

I think you have misunderstood the reason why it is essential to keep
checking the manual.  I personally am sick and tired of C code "that
uses constructs that anybody can understand" but doesn't work.  Example:
someone else's code I'm _still_ trying to fix after a couple of weeks
(ok, I'm not doing this full time) which, amongst other things, assumes
that (a) pointers and 'int's are the same size and (b) casting a pointer
to an int preserves all the bits.  If I tell you that this is not true,
you can probably guess which machine and what memory model...

The point of checking the manual is not to become intimate with all kinds
of super-whizzy features that demonstrate your wizard-hood, but to learn
what kinds of things to _avoid_.  Far too many people confuse what happens
to work in their implementation, or what seems to them like the obvious
translation, with what the language actually promises.  The C standard,
for example, is exceptionally valuable because it has appendices with
long lists of things you _thought_ were ok but aren't.  I was really shocked
when I found out how many things I had relied on were just 'common
extensions'.

If you only have the programmer's reference manual for Brand X, you don't
know what you _shouldn't_ be using.

-- 
The party that took Australia into Vietnam wants to smash the inner-city
yacht school and put a Grand Prix in its place.  They don't change.