Another ammunition

Another ammunition

[Jean-Pierre Rosen]

I know I'm preaching to the choir, but here is another story Ada fans can tell to the other guys who say that "language doesn't
matter"...

My son was recently doing an assignment in C, which involved lots of floating point computations, and he kept getting inconsistent
results. After lots of searching, he discovered that NaNs were generated in various places. There seemed to be no consistency in the
appearing of NaNs: changing optimization options, adding intermediate variables in computations, etc. all changed the way NaNs were
produced.

Here is what happened: A C function was returning a float, but in some place was declared as returning an int. In gcc, a function
that returns a float leaves the result on the coprocessor stack, NOT on the regular stack. Therefore, the return value of the
function was not popped off the coprocessor stack. And when the coprocessor's stack is full, every floating point operation results
in NaN....

It took a week to understand what was happenning. Would not have passed the first compilation in Ada.
FWIW...

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Another ammunition

[Eric G. Miller]

Jean-Pierre Rosen wrote:
> I know I'm preaching to the choir, but here is another story Ada fans can
> tell to the other guys who say that "language doesn't matter"...
> 
> My son was recently doing an assignment in C, which involved lots of floating
> point computations, and he kept getting inconsistent results. After lots of
> searching, he discovered that NaNs were generated in various places. There
> seemed to be no consistency in the appearing of NaNs: changing optimization
> options, adding intermediate variables in computations, etc. all changed the
> way NaNs were produced.
> 
> Here is what happened: A C function was returning a float, but in some place
> was declared as returning an int. In gcc, a function that returns a float
> leaves the result on the coprocessor stack, NOT on the regular stack.
> Therefore, the return value of the function was not popped off the
> coprocessor stack. And when the coprocessor's stack is full, every floating
> point operation results in NaN....
> 
> It took a week to understand what was happenning. Would not have passed the
> first compilation in Ada. FWIW...

You're right, but I'm sure gcc could have immediately diagnosed the
problem had you turned up the warnings ("conflicting types for...", "previous
declaration of ...").

The fault here is that the C language requires compilers to be very forgiving,
so you have to take explicit actions with compilers to turn warnings into
errors (-Wall -W -O -Werror, for starters).  IME, gcc rarely gives
warnings that are spurious with -Wall (i.e. ignore at your peril).

Re: Another ammunition

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]


"Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news: IpfQ9.4953
> > It took a week to understand what was happenning. Would not have passed the
> > first compilation in Ada. FWIW...
>
> You're right, but I'm sure gcc could have immediately diagnosed the
> problem had you turned up the warnings ("conflicting types for...", "previous
> declaration of ...").
>
Warnings were on, he just overlooked them....
That's what makes a huge difference between a warning which is up to the good will of the compiler (and the programmer paying
attention to it), and a *required* compile time error!

(count that as another moral of the story).

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Another ammunition

[Alexander Schreiber]

Jean-Pierre Rosen <rosen@adalog.fr> wrote:
>
>"Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news: IpfQ9.4953
>> > It took a week to understand what was happenning. Would not have passed the
>> > first compilation in Ada. FWIW...
>>
>> You're right, but I'm sure gcc could have immediately diagnosed the
>> problem had you turned up the warnings ("conflicting types for...", "previous
>> declaration of ...").
>>
>Warnings were on, he just overlooked them....
>That's what makes a huge difference between a warning which is up to the good will of the compiler (and the programmer paying
>attention to it), and a *required* compile time error!

For gcc, there is always the "anal retentive mode": run it with
basically _all_ warnings turned on _and_ any warning considered as error
(aborting the compile):
-ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Wshadow 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Waggregate-return -Wmissing-declarations -Wnested-externs -Winline 
-Werror -W

Forces you to fix the simple bugs to even get your code to compile
(leaving you to be more creative in creating tricky logic bugs).

Regards,
     Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

Re: Another ammunition

[AG]

> Jean-Pierre Rosen <rosen@adalog.fr> wrote:

> -ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Wshadow
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
> -Waggregate-return -Wmissing-declarations -Wnested-externs -Winline
> -Werror -W

> Forces you to fix the simple bugs to even get your code to compile
> (leaving you to be more creative in creating tricky logic bugs).

That's an interesting example. All those switches needed
to force you to "fix the simple bugs"? How many people
would you think would bother with all the switches?
And not make a mistake of omitting one?

Even more importantly, how do you know *you* haven't
missed one or two? Sure, there are manuals (or are there?
or are the manuals complete and up to date? etc etc) but
even then, setting up all those switches is surely subject
to human error. Isn't it better to just have all of that built
right into the language which compiler is required to enforce?

Re: Another ammunition

[Alexander Schreiber]

AG <ang@xtra.co.nz> wrote:
>> Jean-Pierre Rosen <rosen@adalog.fr> wrote:
>
>> -ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Wshadow
>> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
>> -Waggregate-return -Wmissing-declarations -Wnested-externs -Winline
>> -Werror -W
>
>> Forces you to fix the simple bugs to even get your code to compile
>> (leaving you to be more creative in creating tricky logic bugs).
>
>That's an interesting example. All those switches needed
>to force you to "fix the simple bugs"?

"simple bugs" == stuff the compiler can find, like trying to write into
constants, type mismatches (returning ints but expecting floats), tyops
(like a forgotten ";") and the like. Still leaves you free to add buffer
overruns, off-by-one errors and so on to your hearts content ;-)

>How many people
>would you think would bother with all the switches?
>And not make a mistake of omitting one?

Very few. I've seen enough projects that simply dump stdout and stderr
of the compiler into /dev/null during the compile stage - probably to
keep the user installing this software from seeing gcc complain about
the ugly C he is fed.

The long list of compiler switches above came from a programming
assignment I once did - I tried to force gcc into the most anal
retentive mode possible to avoid leaving stupid and simple coding errors
in the project. It helped.

>Even more importantly, how do you know *you* haven't
>missed one or two? Sure, there are manuals (or are there?
>or are the manuals complete and up to date? etc etc) but
>even then, setting up all those switches is surely subject
>to human error. Isn't it better to just have all of that built
>right into the language which compiler is required to enforce?

I'm not trying to argue that you should drop Ada and use C instead -
there are more than enough misguided zealots of this kind already
around. IMHO, the digital world would most likely be a slightly safer
place if more software were written in Ada instead of C (and some
obnoxious software wouldn't be written at all - good riddance).

For me, Ada is an interesting and powerful language - but I still need
to find the time to do more than write the canonical "Hello world" in
Ada.

Regards,
      Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

Re: Another ammunition

[Peter Hermann]

Alexander Schreiber <als@usenet.thangorodrim.de> wrote:
> For me, Ada is an interesting and powerful language - but I still need
> to find the time to do more than write the canonical "Hello world" in
> Ada.
> 
> Regards,
>       Alex.
> -- 
> "Opportunity is missed by most people because it is dressed in overalls and
>  looks like work."                                      -- Thomas A. Edison

What a coincidence!

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Another ammunition

[Richard Riehle]

Alexander Schreiber wrote:

> For me, Ada is an interesting and powerful language - but I still need
> to find the time to do more than write the canonical "Hello world" in
> Ada.

Complaints of this kind are one  reason I wrote "Ada Distilled."  It is
intended as an easy way for experienced programmers to try out
different programs with a minimum of prowling through long textual
explanations.   You can download it from www.adaic.org or
www.adapower.com.

Richard Riehle

Re: Another ammunition

[Alexander Schreiber]

Richard Riehle <richard@adaworks.com> wrote:
>Alexander Schreiber wrote:
>
>> For me, Ada is an interesting and powerful language - but I still need
>> to find the time to do more than write the canonical "Hello world" in
>> Ada.
>
>Complaints of this kind are one  reason I wrote "Ada Distilled."  It is
>intended as an easy way for experienced programmers to try out
>different programs with a minimum of prowling through long textual
>explanations.   You can download it from www.adaic.org or
>www.adapower.com.

Downloaded, added to my local digital library and reading it now.
Thanks.

Regards,
      Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

Re: Another ammunition

[u.r. faust]

The "ammunition" analogy is pretty offputting to anyone who is
not a hard core military enthusiast.

All it does is remind people of Ada's link with the DOD.

( Just imagine how you would react if someone used 
"another aids infected needle used by a junkie" as a
synonym for a good point about a language. )

-- 
natsu-gusa ya  / tsuwamono-domo-ga / yume no ato
summer grasses / strong ones       / dreams site
 
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)

Re: Another ammunition

[Larry Kilgallen]

In article <3cnxyf1j.fsf@optushome.com.au>, "u.r. faust" <urfaust@optushome.com.au> writes:
> 
> The "ammunition" analogy is pretty offputting to anyone who is
> not a hard core military enthusiast.

Pleasee take the politics to a group where it is on-topic.

Re: Another ammunition

[Georg Bauhaus]

Larry Kilgallen <Kilgallen@spamcop.net> wrote:
:> The "ammunition" analogy is pretty offputting to anyone who is
:> not a hard core military enthusiast.
: 
: Pleasee take the politics to a group where it is on-topic.

The metaphor "ammunition" can easily (and totally unrelated to
politics) be replaced by the real thing, and it _will_ serve
to bring the discussion back to facts. Convincing arguments in
this case.

Metaphorically speaking, you wouldn't expect the majority of
c.l.Ada readers to feel comfortable with:
"Here is ammunition to neutralize your kids' shouting...",
would you?

-- Georg

Re: Another ammunition

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 716 bytes --]


"AG" <ang@xtra.co.nz> a �crit dans le message news: hVyQ9.4454$F63.96878@news.xtra.co.nz...
> Even more importantly, how do you know *you* haven't
> missed one or two? Sure, there are manuals (or are there?
> or are the manuals complete and up to date? etc etc) but
> even then, setting up all those switches is surely subject
> to human error. Isn't it better to just have all of that built
> right into the language which compiler is required to enforce?
>
Agreed. And to state it more simply: this is another example that safety is on *by default* in Ada.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Another ammunition

[Stephen Leake]

"AG" <ang@xtra.co.nz> writes:

> > Jean-Pierre Rosen <rosen@adalog.fr> wrote:
> 
> > -ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Wshadow
> > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
> > -Waggregate-return -Wmissing-declarations -Wnested-externs -Winline
> > -Werror -W
> 
> > Forces you to fix the simple bugs to even get your code to compile
> > (leaving you to be more creative in creating tricky logic bugs).
> 
> That's an interesting example. All those switches needed
> to force you to "fix the simple bugs"? How many people
> would you think would bother with all the switches?

That's what coding standards are for. Nobody should use any compiler
with just the default switches, at least not without a lot of thought
first. Here's the relevant section from our coding standard:

(2) Compilers shall be configured to enforce the ANSI standard. Table 1
    gives the compiler switches required

(3) All code should compile without warnings. However, it is sometimes
    impossible to eliminate warnings; such cases should be documented
    with comments in the code. 

TABLE 1. Required Compiler switch settings

GNU C -Wall -Wstrict-prototypes -pedantic -ansi -Werror

> Even more importantly, how do you know *you* haven't
> missed one or two? 

Because I have read the manuals, and I have been using this set of
switches for several years. Every time I find a bug that I think
should have been caught by the compiler, I check the manual to see if
there is a new switch for that. 

Of course, first I say "we should be using Ada" :).

> Isn't it better to just have all of that built right into the
> language which compiler is required to enforce?

Yes. That is what Ada is for. 

But even with Ada, you have to read the compiler documentation and set
the compiler switches correctly.

-- 
-- Stephe

Re: Another ammunition

[Warren W. Gay VE3WWG]

Jean-Pierre Rosen wrote:
> "Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news: IpfQ9.4953
>>>It took a week to understand what was happenning. Would not have passed the
>>>first compilation in Ada. FWIW...
>>
>>You're right, but I'm sure gcc could have immediately diagnosed the
>>problem had you turned up the warnings ("conflicting types for...", "previous
>>declaration of ...").
> 
> Warnings were on, he just overlooked them....
> That's what makes a huge difference between a warning which is up to the good will of the compiler (and the programmer paying
> attention to it), and a *required* compile time error!
> 
> (count that as another moral of the story).

Things may be different now, but I once had a long email discussion
with one of the folks about whether a missing return "type" should
be a warning or not (it should actually be an error). At the time,
you had to specify a compile option to make a declaration like:

foo() { ... }

return a warning. It should be something like:

int foo () { ... }

if it does indeed return int.

Well, he didn't like the idea of the warning being on by default,
and so people continue to get burned by this very problem.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Another ammunition

[David Thompson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote :
> Jean-Pierre Rosen wrote:
> > "Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news:
IpfQ9.4953
...
> >>You're right, but I'm sure gcc could have immediately diagnosed the
> >>problem had you turned up the warnings ("conflicting types for...",
"previous
> >>declaration of ...").
> >
> > Warnings were on, he just overlooked them....

Could have (and did) *IF* the same declaration is visible at
all relevant locations, typically by #include'ing the same .h file.
If you just write out a wrong declaration of foo in bar.c, gcc can't
catch it (though a good lint can).  Also, if you mistakenly #include
a wrong .h file (such as from a wrong subtree) gcc can't catch it,
although this is unlikely in simple student projects.
(A C implementation *could* legally and practially do
the kinds of whole-program or at least cross-unit checks
Ada requires and GNAT does, but they don't, not even gcc.)

...
> Things may be different now, but I once had a long email discussion
> with one of the folks about whether a missing return "type" should
> be a warning or not (it should actually be an error). At the time,
> you had to specify a compile option to make a declaration like:
>
> foo() { ... }
>
> return a warning. ...

(That's a definition, not just a declaration.
/*int*/ foo () ; is a typical "external" declaration.)

According to all C standards before C99 (K&R and C89) it *is*
legal and so can't conformingly be an error.  With C99 it is a
required diagnostic and could well be an error, but won't because
implementors don't want to break vast masses of existing legal
and supported code.  I agree it should be a warning, but whether
it's on by default doesn't matter much to me, since I always end up
with some mechanism (makefile, script, envvar) for setting flags
anyway, and if this needs an entry in there it's no real trouble.

--
- David.Thompson 1 now at worldnet.att.net

Re: Another ammunition

[Warren W. Gay VE3WWG]

David Thompson wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote :
>>Jean-Pierre Rosen wrote:
>>
>>>"Eric G. Miller" <egm2.NOSPAM@jps-NOSPAM.net> a �crit dans le message news:
>>
> IpfQ9.4953
> ....
> 
>>>>You're right, but I'm sure gcc could have immediately diagnosed the
>>>>problem had you turned up the warnings ("conflicting types for...",
>>>
> "previous
> 
>>>>declaration of ...").
>>>
>>>Warnings were on, he just overlooked them....
> 
> Could have (and did) *IF* the same declaration is visible at
> all relevant locations, typically by #include'ing the same .h file.
> If you just write out a wrong declaration of foo in bar.c, gcc can't
> catch it (though a good lint can).  Also, if you mistakenly #include
> a wrong .h file (such as from a wrong subtree) gcc can't catch it,
> although this is unlikely in simple student projects.
> (A C implementation *could* legally and practially do
> the kinds of whole-program or at least cross-unit checks
> Ada requires and GNAT does, but they don't, not even gcc.)
> ....
>>Things may be different now, but I once had a long email discussion
>>with one of the folks about whether a missing return "type" should
>>be a warning or not (it should actually be an error). At the time,
>>you had to specify a compile option to make a declaration like:
>>
>>foo() { ... }
>>
>>return a warning. ...
> 
> (That's a definition, not just a declaration.
> /*int*/ foo () ; is a typical "external" declaration.)

Sigh, yes, everyone knows this. Even pure undefiled Ada programmers
know this, I expect. ;-)

> According to all C standards before C99 (K&R and C89) it *is*
> legal and so can't conformingly be an error.  

Fine, but it should be a warning.

> With C99 it is a
> required diagnostic and could well be an error, but won't because
> implementors don't want to break vast masses of existing legal
> and supported code.  I agree it should be a warning, 

Agreed. It _should_ be at least a warning.

> but whether
> it's on by default doesn't matter much to me, since I always end up
> with some mechanism (makefile, script, envvar) for setting flags
> anyway, and if this needs an entry in there it's no real trouble.
> 
> --
> - David.Thompson 1 now at worldnet.att.net

The point is, is that a lot of other projects and even team members
fail to include the support for this "warning". If it were on by
default, there would be uncounted number of hours saved each year
by programmers who instead spend the time debugging a problem
related to this issue.  I've seen this time and again, even though
my team members know about it.

It is not enough to say "it is not an issue because I do this...".
It is an issue, that could be fixed once and for all.
Even a warning doesn't guarantee that it will be noticed and
fixed -- but it greatly increases the odds!

However, the best solution of all is to use Ada instead, and only
rely on C like an assembly level layer, when required ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Another ammunition

[Stephen Leake]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> The point is, is that a lot of other projects and even team members
> fail to include the support for this "warning". If it were on by
> default, there would be uncounted number of hours saved each year
> by programmers who instead spend the time debugging a problem
> related to this issue.  I've seen this time and again, even though
> my team members know about it.

No tool can substitute for good process, and good education.

No tool should be used with only the default command line parameters;
the project style guide should say what parameters to specify, and it
must be enforced.

The first step in your debug process should be to make sure the proper
warnings are turned on, and fix all warnings.

> It is not enough to say "it is not an issue because I do this...".
> It is an issue, 

yes, it is. And the proper solution is good process.

> that could be fixed once and for all. 

Nope. People who don't like to fix warnings will include the option to
supress them (that option has to be there, because you do occasionally
have a legitmate need for it).

> Even a warning doesn't guarantee that it will be noticed and fixed
> -- but it greatly increases the odds!

Not much. As has been pointed out in this thread, many people ignore
warnings all the time.

> However, the best solution of all is to use Ada instead, and only
> rely on C like an assembly level layer, when required ;-)

True. But even for Ada, using the default command line parameters for
the compiler and linker is bad practice.

-- 
-- Stephe

Re: Another ammunition

[Warren W. Gay VE3WWG]

Stephen Leake wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> 
>>The point is, is that a lot of other projects and even team members
>>fail to include the support for this "warning". If it were on by
>>default, there would be uncounted number of hours saved each year
>>by programmers who instead spend the time debugging a problem
>>related to this issue.  I've seen this time and again, even though
>>my team members know about it.
> 
> No tool can substitute for good process, and good education.

I agree with this to some degree, but I would also suggest that
no amount of "good process or education" is a substitute for
bad tools or defaults!

> No tool should be used with only the default command line parameters;

Nobody said that this should be the case. Nobody. So why harp
about this?

What was said was that there are safer defaults.

> the project style guide should say what parameters to specify, and it
> must be enforced.

So do you lock down every developer's PC too, so they can't mess
with their environment?  Programmers are a rebellious lot, and
strict levels of enforcement may work in some environments for
military projects and NASA, but they don't work in many other
environments. Or at least _it isn't done_ ;-)

> The first step in your debug process should be to make sure the proper
> warnings are turned on, and fix all warnings.

No one is doubting this, but there are two problems with this:

   (1) if the developer is working on a large project with
       a ton of warnings already, he's not likely to fix them
       all now. However, if he's smart (and that is not necessarily
       a given ;-), he'd grep for the most important warnings at
       least.

   (2) Some developers (particularly the less experienced ones), do
       not know what to look for, let alone turn on the correct
       compile options.

At least if it was on by default (or with -Wall), then there would
be at least a chance that they'd see it and do something about it.

Note: For a time (if not currently), -Wall did not include _all_
warnings. I believe the return type warning was not included.

>>It is not enough to say "it is not an issue because I do this...".
>>It is an issue, 
> 
> yes, it is. And the proper solution is good process.

I don't buy this. We're going to have to disagree on this point.

>>that could be fixed once and for all. 
> 
> Nope. People who don't like to fix warnings will include the option to
> supress them (that option has to be there, because you do occasionally
> have a legitmate need for it).

Again, nobody (I repeat nobody) said that the option to remove that
warning should be disabled or removed. The statement was, that it
should be on by _default_.

Read my lips ;-) "Nothing more, nothing less."

If you left your house for a vacation, and due to the hustle and
bustle of getting your 3 kids, 2 dogs and your wife all in the
van to go, wouldn't you want to be warned that you forgot to lock
the back door?  Your solution is to strickly depend upon process
and "education". Human nature is such that you cannot _depend_
soley upon this.  This is why Ada does not depend strictly upon
process or education.

>>Even a warning doesn't guarantee that it will be noticed and fixed
>>-- but it greatly increases the odds!
> 
> Not much. As has been pointed out in this thread, many people ignore
> warnings all the time.

Whether its is much or little, I won't argue. You concede that it
is better, and so even that suggests in favour of what I said in the
beginning (change the default).

>>However, the best solution of all is to use Ada instead, and only
>>rely on C like an assembly level layer, when required ;-)
> 
> True. But even for Ada, using the default command line parameters for
> the compiler and linker is bad practice.

Again, nobody is saying that you should use strictly defaults. Nobody!

But having _safer_ defaults is useful and helpful in the general
sense, because _some_ people will use them, irregardless of
your superior education and process. Its like herding cats ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Another ammunition

[Stephen Leake]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Stephen Leake wrote:
> > No tool should be used with only the default command line parameters;
> 
> Nobody said that this should be the case. Nobody. So why harp
> about this?

Because you and others keep bringing it up :).

> What was said was that there are safer defaults.

Why do the defaults matter if you are not going to use them?


-- 
-- Stephe

Re: Another ammunition

[Warren W. Gay VE3WWG]

Stephen Leake wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>>Stephen Leake wrote:
>>
>>>No tool should be used with only the default command line parameters;
>>
>>Nobody said that this should be the case. Nobody. So why harp
>>about this?
> 
> Because you and others keep bringing it up :).

But I never said this 8-)

>>What was said was that there are safer defaults.
> 
> Why do the defaults matter if you are not going to use them?

Well this is precisely why I don't understand your resistance
to the idea!  You say "you never should..." and "I never do..."
and yet all of the resistance to changing the default is coming
from you, LOL.  I am in favour of changing the default for the
various reasons I have already stated.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Another ammunition

[Michael Erdmann]

Jean-Pierre Rosen wrote:

> I know I'm preaching to the choir, but here is another story Ada fans can
> tell to the other guys who say that "language doesn't matter"...
> 
For me this is a good example, that language does not matter since 
you can achieve everything in any language by spending unlimited
ammount of effort in the implementation phase.

> My son was recently doing an assignment in C, which involved lots of
> floating point computations, and he kept getting inconsistent results.
> After lots of searching, he discovered that NaNs were generated in various
> places. There seemed to be no consistency in the appearing of NaNs:
> changing optimization options, adding intermediate variables in
> computations, etc. all changed the way NaNs were produced.
> 
This is the reason why i am using still Fortran for heavy 
caculcation.

I think that this is not a pure technical problem, because 
i know a lot researchers which are using C for there calculations.
The problem seems to me the teacher, which should know, that a 
lanaguage is simply a tool to achieve the implementation 
of your requierements. The usage of these tools has to be 
questioned during design since every tool is has a limited 
application domain.
My personal experience was that teachers are forced by 
curiculum to teach on basis of a single language, which i think
is simply wrong. The teacher should be asked why he has asked
to do the job in C.


A happy new year

Michael.

Re: Another ammunition

[Peter Hermann]

> This is the reason why i am using still Fortran for heavy 
> caculcation.

an appropriate Freudian typo (in German language)