Fun with C

Fun with C

[George P.]

Spend few days chasing bug in embedded C project which can drilled
down to this. Consider the following program, and all reasonable men
will expect the result to be negative.  Not in C, and it is not a
compiler bug :-(

And offcorse none of the three comilers I cheched did not bother to
issue a warning at least..

#include <stdio.h>

int main()
{
     unsigned n = 128;
     int i = -2048;
     int r;

     r = i / n;

     printf("R = %d\n", r);

     return 0;
}

Re: Fun with C

[Nasser M. Abbasi]

On 4/16/2011 10:02 AM, George P. wrote:
> Spend few days chasing bug in embedded C project which can drilled
> down to this. Consider the following program, and all reasonable men
> will expect the result to be negative.  Not in C, and it is not a
> compiler bug :-(
>
> And offcorse none of the three comilers I cheched did not bother to
> issue a warning at least..
>
> #include<stdio.h>
>
> int main()
> {
>       unsigned n = 128;
>       int i = -2048;
>       int r;
>
>       r = i / n;
>
>       printf("R = %d\n", r);
>
>       return 0;
> }


$ gcc -Wall  t.c
$ ./a.out
R = 33554416


That is why we all love C. Best Job security in the world
for programmers.

There are always "issues" to fix.  You see, you yourself had to
work for few days on this one. If you had used Ada, or any  other
more strongly typed languages, then you'll be done early,
then the manager will have come in and saw you sitting
doing nothing becuase your program is done, and you'll be out
of work.

So, you should be very happy you are working on C.

--Nasser

Re: Fun with C

[Ludovic Brenta]

"Nasser M. Abbasi" <nma@12000.org> writes:
> On 4/16/2011 10:02 AM, George P. wrote:
>> Spend few days chasing bug in embedded C project which can drilled
>> down to this. Consider the following program, and all reasonable men
>> will expect the result to be negative.  Not in C, and it is not a
>> compiler bug :-(
>>
>> And offcorse none of the three comilers I cheched did not bother to
>> issue a warning at least..
>>
>> #include<stdio.h>
>>
>> int main()
>> {
>>       unsigned n = 128;
>>       int i = -2048;
>>       int r;
>>
>>       r = i / n;
>>
>>       printf("R = %d\n", r);
>>
>>       return 0;
>> }
>
>
> $ gcc -Wall  t.c
> $ ./a.out
> R = 33554416

So R = 2**25 - 16, the correct answer is -16, so the actual result is
the correct one except for bit 24, which is 1 when it should be zero.

Out of curiosity, is this actual result a predictable consequence of the
language definition, or is it undefined behavior?

-- 
Ludovic Brenta.

Re: Fun with C

[jimmaureenrogers]

On Apr 16, 3:12 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> "Nasser M. Abbasi" <n...@12000.org> writes:
>
>
>
>
>
> > On 4/16/2011 10:02 AM, George P. wrote:
> >> Spend few days chasing bug in embedded C project which can drilled
> >> down to this. Consider the following program, and all reasonable men
> >> will expect the result to be negative.  Not in C, and it is not a
> >> compiler bug :-(
>
> >> And offcorse none of the three comilers I cheched did not bother to
> >> issue a warning at least..
>
> >> #include<stdio.h>
>
> >> int main()
> >> {
> >>       unsigned n = 128;
> >>       int i = -2048;
> >>       int r;
>
> >>       r = i / n;
>
> >>       printf("R = %d\n", r);
>
> >>       return 0;
> >> }
>
> > $ gcc -Wall  t.c
> > $ ./a.out
> > R = 33554416
>
> So R = 2**25 - 16, the correct answer is -16, so the actual result is
> the correct one except for bit 24, which is 1 when it should be zero.
>
> Out of curiosity, is this actual result a predictable consequence of the
> language definition, or is it undefined behavior?
>
> --
> Ludovic Brenta.- Hide quoted text -
>
> - Show quoted text -

This is actually predictable. The C compiler implicitly converted the
negative
value to an unsigned representation of the same bit pattern. The
division was
performed on that converted value.

Note that this wonderful behavior is also expected using C++, because
of its
compatibility with C.

Jim Rogers

Re: Fun with C

[George P.]

On Apr 16, 4:04 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 4/16/2011 10:02 AM, George P. wrote:
>
>
>
> > Spend few days chasing bug in embedded C project which can drilled
> > down to this. Consider the following program, and all reasonable men
> > will expect the result to be negative.  Not in C, and it is not a
> > compiler bug :-(
>
> > And offcorse none of the three comilers I cheched did not bother to
> > issue a warning at least..
>
> > #include<stdio.h>
>
> > int main()
> > {
> >       unsigned n = 128;
> >       int i = -2048;
> >       int r;
>
> >       r = i / n;
>
> >       printf("R = %d\n", r);
>
> >       return 0;
> > }
>
> $ gcc -Wall  t.c
> $ ./a.out
> R = 33554416
>
> That is why we all love C. Best Job security in the world
> for programmers.
>
> There are always "issues" to fix.  You see, you yourself had to
> work for few days on this one. If you had used Ada, or any  other
> more strongly typed languages, then you'll be done early,
> then the manager will have come in and saw you sitting
> doing nothing becuase your program is done, and you'll be out
> of work.
>
> So, you should be very happy you are working on C.
>
> --Nasser

Was difficult to find this one. Unsigned was used as counter to
compute average which could have both signs. Were looking elsewhere
since code seemed to be so logical: dividing on unsigned integer
should always give the result less then argument.  With C disregard to
overflow, seems to be strange such a sudden concern to types
converting everything to higher ranked unsigned.

I do work in C/C++ on one project out of necessity (TI DSP).  Despite
very strict coding conventions this one still sneaked in.  No issue
for ADA and C# gives compile error (fair).  Again, at least compiler
warning will be nice IMHO.

Re: Fun with C

[KK6GM]

On Apr 16, 10:02 am, "George P." <george.p...@gmail.com> wrote:
> Spend few days chasing bug in embedded C project which can drilled
> down to this. Consider the following program, and all reasonable men
> will expect the result to be negative.  Not in C, and it is not a
> compiler bug :-(
>
> And offcorse none of the three comilers I cheched did not bother to
> issue a warning at least..
>
> #include <stdio.h>
>
> int main()
> {
>      unsigned n = 128;
>      int i = -2048;
>      int r;
>
>      r = i / n;
>
>      printf("R = %d\n", r);
>
>      return 0;
>
>
>
> }- Hide quoted text -
>
> - Show quoted text -

Wow and wow.  I've been writing C all my adult life and I didn't
realize this could or would happen.  I would have said that the
unsigned would be promoted to signed.

I'm going to include this example in my push to use Ada in our next
project.

Re: Fun with C

[Georg Bauhaus]

On 4/17/11 8:26 AM, KK6GM wrote:

> Wow and wow.  I've been writing C all my adult life and I didn't
> realize this could or would happen.  I would have said that the
> unsigned would be promoted to signed.
>
> I'm going to include this example in my push to use Ada in our next
> project.

Be careful that there are no C savvy people around.
You are demonstrating a lack of understanding of C basics!
("Stupid!")
That lack is not (in their view, and it's their view that counts)
a good start for asking for a different language.

Had you read section 2.7 of K&R (or A.6), you'd have expected
the result you got: arithmetic operators will convert their
arguments following the rules of the C language definition.

Re: Fun with C

[Georg Bauhaus]

On 4/16/11 11:12 PM, Ludovic Brenta wrote:
> "Nasser M. Abbasi"<nma@12000.org>  writes:

>> $ gcc -Wall  t.c
>> $ ./a.out
>> R = 33554416
>
> So R = 2**25 - 16, the correct answer is -16, so the actual result is
> the correct one except for bit 24, which is 1 when it should be zero.
>
> Out of curiosity, is this actual result a predictable consequence of the
> language definition, or is it undefined behavior?

Why, it is the same in Ada.

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Unchecked_Conversion;

procedure Conv is

     type UInt is mod 2**32;
     type Int is range -2**31 .. 2**31 -1;

     function To_UInt is new Ada.Unchecked_Conversion(Int, UInt);
     N: UInt := 128;
     I: Int := -2048;
     R : Int;
begin
     R := Int(To_UInt(I) / N);
     Put_Line ("R =" & Int'Image(R));
end;

Re: Fun with C

[Martin]

On Apr 17, 8:17 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 4/16/11 11:12 PM, Ludovic Brenta wrote:
>
> > "Nasser M. Abbasi"<n...@12000.org>  writes:
> >> $ gcc -Wall  t.c
> >> $ ./a.out
> >> R = 33554416
>
> > So R = 2**25 - 16, the correct answer is -16, so the actual result is
> > the correct one except for bit 24, which is 1 when it should be zero.
>
> > Out of curiosity, is this actual result a predictable consequence of the
> > language definition, or is it undefined behavior?
>
> Why, it is the same in Ada.
>
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Unchecked_Conversion;
>
> procedure Conv is
>
>      type UInt is mod 2**32;
>      type Int is range -2**31 .. 2**31 -1;
>
>      function To_UInt is new Ada.Unchecked_Conversion(Int, UInt);
>      N: UInt := 128;
>      I: Int := -2048;
>      R : Int;
> begin
>      R := Int(To_UInt(I) / N);
>      Put_Line ("R =" & Int'Image(R));
> end;

Yes, the Ada version is _much_ more obvious and understandable

But I suspect the _intent_ is of the original code is (probably):

with Ada.Text_IO; use Ada.Text_IO;

procedure Conv is

     type UInt is mod 2**32;
     type Int is range -2**31 .. 2**31 -1;

     N: UInt := 128;
     I: Int := -2048;
     R : Int;
begin
     R := I / Int (N);
     Put_Line ("R =" & Int'Image(R));
end;

-- Martin

Re: Fun with C

[Georg Bauhaus]

On 4/16/11 11:12 PM, Ludovic Brenta wrote:

> Out of curiosity, is this actual result a predictable consequence of the
> language definition, or is it undefined behavior?

C's definitions of what happens to arithmetic operands look
like an interesting exercise in making definitions (work).
The standard seems to land the resulting rules somewhere
between Ada types and the effect of Ada.Unchecked_Conversion.
It is not unchecked conversion, I think.

C's rules do not assume a specific bit representation of
arithmetic types, IINM. An interesting consequence  is
that the C99 Rationale lists specific circumstances in which
a result "must be dubbed _questionably signed_". But,
"(...) of course, _all of these ambiguities can be avoided
by a judicous use of casts_."
-- C99 Rationale,  �6.3.1.1

A difference between C and Ada here will be the difference
between *can* and *must*, as in "can be avoided using casts"
and "must be stated using conversions".  Consider programmers
shouting

  I can!

or

  I must!

If the first means "I can do it!" and latter means "It forces me
to do that...", this puts humans in two opposing camps.  Guess who
will be considered to have the more positive attitude. :-)

(Placement in this or that group will not be based on a consistent
set of facts, of course, but with such a set, we we'd have much
less to shout at each other...)

Re: Fun with C

[KK6GM]

On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 4/17/11 8:26 AM, KK6GM wrote:
>
> > Wow and wow.  I've been writing C all my adult life and I didn't
> > realize this could or would happen.  I would have said that the
> > unsigned would be promoted to signed.
>
> > I'm going to include this example in my push to use Ada in our next
> > project.
>
> Be careful that there are no C savvy people around.
> You are demonstrating a lack of understanding of C basics!
> ("Stupid!")
> That lack is not (in their view, and it's their view that counts)
> a good start for asking for a different language.
>
> Had you read section 2.7 of K&R (or A.6), you'd have expected
> the result you got: arithmetic operators will convert their
> arguments following the rules of the C language definition.

Yes, I understand how the "stupid" argument works in the C community.
I'm going to ask some other programmers tomorrow and see how many of
them get this right.  I'm guessing our situation will be similar to
the situation at the OP's workplace, where presumably competent
programmers still got clobbered by this language-legal insanity.

Re: Fun with C

[George P.]

On Apr 17, 3:17 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 4/16/11 11:12 PM, Ludovic Brenta wrote:
>
> > "Nasser M. Abbasi"<n...@12000.org>  writes:
> >> $ gcc -Wall  t.c
> >> $ ./a.out
> >> R = 33554416
>
> > So R = 2**25 - 16, the correct answer is -16, so the actual result is
> > the correct one except for bit 24, which is 1 when it should be zero.
>
> > Out of curiosity, is this actual result a predictable consequence of the
> > language definition, or is it undefined behavior?
>
> Why, it is the same in Ada.
>
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Unchecked_Conversion;
>
> procedure Conv is
>
>      type UInt is mod 2**32;
>      type Int is range -2**31 .. 2**31 -1;
>
>      function To_UInt is new Ada.Unchecked_Conversion(Int, UInt);
>      N: UInt := 128;
>      I: Int := -2048;
>      R : Int;
> begin
>      R := Int(To_UInt(I) / N);
>      Put_Line ("R =" & Int'Image(R));
> end;

Not exactly, here you have at least freedom and understanding what is
being cast to what.  As I mentioned I have no problem C# giving
compile error, screeming - tell me exactly what to do here.  BTW, it
defaults result to a long int, complaining about assigning it to int.

Not to mentioned that negative integer number may be larger then
unsigned.  I am now looking at the rest the code to see where else
could be the same type of cr..p.

George

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 16, 2:02 pm, "George P." <george.p...@gmail.com> wrote:
> Spend few days chasing bug in embedded C project which can drilled
> down to this. Consider the following program, and all reasonable men
> will expect the result to be negative.  Not in C, and it is not a
> compiler bug :-(

All reasonable men will try to learn the language before programming.
The mentioned behavior is the one C is supposed to have, whether you
like it or not. It one of the first thing I teach in my C classes:
type promotions in expression. They may be dumb, or may not, I will
not argue on that. But being reasonable is knowing the tool before
trying to use it.

Is this also a bug?

int i = 1;
int j = 2;
double result = i / j;
printf("%lf\n", result);

results in 0 being output. Oh my god, C can't perform arithmetic
division! More fun with C?

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
> On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> wrote:
>
>
>
>
>
>
>
>
>
> > On 4/17/11 8:26 AM, KK6GM wrote:
>
> > > Wow and wow.  I've been writing C all my adult life and I didn't
> > > realize this could or would happen.  I would have said that the
> > > unsigned would be promoted to signed.
>
> > > I'm going to include this example in my push to use Ada in our next
> > > project.
>
> > Be careful that there are no C savvy people around.
> > You are demonstrating a lack of understanding of C basics!
> > ("Stupid!")
> > That lack is not (in their view, and it's their view that counts)
> > a good start for asking for a different language.
>
> > Had you read section 2.7 of K&R (or A.6), you'd have expected
> > the result you got: arithmetic operators will convert their
> > arguments following the rules of the C language definition.
>
> Yes, I understand how the "stupid" argument works in the C community.
> I'm going to ask some other programmers tomorrow and see how many of
> them get this right.  I'm guessing our situation will be similar to
> the situation at the OP's workplace, where presumably competent
> programmers still got clobbered by this language-legal insanity.

Most programmers are competent in their views. Few really are and it
does not matter what is the actual language. For example, looks like
you feel you are competent in C, but are you?

"I would expect unsigned to int conversion" is just unacceptable!
Someone has written a line of code without knowing what it does. Is it
a language problem? Not that C is spectacular, but blaming the
language here is not fair. Minimally competent C programmers do know
about such conversions. If you don't you suck as a C programmer. If
you suck as a C programmer, please do not try to advocate any other
language over it, this _is_ stupid!

Maybe Ada over C is a smart choice, but advocating it without having a
strong knowledge of both is unacceptable.

Re: Fun with C

[KK6GM]

On Apr 17, 12:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
wrote:
> On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
>
>
>
>
>
> > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> > wrote:
>
> > > On 4/17/11 8:26 AM, KK6GM wrote:
>
> > > > Wow and wow.  I've been writing C all my adult life and I didn't
> > > > realize this could or would happen.  I would have said that the
> > > > unsigned would be promoted to signed.
>
> > > > I'm going to include this example in my push to use Ada in our next
> > > > project.
>
> > > Be careful that there are no C savvy people around.
> > > You are demonstrating a lack of understanding of C basics!
> > > ("Stupid!")
> > > That lack is not (in their view, and it's their view that counts)
> > > a good start for asking for a different language.
>
> > > Had you read section 2.7 of K&R (or A.6), you'd have expected
> > > the result you got: arithmetic operators will convert their
> > > arguments following the rules of the C language definition.
>
> > Yes, I understand how the "stupid" argument works in the C community.
> > I'm going to ask some other programmers tomorrow and see how many of
> > them get this right.  I'm guessing our situation will be similar to
> > the situation at the OP's workplace, where presumably competent
> > programmers still got clobbered by this language-legal insanity.
>
> Most programmers are competent in their views. Few really are and it
> does not matter what is the actual language. For example, looks like
> you feel you are competent in C, but are you?
>
> "I would expect unsigned to int conversion" is just unacceptable!
> Someone has written a line of code without knowing what it does. Is it
> a language problem? Not that C is spectacular, but blaming the
> language here is not fair. Minimally competent C programmers do know
> about such conversions. If you don't you suck as a C programmer. If
> you suck as a C programmer, please do not try to advocate any other
> language over it, this _is_ stupid!
> - Show quoted text -

So, the spankings begin. :)

What is a competent programmer?  One who has made a good living using
the language for 30 years, with no complaints as to my competency?
That's my only claim.  Perhaps the programmers in the OP's
organization would make a similar claim.  I guess in some perfect
world we wouldn't need any of the myriad of checking and verification
tools and rules that people use to protect themselves from their
chosen programming language.

You are making a classic "CMM0" argument, where heroic programmers are
necessary to acheive semi-acceptable results.  You criticize those who
do not know some arcane language rule, when I think the real criticism
shoult be for a language, any language, that blows up on -2048/128.

C is a Steam Age language.  It served a purpose, but it is a sign of
unseriousness and immaturity in our industry that it is still so
widely used, that the terms "C" and "best practice" can ever be found
together.

I work at a company that uses a lot of very large and dangerous
machines for manufacturing.  They would not for a moment stand for
their machines to be as dangerous as C is.  Nor would their insurers
nor the various government organizations to which they must account.
It's not enough any more to say "Yes, C may silently rip the scalp off
of your head, or chop off your arm, but only if you don't know all the
rules and obey them without fail."  Are we to be forever stuck in the
year 1900, programming language-wise?

-2048/128 = 33554416 (or whatever your int size produces).  There's
little more to say.

Re: Fun with C

[Georg Bauhaus]

On 4/17/11 9:35 PM, Elias Salom�o Helou Neto wrote:

> Someone has written a line of code without knowing what it does. Is it
> a language problem? Not that C is spectacular, but blaming the
> language here is not fair. Minimally competent C programmers do know
> about such conversions.

OK, that's a claim.  Michael Barr seem to have found results
contradicting it if the "minimum" is what you minimally
find with professional C programmers. In his netrino.com embedded
C quiz, he found that US takers got at D+ on average.
That's a real world, observable minimum, then.

I suggest turning to observable facts and away from
normative ontology for a moment.  Towards justifiable
language design.

Whenever a statistical phenomenon is observed,
many start looking for correlations and hypotheses.
Here, we have errors related to the / operation and
the promotion rules of C's $6.3.1.  Is there a correlation?
Will the correlation between error rates and language
rules  be the same if using another language?
Is that other language intrinsically better or worse, then?

If there is a correlation between the frequency of a number
of programming errors (in this case related to +,-,*,/ etc)
and the way the corresponding part of the programming language
is defined (in this case operand treatment), then I suggest
the following

Hypothesis 1:

A language A is better designed than another B if,
after comparable introduction to the languages,
programmers of an A-group make fewer mistakes than
programmers of a B-group when implementing the same
algorithm.

If so, then competent, informed language *design* will have to
consider expected error rates when defining the language.
Because the definitions affect error rates.

A second perspective:

Definition: The complexity of / (or another language feature) is
the number of concepts that a human mind will have to connect
properly in order to use / (or another language feature) correctly.

Assumption:  Programming is a human activity.
Since programs express human ideas, clear means of expression reflect
programmer intentions better than formally implicit means that
in addition depend on statements outside the language, as is the
case with C's fundamental types.

I suggest, then,

Hypothesis 2:

A language A is better designed than another B if an
understanding and using the language properly is less complex,
that is, in order to express the same algorithm,

(a) it requires thinking about fewer interconnected, possibly
implicit concepts and

(b) depends less on statements outside the language.

Re: Fun with C

[Gautier write-only]

On 17 avr, 21:19, Elias Salomão Helou Neto <eshn...@gmail.com> wrote:

> All reasonable men will try to learn the language before programming.

Waw! Then you won't meet many reasonable people in companies (or
perhaps only among those who never program)...
______________________________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address

Re: Fun with C

[Nasser M. Abbasi]

On 4/17/2011 4:26 PM, Gautier write-only wrote:
> On 17 avr, 21:19, Elias Salom�o Helou Neto<eshn...@gmail.com>  wrote:
>
>> All reasonable men will try to learn the language before programming.

>
> Waw! Then you won't meet many reasonable people in companies (or
> perhaps only among those who never program)...

I must have been doing something really wrong all those years,
becuase the only way I learned a new language was by
programming in it.  

--Nasser

Re: Fun with C

[George P.]

On Apr 17, 3:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
wrote:
> On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
>
>
>
>
>
> > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> > wrote:
>
> > > On 4/17/11 8:26 AM, KK6GM wrote:
>
> > > > Wow and wow.  I've been writing C all my adult life and I didn't
> > > > realize this could or would happen.  I would have said that the
> > > > unsigned would be promoted to signed.
>
> > > > I'm going to include this example in my push to use Ada in our next
> > > > project.
>
> > > Be careful that there are no C savvy people around.
> > > You are demonstrating a lack of understanding of C basics!
> > > ("Stupid!")
> > > That lack is not (in their view, and it's their view that counts)
> > > a good start for asking for a different language.
>
> > > Had you read section 2.7 of K&R (or A.6), you'd have expected
> > > the result you got: arithmetic operators will convert their
> > > arguments following the rules of the C language definition.
>
> > Yes, I understand how the "stupid" argument works in the C community.
> > I'm going to ask some other programmers tomorrow and see how many of
> > them get this right.  I'm guessing our situation will be similar to
> > the situation at the OP's workplace, where presumably competent
> > programmers still got clobbered by this language-legal insanity.
>
> Most programmers are competent in their views. Few really are and it
> does not matter what is the actual language. For example, looks like
> you feel you are competent in C, but are you?
>
> "I would expect unsigned to int conversion" is just unacceptable!
> Someone has written a line of code without knowing what it does. Is it
> a language problem? Not that C is spectacular, but blaming the
> language here is not fair. Minimally competent C programmers do know
> about such conversions. If you don't you suck as a C programmer. If
> you suck as a C programmer, please do not try to advocate any other
> language over it, this _is_ stupid!
>
> Maybe Ada over C is a smart choice, but advocating it without having a
> strong knowledge of both is unacceptable.- Hide quoted text -
>
> - Show quoted text -

Seems that someone never worked on projects of more then few thousand
lines of code, supports multiple hardware platforms and yes after
programming for 30+ years in it can tell C sucks.

Wonder if sudden acceleration in Toyota cars was not caused by
"intuitive" C typing conversions.

G.

Re: Fun with C

[Peter C. Chapin]

On Sat, 16 Apr 2011 23:12:37 +0200, Ludovic Brenta
<ludovic@ludovic-brenta.org> wrote:


>Out of curiosity, is this actual result a predictable consequence of the
>language definition, or is it undefined behavior?

It is standard. It's part of the rules for "usual arithmetic conversions"
described in section 6.3.1.8 of the C99 standard. In particular when
unsigned int and int are mixed in operations like this, the signed int is
converted to its corresponding unsigned value using the rules in 6.3.1.3
(which typically amounts to just reinterpreting the bit pattern).

As someone who has used C for many years, I don't find this particularly
strange. It is an example of why unsigned types are tricky and should be
avoided unless one has a specific reason for using them.

Many compilers (or other analysis tools) can produce warning messages about
this if you ask for them.

Peter

Re: Fun with C

[George P.]

On Apr 17, 9:04 pm, Peter C. Chapin <PCha...@vtc.vsc.edu> wrote:
> On Sat, 16 Apr 2011 23:12:37 +0200, Ludovic Brenta
>
> <ludo...@ludovic-brenta.org> wrote:
> >Out of curiosity, is this actual result a predictable consequence of the
> >language definition, or is it undefined behavior?
>
> It is standard. It's part of the rules for "usual arithmetic conversions"
> described in section 6.3.1.8 of the C99 standard. In particular when
> unsigned int and int are mixed in operations like this, the signed int is
> converted to its corresponding unsigned value using the rules in 6.3.1.3
> (which typically amounts to just reinterpreting the bit pattern).
>
> As someone who has used C for many years, I don't find this particularly
> strange. It is an example of why unsigned types are tricky and should be
> avoided unless one has a specific reason for using them.
>
> Many compilers (or other analysis tools) can produce warning messages about
> this if you ask for them.
>
> Peter

Now since looking through rest of the code run into another puzzle.
Seems that filter works correctly, but should it?
Assuming that px->acc and pbr is unsigned short, px->lopass is
unsigned char (byte) .



	// Lo-pass Filter
	px->acc += (pbr - (px->acc >> FILT));
	px->lopass= (px->acc >> FILT);


As I unserstand, in this case it does not matter wether (pbr - (px-
>acc >> FILT)) will resilt in large positive number instead of small
negative since overflow on addition will still bring it to right
result.  So we have expression that conceptually wrong, but produce
right answer.

How would C purist rewrite this code?

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 17, 7:26 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 4/17/11 9:35 PM, Elias Salomão Helou Neto wrote:
>
> > Someone has written a line of code without knowing what it does. Is it
> > a language problem? Not that C is spectacular, but blaming the
> > language here is not fair. Minimally competent C programmers do know
> > about such conversions.
>
> OK, that's a claim.  Michael Barr seem to have found results
> contradicting it if the "minimum" is what you minimally
> find with professional C programmers. In his netrino.com embedded
> C quiz, he found that US takers got at D+ on average.
> That's a real world, observable minimum, then.
>
> I suggest turning to observable facts and away from
> normative ontology for a moment.  Towards justifiable
> language design.
>
> Whenever a statistical phenomenon is observed,
> many start looking for correlations and hypotheses.
> Here, we have errors related to the / operation and
> the promotion rules of C's $6.3.1.  Is there a correlation?
> Will the correlation between error rates and language
> rules  be the same if using another language?
> Is that other language intrinsically better or worse, then?
>
> If there is a correlation between the frequency of a number
> of programming errors (in this case related to +,-,*,/ etc)
> and the way the corresponding part of the programming language
> is defined (in this case operand treatment), then I suggest
> the following
>
> Hypothesis 1:
>
> A language A is better designed than another B if,
> after comparable introduction to the languages,
> programmers of an A-group make fewer mistakes than
> programmers of a B-group when implementing the same
> algorithm.
>
> If so, then competent, informed language *design* will have to
> consider expected error rates when defining the language.
> Because the definitions affect error rates.
>
> A second perspective:
>
> Definition: The complexity of / (or another language feature) is
> the number of concepts that a human mind will have to connect
> properly in order to use / (or another language feature) correctly.
>
> Assumption:  Programming is a human activity.
> Since programs express human ideas, clear means of expression reflect
> programmer intentions better than formally implicit means that
> in addition depend on statements outside the language, as is the
> case with C's fundamental types.
>
> I suggest, then,
>
> Hypothesis 2:
>
> A language A is better designed than another B if an
> understanding and using the language properly is less complex,
> that is, in order to express the same algorithm,
>
> (a) it requires thinking about fewer interconnected, possibly
> implicit concepts and
>
> (b) depends less on statements outside the language.

Ok, Ada is better than C, but if you wish we can find a metric whereby
C is better than Ada as well. I won't argue on that. Specially, your
metric seems to imply that Ada is much better for those who find it
hard to think, most people after all.

It is just that industry standard is no standard. Hired programmers
are dumb and incompetent - because those are cheap, there are lots of
them. Look above for someone who say that has been programming
professionally in C for 30 years but doesn't know type promotion
rules. If you are to design a language for those guys, good luck. I am
a researcher, I do not have to, that's why I am happy with C++.

Those who have designed C, have done so for people with brain, for
real computer scientists. It is not the way to go with professional
programmers these days, so don't blame C for its popularity. Of course
Ada is a better approach for the masses. You've made your point:
programmers, as it happens with people in general, are dumb. Let us
create a language for them.

However, here is my piece of advice: it won't work. See Ariane 5's
example. Ada may give programmers a false sense of security, leading
to even more sloppiness.

If I knew it well, I guess I would advocate Ada for parallel
programming. Even the smartest researcher gets surprised sometimes by
the perils of concurrent software and some extra safety here is really
welcome. As long as it does not come at expense of performance, of
course, since this is likely the goal in parallel software.

Surely Ada would be a good and justifiable choice for most industrial
programming projects, but this is not what C was planned for - don't
blame it. Is an airplane's fault if someone without proper knowledge
tries to fly it and kills hundreds? Is a spaceship fault if an
airplane pilot feels competent to fly it and ends up killing
thousands?

Elias.

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 17, 8:26 pm, Gautier write-only <gautier_niou...@hotmail.com>
wrote:
> On 17 avr, 21:19, Elias Salomão Helou Neto <eshn...@gmail.com> wrote:
>
> > All reasonable men will try to learn the language before programming.
>
> Waw! Then you won't meet many reasonable people in companies (or
> perhaps only among those who never program)...

That's exactly what I meant. Because reasonable people are expensive.

Elias.

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 17, 8:43 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 4/17/2011 4:26 PM, Gautier write-only wrote:
>
> > On 17 avr, 21:19, Elias Salom o Helou Neto<eshn...@gmail.com>  wrote:
>
> >> All reasonable men will try to learn the language before programming.
>
> > Waw! Then you won't meet many reasonable people in companies (or
> > perhaps only among those who never program)...
>
> I must have been doing something really wrong all those years,
> becuase the only way I learned a new language was by
> programming in it.  

Without even reading a book about it? You are doing things terribly
wrong. Of course programming is the best way to learn, but not without
a good book to read while practicing.

Furthermore, have you being learning while writing code for a critical
embedded system? If so, you should be in jail. Only those who already
know what is doing should code this stuff.

Elias.

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 17, 9:12 pm, "George P." <george.p...@gmail.com> wrote:
> On Apr 17, 3:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
> wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
>
> > > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> > > wrote:
>
> > > > On 4/17/11 8:26 AM, KK6GM wrote:
>
> > > > > Wow and wow.  I've been writing C all my adult life and I didn't
> > > > > realize this could or would happen.  I would have said that the
> > > > > unsigned would be promoted to signed.
>
> > > > > I'm going to include this example in my push to use Ada in our next
> > > > > project.
>
> > > > Be careful that there are no C savvy people around.
> > > > You are demonstrating a lack of understanding of C basics!
> > > > ("Stupid!")
> > > > That lack is not (in their view, and it's their view that counts)
> > > > a good start for asking for a different language.
>
> > > > Had you read section 2.7 of K&R (or A.6), you'd have expected
> > > > the result you got: arithmetic operators will convert their
> > > > arguments following the rules of the C language definition.
>
> > > Yes, I understand how the "stupid" argument works in the C community.
> > > I'm going to ask some other programmers tomorrow and see how many of
> > > them get this right.  I'm guessing our situation will be similar to
> > > the situation at the OP's workplace, where presumably competent
> > > programmers still got clobbered by this language-legal insanity.
>
> > Most programmers are competent in their views. Few really are and it
> > does not matter what is the actual language. For example, looks like
> > you feel you are competent in C, but are you?
>
> > "I would expect unsigned to int conversion" is just unacceptable!
> > Someone has written a line of code without knowing what it does. Is it
> > a language problem? Not that C is spectacular, but blaming the
> > language here is not fair. Minimally competent C programmers do know
> > about such conversions. If you don't you suck as a C programmer. If
> > you suck as a C programmer, please do not try to advocate any other
> > language over it, this _is_ stupid!
>
> > Maybe Ada over C is a smart choice, but advocating it without having a
> > strong knowledge of both is unacceptable.- Hide quoted text -
>
> > - Show quoted text -
>
> Seems that someone never worked on projects of more then few thousand
> lines of code, supports multiple hardware platforms and yes after
> programming for 30+ years in it can tell C sucks.
>
> Wonder if sudden acceleration in Toyota cars was not caused by
> "intuitive" C typing conversions.

Now you're making hypothesis. I don't even know the problem the, less
so the language of the code, but rest assured that it was a
programmer's fault. Or a compiler bug. One thing that can't be the
cause is the language. Maybe lack of knowledge of it, but not the
language per se.

And nobody said type promotion rules in C are intuitive. They are what
they are, they won't change, is it smart to keep complaining instead
of go read a book?

You say C sucks, ok it is an opinion. I would say someone who doesn't
know type promotion rules and considers himself competent in C sucks
far more.

Elias.

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 17, 5:18 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
> On Apr 17, 12:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
> wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
>
> > > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> > > wrote:
>
> > > > On 4/17/11 8:26 AM, KK6GM wrote:
>
> > > > > Wow and wow.  I've been writing C all my adult life and I didn't
> > > > > realize this could or would happen.  I would have said that the
> > > > > unsigned would be promoted to signed.
>
> > > > > I'm going to include this example in my push to use Ada in our next
> > > > > project.
>
> > > > Be careful that there are no C savvy people around.
> > > > You are demonstrating a lack of understanding of C basics!
> > > > ("Stupid!")
> > > > That lack is not (in their view, and it's their view that counts)
> > > > a good start for asking for a different language.
>
> > > > Had you read section 2.7 of K&R (or A.6), you'd have expected
> > > > the result you got: arithmetic operators will convert their
> > > > arguments following the rules of the C language definition.
>
> > > Yes, I understand how the "stupid" argument works in the C community.
> > > I'm going to ask some other programmers tomorrow and see how many of
> > > them get this right.  I'm guessing our situation will be similar to
> > > the situation at the OP's workplace, where presumably competent
> > > programmers still got clobbered by this language-legal insanity.
>
> > Most programmers are competent in their views. Few really are and it
> > does not matter what is the actual language. For example, looks like
> > you feel you are competent in C, but are you?
>
> > "I would expect unsigned to int conversion" is just unacceptable!
> > Someone has written a line of code without knowing what it does. Is it
> > a language problem? Not that C is spectacular, but blaming the
> > language here is not fair. Minimally competent C programmers do know
> > about such conversions. If you don't you suck as a C programmer. If
> > you suck as a C programmer, please do not try to advocate any other
> > language over it, this _is_ stupid!
> > - Show quoted text -
>
> So, the spankings begin. :)
>
> What is a competent programmer?  One who has made a good living using
> the language for 30 years, with no complaints as to my competency?
> That's my only claim.  Perhaps the programmers in the OP's
> organization would make a similar claim.  I guess in some perfect
> world we wouldn't need any of the myriad of checking and verification
> tools and rules that people use to protect themselves from their
> chosen programming language.
>
> You are making a classic "CMM0" argument, where heroic programmers are
> necessary to acheive semi-acceptable results.  You criticize those who
> do not know some arcane language rule, when I think the real criticism
> shoult be for a language, any language, that blows up on -2048/128.
>
> C is a Steam Age language.  It served a purpose, but it is a sign of
> unseriousness and immaturity in our industry that it is still so
> widely used, that the terms "C" and "best practice" can ever be found
> together.
>
> I work at a company that uses a lot of very large and dangerous
> machines for manufacturing.  They would not for a moment stand for
> their machines to be as dangerous as C is.  Nor would their insurers
> nor the various government organizations to which they must account.
> It's not enough any more to say "Yes, C may silently rip the scalp off
> of your head, or chop off your arm, but only if you don't know all the
> rules and obey them without fail."  Are we to be forever stuck in the
> year 1900, programming language-wise?

Yes, at least while the huge codebase written in C remains. What is
dumbness, ignoring it or living with it? Go and use Ada for your
safety critical software, but there are uses for C too, if you don't
know.

Do you know what is dumbness? Trying to create "A Language to Rule
them All". Ada is Ada and C is C. I have never seen a real numeric
library in Ada, there are tons written in FORTRAN, C and C++. Now go
and advocate Ada for those folks too, you surely know more than all of
us about numeric programming don't you? Or why would we keep using a
year 1900 programming language? Go and advocate Ada for system
programming, of course there is no Ada OS in use today simply because
all system programmers are stupid and stubborn and prefer C or C++
over the much better Ada. Ada is for everything. Now, this is
dumbness.

Have you ever heard me saying Ada sucks? No, because saying it is
stupid. As it is also stupid to say that C sucks. Neither FORTRAN or
assembly sucks as well. Use each language where it should be used and
this is being smart. Maybe even Java has its proper place.

Anyone who says "C sucks", "Ada sucks", "FORTRAN sucks", "C++ sucks",
is being stupid. The way to go is to select the proper tool for the
job. Maybe "C sucks for safety-critical embedded systems" would be
better. And C will never suck only because its type promotion system.
While it is not intuitive it is pretty simple and easy to understand:
are you mixing unsigned and int and wish to obtain a signed integer?
Use a cast to int on the unsigned. This is really very difficult to
learn, isn't it?

>
> -2048/128 = 33554416 (or whatever your int size produces).  There's
> little more to say.

If this is your argument against C, there is nothing to say. I dislike
those rules too and when I was a beginner they used to surprise me as
well. But now I know what I am doing and I refuse to keep whining
against it. I am not such a sissy.

Re: Fun with C

[KK6GM]

On Apr 18, 12:12 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
wrote:
>
> <industrial programming projects> is not what C was planned for - don't
> blame it.

Here we agree.  C is what it is, it never claimed to be One Language
To Rule Them All.  But it is a sign of our industry's lack of maturity
that it has been used in so many areas where it is not the most
suitable choice, and was never the most suitable choice.  C (and C++)
are highly unsafe languages.  That is why they require so many tools
and restrictions to be used reliably.  But our industry continues to
pound that square peg into every possible shape of holes.  And so,
inevitably, we end up with e.g. C code certified to DO-178B Level A
that still has 10 times the anomalies of certified Ada code, and 100
times the anomalies of certified SPARK code.  It defies logic.

Re: Fun with C

[Georg Bauhaus]

On 4/18/11 9:12 PM, Elias Salom�o Helou Neto wrote:
> On Apr 17, 7:26 pm, Georg Bauhaus<rm.dash-bauh...@futureapps.de>

>> I suggest turning to observable facts and away from
>> normative ontology for a moment.  Towards justifiable
>> language design.

Unfortunately, when it comes to empirical research into the effects
of language definitions, hardly anyone ever finds a scientific
approach worthwhile.

> if you wish we can find a metric whereby
> C is better than Ada as well.

I'm eager to add more metrics to my collection programming language
metrics.

C's pointer arithmetic is unchecked, unlike Ada's, and thus faster.
(A experiment that some embedded C people found fair resulted in
a ratio of 10:12).  Another metric.

So we have three PL metrics and three hypotheses for a start.

> I won't argue on that. Specially, your
> metric seems to imply that Ada is much better for those who find it
> hard to think, most people after all.

Uhm, no, that's a misunderstanding, Ada requires quite some thinking,
it is just that its basic types do not require so much thinking.

I should stress one *major* concern of my favorite approach to
language definition:

Smart brains should not have to spend time with tackling basic
programming techniques.  In any language.  They should have all
their thinking capacity engaged in thinking about smart solutions.
Not in keeping track of types' implicit sizes. That's wasted effort.
(PC-lint -w 4 seems to confirm this view.)

If mastering a relatively basic feature of a language requires
much learning, then this investment should be compared to its results.
What is the return on investment a programmer spent on implicit
type size education, say?

Among the observable results are these:

(a) you know how to use basic programming features

(b) you take pride in this ability

(c) you can set yourself apart from others without the skill

Which skill is, nota bene, knowing how to write basics.


> Of course Ada is a better approach for the masses.

Certainly not in full.  Like C++. Because no big, detailed language
will ever work for the masses.  Subsets may do so, as a starting
point, I think.


> However, here is my piece of advice: it won't work. See Ariane 5's
> example.

I understand your idea, I think, but it is this very example that
has surprisingly little to do with languages, in spite of all
the ambitious remarks made about the case.  Have you had time to
look into the report?

> Ada may give programmers a false sense of security, leading
> to even more sloppiness.

Hmm... Is there an operational definition useful to turn this claim
into a hypothesis?  I had thought that Ada culture nurtures awareness
of security issues more than false beliefs in "secure languages".

> Surely Ada would be a good and justifiable choice for most industrial
> programming projects, but this is not what C was planned for - don't
> blame it.

Complaints were addressing using C in industrial projects because of the
effects it has in industrial projects.  There is evidence that different
fundamental type  systems help non-dumb people solve their problems more
successfully.  People will still be using C libraries and additional
code generators, as a replacement for a better suited type system.

If something is going to replace C, it sure mustn't look like Ada.
Just be like it in some ways.  That's the crucial part, I think.
Keeps face.

Re: Fun with C

[Nasser M. Abbasi]

On 4/18/2011 2:01 PM, Georg Bauhaus wrote:

>
> Smart brains should not have to spend time with tackling basic
> programming techniques.  In any language.  They should have all
> their thinking capacity engaged in thinking about smart solutions.
> Not in keeping track of types' implicit sizes. That's wasted effort.
> (PC-lint -w 4 seems to confirm this view.)
>
> If mastering a relatively basic feature of a language requires
> much learning, then this investment should be compared to its results.
> What is the return on investment a programmer spent on implicit
> type size education, say?
>

Exactly. the above is the main point that
needs to stressed.

Someone who programs in C/C++ and other weakly
typed languages, can spend 5 days to find a bug,
then they would feel so proud of themselves, and may
be even get a raise from the boss, because they
keep finding more bugs.

But if they would have used a better language,
a more strongly typed language, then this time would
have been saved to work on the design and the algorithm
itself, and think about the problem itself.

May be even use the saved time to write more test
cases, instead of wasted hours debugging pointers and
type mismatches problems, and But then these warrior
programmers would not longer feel like they are in a
battle anymore when 'coding'. So programming
would not be 'fun' any more.

--Nasser

Re: Fun with C

[Peter C. Chapin]

On Mon, 18 Apr 2011 12:47:56 -0700 (PDT), Elias Salom�o Helou Neto
<eshneto@gmail.com> wrote:

>Have you ever heard me saying Ada sucks? No, because saying it is
>stupid. As it is also stupid to say that C sucks. Neither FORTRAN or
>assembly sucks as well. Use each language where it should be used and
>this is being smart. Maybe even Java has its proper place.

It is true that different languages are good at different things. It is
also politically correct to argue that every language has its place, etc.
Yet it is also true that there are real technical differences between
languages and some languages are just plain better than others.

Ada competes with C in the same application areas. I think that any
application for which it is reasonable to deploy a C program is also a good
application for Ada (and visa-versa). Considering the technical differences
in the languages it is difficult to see what advantage C has over Ada aside
from a difference in popularity, tool and library support, etc (not that
those are insignificant differences but they are not really related to the
merits of the language itself).

Comparing Ada to C++ is more interesting. Again both languages tend to make
sense in similar application areas and C++, unlike C, provides extensive
facilities for creating and using abstractions (like Ada).

Peter

Re: Fun with C

[Randy Brukardt]

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

"Elias Salom�o Helou Neto" <eshneto@gmail.com> wrote in message 
news:d169b543-eed4-4a0a-a295-e391c198463e@j9g2000prj.googlegroups.com...
On Apr 17, 8:43 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
...
>> I must have been doing something really wrong all those years,
>> becuase the only way I learned a new language was by
>> programming in it.
>
>Without even reading a book about it? You are doing things terribly
>wrong. Of course programming is the best way to learn, but not without
>a good book to read while practicing.

There aren't always books to read. We wrote a partial Ada *compiler* back in 
1980 from a description circulated by our professor (Janus/Ada originally 
started in a compiler construction course). The only book that we had (and 
we didn't get that until near the end of the class when we had already 
decided to commercialize it) was the 1980 Ada Reference Manual. I'm pretty 
sure that we had already converted the entire compiler into Ada code (so it 
could compile itself) before we saw any of the early Ada textbooks. (The 
Pyle textbook that we distributed with the compiler didn't come out until 
late 1981, I think.)

That was OK, Ada wasn't that different than Pascal which we both already 
knew well.

I recall being asked on several occassions why we were able to build an Ada 
compiler is so much less time and manpower than everyone else. And there was 
no secret -- we used Ada and probably didn't spend as much time debugging as 
others.

                                         Randy.

Re: Fun with C

[Elias Salomão Helou Neto]

> Uhm, no, that's a misunderstanding, Ada requires quite some thinking,
> it is just that its basic types do not require so much thinking.
>
> I should stress one *major* concern of my favorite approach to
> language definition:
>
> Smart brains should not have to spend time with tackling basic
> programming techniques.  In any language.  They should have all
> their thinking capacity engaged in thinking about smart solutions.
> Not in keeping track of types' implicit sizes. That's wasted effort.
> (PC-lint -w 4 seems to confirm this view.)

There is no time spent thinking about promotions in C when you learn
it. It is surely mor difficult to learn, so you've still made your
point.

>
> If mastering a relatively basic feature of a language requires
> much learning, then this investment should be compared to its results.
> What is the return on investment a programmer spent on implicit
> type size education, say?
>
> Among the observable results are these:
>
> (a) you know how to use basic programming features
>
> (b) you take pride in this ability
>
> (c) you can set yourself apart from others without the skill
>
> Which skill is, nota bene, knowing how to write basics.

Ok, I understand, just please notice that I am not taking pride for
anything. It is quite the opposite, those who don't know the basics
should be ashamed of screaming "C sucks".

>
> > Of course Ada is a better approach for the masses.
>
> Certainly not in full.  Like C++. Because no big, detailed language
> will ever work for the masses.  Subsets may do so, as a starting
> point, I think.
>
> > However, here is my piece of advice: it won't work. See Ariane 5's
> > example.
>
> I understand your idea, I think, but it is this very example that
> has surprisingly little to do with languages, in spite of all
> the ambitious remarks made about the case.  Have you had time to
> look into the report?

I did not. But what I meant was basically that: people will keep doing
dumbness because they are just people (me included). No matter what
language is used.

> > Ada may give programmers a false sense of security, leading
> > to even more sloppiness.
>
> Hmm... Is there an operational definition useful to turn this claim
> into a hypothesis?  I had thought that Ada culture nurtures awareness
> of security issues more than false beliefs in "secure languages".

No there is not and I should not have said that without thinking a
little bit more about it.

>
> > Surely Ada would be a good and justifiable choice for most industrial
> > programming projects, but this is not what C was planned for - don't
> > blame it.
>
> Complaints were addressing using C in industrial projects because of the
> effects it has in industrial projects.  There is evidence that different
> fundamental type  systems help non-dumb people solve their problems more
> successfully.  People will still be using C libraries and additional
> code generators, as a replacement for a better suited type system.

I would like to see this evidence.

>
> If something is going to replace C, it sure mustn't look like Ada.
> Just be like it in some ways.  That's the crucial part, I think.
> Keeps face.

Re: Fun with C

[George P.]

On Apr 18, 3:24 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
wrote:
> On Apr 17, 9:12 pm, "George P." <george.p...@gmail.com> wrote:
>
>
>
>
>
> > On Apr 17, 3:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
> > wrote:
>
> > > On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
>
> > > > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> > > > wrote:
>
> > > > > On 4/17/11 8:26 AM, KK6GM wrote:
>
> > > > > > Wow and wow.  I've been writing C all my adult life and I didn't
> > > > > > realize this could or would happen.  I would have said that the
> > > > > > unsigned would be promoted to signed.
>
> > > > > > I'm going to include this example in my push to use Ada in our next
> > > > > > project.
>
> > > > > Be careful that there are no C savvy people around.
> > > > > You are demonstrating a lack of understanding of C basics!
> > > > > ("Stupid!")
> > > > > That lack is not (in their view, and it's their view that counts)
> > > > > a good start for asking for a different language.
>
> > > > > Had you read section 2.7 of K&R (or A.6), you'd have expected
> > > > > the result you got: arithmetic operators will convert their
> > > > > arguments following the rules of the C language definition.
>
> > > > Yes, I understand how the "stupid" argument works in the C community.
> > > > I'm going to ask some other programmers tomorrow and see how many of
> > > > them get this right.  I'm guessing our situation will be similar to
> > > > the situation at the OP's workplace, where presumably competent
> > > > programmers still got clobbered by this language-legal insanity.
>
> > > Most programmers are competent in their views. Few really are and it
> > > does not matter what is the actual language. For example, looks like
> > > you feel you are competent in C, but are you?
>
> > > "I would expect unsigned to int conversion" is just unacceptable!
> > > Someone has written a line of code without knowing what it does. Is it
> > > a language problem? Not that C is spectacular, but blaming the
> > > language here is not fair. Minimally competent C programmers do know
> > > about such conversions. If you don't you suck as a C programmer. If
> > > you suck as a C programmer, please do not try to advocate any other
> > > language over it, this _is_ stupid!
>
> > > Maybe Ada over C is a smart choice, but advocating it without having a
> > > strong knowledge of both is unacceptable.- Hide quoted text -
>
> > > - Show quoted text -
>
> > Seems that someone never worked on projects of more then few thousand
> > lines of code, supports multiple hardware platforms and yes after
> > programming for 30+ years in it can tell C sucks.
>
> > Wonder if sudden acceleration in Toyota cars was not caused by
> > "intuitive" C typing conversions.
>
> Now you're making hypothesis. I don't even know the problem the, less
> so the language of the code, but rest assured that it was a
> programmer's fault. Or a compiler bug. One thing that can't be the
> cause is the language. Maybe lack of knowledge of it, but not the
> language per se.
>
> And nobody said type promotion rules in C are intuitive. They are what
> they are, they won't change, is it smart to keep complaining instead
> of go read a book?
>
> You say C sucks, ok it is an opinion. I would say someone who doesn't
> know type promotion rules and considers himself competent in C sucks
> far more.
>
> Elias.- Hide quoted text -
>
> - Show quoted text -

Oh really? So C is the language of cyborgs that never have bad days,
never argue with their girlfriends and never go late night drinking?
And sure none of such people should be allowed to design embedded
systems :-)

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 18, 8:10 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Elias Salomão Helou Neto" <eshn...@gmail.com> wrote in messagenews:d169b543-eed4-4a0a-a295-e391c198463e@j9g2000prj.googlegroups.com...
> On Apr 17, 8:43 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> ...
>
> >> I must have been doing something really wrong all those years,
> >> becuase the only way I learned a new language was by
> >> programming in it.
>
> >Without even reading a book about it? You are doing things terribly
> >wrong. Of course programming is the best way to learn, but not without
> >a good book to read while practicing.
>
> There aren't always books to read.

C books? Come on!

> We wrote a partial Ada *compiler* back in
> 1980 from a description circulated by our professor (Janus/Ada originally
> started in a compiler construction course).

Surely the first Ada compiler you wrote wasn't coded in Ada itself.
Haven't you read any book about the language used to code the compiler
before? Weren't the professor's description a kind of "book"?

So keep saying people that they do not need to study the language they
intend to write code on. This is really smart, isn't it?

> The only book that we had (and
> we didn't get that until near the end of the class when we had already
> decided to commercialize it) was the 1980 Ada Reference Manual.

So you're again trying to claim you have written a compiler without
knowledge of the language to be compiled? It must be some kind of
magic, for sure. Again, what about the description by your teacher?

> I'm pretty
> sure that we had already converted the entire compiler into Ada code (so it
> could compile itself) before we saw any of the early Ada textbooks. (The
> Pyle textbook that we distributed with the compiler didn't come out until
> late 1981, I think.)

After writing an Ada compiler it is very unlikely for someone not to
know the language. There are lots of C textbooks, why not to use them?
Nonsense.

Also, please notice that I've recommended a book for those that are
learning the language, not for those who have already mastered it (but
even so a good reference manual is invaluable).

>
> That was OK, Ada wasn't that different than Pascal which we both already
> knew well.

This is dangerous. People seem to believe C is like Pascal or BASIC.
Is this knowing C? This is the kind of misconception we have to fight.
No programmer should claim to know C (or any other language) if he/she
doesn't really knows it.

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 18, 10:22 pm, "George P." <george.p...@gmail.com> wrote:
> On Apr 18, 3:24 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
> wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 17, 9:12 pm, "George P." <george.p...@gmail.com> wrote:
>
> > > On Apr 17, 3:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
> > > wrote:
>
> > > > On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
>
> > > > > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> > > > > wrote:
>
> > > > > > On 4/17/11 8:26 AM, KK6GM wrote:
>
> > > > > > > Wow and wow.  I've been writing C all my adult life and I didn't
> > > > > > > realize this could or would happen.  I would have said that the
> > > > > > > unsigned would be promoted to signed.
>
> > > > > > > I'm going to include this example in my push to use Ada in our next
> > > > > > > project.
>
> > > > > > Be careful that there are no C savvy people around.
> > > > > > You are demonstrating a lack of understanding of C basics!
> > > > > > ("Stupid!")
> > > > > > That lack is not (in their view, and it's their view that counts)
> > > > > > a good start for asking for a different language.
>
> > > > > > Had you read section 2.7 of K&R (or A.6), you'd have expected
> > > > > > the result you got: arithmetic operators will convert their
> > > > > > arguments following the rules of the C language definition.
>
> > > > > Yes, I understand how the "stupid" argument works in the C community.
> > > > > I'm going to ask some other programmers tomorrow and see how many of
> > > > > them get this right.  I'm guessing our situation will be similar to
> > > > > the situation at the OP's workplace, where presumably competent
> > > > > programmers still got clobbered by this language-legal insanity.
>
> > > > Most programmers are competent in their views. Few really are and it
> > > > does not matter what is the actual language. For example, looks like
> > > > you feel you are competent in C, but are you?
>
> > > > "I would expect unsigned to int conversion" is just unacceptable!
> > > > Someone has written a line of code without knowing what it does. Is it
> > > > a language problem? Not that C is spectacular, but blaming the
> > > > language here is not fair. Minimally competent C programmers do know
> > > > about such conversions. If you don't you suck as a C programmer. If
> > > > you suck as a C programmer, please do not try to advocate any other
> > > > language over it, this _is_ stupid!
>
> > > > Maybe Ada over C is a smart choice, but advocating it without having a
> > > > strong knowledge of both is unacceptable.- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > Seems that someone never worked on projects of more then few thousand
> > > lines of code, supports multiple hardware platforms and yes after
> > > programming for 30+ years in it can tell C sucks.
>
> > > Wonder if sudden acceleration in Toyota cars was not caused by
> > > "intuitive" C typing conversions.
>
> > Now you're making hypothesis. I don't even know the problem the, less
> > so the language of the code, but rest assured that it was a
> > programmer's fault. Or a compiler bug. One thing that can't be the
> > cause is the language. Maybe lack of knowledge of it, but not the
> > language per se.
>
> > And nobody said type promotion rules in C are intuitive. They are what
> > they are, they won't change, is it smart to keep complaining instead
> > of go read a book?
>
> > You say C sucks, ok it is an opinion. I would say someone who doesn't
> > know type promotion rules and considers himself competent in C sucks
> > far more.
>
> > Elias.- Hide quoted text -
>
> > - Show quoted text -
>
> Oh really? So C is the language of cyborgs that never have bad days,
> never argue with their girlfriends and never go late night drinking?
> And sure none of such people should be allowed to design embedded
> systems :-)

No, not cyborgs, it is the language of nerds. They don't drink and
about girlfriends, you've gotta be kidding! Also all of their days are
bad, so they're used to it.
:-)

Now, seriously, what I meant is that bashing C without knowing the
basics doesn't make anyone look smart. It is quite the opposite. And I
repeat, whining is not the way to go here. Yes, C is dangerous, unsafe
and difficult to master, but let us be men and use it well if
required.

I believe making assumptions about language behavior is danger. There
are historical reasons why C is the way it is. Some of them were
wrong, now we know, but it won't change - mainly because of the huge
codebase. So, let's have fun with C, why not? I have fun with C, C++,
TeX, Lisp, Pascal, Matlab, etc. Right now I am trying to find time to
study Ada - more fun! I am sure I will share you guys' view about how
Ada is good and safe, but it is really unlikely that I am going to
become such a sissy and fill this newsgroups with foolish complaints.

And as a side note, even sober, I have recently written a heavily
templated C++ ray tracer which I instantiated with unsigneds as
indices and signeds as difference types. There was a mixed expression
that gave me some trouble, and I do understand the problem people
mention in this thread. What I do not understand is how people can
show pride in not knowing the language! And I can't see me whining
that much because of something that won't (because it can't) change -
the C language.

Re: Fun with C

[Bill Findlay]

On 19/04/2011 03:06, in article
2693b280-bbe2-45ea-8355-e96ccbc381f9@a26g2000vbo.googlegroups.com, "Elias
Salom�o Helou Neto" <eshneto@gmail.com> wrote:

...

> Yes, C is dangerous, unsafe and difficult to master,
> but LET US BE MEN and use it well if required.

...

> IT IS REALLY UNLIKELY THAT I AM GOING TO BECOME SUCH A SISSY
> and fill this newsgroups with foolish complaints.

It is a truth universally acknowledged that defenders of C eventually stoop
to macho posturing.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Fun with C

[George P.]

On Apr 18, 5:20 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 4/18/2011 2:01 PM, Georg Bauhaus wrote:
>
> Someone who programs in C/C++ and other weakly
> typed languages, can spend 5 days to find a bug,
> then they would feel so proud of themselves, and may
> be even get a raise from the boss, because they
> keep finding more bugs.
>
> But if they would have used a better language,
> a more strongly typed language, then this time would
> have been saved to work on the design and the algorithm
> itself, and think about the problem itself.
>
>...
>
> --Nasser

How true.  I know good C coders that show very little interest in
application part of software design. The pride is built around
performance gains individual can produce. That rarely exceeds 10-20%
though.

The fundamental difference between C and other languages in my view,
is that C is not exactly a high level programming language.  It is
built around simple mini-computer architecture and as such is limited
by it.  It has it's place ofcorse. After all, one can write compilers
generating C code.

Coming back to my project here is the JSF Coding standard rules that
we follow indeed states:

http://www2.research.att.com/~bs/JSF-AV-rules.pdf

AV Rule 162
Signed and unsigned values shall not be mixed in arithmetic or
comparison operations.
Rationale: Mixing signed and unsigned values is error prone as it
subjects operations to numerous arithmetic conversion and integral
promotion rules.

Obviously that one slipped through. No wonder since these rules are
141 pages long.  Well, computers are still programmed by humans
(unfortunately) ;-)


--

Re: Fun with C

[George P.]

On Apr 18, 10:06 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
wrote:
> On Apr 18, 10:22 pm, "George P." <george.p...@gmail.com> wrote:
>
>
>
>
>
>
> > Oh really? So C is the language of cyborgs that never have bad days,
> > never argue with their girlfriends and never go late night drinking?
> > And sure none of such people should be allowed to design embedded
> > systems :-)
>
> No, not cyborgs, it is the language of nerds. They don't drink and
> about girlfriends, you've gotta be kidding! Also all of their days are
> bad, so they're used to it.
> :-)
>
> Now, seriously, what I meant is that bashing C without knowing the
> basics doesn't make anyone look smart. It is quite the opposite. And I
> repeat, whining is not the way to go here. Yes, C is dangerous, unsafe
> and difficult to master, but let us be men and use it well if
> required.
>
> I believe making assumptions about language behavior is danger. There
> are historical reasons why C is the way it is. Some of them were
> wrong, now we know, but it won't change - mainly because of the huge
> codebase. So, let's have fun with C, why not? I have fun with C, C++,
> TeX, Lisp, Pascal, Matlab, etc. Right now I am trying to find time to
> study Ada - more fun! I am sure I will share you guys' view about how
> Ada is good and safe, but it is really unlikely that I am going to
> become such a sissy and fill this newsgroups with foolish complaints.
>
> And as a side note, even sober, I have recently written a heavily
> templated C++ ray tracer which I instantiated with unsigneds as
> indices and signeds as difference types. There was a mixed expression
> that gave me some trouble, and I do understand the problem people
> mention in this thread. What I do not understand is how people can
> show pride in not knowing the language! And I can't see me whining
> that much because of something that won't (because it can't) change -
> the C language.- Hide quoted text -
>
> - Show quoted text -

I thought you was the first accusing incompetence here.  I respect
your talents in mastering so many languages, but for many of us
languages are just tools to solve problems. Thinking of the problem is
hard enough. Thus, combing throuh code trying to figure out what
compiler will do is just ectra distruction.  I understand very well
that C is sort of F1 racing car.  It's all good, but if you are in
freight business investing in F1 car is of questionable value (except
for promotion).  For those of us who is in commercial application
development cost/value becomes of importance.  What we are getting in
costs?  Special bread of coders, lengthy development cycle (you
admitted yourself your excapade with templates), possibility of having
sleeping bugs.
Now what will be the value? 10-20% performance?

Sometime we are forced to use languages by hardware vendors...

G.

Re: Fun with C

[Georg Bauhaus]

On 4/19/11 3:10 AM, Elias Salom�o Helou Neto wrote:
>  what I meant was basically that: people will keep doing
> dumbness because they are just people (me included). No matter what
> language is used.

Agree.  Perhaps one language can make being stupid more difficult
than another, then.



>> There is evidence that different
>> fundamental type  systems help non-dumb people solve their problems more
>> successfully.  People will still be using C libraries and additional
>> code generators, as a replacement for a better suited type system.
>
> I would like to see this evidence.

One comparative study, not entirely free of all bias I would think,
but pretty close to standard experiments yielding valid data,
was conducted over several years, by John W. McCormick. It is
about a project that switched not subjects or algorithms but the
language. The result was published in August 2000 as
http://www.crosstalkonline.org/storage/issue-archives/2000/200008/200008-McCormick.pdf

 From which is this quote:

"Upon reading the project listings and team member diaries,
  I concluded that the major advantages of Ada for these
students were, in order of importance:
� Modeling of scalar objects.
   � Strong typing.
   � Range constraints.
   � Enumeration types.
� Parameter modes that reflect the problem rather than the mechanism.
� Named parameter association.
� (...)"

(There may be news on this, ACM lists a 2008 experience report.)

Re: Fun with C

[Jeffrey Carter]

On 04/19/2011 07:28 AM, Georg Bauhaus wrote:
>
> One comparative study, not entirely free of all bias I would think,
> but pretty close to standard experiments yielding valid data,
> was conducted over several years, by John W. McCormick. It is
> about a project that switched not subjects or algorithms but the
> language. The result was published in August 2000 as
> http://www.crosstalkonline.org/storage/issue-archives/2000/200008/200008-McCormick.pdf

In addition to McCormick's report, there's the Rational comparison of 2 
Ada-compiler projects:

archive.adaic.com/intro/ada-vs-c/cada_art.html

archive.adaic.com wasn't responding for me, but Google has it cached.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17

Re: Fun with C

[Vinzent Hoefler]

George P. wrote:

> Coming back to my project here is the JSF Coding standard rules that
> we follow indeed states:
>
> http://www2.research.att.com/~bs/JSF-AV-rules.pdf
>
> AV Rule 162
> Signed and unsigned values shall not be mixed in arithmetic or
> comparison operations.

One question: Did you just forget to launch the appropriate checker
or does nobody actually check if those rules are obeyed?


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
    --  Waldi Ravens

Re: Fun with C

[George P.]

On Apr 19, 2:05 pm, "Vinzent Hoefler"
<0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote:
> George P. wrote:
> > Coming back to my project here is the JSF Coding standard rules that
> > we follow indeed states:
>
> >http://www2.research.att.com/~bs/JSF-AV-rules.pdf
>
> > AV Rule 162
> > Signed and unsigned values shall not be mixed in arithmetic or
> > comparison operations.
>
> One question: Did you just forget to launch the appropriate checker
> or does nobody actually check if those rules are obeyed?
>
> Vinzent.
>
> --
> A C program is like a fast dance on a newly waxed dance floor by people carrying
> razors.
>     --  Waldi Ravens

We simply follow the styling described here. I don' know of any
checker for LM JSF. MISRA would be too strict for our needs.  It is an
imaging device with built-in AI.

G.

Re: Fun with C

[Georg Bauhaus]

On 4/19/11 9:34 PM, George P. wrote:

> We simply follow the styling described here. I don' know of any
> checker for LM JSF. MISRA would be too strict for our needs.  It is an
> imaging device with built-in AI.

Shamelessly pasting your original example  into the
DIY box at Gimpel Software, without triggering anything
related to MISRA, it gives:

FlexeLint for C/C++ (Unix) Vers. 9.00f, Copyright Gimpel Software 1985-2010
--- Module: diy.c (C)
      1  /* Enter your C code here - you can delete this line. */
      2
      3
      4  #include <stdio.h>
      5
      6  int main()
      7  {
      8       unsigned n = 128;
      9       int i = -2048;
     10       int r;
     11
                       _
     12       r = i / n;
diy.c  12  Warning 573:  Signed-unsigned mix with divide
diy.c  12  Info 737:  Loss of sign in promotion from int to unsigned int
diy.c  12  Info 713:  Loss of precision (assignment) (unsigned int to int)
     13
     14       printf("R = %d\n", r);
     15
     16       return 0;
     17  }

Re: Fun with C

[J-P. Rosen]

Le 17/04/2011 21:19, Elias Salom�o Helou Neto a �crit :
> All reasonable men will try to learn the language before programming.
> The mentioned behavior is the one C is supposed to have, whether you
> like it or not. It one of the first thing I teach in my C classes:
> type promotions in expression. They may be dumb, or may not, I will
> not argue on that. But being reasonable is knowing the tool before
> trying to use it.
>

I really wonder why there are barriers on balconies. All reasonable 
people know that being too close to the edge of the balcony is dangerous.

Here is a quote from one of the first books on C, written by K&R:
"C was designed under the assumption that the programmer is someone 
reasonable who knows what he is doing".

Here is a quote from the introduction to the Ada LRM:
"Ada was designed with consideration for programming as a human activity"

I let as a philosophy homework that these two starting point led to 
completely different languages.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Fun with C

[KK6GM]

On Apr 19, 10:11 pm, "J-P. Rosen" <ro...@adalog.fr> wrote:
> Le 17/04/2011 21:19, Elias Salom o Helou Neto a crit :
>
> > All reasonable men will try to learn the language before programming.
> > The mentioned behavior is the one C is supposed to have, whether you
> > like it or not. It one of the first thing I teach in my C classes:
> > type promotions in expression. They may be dumb, or may not, I will
> > not argue on that. But being reasonable is knowing the tool before
> > trying to use it.
>
> I really wonder why there are barriers on balconies. All reasonable
> people know that being too close to the edge of the balcony is dangerous.
>
> Here is a quote from one of the first books on C, written by K&R:
> "C was designed under the assumption that the programmer is someone
> reasonable who knows what he is doing".
>
> Here is a quote from the introduction to the Ada LRM:
> "Ada was designed with consideration for programming as a human activity"
>
> I let as a philosophy homework that these two starting point led to
> completely different languages.

A simple extrapolation of a 2002 study puts the worldwide cost of
buggy software at about $350 billion today.  1/3 of that cost is
incurred by developers, 2/3 by end users.  I want to know who these
reasonable developers are who are OK with losing $120 billion per year
using "popular" languages when all the data points to languages that
could reduce that figure dramatically.

And I'd like to know what their customers would think (the customers
who are losing $240 billion a year) if they knew that they were being
sold buggy software even though there were proven languages that could
reduce that loss dramatically.

So, by what standard is the use of C "reasonable"?

Re: Fun with C

[Vinzent Hoefler]

J-P. Rosen wrote:

> Here is a quote from one of the first books on C, written by K&R:
> "C was designed under the assumption that the programmer is someone
> reasonable who knows what he is doing".

Or simply:

<http://www.open-std.org/jtc1/sc22/wg14/www/charter>:

|Some of the facets of the spirit of C can be summarized in phrases like
|(a) Trust the programmer.
|(b) Don't prevent the programmer from doing what needs to be done.
|(c) Keep the language small and simple.
|(d) Provide only one way to do an operation.
|(e) Make it fast, even if it is not guaranteed to be portable.

Now the question remains who is more reasonable: The one using a language
that prevents him from making silly mistakes - or the one assuming he does
not even make those mistakes in the first place.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: Fun with C

[Georg Bauhaus]

On 4/20/11 9:04 PM, Vinzent Hoefler wrote:

> <http://www.open-std.org/jtc1/sc22/wg14/www/charter>:
>
> |Some of the facets of the spirit of C can be summarized in phrases like
> |(a) Trust the programmer.
> |(b) Don't prevent the programmer from doing what needs to be done.
> |(c) Keep the language small and simple.
> |(d) Provide only one way to do an operation.
> |(e) Make it fast, even if it is not guaranteed to be portable.

Not much different from what is true about Ada.

(a) (Like Haskell,) Ada trusts the programmer to be explicit,
e.g. instantiating Unchecked_Conversion.
Normally, though, Ada doesn't trust us when we want to pass
addresses of local objects up the call chain. But it is possible.

(b) Ada seems to make it a little difficult to get pointer arithmetic
from Interfaces.C.Pointers to omit null tests.  But otherwise...

(c) The C standard is about the same size as Ada's, isn't it?
C is simple?

(d) Are there two ways to do an operation in Ada?

(e) Some Ada programs are fast and still guaranteed to be portable.
That's true of some C programs as well.  Ada programs might need unchecked
conversions and representation clauses to make a program non-portable.

Although, an Ada program need not be non-portable even though we let
the *compiler* choose efficient the representation on a target
machine:

     type Roman is ('M', 'D', 'C', 'L', 'V', 'I', 'X');
     for Roman'Size use Integer'Size;

     function To_Integer is new Unchecked_Conversion(Roman, Integer);

Now

     To_Integer(X) + N;

will produce the "byte operation [that] is more efficient on the
target machine" iff the compiler uses efficient byte operations
for Integer.  Or this,

     type S is new String;
     for S'Component_Size use Integer'Size;

So I guess C's (e) is working around the fact that C's choices
would not allow the programmer to say what needs to be done?

Re: Fun with C

[Vinzent Hoefler]

Georg Bauhaus wrote:

> On 4/20/11 9:04 PM, Vinzent Hoefler wrote:
>
>> <http://www.open-std.org/jtc1/sc22/wg14/www/charter>:
>>
>> |Some of the facets of the spirit of C can be summarized in phrases like
>> |(a) Trust the programmer.
>> |(b) Don't prevent the programmer from doing what needs to be done.
>> |(c) Keep the language small and simple.
>> |(d) Provide only one way to do an operation.
>> |(e) Make it fast, even if it is not guaranteed to be portable.
>
> Not much different from what is true about Ada.

I am quite sure, that the meaning of "trust the programmer" is
completely different here. More along the lines of "if in doubt,
the programmer takes precedence".

Also for the "prevention". Ada doesn't prevent you from doing bad things,
but at least it makes it hard for you - and visible for others.

> (c) The C standard is about the same size as Ada's, isn't it?
> C is simple?

It has less pages at least: Just checked, my copy of the C99 PDF has
554 pages, the ARM05 has 791 pages. But considering that the ARM is
much wordier than its C counterpart...

> (d) Are there two ways to do an operation in Ada?

Less so than in C.

> (e) Some Ada programs are fast and still guaranteed to be portable.
> That's true of some C programs as well.  Ada programs might need unchecked
> conversions and representation clauses to make a program non-portable.

There are easier ways to make it non-portable. Using Integer and assuming
'Size of 32, for instance, just like someone would in C when using "int".

> So I guess C's (e) is working around the fact that C's choices
> would not allow the programmer to say what needs to be done?

Like the lack of being able to define the Endianess of bit-records?

That's what the charter says:

|3. C code can be non-portable. Although it strove to give programmers the
|opportunity to write truly portable programs, the Committee did not want to
|force programmers into writing portably, to preclude the use of C as a
|``high-level assembler;'' the ability to write machine-specific code is one
|of the strengths of C.

So, their understanding of "what needs to be done" seems more like "forgot
the syntax of my assembler, lemme use C instead". ;)


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
     --  Waldi Ravens

Re: Fun with C

[Randy Brukardt]

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

"Elias Salom�o Helou Neto" <eshneto@gmail.com> wrote in message 
news:86748003-860f-4729-ae26-55be1e58ac2b@d27g2000vbz.googlegroups.com...
>On Apr 18, 8:10 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> "Elias Salom�o Helou Neto" <eshn...@gmail.com> wrote in 
>> messagenews:d169b543-eed4-4a0a-a295-e391c198463e@j9g2000prj.googlegroups.com...
>> On Apr 17, 8:43 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
>> ...
>>
>> >> I must have been doing something really wrong all those years,
>> >> becuase the only way I learned a new language was by
>> >> programming in it.
>>
>> >Without even reading a book about it? You are doing things terribly
>> >wrong. Of course programming is the best way to learn, but not without
>> >a good book to read while practicing.
>>
>> There aren't always books to read.
>
>C books? Come on!

We're not talking about C specifically, we're talking about "a new 
language".

>> We wrote a partial Ada *compiler* back in
>> 1980 from a description circulated by our professor (Janus/Ada originally
>> started in a compiler construction course).
>
>Surely the first Ada compiler you wrote wasn't coded in Ada itself.
>Haven't you read any book about the language used to code the compiler
>before?

Sure, but irrelevant, since we had to create test programs for the compiler 
in Ada (gotta test that it works), and that requires some understanding of 
the language.

> Weren't the professor's description a kind of "book"?

Depends on what you meant by "good book". A raw language description (as in 
the professor's handful of mimographed sheets) or even the Ada Reference 
Manual doesn't seem to be a "good book" about programming in the language. I 
had presumed that you meant "textbook" when you said "book", because 
otherwise your statement doesn't seem to say anything useful (by definition 
you'd have to read a language description to program, but there is no such 
requirement to read a book about how best to program in a particular 
language).

Even so, the professor's description looked nothing like a "book", in any 
sense of the term. So you have to be so expansive about the meaning of 
"book" to have made a meaningless statement.

> So keep saying people that they do not need to study the language they
> intend to write code on. This is really smart, isn't it?

Huh? I said no such thing. I simply said that you don't necessarily need a 
"book". I meant "textbook" when I said that, but it is really strictly true 
as well: you need a "language description", but it surely doesn't need to be 
in the form of a book -- it could be a handful of loose pages, it could be a 
a web site somewhere, a help file, or even a program editor.

Go back and re-read the statement that you made: "...but not without a good 
book to read while practicing.". I disagree with this statement as written, 
and I explained why. I also didn't feel any need to insult you when 
disagreeing with you, which does not help your point any.

>> The only book that we had (and
>> we didn't get that until near the end of the class when we had already
>> decided to commercialize it) was the 1980 Ada Reference Manual.
>
>So you're again trying to claim you have written a compiler without
>knowledge of the language to be compiled? It must be some kind of
>magic, for sure. Again, what about the description by your teacher?

It surely was not a "book". And by no stretch of the imagination, a "good 
book"!

These days, I hardly expect anyone to expect requiring a "book" to do 
anything. Even counting "e-books" as "books", there are a lot of information 
sources which have nothing to do with "books". It was a lot harder to 
understand back in 1981, yet it still happened then (and even then there 
were a lot of information sources having nothing to do with books - papers, 
magazine articles, seminars, lectures, computer-aided-instruction).

>> I'm pretty
>> sure that we had already converted the entire compiler into Ada code (so 
>> it
>> could compile itself) before we saw any of the early Ada textbooks. (The
>> Pyle textbook that we distributed with the compiler didn't come out until
>> late 1981, I think.)
>
>After writing an Ada compiler it is very unlikely for someone not to
>know the language. There are lots of C textbooks, why not to use them?
>Nonsense.

We're not talking about C specifically, we're talking about "a new language" 
in general.

And I doubt I would *buy* a textbook these days; pretty much everything one 
needs is on-line (and often not in the form of a book!).

>Also, please notice that I've recommended a book for those that are
>learning the language, not for those who have already mastered it (but
>even so a good reference manual is invaluable).

Again, I don't give a hose about C; I see no reason to waste my time with 
obscure language wars. (Ada is best, and that's it. :-)

>> That was OK, Ada wasn't that different than Pascal which we both already
>> knew well.
>
>This is dangerous. People seem to believe C is like Pascal or BASIC.
>Is this knowing C? This is the kind of misconception we have to fight.

Maybe *you* have to fight it. I happen to think that a language that is 
unnecessarily different than what a typical programmer would expect is 
dangerous. (And yes, Ada suffers from this in a few places as well -- and 
those things are also dangerous.)

A lot of people (not me, thankfully) have to program in a polyglot of 
languages, and remembering the obscure rules of one or the other without 
confusing them is difficult. We had this problem in the first year of 
Janus/Ada, when we were programming in Pascal, Modula I (for classes), and 
Ada all at the same time. Lots of mistakes made where they differed --  
luckily most of those were compile-time failures and thus didn't cause bugs.

>No programmer should claim to know C (or any other language) if he/she
>doesn't really knows it.

I don't claim to know C (anymore), but that doesn't prevent me from hating 
it. :-)
The one project I was forced to write in C (rather than Pascal or Modula) 
during my university days was the only such project that didn't work at the 
deadline. (And I was annoyed enough to spend several hours afterwards 
figuring out why it didn't work - the bug turned out to be a missing pointer 
dereference which the C compiler was happy to ignore.) Since then, I've 
learned to detest the C syntax -- I don't even get to hating the semantics. 
The only C I do is to read it well enough to be able to write interfaces to 
C APIs.

I realize this is somewhat irrational, which is why I try to stay out of 
language wars -- there is no way to win (I'm more likely to marry a 
supermodel than I am to change my mind about C! :-)

                                       Randy.

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 20, 2:11 am, "J-P. Rosen" <ro...@adalog.fr> wrote:
> Le 17/04/2011 21:19, Elias Salom o Helou Neto a crit :
>
> > All reasonable men will try to learn the language before programming.
> > The mentioned behavior is the one C is supposed to have, whether you
> > like it or not. It one of the first thing I teach in my C classes:
> > type promotions in expression. They may be dumb, or may not, I will
> > not argue on that. But being reasonable is knowing the tool before
> > trying to use it.
>
> I really wonder why there are barriers on balconies. All reasonable
> people know that being too close to the edge of the balcony is dangerous.

What about kids? C is not out there to be used by kids, as barriers on
balconies are mostly because of that. Furthermore, there are always
those who have acrophobia..

> Here is a quote from one of the first books on C, written by K&R:
> "C was designed under the assumption that the programmer is someone
> reasonable who knows what he is doing".
>
> Here is a quote from the introduction to the Ada LRM:
> "Ada was designed with consideration for programming as a human activity"
>
> I let as a philosophy homework that these two starting point led to
> completely different languages.

Interestingly, just like I said, C "pretends" people are reasonable,
while Ada does not. The second approach is far nearer the truth, as we
all can see.

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 19, 11:28 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 4/19/11 3:10 AM, Elias Salomão Helou Neto wrote:
>
> >  what I meant was basically that: people will keep doing
> > dumbness because they are just people (me included). No matter what
> > language is used.
>
> Agree.  Perhaps one language can make being stupid more difficult
> than another, then.
>
> >> There is evidence that different
> >> fundamental type  systems help non-dumb people solve their problems more
> >> successfully.  People will still be using C libraries and additional
> >> code generators, as a replacement for a better suited type system.
>
> > I would like to see this evidence.
>
> One comparative study, not entirely free of all bias I would think,
> but pretty close to standard experiments yielding valid data,
> was conducted over several years, by John W. McCormick. It is
> about a project that switched not subjects or algorithms but the
> language. The result was published in August 2000 ashttp://www.crosstalkonline.org/storage/issue-archives/2000/200008/200...

I've had a difficult time reading the report because the authoring
software did not embed the fonts (this kind of thing makes me itch),
making it difficult to read it in full because metrics were wrong.
This is not my fault, the document simply was not made to be read by
others if fonts were not embedded.

>  From which is this quote:
>
> "Upon reading the project listings and team member diaries,
>   I concluded that the major advantages of Ada for these
> students were, in order of importance:
> • Modeling of scalar objects.
>    – Strong typing.
>    – Range constraints.
>    – Enumeration types.
> • Parameter modes that reflect the problem rather than the mechanism.
> • Named parameter association.
> • (...)"

You've quoted those which make sense. But what about "Arrays whose
indices do not have to begin at zero"? While it is a workaround and I
don't actually recommend it, in C you can simply declare an array with
a size slightly (+1) larger and use it as it started at 1.

Also, students of an introductory course do not qualify as "non-dumb".
Most professional programmers are dumb and had likely gone through
some kind of course like that. Anyway, it is good evidence in favor of
Ada for embedded projects written by real-life programmers, but I
don't remember to have disagreed that Ada would be better for non-
competent (real-life) programmers.

For the record, I've recently seen in this newsgroup a discussion on
how difficult is to hire good programmers, most couldn't even do the
most basic bit manipulation in whatever language. That's why I say
that real-life programmers are non competent.

So, ok, you're right in advocating Ada. It is just not fair to bash C.

Elias.

Re: Fun with C

[Elias Salomão Helou Neto]

> We're not talking about C specifically, we're talking about "a new
> language".

New to the programmer or to the world? If it is the former, I still
recommend a book. A textbook will take you from the basics to the more
advanced features of the language. This is the way to learn. By
skipping the first steps people simply won't know the most basic
stuff, such as C's type promotions.

Instead, people like to program by "trial and error". Which will
rarely, if ever, work.

>
> >> We wrote a partial Ada *compiler* back in
> >> 1980 from a description circulated by our professor (Janus/Ada originally
> >> started in a compiler construction course).
>
> >Surely the first Ada compiler you wrote wasn't coded in Ada itself.
> >Haven't you read any book about the language used to code the compiler
> >before?
>
> Sure, but irrelevant, since we had to create test programs for the compiler
> in Ada (gotta test that it works), and that requires some understanding of
> the language.

Not at all irrelevant. Test programs are not real-life programs, while
a compiler surely is. Furthermore, the language description you had
from your professor had to be deeply studied in order to get the
compiler working. So you've had to learn from the most basic to the
most advanced feature of the language.

> Depends on what you meant by "good book". A raw language description (as in
> the professor's handful of mimographed sheets) or even the Ada Reference
> Manual doesn't seem to be a "good book" about programming in the language. I
> had presumed that you meant "textbook" when you said "book".

Ok.

> Go back and re-read the statement that you made: "...but not without a good
> book to read while practicing.". I disagree with this statement as written,
> and I explained why. I also didn't feel any need to insult you when
> disagreeing with you, which does not help your point any.

Did I insult you? Sorry if I did. But I keep the reasoning: go and
read a book before programming. One that progressively goes from the
basic to the advanced features in a reasonable way.

You are a talented programmer and learned Ada from a description. But
you did not start to write random code in Ada. You had a solid
foundation on it because you had to be precise when writing the
compiler. I am sure you will notice how different it is from just
"starting coding and making it compile".

> These days, I hardly expect anyone to expect requiring a "book" to do
> anything. Even counting "e-books" as "books", there are a lot of information
> sources which have nothing to do with "books". It was a lot harder to
> understand back in 1981, yet it still happened then (and even then there
> were a lot of information sources having nothing to do with books - papers,
> magazine articles, seminars, lectures, computer-aided-instruction).

I still do not recommend any of those as means for a beginner to learn
a language: papers are not for beginners; magazine articles are too
vague or too specific; seminars are usually too short to be of any use
for beginners and they are, decause of being short, focused on a too
narrow or too vague subject; lectures are good, but good lecturers
will likely indicate a bibliography, which will include textbooks if
it is intended to beginners. Perhaps computer-aided-instruction, but I
haven't seen it in use, so I do not recommend it.

Remember, I am a professor. I do lecture and present seminars. And no,
seminars won't teach you how to program. Neither will the lectures,
unless followed by laboratory classes and homeworks, which should be
done alongside a good book on the subject. Honestly, I do not like
students taking notes of my lectures, they should be paying attention
and latter they should use the recommended book as a reference. Unless
I've explicitly stated otherwise.

> >After writing an Ada compiler it is very unlikely for someone not to
> >know the language. There are lots of C textbooks, why not to use them?
> >Nonsense.
>
> We're not talking about C specifically, we're talking about "a new language"
> in general.

I don't get it. Which new language may someone want to learn for which
there is no good textbook available? Again, do you mean "new to the
programmer" or "new to the world"?

> And I doubt I would *buy* a textbook these days; pretty much everything one
> needs is on-line (and often not in the form of a book!).

Even though there is plenty information on the internet, books are
still worth buying, I am sure of that. You can't (legally) find the
really good textbooks on-line neither you can find anything comparable
to those textbooks. Good information still has its price.

As a test, find me a replacement for "C++ Primer" on-line.

> >Also, please notice that I've recommended a book for those that are
> >learning the language, not for those who have already mastered it (but
> >even so a good reference manual is invaluable).
>
> Again, I don't give a hose about C; I see no reason to waste my time with
> obscure language wars. (Ada is best, and that's it. :-)

It is true that I said "learning _the_ language" and that it referred
to C, but it surely applies to any language.

> Maybe *you* have to fight it. I happen to think that a language that is
> unnecessarily different than what a typical programmer would expect is
> dangerous. (And yes, Ada suffers from this in a few places as well -- and
> those things are also dangerous.)

Ops. I think you're wrong here. Programming languages _must_ be
different from each other, otherwise there would not be reason for so
many to exist. And some new, useful, paradigms appear that can't be
natural to any programmer simply because it did not exist before its
invention!

> I don't claim to know C (anymore), but that doesn't prevent me from hating
> it. :-)

I did not mean that you claim to do so, but that other did when they
should not.

> I realize this is somewhat irrational, which is why I try to stay out of
> language wars -- there is no way to win (I'm more likely to marry a
> supermodel than I am to change my mind about C! :-)

I am not quite into language wars too. I have never advocated one
language over another, just look at my posts above. So, forget C and
good luck in marrying a supermodel. When it happens, if she has any
friends, please introduce me to them :-)

Elias

Re: Fun with C

[Vinzent Hoefler]

Elias Salomão Helou Neto wrote:

> Interestingly, just like I said, C "pretends" people are reasonable,
> while Ada does not. The second approach is far nearer the truth, as we
> all can see.

One of my favorite quotes I read somewhere (Bruce Powell Douglas, I think):

"
C treats you like a consent adult.
Pascal treats you like a naughty child.
Ada treats you like a criminal.
"

This also explains the different popularity of those languages. ;) Still,
when it comes to safety-critical, I'd rather be treated like a criminal by
a compiler than by a judge. :->


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: Fun with C

[Dmitry A. Kazakov]

On Thu, 21 Apr 2011 09:19:08 -0700 (PDT), Elias Salom�o Helou Neto wrote:

> Ops. I think you're wrong here. Programming languages _must_ be
> different from each other, otherwise there would not be reason for so
> many to exist. And some new, useful, paradigms appear that can't be
> natural to any programmer simply because it did not exist before its
> invention!

Nope. A counterexample is natural languages. There are many of them. They
are different in some senses and same in others. Languages existed before
poetry, novels, scripts and graffiti were invented.

I doubt that a language (natural or formal) can be designed for new
paradigms. Rather it is so that so-called "paradigms" are imprinted in our
brains and languages just reflect the ways we are thinking. This, I think,
can explain popularity of such outrageously poor languages like C. C
programmers are in majority simply because most of programmers do think as
they write.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Hyman Rosen]

On 4/21/2011 1:36 PM, Dmitry A. Kazakov wrote:
> C programmers are in majority simply because most
 > of programmers do think as they write.

Why do you believe that Ada programmers do not also do that?
I don't know Ada, but if I were to sit down to write an Ada
program I would also write it as I was thinking, and would
simply add and modify types and interfaces as needed. I expect
I would also compile frequently and let the compiler tell me
where I missed a spot and then just go and fix it up. In fact,
it seems to me that Ada is more conducive to think-and-type
than C is, because the compiler is better at telling you when
you've gotten something wrong.

Re: Fun with C

[Georg Bauhaus]

On 4/21/11 4:52 PM, Elias Salom�o Helou Neto wrote:

> You've quoted those which make sense. But what about "Arrays whose
> indices do not have to begin at zero"? While it is a workaround and I
> don't actually recommend it, in C you can simply declare an array with
> a size slightly (+1) larger and use it as it started at 1.

Another instance of the *but you can roll it* argument ;-).
Certainly true, and creative, but misses one thing IMHO.
The index type of an Ada array induces the compiler
to test for correct index values.  Similarly, the compiler
will complain when a case distinction does not exactly
cover the whole set of values in a type.  Change the set of
values in a type and watch the Ada compiler tell you
which dependent declarations will now be incorrect,
or where a case value isn't handled by a case statement.

Suppose you could do the following in C. I trust that
C programmers would find this really cool:

#include <stdint.h>

enum Color {Red, Green, Blue};
typedef uint8_t rgb_intensity;

int main(void)
{
     rgb_intensity things[enum Color];  // This Here
     return 0;
}

a = http://itunes.apple.com/de/album/this-here/id218299914?i=218299916
listen(a[0]);

A := http://itunes.apple.com/de/album/this-here/id218299914?i=218299916
Listen(To => A(A'First));

Re: Fun with C

[John B. Matthews]

In article <op.vuaqfkwhlzeukk@jellix.jlfencey.com>,
 "Vinzent Hoefler" 
 <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote:

> Elias Salomão Helou Neto wrote:
> 
> > Interestingly, just like I said, C "pretends" people are 
> > reasonable, while Ada does not. The second approach is far nearer 
> > the truth, as we all can see.
> 
> One of my favorite quotes I read somewhere (Bruce Powell Douglas, I 
> think):
> 
> " C treats you like a consent adult. Pascal treats you like a naughty 
> child. Ada treats you like a criminal. "
> 
> This also explains the different popularity of those languages. ;) 
> Still, when it comes to safety-critical, I'd rather be treated like a 
> criminal by a compiler than by a judge. :->

Inexplicably, others seem to resent it:

<https://groups.google.com/d/topic/rec.humor.funny.reruns/bo5KznjUtXo>

I think I may have "Ada tendencies." :-)

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Fun with C

[Hyman Rosen]

On 4/21/2011 2:58 PM, Georg Bauhaus wrote:
> Suppose you could do the following in C. I trust that
> C programmers would find this really cool:
>
> #include <stdint.h>
>
> enum Color {Red, Green, Blue};
> typedef uint8_t rgb_intensity;
>
> int main(void)
> {
> rgb_intensity things[enum Color]; // This Here
> return 0;
> }

That doesn't work for C because a variable of an enum type
may hold any integer value up to the number of bits taken
by the largest enumerator (with a variation for negatives
that isn't important here). The C enum concept is meant to
encompass literals used as bit masks as well as singular
values.

Re: Fun with C

[Dmitry A. Kazakov]

On Thu, 21 Apr 2011 13:43:46 -0400, Hyman Rosen wrote:

> On 4/21/2011 1:36 PM, Dmitry A. Kazakov wrote:
>> C programmers are in majority simply because most
>  > of programmers do think as they write.
> 
> Why do you believe that Ada programmers do not also do that?

Certainly they do!

> I don't know Ada, but if I were to sit down to write an Ada
> program I would also write it as I was thinking, and would
> simply add and modify types and interfaces as needed. I expect
> I would also compile frequently and let the compiler tell me
> where I missed a spot and then just go and fix it up. In fact,
> it seems to me that Ada is more conducive to think-and-type
> than C is, because the compiler is better at telling you when
> you've gotten something wrong.

Yes, but in order to value this you must be comfortable with this way of
thinking. Most programmers are not. They feel the "Ada's way" constraining
rather than helping. You can make Ada more popular only through an
extensive training and selection. Compare it with guitar playing. When you
start, you find proper hand positions extremely demanding. Not every must
play guitar, but programmers are just too many. Like a good musician can
learn to play any instrument, any good C programmer can easily switch to
Ada and enjoy it. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Randy Brukardt]

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

"Elias Salom�o Helou Neto" <eshneto@gmail.com> wrote in message 
news:4b5748dc-60fa-4cec-a317-054626e9a1ca@d19g2000prh.googlegroups.com...
>> We're not talking about C specifically, we're talking about "a new
>> language".
>
> New to the programmer or to the world? If it is the former, I still
> recommend a book. A textbook will take you from the basics to the more
> advanced features of the language. This is the way to learn. By
> skipping the first steps people simply won't know the most basic
> stuff, such as C's type promotions.
>
> Instead, people like to program by "trial and error". Which will
> rarely, if ever, work.

I don't think anyone was advocating "trial-and-error". But there are lots of 
ways to learn something beyond reading a textbook. (I've rarely done that 
specifically.)

...
>> These days, I hardly expect anyone to expect requiring a "book" to do
>> anything. Even counting "e-books" as "books", there are a lot of 
>> information
>> sources which have nothing to do with "books". It was a lot harder to
>> understand back in 1981, yet it still happened then (and even then there
>> were a lot of information sources having nothing to do with books - 
>> papers,
>> magazine articles, seminars, lectures, computer-aided-instruction).
>
> I still do not recommend any of those as means for a beginner to learn
> a language: papers are not for beginners; magazine articles are too
> vague or too specific; seminars are usually too short to be of any use
> for beginners and they are, decause of being short, focused on a too
> narrow or too vague subject; lectures are good, but good lecturers
> will likely indicate a bibliography, which will include textbooks if
> it is intended to beginners. Perhaps computer-aided-instruction, but I
> haven't seen it in use, so I do not recommend it.
>
> Remember, I am a professor. I do lecture and present seminars. And no,
> seminars won't teach you how to program. Neither will the lectures,
> unless followed by laboratory classes and homeworks, which should be
> done alongside a good book on the subject. Honestly, I do not like
> students taking notes of my lectures, they should be paying attention
> and latter they should use the recommended book as a reference. Unless
> I've explicitly stated otherwise.

I suspected that, and that is your bias here. For the most part, I don't 
agree with the need for formal training. It's useful for those with no 
programming training at all, but for those that have significant programming 
experience, picking up a new language does not require that level of 
imersion.

...
>> And I doubt I would *buy* a textbook these days; pretty much everything 
>> one
>> needs is on-line (and often not in the form of a book!).
>
> Even though there is plenty information on the internet, books are
> still worth buying, I am sure of that. You can't (legally) find the
> really good textbooks on-line neither you can find anything comparable
> to those textbooks. Good information still has its price.
>
> As a test, find me a replacement for "C++ Primer" on-line.

Dunno anything about C++, but at least two of the best Ada books are 
available free on-line (English's "Ada 95: The Craft of Object-Oriented 
Programming" [for new programmers] and Riehle's "Ada Distilled" [for 
experienced programmers new to Ada]). I've probably forgotten some. The Ada 
Programming Wikibook is also a good resource, especially to answer 
questions.

Perhaps the C++ market is different because there is a lot more money to be 
made, but I would doubt it.

There are good Ada books that you can only buy, of course, but unless you 
are doing a professional project, I recommend starting with the free 
resources. If it turns out that Ada is not for you, you are only out time.

...
>> Maybe *you* have to fight it. I happen to think that a language that is
>> unnecessarily different than what a typical programmer would expect is
>> dangerous. (And yes, Ada suffers from this in a few places as well -- and
>> those things are also dangerous.)
>
> Ops. I think you're wrong here. Programming languages _must_ be
> different from each other, otherwise there would not be reason for so
> many to exist. And some new, useful, paradigms appear that can't be
> natural to any programmer simply because it did not exist before its
> invention!

I'm unconvinced that most programming languages even need to exist. Most 
programming languages exist because someone thought that they could do it 
better. And hardly any of them were right. :-) Ada has a different history 
than that (although one could argue the same thing). I don't see the point 
of using a polyglot of programming languages that all do essentially the 
same thing.

One of the problems is that everyone makes incremental differences in their 
programming languages, which just makes them different without making them 
much better. This is the same problem that I have with the way Microsoft 
changes everything around in each new version of Windows, without any 
obvious improvement in functionality (it is just different, and thus 
requires relearning everything you already know). For a new programming 
language (or OS) to be worthwhile, it needs to embody a significant paradyme 
shift (such as functional or transactional programming for a programming 
language, or a touch GUI, as in iOS/Android). Otherwise, we might as well be 
using Windows 2000 (it worked perfectly fine, thank you).

A programming language that brings something wildly new to the table might 
be worthwhile, but piles of languages all the same just waste time. (You can 
probably tell that I support/use interfacing to C and other languages by 
practical necessity, and definitely not by choice!)

                             Randy.

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 21, 2:36 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 21 Apr 2011 09:19:08 -0700 (PDT), Elias Salom o Helou Neto wrote:
>
> > Ops. I think you're wrong here. Programming languages _must_ be
> > different from each other, otherwise there would not be reason for so
> > many to exist. And some new, useful, paradigms appear that can't be
> > natural to any programmer simply because it did not exist before its
> > invention!
>
> Nope. A counterexample is natural languages. There are many of them. They
> are different in some senses and same in others. Languages existed before
> poetry, novels, scripts and graffiti were invented.
> I doubt that a language (natural or formal) can be designed for new
> paradigms.
> Rather it is so that so-called "paradigms" are imprinted in our
> brains and languages just reflect the ways we are thinking.

Could you please elaborate on that? I understand (and mostly agree
with) your claim that all paradigms are imprinted in our brains, but
I'd rather still call one of them new if it is the first time it is
actually explicitly stated and used for a purpose such as designing a
programming language.

> This, I think,
> can explain popularity of such outrageously poor languages like C. C
> programmers are in majority simply because most of programmers do think as
> they write.

Yep. That's a major problem. No matter how much I try to teach people
to think before coding, they won't do so. But I don't think that Ada
makes it any better, does it? It is not a claim, since I could not do
it without knowing Ada, but rather a truly interested question.

And I fail to see why is C so "outrageously poor". My view is that
professional programmers deserve much more this epithet than C does.
Remember all those guys you've interviewed that couldn't mentally do
an XOR with 0xFF? My tendency is to say they're the ones who are
"outrageously poor".

Of course this is a rather good justification for Ada to be more
widely adopted. As I've said elsewhere on this thread, Ada's premises
are far more realistic than C's ones. But it does not make C a lame
language.

Elias.

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 21, 8:29 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> I suspected that, and that is your bias here. For the most part, I don't
> agree with the need for formal training. It's useful for those with no
> programming training at all, but for those that have significant programming
> experience, picking up a new language does not require that level of
> imersion.

C does. People must understand it. That's what I've been trying to
explain.

> Dunno anything about C++, but at least two of the best Ada books are
> available free on-line (English's "Ada 95: The Craft of Object-Oriented
> Programming" [for new programmers] and Riehle's "Ada Distilled" [for
> experienced programmers new to Ada]). I've probably forgotten some. The Ada
> Programming Wikibook is also a good resource, especially to answer
> questions.

Great, thank you for pointing me those! But they're still books :-)

Elias.

Re: Fun with C

[Dmitry A. Kazakov]

On Thu, 21 Apr 2011 23:16:47 -0700 (PDT), Elias Salom�o Helou Neto wrote:

> On Apr 21, 2:36�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 21 Apr 2011 09:19:08 -0700 (PDT), Elias Salom o Helou Neto wrote:
>>
>>> Ops. I think you're wrong here. Programming languages _must_ be
>>> different from each other, otherwise there would not be reason for so
>>> many to exist. And some new, useful, paradigms appear that can't be
>>> natural to any programmer simply because it did not exist before its
>>> invention!
>>
>> Nope. A counterexample is natural languages. There are many of them. They
>> are different in some senses and same in others. Languages existed before
>> poetry, novels, scripts and graffiti were invented.
>> I doubt that a language (natural or formal) can be designed for new
>> paradigms.
>> Rather it is so that so-called "paradigms" are imprinted in our
>> brains and languages just reflect the ways we are thinking.
> 
> Could you please elaborate on that? I understand (and mostly agree
> with) your claim that all paradigms are imprinted in our brains, but
> I'd rather still call one of them new if it is the first time it is
> actually explicitly stated and used for a purpose such as designing a
> programming language.

I think that all significant paradigms are already stated. All languages we
are talking about are equivalent in terms of Turing completeness. Paradigms
are of course finer than that, but still I believe that there is nothing
significantly new left. All these agent-, aspect-, cloud-, extreme-,
whatever stuff was known and used before 1980.

>> This, I think,
>> can explain popularity of such outrageously poor languages like C. C
>> programmers are in majority simply because most of programmers do think as
>> they write.
> 
> Yep. That's a major problem. No matter how much I try to teach people
> to think before coding, they won't do so.

Not every man or woman can program. I doubt that programming should be
taught to people specializing on other majors. Sorry guys, programming is
not a modern lingua franca.

> But I don't think that Ada
> makes it any better, does it? It is not a claim, since I could not do
> it without knowing Ada, but rather a truly interested question.

I agree. Ada is a tool, it is no cure.

Nevertheless, future professional programmers should never be exposed to C
as the first language. It is like teaching physics in the school. Pupils
first learn the physics of XIX century. When they made 3/4, they are told:
guys, that was wrong! Here is how it goes! Programmers must learn concepts
and techniques which C cannot illustrate. What C can illustrate is how not
to program.

> And I fail to see why is C so "outrageously poor". My view is that
> professional programmers deserve much more this epithet than C does.
> Remember all those guys you've interviewed that couldn't mentally do
> an XOR with 0xFF? My tendency is to say they're the ones who are
> "outrageously poor".

One poor with another poor does not make it good. My point is that poor
programmers prefer poor languages. Both are in majority and without
selection this state will maintain itself infinitely. So the first step for
programming to become engineering will be deliberate extermination of
certain language features and practices, which dominate in C. Having said
that, I don't claim that Ada is that ideal language. It is a long way
ahead. Even so, there is no reason to look back trying to move forward.

> Of course this is a rather good justification for Ada to be more
> widely adopted. As I've said elsewhere on this thread, Ada's premises
> are far more realistic than C's ones. But it does not make C a lame
> language.

C is poor for teaching because it takes too much noise to illustrate basic
programming concepts like array, string, result of a function etc. It is
full of silly limitations, which programmers must learn to circumvent,
before they get at the core ideas. In the end they learn only these tricks
and think that programming is about that, lacking understanding of software
engineering as a whole.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[J-P. Rosen]

Le 22/04/2011 08:16, Elias Salom�o Helou Neto a �crit :
> Yep. That's a major problem. No matter how much I try to teach people
> to think before coding, they won't do so. But I don't think that Ada
> makes it any better, does it?
No, it just makes it more likely that inconsistent design will produce 
code that does not compile.

> Of course this is a rather good justification for Ada to be more
> widely adopted. As I've said elsewhere on this thread, Ada's premises
> are far more realistic than C's ones. But it does not make C a lame
> language.
>
C is not a lame language, because it fulfills its intended purpose: a 
portable assembly language. The trouble is if you take it for anything else.

My view of the difference between C and Ada is as follows:
    C is the best language to program a computer;
    Ada is the best language to develop a software application.

(please don't quote me on the first half without the second one!)

C is simply unbearable to people who are used to thinking at a higher 
level. (Says someone who programmed in an earlier life at a much lower 
level than anybody does nowadays - in binary, directly on the keys of a 
control panel).

Re: Fun with C

[Hyman Rosen]

On 4/22/2011 5:21 AM, Dmitry A. Kazakov wrote:
> Not every man or woman can program. I doubt that programming
> should be taught to people specializing on other majors.

No, you're wrong about that. It is correct that not everyone
can program, but many people exhibit a talent for it regardless
of their major, and may not know that because they've never tried.
If you limit teaching programming to those who are majoring in
software-related fields, you'll lose a lot of possible talent.

> software engineering

When I was still reading computer journals many years ago, it
seemed to me that papers on software engineering were only about
doing various kinds of measurements of the development process, and
were dull and useless. They were never about how to program well.

Re: Fun with C

[Niklas Holsti]

J-P. Rosen wrote:
> Le 22/04/2011 08:16, Elias Salom�o Helou Neto a �crit :
>> Yep. That's a major problem. No matter how much I try to teach people
>> to think before coding, they won't do so. But I don't think that Ada
>> makes it any better, does it?
> No, 

I disagree with J-P. Even if Ada programmers may be as likely as C 
programmers to start typing ("coding") before thinking, I believe that 
Ada programmers are much more likely to start by typing things that are 
on the design level, such as package declarations, type declarations, 
and subprogram declarations, because these things are so much better 
supported and therefore easier to use in Ada than in C. Thus, the 
initial Ada "coding" is really "designing".

A programmer can of course create a C program in the same way, with type 
declarations in header files etc., but the traditional C culture does 
not guide programmers in this direction.

> it just makes it more likely that inconsistent design will produce 
> code that does not compile.

I entirely agree with that.

>> Of course this is a rather good justification for Ada to be more
>> widely adopted. As I've said elsewhere on this thread, Ada's premises
>> are far more realistic than C's ones. But it does not make C a lame
>> language.
>>
> C is not a lame language, because it fulfills its intended purpose: a 
> portable assembly language.

In my view C is not even good as a portable assembly language. The least 
I would expect from an assembly language is full control over the 
machine, at least over the abstracted machine that the language shows 
you. But in C, very basic things such as the behaviour on overflow of 
signed integer operations is undefined. Only recently has the language 
even defined integer types with known sizes.

I think C was originally an attempt to get some of the benefits of a 
high-level language (portability being one of them) with the same 
performance and code size as assembly language. In the circumstances of 
the first C implementations, the language designers and compiler 
developers were satisfied with a hybrid language that has some 
high-level flavour but is mired in a swamp of low-level, yet undefined 
and unportable semantics. Perhaps this was the best that they could do, 
within their resources, but unfortunately C became popular and 
standardized in this inadequate form.

I think of C as a Model-T Ford. It worked, and still works, but good 
grief... to claim that it is the ideal car boggles my mind.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Fun with C

[Dmitry A. Kazakov]

On Fri, 22 Apr 2011 09:18:20 -0400, Hyman Rosen wrote:

> On 4/22/2011 5:21 AM, Dmitry A. Kazakov wrote:
>> Not every man or woman can program. I doubt that programming
>> should be taught to people specializing on other majors.
> 
> No, you're wrong about that. It is correct that not everyone
> can program, but many people exhibit a talent for it regardless
> of their major, and may not know that because they've never tried.

They may have a talent to knitting. So what? Programming is not a
fundamental knowledge like mathematics or physics that any educated person
must know.

> If you limit teaching programming to those who are majoring in
> software-related fields, you'll lose a lot of possible talent.

I don't care of a surgeon having some talent to programming. I care of
programmers. I don't want either programming surgeons or programmers
performing surgical operations.

>> software engineering
> 
> When I was still reading computer journals many years ago, it
> seemed to me that papers on software engineering were only about
> doing various kinds of measurements of the development process, and
> were dull and useless.

Right, CS is not a science and programming is not engineering. These papers
are as scientific as knitting journals...

> They were never about how to program well.

Yep, differently to them people publishing knitting musters at least can
knit. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 22, 6:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> I think that all significant paradigms are already stated. All languages we
> are talking about are equivalent in terms of Turing completeness. Paradigms
> are of course finer than that, but still I believe that there is nothing
> significantly new left. All these agent-, aspect-, cloud-, extreme-,
> whatever stuff was known and used before 1980.

I must mention that it is always like that, people tend to believe
that every paradigm is already around until someone comes up with a
"new" one. But it may pretty well be the case that you're right and
they're all already stated, I guess there is just no way to know.

> Not every man or woman can program. I doubt that programming should be
> taught to people specializing on other majors. Sorry guys, programming is
> not a modern lingua franca.

Surely you're right. But still I have to teach my students...

> Nevertheless, future professional programmers should never be exposed to C
> as the first language. It is like teaching physics in the school. Pupils
> first learn the physics of XIX century. When they made 3/4, they are told:
> guys, that was wrong! Here is how it goes! Programmers must learn concepts
> and techniques which C cannot illustrate. What C can illustrate is how not
> to program.

When it comes to physics, the main reason to teach classical
mechanical is that it is actually a good approximation to modern
theories and the math is far more simple. Nobody will say "guys, that
was wrong!" because that is not wrong, it just must be used within its
valid limits. Rockets reached the moon based on computations that used
classical Newtonian mechanics.

It is quite different with programming languages, as C is actually
harder than Pascal, which is a great tool for teaching programming.

Only for the record, my current students are not supposed to become
professional programmers, but physicists. Not that it actually
matters, since those who should become professionals are exposed to C
as a first programming language as well in here.

> C is poor for teaching because it takes too much noise to illustrate basic
> programming concepts like array, string, result of a function etc. It is
> full of silly limitations, which programmers must learn to circumvent,
> before they get at the core ideas. In the end they learn only these tricks
> and think that programming is about that, lacking understanding of software
> engineering as a whole.

C is terrible for teaching, but it is not up to me to decide which
language to teach in those introductory classes.

Elias.

Re: Fun with C

[Dmitry A. Kazakov]

On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salom�o Helou Neto wrote:

> On Apr 22, 6:21�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> Nevertheless, future professional programmers should never be exposed to C
>> as the first language. It is like teaching physics in the school. Pupils
>> first learn the physics of XIX century. When they made 3/4, they are told:
>> guys, that was wrong! Here is how it goes! Programmers must learn concepts
>> and techniques which C cannot illustrate. What C can illustrate is how not
>> to program.
> 
> When it comes to physics, the main reason to teach classical
> mechanical is that it is actually a good approximation to modern
> theories and the math is far more simple. Nobody will say "guys, that
> was wrong!" because that is not wrong, it just must be used within its
> valid limits.

I heard that wrong argument so many times.

> Rockets reached the moon based on computations that used
> classical Newtonian mechanics.

So? Linux was written in C, does it justify C?

[I hope your students do not build rockets (:-))]

> It is quite different with programming languages, as C is actually
> harder than Pascal, which is a great tool for teaching programming.

In which sense is C harder? I bet students find it simple. It is hard to
teach concepts of software design on example of C? But Newtonian mechanics
is perfect for teaching cosmology, quantum effects, optics, fields etc?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Georg Bauhaus]

On 4/23/11 9:23 AM, Dmitry A. Kazakov wrote:
> On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salomão Helou Neto wrote:

>> It is quite different with programming languages, as C is actually
>> harder than Pascal, which is a great tool for teaching programming.
>
> In which sense is C harder?

C is harder to learn from the ground up, as your first formalism,
when measured by the number of non-intuitive and non-essential
fundamental concepts that students must all understand in order
to understand and use fundamental ideas of C.

Notions are formed by distinction. Formally, each distinction D(n)
means another fork in the "tree of rules" that a human mind must
climb when trying to understand what's in the leaves. Humans have
limited capacity when following decision trees in any case, not just
when learning.  More so when topics change along the way, as is the
case with C, as explained below.  Changing topics requires context
switching---which is another distinction, thus f(D(n)) where f >= id.

Some of C's concepts will draw students of C to syntax, others
to operating systems, rather than focusing their attention
on what should be a meaningful part of C program text,  You might
be so familiar with these distinct notions that you have forgotten
that it once was difficult to keep them apart: you just saw
these different pieces of C text but they all looked alike!
Teaching C, then, by force is lacking modularization, in the following
sense.

For example, C offers distinctions that are non-essential
when seen from the viewpoint of teaching programming subjects.
Yet, they must be understood by the novices should they need to
to write programs, which, I think, they usually do.

- The statement and the block (of statements), and why and how
   to write them

Typically, a distraction:

Mostly offered when the subject is C's case distinction with if/else.
When teaching conditionals, the focus should be on conditional
execution.  It will easily be on whether or not you need braces,
and what the braces mean, and about what happens if you do or don't
write "else" and then do or do not write braces,

Blocks/statements confront novices with recursion at the level of
grammars---when they are trying to understand if/else.  But
recursive definition is not an easy concept in itself.  Observe
students (in the general sense of the word "students",
i.e. including pupils, or hobbyists) trying to understand
mathematical induction, which requires recursive thought.  It takes
time and practice to become acquainted, and then induction at school
was usually about natural numbers, not symbols, or about how
you yourself write.  Entire books like "The Little Functionaler"
by Friedman / Felleisen are all about recursive definitions.
They aren't easy.  Intrinsically, recursive definitions are very
close to circular definition, which, as you know, are vicious.


- C's shorthands

Too many things in one piece.

Professional typists learn how to write first.  Shouldn't students
of C (as a first language) do this, too? (Typists need to learn
the rules of written natural language first.  Orthography.  Then,
I imagine, other practical things about writing.)

Only then they, typists, learn how to use shorthands.

C culture, I believe, does not call *x++ a shorthand.  It calls
it an idiom.  It is even possible to argue that there is no
shorthand at all because everything is (mostly) well defined
and not an abbreviation.  But this argument misses modularity of
attention: one thing at a time.  The above expression requires
that the student isolates each single effect, and separates it from
the others.  Then thinks about implicit order and such. Why
should beginners in programming become familiar with shorthands
so very early?

Note how C's shorthands are totally different from the definitions of
"A Programming Language", i.e. APL languages.  There, TTBOMK, every
symbol has one (or two) well defined meaning(s) that do not
"abbreviate". Or that could easily be written in another way, as is
the case with C when, e.g. isolating the constituent parts of *x++.
The sum of 1 .. 100 in APL is

    +/⍳100

which, in Python, reads

   reduce(plus, range(101))

where
   def plus(x, y): return x + y

That is not to say that using "/" as reduction operator and not
division might not be confusing at first.  It is also not to say
that ⍳ and the many other operator symbols won't take time to learn.
But APL's mode of expression does not conflate so many things into
one piece, and fewer of them are about syntax or precedence.


- main and its (int argc, char* argv[]), that C shares with Java.

You will see lengthy discussions of what these mean.
And how they come to be, out of nowhere (known).  Or how
they could be passed to the program and that argv[0] is
of a different quality than argv[n], n > 0.

Similarly, about return 0; the teacher will have to explain why in
a Boolean context 0 means false but in the context of operating
systems, 0 means OK.  And what this has to do with the C program
in the first place.


- file scope.

An important feature of C---and its OS...

You'll need to know operating system concepts including file
system concepts before you can understand program text.
What is it that warrants dragging the file systems into it?
Why can't we understand the text of programs without the
external notion of a file?  K&R have no need to ship their
book split suitably into files.  They don't!


I guess I could go on for some time...  And I haven't mentioned
pointers at all and how they relate to arrays and to the + operator,
...

Is this a sense in which C is harder when you
want to learn the fundamentals of programming?

Re: Fun with C

[Dmitry A. Kazakov]

On Sat, 23 Apr 2011 11:42:51 +0200, Georg Bauhaus wrote:

> On 4/23/11 9:23 AM, Dmitry A. Kazakov wrote:
>> On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salom�o Helou Neto wrote:
> 
>>> It is quite different with programming languages, as C is actually
>>> harder than Pascal, which is a great tool for teaching programming.
>>
>> In which sense is C harder?
> 
> C is harder to learn from the ground up, as your first formalism,
> when measured by the number of non-intuitive and non-essential
> fundamental concepts that students must all understand in order
> to understand and use fundamental ideas of C.
[...]
> Is this a sense in which C is harder when you
> want to learn the fundamentals of programming?

True, but this does not imply difficulty to learn. It depends on the goals
set. People *feel* they know C very quickly. The fact that they actually do
not know it and even less know software engineering does not change that
felt easiness. This is why I asked for the meaning of being hard. Nobody
cares that C is hard from the stand point of software engineering because
nobody cares about the latter.

Is it hard to learn how to use a hammer?

1. No
2. What for?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[George P.]

On Apr 22, 10:08 pm, Elias Salomão Helou Neto <eshn...@gmail.com>
wrote:
> On Apr 22, 6:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
> > I think that all significant paradigms are already stated. All languages we
> > are talking about are equivalent in terms of Turing completeness. Paradigms
> > are of course finer than that, but still I believe that there is nothing
> > significantly new left. All these agent-, aspect-, cloud-, extreme-,
> > whatever stuff was known and used before 1980.
>
> I must mention that it is always like that, people tend to believe
> that every paradigm is already around until someone comes up with a
> "new" one. But it may pretty well be the case that you're right and
> they're all already stated, I guess there is just no way to know.
>
> > Not every man or woman can program. I doubt that programming should be
> > taught to people specializing on other majors. Sorry guys, programming is
> > not a modern lingua franca.
>
> Surely you're right. But still I have to teach my students...
>
> > Nevertheless, future professional programmers should never be exposed to C
> > as the first language. It is like teaching physics in the school. Pupils
> > first learn the physics of XIX century. When they made 3/4, they are told:
> > guys, that was wrong! Here is how it goes! Programmers must learn concepts
> > and techniques which C cannot illustrate. What C can illustrate is how not
> > to program.
>
> When it comes to physics, the main reason to teach classical
> mechanical is that it is actually a good approximation to modern
> theories and the math is far more simple. Nobody will say "guys, that
> was wrong!" because that is not wrong, it just must be used within its
> valid limits. Rockets reached the moon based on computations that used
> classical Newtonian mechanics.
>
> It is quite different with programming languages, as C is actually
> harder than Pascal, which is a great tool for teaching programming.
>
> Only for the record, my current students are not supposed to become
> professional programmers, but physicists. Not that it actually
> matters, since those who should become professionals are exposed to C
> as a first programming language as well in here.
>
> > C is poor for teaching because it takes too much noise to illustrate basic
> > programming concepts like array, string, result of a function etc. It is
> > full of silly limitations, which programmers must learn to circumvent,
> > before they get at the core ideas. In the end they learn only these tricks
> > and think that programming is about that, lacking understanding of software
> > engineering as a whole.
>
> C is terrible for teaching, but it is not up to me to decide which
> language to teach in those introductory classes.
>
> Elias.

Just out of curiosity, why physicists should learn C?  Isn't FORTRAN
much better choice for them?

Re: Fun with C

[Nasser M. Abbasi]

On 4/22/2011 7:08 PM, Elias Salom�o Helou Neto wrote:

>
> Only for the record, my current students are not supposed to become
> professional programmers, but physicists.

For physics programming, there are much better systems than C.

C makes one think more about 'coding' than about the problem itself,
which is what one should be thinking about, instead of pointers and
casting problems.

I suggest the following alternatives as better for physics students:

1. Mathematica: symbolic and numerical and graphics all integrated.
2. Matlab: Simple to program, but less symbolic, but good for computational
physics.
3. Maple: Similar to Mathematica, but Mathematica is based on functional
programming, Maple is more procedural.
4. Many other open/free alternatives to the above: Octave, Sage, Maxima, etc..

I think C is the worst language to choose to teach students
programming in physics, or any other subject, other than operating
systems and drivers may be.

>
> C is terrible for teaching, but it is not up to me to decide which
> language to teach in those introductory classes.
>
> Elias.

But you are the teacher, so ofcourse it is up to you. If
it is not up the teacher to choose the language to teach with,
then you are teaching at the wrong university.

This is like saying it is not up to the doctor to decide which
medicine should be given to the sick person.

regards,
--Nasser

Re: Fun with C

[Nasser M. Abbasi]

On 4/23/2011 8:23 AM, George P. wrote:

> Just out of curiosity, why physicists should learn C?  Isn't FORTRAN
> much better choice for them?
>

Yes and No.

First, there are really two types of physics courses: computational
physics, where the emphasis is on solving physics problems
computationally, and there are the classical physics courses,
where the emphasis is on solving physics problems analytically.
Some courses have a combination of both.

For STUDENTS, Fortran is not a good choice for many of the physics
courses, other than the ones with more of the computational aspect.

Look at any physics dept. these days, hardly anyone is using Fortran
any more for teaching.

Also, Fortran does not have plotting ability build-in, so if a
student solves a differential equation using Fortran and wants to
plot the solution, then how to do it? Then have to go learn
a new system, maybe gnuplot, learn how to save the data correctly
from the Fortran program, etc... Most student have hard time
just learning how to open a file, never mind all the rest.

Ada would have been a good choice for computational physics,
but it also have the same problem when it comes to visualization.

That is why, for teaching physics, better to use a packaged
system, which makes it easy for students to use, and they
can concentrate on the physics, not on the nitty gritty of
'coding'.  For courses with more analytical physics,
Mathematica/Maple/Sage type systems are better, since they
allow symbolic computation, and for the more computational
physics courses, other alternative are available, such as
Matlab/Ocatve etc..might be a good choice also.

The point is to learn physics with least waste of time in
the implementation part of the solution of the physics problem.

But any one of the above is better than C.

--Nasser

Re: Fun with C

[Dmitry A. Kazakov]

On Sat, 23 Apr 2011 10:28:24 -0700, Nasser M. Abbasi wrote:

> Also, Fortran does not have plotting ability build-in, so if a
> student solves a differential equation using Fortran and wants to
> plot the solution, then how to do it?

If I correctly remember grafor (Graphical FORTRAN?) was the first ever
plotting library.

Not that I am advocating FORTRAN, of course... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Nasser M. Abbasi]

On 4/23/2011 10:52 AM, Dmitry A. Kazakov wrote:
> On Sat, 23 Apr 2011 10:28:24 -0700, Nasser M. Abbasi wrote:
>
>> Also, Fortran does not have plotting ability build-in, so if a
>> student solves a differential equation using Fortran and wants to
>> plot the solution, then how to do it?
>

> If I correctly remember grafor (Graphical FORTRAN?) was the first ever
> plotting library.
>
> Not that I am advocating FORTRAN, of course... (:-))
>

I never heard of the above. I collect list of all plotting
libraries for Fortran, and that one is not on my list, will add it.

Here is the current list I have now (added your reference)

1. PGPLOT
2. PLPLOT
3.  PSPLOT
4. DISLIN
5. F90GL
6. GINO
7. grafor (per this post)

But whatever it is, it will have the same problem as all the
others: it will not be available on the student computer at school,
since it is not part of the system. A student can't just go
download something from the net, build it, etc.. since this is not
allowed to do at school computers.

It is really better for students and the teacher to use one known
and fully packaged system, which has easy to use graphics,
build-in math functions, debugger, editor etc.. all from one
source.

--Nasser

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 23, 4:23 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salomão Helou Neto wrote:
>
> > On Apr 22, 6:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
>
> >> Nevertheless, future professional programmers should never be exposed to C
> >> as the first language. It is like teaching physics in the school. Pupils
> >> first learn the physics of XIX century. When they made 3/4, they are told:
> >> guys, that was wrong! Here is how it goes! Programmers must learn concepts
> >> and techniques which C cannot illustrate. What C can illustrate is how not
> >> to program.
>
> > When it comes to physics, the main reason to teach classical
> > mechanical is that it is actually a good approximation to modern
> > theories and the math is far more simple. Nobody will say "guys, that
> > was wrong!" because that is not wrong, it just must be used within its
> > valid limits.
>
> I heard that wrong argument so many times.

Certainly you've not heard it from good physicists, but from rather
stupid ones. Let me state it clearly: Classical Mechanics isn't wrong
at all. It is the best and most useful approximation for a wide range
of phenomena. Why would someone use Quantum Mechanics or Relativity to
compute velocities when designing an automatic train control system?

> > Rockets reached the moon based on computations that used
> > classical Newtonian mechanics.
>
> So? Linux was written in C, does it justify C?

I was justifying Classical Mechanics. But Linux' success kind of
justifies C as a system language, but let us not argue on that.

> [I hope your students do not build rockets (:-))]

I hope they eventually will. I just hope they do not use C.

> > It is quite different with programming languages, as C is actually
> > harder than Pascal, which is a great tool for teaching programming.
>
> In which sense is C harder? I bet students find it simple. It is hard to
> teach concepts of software design on example of C?

Bauhaus explained it very well. And why on earth would I be teaching
software design on an introductory course on programming? It is much
more about algorithm, data structures and the language itself.

> But Newtonian mechanics
> is perfect for teaching cosmology, quantum effects, optics, fields etc?

Do you want to teach this stuff to high school students? I don't get
your idea here.

Elias

Re: Fun with C

[Elias Salomão Helou Neto]

> But you are the teacher, so ofcourse it is up to you. If
> it is not up the teacher to choose the language to teach with,
> then you are teaching at the wrong university.

No, it is not up to me. I'd rather be teaching Matlab (Octave
actually), but the course's description clearly stated C and other
disciplines will require this knowledge later.

Th university I teach is USP, the most prestigious in Latin America.
It is the wrong one in the sense that it is not mine, so I can't take
all decisions about the courses I teach.

> This is like saying it is not up to the doctor to decide which
> medicine should be given to the sick person.

Not quite, they will be required to know C in later courses and if I
don't teach them, who will?

Elias.

Re: Fun with C

[George P.]

On Apr 23, 1:52 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 23 Apr 2011 10:28:24 -0700, Nasser M. Abbasi wrote:
> > Also, Fortran does not have plotting ability build-in, so if a
> > student solves a differential equation using Fortran and wants to
> > plot the solution, then how to do it?
>
> If I correctly remember grafor (Graphical FORTRAN?) was the first ever
> plotting library.
>
> Not that I am advocating FORTRAN, of course... (:-))
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

There were few, and there was always Open-GL.

Last time I checked on FORTRAN in 2002-3, it was pretty decent
language for the purpose.  Nothing like FORTRAN IV I started on. And
it also was fast (Compaq/DEC).
Surprisingly, while it went through series of dramatic transitions
(f90 to f08),  it seems that F community is not obsessed with backward
compatibility as much as C community.  Compilers are able compile and
link to old legacy code but for those who writes software there is a
new format.

Anyone knows how widely it is still being used and what is
demographics of it?

G.

Re: Fun with C

[Dmitry A. Kazakov]

On Sat, 23 Apr 2011 11:37:00 -0700 (PDT), Elias Salom�o Helou Neto wrote:

> On Apr 23, 4:23�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salom�o Helou Neto wrote:
>>
>>> On Apr 22, 6:21�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>
>>>> Nevertheless, future professional programmers should never be exposed to C
>>>> as the first language. It is like teaching physics in the school. Pupils
>>>> first learn the physics of XIX century. When they made 3/4, they are told:
>>>> guys, that was wrong! Here is how it goes! Programmers must learn concepts
>>>> and techniques which C cannot illustrate. What C can illustrate is how not
>>>> to program.
>>
>>> When it comes to physics, the main reason to teach classical
>>> mechanical is that it is actually a good approximation to modern
>>> theories and the math is far more simple. Nobody will say "guys, that
>>> was wrong!" because that is not wrong, it just must be used within its
>>> valid limits.
>>
>> I heard that wrong argument so many times.
> 
> Certainly you've not heard it from good physicists, but from rather
> stupid ones. Let me state it clearly: Classical Mechanics isn't wrong
> at all. It is the best and most useful approximation for a wide range
> of phenomena.

3.14 might be a useful approximation of Pi, but not Pi.

> Why would someone use Quantum Mechanics or Relativity to
> compute velocities when designing an automatic train control system?

Why would anybody consider the Earth round? Let us start teaching students
that the Earth is flat, after all it is a useful approximation for building
construction. Later you can tell them that it is not very flat...

>>> It is quite different with programming languages, as C is actually
>>> harder than Pascal, which is a great tool for teaching programming.
>>
>> In which sense is C harder? I bet students find it simple. It is hard to
>> teach concepts of software design on example of C?
> 
> Bauhaus explained it very well. And why on earth would I be teaching
> software design on an introductory course on programming?

Maybe because it supposed to be *introductory*? Is it an introduction into
C or into programming? I have no idea how to teach students programming, I
doubt that it must or can be taught, but it is obvious to me as a consumer,
that what is taught is mostly useless and often damaging.

> It is much more about algorithm, data structures and the language itself.

A "Newtonian mechanics" of coding. Again, I am not a teacher, but
programming today is not very much about algorithms, structures and even
concrete languages. Not that fresh students knew much about algorithms or
structures, that is not their biggest problem.

>> But Newtonian mechanics
>> is perfect for teaching cosmology, quantum effects, optics, fields etc?
> 
> Do you want to teach this stuff to high school students? I don't get
> your idea here.

Certainly yes, if it is about physics.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Gerd]

On 16 Apr., 19:02, "George P." <george.p...@gmail.com> wrote:
> Spend few days chasing bug in embedded C project which can drilled
> down to this. Consider the following program, and all reasonable men
> will expect the result to be negative.  Not in C, and it is not a
> compiler bug :-(
>
> And offcorse none of the three comilers I cheched did not bother to
> issue a warning at least..
>
> #include <stdio.h>
>
> int main()
> {
>      unsigned n = 128;
>      int i = -2048;
>      int r;
>
>      r = i / n;
>
>      printf("R = %d\n", r);
>
>      return 0;
>
>
>
> }- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -


Try to run a MISRA checker.

Re: Fun with C

[Peter C. Chapin]

On Sat, 23 Apr 2011 23:36:36 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>Why would anybody consider the Earth round? Let us start teaching students
>that the Earth is flat, after all it is a useful approximation for building
>construction. Later you can tell them that it is not very flat...

It sounds like you think that's a bad thing.

In fact when constructing a building you don't take into account the
curvature of the Earth. For example you don't use spherical trigonometry to
lay out the foundation. Students learning about building construction
certainly know (from elsewhere) that the Earth is not flat but they also
don't want to hear about it in their course.

Similarly students in an introductory physics course know that Newtonian
physics isn't the last word on the subject but they are happy to study a
more basic (and still useful) system to start.

You've said repeatedly that you are not a teacher and, frankly, it shows. I
can tell you based on my 25 years of experience teaching that attempting to
teach relativity and quantum mechanics, in any sort of significant way, to
first year physics students would be a disaster. They don't have the
mathematical background, for one thing, to handle it.

I think similar comments apply to programming education. That said, I do
agree with one point that you've made: programming languages can be a
distraction. I actually had a student recently suggest to me that we teach
our first programming course using pseudo-code instead of C (we are a
computer engineering program so C seems like the right first language). He
said, "that way students could focus on organizing their program rather
than on getting some strange code to compile."

It would be an interesting experiment to try that, but I'm not sure it
would help in the long run. In later courses I want them to write programs
that compile and work so they will need to deal with that issue sooner or
later. Which is easier to teach first? It's unclear.

Peter

Re: Fun with C

[Peter C. Chapin]

On Sat, 23 Apr 2011 13:47:51 -0700 (PDT), "George P."
<george.priv@gmail.com> wrote:

>Surprisingly, while it went through series of dramatic transitions
>(f90 to f08),  it seems that F community is not obsessed with backward
>compatibility as much as C community.  Compilers are able compile and
>link to old legacy code but for those who writes software there is a
>new format.
>
>Anyone knows how widely it is still being used and what is
>demographics of it?

Fortran is definitely still being used. I have at times lurked on
comp.lang.fortran and it is at least as active as this group (I think more
active). And yes, starting with Fortran 90 the language was utterly
transformed and is now reasonably modern. I believe the latest version
(Fortran 2008) is even object oriented.

My impression is that Fortran is still primarly used in its traditional
area of numeric computation where C is considered an upstart language. In
fact in a head-to-head comparison between C and Fortran it is common for a
Fortran program to outperform an equivalent C program. I've explored this
effect myself with a toy program that does Gaussian elmination. Thus people
interested in maximum numeric performance are drawn to Fortran.

Ada could also be a contender in this application area but Fortran's array
operators are so nice and modern Fortran compilers are so mature that the
language is hard to beat when it comes to numerical applications.

In any case, don't joke about Fortran as if it's some kind of dinosaur. It
will just make the people in the Fortran community roll their eyes in
disgust... or amusement. :)

Peter

Re: Fun with C

[Dmitry A. Kazakov]

On Sun, 24 Apr 2011 07:27:10 -0400, Peter C. Chapin wrote:

> On Sat, 23 Apr 2011 23:36:36 +0200, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> wrote:
> 
>>Why would anybody consider the Earth round? Let us start teaching students
>>that the Earth is flat, after all it is a useful approximation for building
>>construction. Later you can tell them that it is not very flat...
> 
> It sounds like you think that's a bad thing.

Yes, is see no reason in teaching lies, even if lies are simpler than the
truth.

> In fact when constructing a building you don't take into account the
> curvature of the Earth. For example you don't use spherical trigonometry to
> lay out the foundation. Students learning about building construction
> certainly know (from elsewhere) that the Earth is not flat but they also
> don't want to hear about it in their course.

The question was in the order. First teach that the Earth is round and only
then say that the curvature is so small that it can be ignored for the case
at hand.

> You've said repeatedly that you are not a teacher and, frankly, it shows. I
> can tell you based on my 25 years of experience teaching that attempting to
> teach relativity and quantum mechanics, in any sort of significant way, to
> first year physics students would be a disaster. They don't have the
> mathematical background, for one thing, to handle it.

Really? I see no significant difference in their mathematics. Difference is
when functional, differential analysis, integration is needed. And it is
much too late to me anyway. The fundamentals of the relativity theory and
quantum mechanics should be taught in the school, before they get spoiled.

I am so certain about this because as a schoolboy I was exposed to an
experimental program which started mathematics right from the set theory
and used formalisms from the beginning. On the contrary physics was taught
traditionally "wrong". The program was soon scrapped, but I still remember
how much simpler it was comparing to physics, though I was little
interested in mathematics that time. My worst experience was later, when
reading a manual of physics "for advanced", which on 10 pages calculated
waves would be emitted by a moving electron using classical physics and no
differential analysis(!), just in order to state on the last page that all
this was just rubbish, the right way you learn later when attend high
school. This remains to me the epitaph of modern education.

> I think similar comments apply to programming education. That said, I do
> agree with one point that you've made: programming languages can be a
> distraction. I actually had a student recently suggest to me that we teach
> our first programming course using pseudo-code instead of C (we are a
> computer engineering program so C seems like the right first language). He
> said, "that way students could focus on organizing their program rather
> than on getting some strange code to compile."

Well, but pseudo-code itself is a distraction, a remnant of the procedural
paradigm mostly concentrating on the algorithm. It is not the way or at
least not the whole way the software is written now. Here I see the same
problem, education tries to follow the historical way of scholarship
instead of cutting dark corners.

> It would be an interesting experiment to try that, but I'm not sure it
> would help in the long run. In later courses I want them to write programs
> that compile and work so they will need to deal with that issue sooner or
> later. Which is easier to teach first? It's unclear.

I don't know. How about teaching them how to write a bug report and never
ever say "I did nothing, it worked yesterday"?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Nasser M. Abbasi]

On 4/24/2011 6:53 AM, Dmitry A. Kazakov wrote:

>
> The question was in the order. First teach that the Earth is round and only
> then say that the curvature is so small that it can be ignored for the case
> at hand.
>

Mr Kazakov;

In every other argument your were part of in this forum, I've
seen you always as  right and on the correct end, except
for this one :)

Do then you start teaching students nonlinear systems before
linear systems?

Since, real systems in reality are non-linear, but we linearized
things to be able to understand them and approximate the
very complex behavior to something we can analyze.

Only in advanced courses we start to study how to analyze
non-linear systems.

Your point that we should start learning general relativity
before classical mechanics makes no sense to me.

Then why not start with string theory first before general
relativity? Lets teach string theory and quantum relativity
as well to high school students before F=ma?

I really lost trying to understand your views here.

Best,
--Nasser

Re: Fun with C

[Dmitry A. Kazakov]

On Sun, 24 Apr 2011 12:07:37 -0700, Nasser M. Abbasi wrote:

> Do then you start teaching students nonlinear systems before
> linear systems?

If you are going to teach them pendulum, would it make much sense to
pretend it linear? x is a pretty good approximation of sin(x) near 0.

BTW, there is an important difference between empirical and fundamental
laws of nature.

> Your point that we should start learning general relativity
> before classical mechanics makes no sense to me.

My point is that historic views need not to be taught. Anyway, importance
of classic mechanics looks overestimated. You cannot see planets when
living in a large city, but do can the computer on your desk. Explain why
it works using Newtonian mechanics.

> Then why not start with string theory first before general
> relativity?

String theory is not yet generally accepted.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Georg Bauhaus]

Peter C. Chapin <PChapin@vtc.vsc.edu> wrote:

> It would be an interesting experiment to try that, but I'm not sure it
> would help in the long run. In later courses I want them to write programs
> that compile and work so they will need to deal with that issue sooner or
> later. Which is easier to teach first? It's unclear.

one thing seems certain, though.

(1) it is students who should learn all those things.
(2)  "we" know a certain minimum if things that
must be understood in order for the whole to
make "sense"

from (1) it follows that we can inquire into what
students already know.
from (1) it follows that we can ask professionals
for help with what they can possibly grasp
(amount and diversity of information, for example)

Then build a formal model, approximate, of
learning capacity.

From (2), it follows that there exists a model
of computation that is didactically complete.
(Meyer writes about such a model.)

The choice of subjects and languages, then,
is a matter of matching the two above.

It is a good hint IMHO that our masters
learned how to program computers that
were a lot simpler than a PC!

And do not start introductions to the
basics of computing by giving detailed
explanations of 7 segment displays.

Re: Fun with C

[Nasser M. Abbasi]

On 4/24/2011 12:46 PM, Dmitry A. Kazakov wrote:
> On Sun, 24 Apr 2011 12:07:37 -0700, Nasser M. Abbasi wrote:
>
>> Do then you start teaching students nonlinear systems before
>> linear systems?
>
> If you are going to teach them pendulum, would it make much sense to
> pretend it linear? x is a pretty good approximation of sin(x) near 0.
>

It is not pretending, it is approximation. A good one, if the angle is
small.  Buildings, rockets, trains, advanced control systems are
designed based on linear system theory, and somehow they seem to
work just fine. My teacher kept telling us this all the time. He should
know :)

> BTW, there is an important difference between empirical and fundamental
> laws of nature.
>

And what makes you think GR is fundamental and classical mechanics
is not?  We do not know what the fundamental laws of nature are, if
we did, we would have a unified field theory, which we do not. GR works
well in large scale, but not too well at at the nano-scale, so it
can't be a fundamental law of nature.

Everything we learn can be viewed as approximation to how nature work.

>> Your point that we should start learning general relativity
>> before classical mechanics makes no sense to me.
>
> My point is that historic views need not to be taught.

My view is the opposite. I learn a subject better by learning how
it came about. I like to read old papers and books more than new ones,
because it gives me more insight into the subject. Even if the
old views are no longer the most accurate ones on the subject.

> Anyway, importance
> of classic mechanics looks overestimated. You cannot see planets when
> living in a large city, but do can the computer on your desk. Explain why
> it works using Newtonian mechanics.
>

Do not understand.
  
>> Then why not start with string theory first before general
>> relativity?
>

> String theory is not yet generally accepted.
>

It is tought at many schools allready. Any way, the point
is that, there are many models of nature, some are
more complicated than others. If a model works well for
what one wants to do, and the model is simpler, use that
mathematical model.

Telling a civil engineer they need to learn GR first in order
to design a building do not make any sense.

--Nasser

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 24, 4:46 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> Anyway, importance
> of classic mechanics looks overestimated. You cannot see planets when
> living in a large city, but do can the computer on your desk. Explain why
> it works using Newtonian mechanics.

Why would anyone try it? Newton mechanics is about movement and
gravity. I guess you confuse things because of the term "mechanics" in
"quantum mechanics". You're the one who should try to explain why
rocks fall using quantum mechanics. I see you have a great deal of
difficult in separating each problem's domain.

> > Then why not start with string theory first before general
> > relativity?
>
> String theory is not yet generally accepted.

But Newtonian mechanics is. You must understand it. We don't teach
Aristotle's viewpoint, it is not about teaching historic views, but
rather an useful and simply understandable theory. And a correct one,
whether you want it or not, Newton's mechanics is correct within a
huge range of values.

In fact, if quantum mechanics did not agree with classical mechanics
in the macroscopic world ("classical" quantum mechanics would agree
with Newton's theory even at the microscopic realm), it would not have
been accepted. The same holds for relativity when velocities are not
really high and masses are not huge. It makes a lot of sense teaching
the classical viewpoint first, if not for any other reason, to justify
new theories by showing that they agree with it.

What you want to is to teach theories that are only useful for a much
smaller set of problems than Newton's theory is. And to forget
Newton's theory. Sorry, but it is far from being wise. It is quite the
opposite: it is being fundamentalist.

And there is more to that. Quantum mechanics is, as of today, not
fully compatible with relativity. Should we pick which of them to
teach? Is any of them wrong? Newton's mechanic is the midterm, with
each of the theories agree well. Not to teach it, really?

There is no correct fundamental theory in physics. There will never
be, at least it will not be possible for us to ascertain that it is.
All we have are good models that work within certain range of
phenomena. Arguably, Newtonian mechanics is the most useful of all
them.

Elias.

Re: Fun with C

[Elias Salomão Helou Neto]

On Apr 24, 6:20 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> >> Do then you start teaching students nonlinear systems before
> >> linear systems?
>
> > If you are going to teach them pendulum, would it make much sense to
> > pretend it linear? x is a pretty good approximation of sin(x) near 0.
>
> It is not pretending, it is approximation. A good one, if the angle is
> small.  Buildings, rockets, trains, advanced control systems are
> designed based on linear system theory, and somehow they seem to
> work just fine. My teacher kept telling us this all the time. He should
> know :)

Dmitry seems to deny the value of proper approximations, he is clearly
not a physicist :-) Neither am I, but as an Applied Mathematician I do
value them.

> > BTW, there is an important difference between empirical and fundamental
> > laws of nature.
>
> And what makes you think GR is fundamental and classical mechanics
> is not?  We do not know what the fundamental laws of nature are, if
> we did, we would have a unified field theory, which we do not. GR works
> well in large scale, but not too well at at the nano-scale, so it
> can't be a fundamental law of nature.

What are fundamental laws of nature? We will never be able to tell. In
fact, all we have are empirical laws, but some seem to don't
understand it.

>
> Everything we learn can be viewed as approximation to how nature work.

Yep!

> >> Your point that we should start learning general relativity
> >> before classical mechanics makes no sense to me.
>
> > My point is that historic views need not to be taught.
>
> My view is the opposite. I learn a subject better by learning how
> it came about. I like to read old papers and books more than new ones,
> because it gives me more insight into the subject. Even if the
> old views are no longer the most accurate ones on the subject.

Dmitry's viewpoint scared me at first, but I guess he meant that not
everything should be taught in physics school. No one could deny the
value of history, not even such a controversial guy :-)

> > Anyway, importance
> > of classic mechanics looks overestimated. You cannot see planets when
> > living in a large city, but do can the computer on your desk. Explain why
> > it works using Newtonian mechanics.
>
> Do not understand.

Nobody could. He is confusing things because the presence of
"mechanics" in "quantum mechanics".

>
> >> Then why not start with string theory first before general
> >> relativity?
>
> > String theory is not yet generally accepted.
>
> It is tought at many schools allready. Any way, the point
> is that, there are many models of nature, some are
> more complicated than others. If a model works well for
> what one wants to do, and the model is simpler, use that
> mathematical model.
>
> Telling a civil engineer they need to learn GR first in order
> to design a building do not make any sense.

Does it?

Elias

Re: Fun with C

[Dmitry A. Kazakov]

On Sun, 24 Apr 2011 14:20:59 -0700, Nasser M. Abbasi wrote:

> On 4/24/2011 12:46 PM, Dmitry A. Kazakov wrote:
>> On Sun, 24 Apr 2011 12:07:37 -0700, Nasser M. Abbasi wrote:
>>
>>> Do then you start teaching students nonlinear systems before
>>> linear systems?
>>
>> If you are going to teach them pendulum, would it make much sense to
>> pretend it linear? x is a pretty good approximation of sin(x) near 0.
> 
> It is not pretending, it is approximation. A good one, if the angle is
> small.

No, it is a catastrophic approximation because linear system cannot
oscillate.

>> BTW, there is an important difference between empirical and fundamental
>> laws of nature.
> 
> And what makes you think GR is fundamental and classical mechanics
> is not?

It is a relationship of laws. A law is fundamental to another when it is or
thought to be derived from the former.

>>> Your point that we should start learning general relativity
>>> before classical mechanics makes no sense to me.
>>
>> My point is that historic views need not to be taught.
> 
> My view is the opposite. I learn a subject better by learning how
> it came about. I like to read old papers and books more than new ones,
> because it gives me more insight into the subject. Even if the
> old views are no longer the most accurate ones on the subject.

Then you should start with astrology. To me the goal of education is giving
a scientific view on the world.

>> Anyway, importance
>> of classic mechanics looks overestimated. You cannot see planets when
>> living in a large city, but do can the computer on your desk. Explain why
>> it works using Newtonian mechanics.
> 
> Do not understand.

Take Newtonian mechanics and use it to describe the computer hardware as a
physical system.

> Any way, the point
> is that, there are many models of nature, some are
> more complicated than others. If a model works well for
> what one wants to do, and the model is simpler, use that
> mathematical model.

Do you order the models according to:

1. the time when they first appeared (e.g. the light-bearing aether theory)
2. their adequateness (e.g. Ptolemy's system vs. Copernican)
3. their place in the physical model of the world (fundamentals)

> Telling a civil engineer they need to learn GR first in order
> to design a building do not make any sense.

It does, because building construction is secondary according to the
classification 3. A civil engineer must know physics (en large), before
diving into the resistance of materials.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Dmitry A. Kazakov]

On Sun, 24 Apr 2011 15:23:04 -0700 (PDT), Elias Salom�o Helou Neto wrote:

> On Apr 24, 4:46�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> Anyway, importance
>> of classic mechanics looks overestimated. You cannot see planets when
>> living in a large city, but do can the computer on your desk. Explain why
>> it works using Newtonian mechanics.
> 
> Why would anyone try it?

Because that is the goal of education. People must see physics as a method
of understanding physical world.

So is programming, it is not about how to move the mouse cursor, it is
about how to program those damned things and how to understand the way
things are programmed.

P.S. I find this discussion very illuminating. At least it explains to me
why we, software industry guys, are so unsatisfied with the output of the
education system.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Georg Bauhaus]

On 4/25/11 1:06 PM, Paul Colin Gloster wrote:

> It was suspected in John R. Anderson; and Robin Jeffries, "Novice LISP
> Errors: Undetected Losses of Information from Working Memory",
> "Human-Computer Interaction", Volume 1, 1985 that people can
> successfully learn to overcome minor problems, but when they later are
> trying to solve harder problems then they make simple mistakes which
> they had already learnt to not make.

The impact of typos and other glitches seems a most interesting criterion
for error classification and how a language facilitates ease of checking.


> Anyway, the C example explicitly involved  int  and  unsigned int  and
> there is no guarantee that  int  is  signed int  though it is with
> many compilers.

That int is signed is defined by the language C, I think.
C99, § 6.2.5

Re: Fun with C

[Paul Colin Gloster]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2291 bytes --]

Elias Salomão Helou Neto <eshneto@gmail.com> sent on April 18th, 2011:

|--------------------------------------------------------------------------|
|"> Uhm, no, that's a misunderstanding, Ada requires quite some thinking,  |
|> it is just that its basic types do not require so much thinking.        |
|>                                                                         |
|> I should stress one *major* concern of my favorite approach to          |
|> language definition:                                                    |
|>                                                                         |
|> Smart brains should not have to spend time with tackling basic          |
|> programming techniques.  In any language.  They should have all         |
|> their thinking capacity engaged in thinking about smart solutions.      |
|> Not in keeping track of types' implicit sizes. That's wasted effort.    |
|> (PC-lint -w 4 seems to confirm this view.)                              |
|                                                                          |
|There is no time spent thinking about promotions in C when you learn      |
|it. It is surely mor difficult to learn, so you've still made your        |
|point.                                                                    |
|                                                                          |
|[..]"                                                                     |
|--------------------------------------------------------------------------|

Hi,

It was suspected in John R. Anderson; and Robin Jeffries, "Novice LISP
Errors: Undetected Losses of Information from Working Memory",
"Human-Computer Interaction", Volume 1, 1985 that people can
successfully learn to overcome minor problems, but when they later are
trying to solve harder problems then they make simple mistakes which
they had already learnt to not make.

As an example, Elias Salomão Helou Neto has skillfully used English,
but seems to have misspelt "not" with "mor" when devoting brainpower
to a discussion instead of a spelling test.

Anyway, the C example explicitly involved  int  and  unsigned int  and
there is no guarantee that  int  is  signed int  though it is with
many compilers.

Re: Fun with C

[Paul Colin Gloster]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1592 bytes --]

Elias Salomão Helou Neto <eshneto@gmail.com> sent on April 21st, 2011:

|---------------------------------------------------------------------|
|"[..]                                                                |
|                                                                     |
|[..]                                                                 |
|[..] Honestly, I do not like                                         |
|students taking notes of my lectures, they should be paying attention|
|[..]"                                                                |
|---------------------------------------------------------------------|

Who writes once reads twice.

|---------------------------------------------------------------------|
|"[..]                                                                |
|                                                                     |
|Ops. I think you're wrong here. Programming languages _must_ be      |
|different from each other, otherwise there would not be reason for so|
|many to exist. And some new, useful, paradigms appear that can't be  |
|natural to any programmer simply because it did not exist before its |
|invention!                                                           |
|                                                                     |
|[..]"                                                                |
|---------------------------------------------------------------------|

Some languages must be different from each other, but there are
unnecessarily many languages.

Re: Fun with C

[Paul Colin Gloster]

Peter C. Chapin <PChapin@vtc.vsc.edu> sent on April 24th, 2011:

|---------------------------------------------------------------------------|
|"On Sat, 23 Apr 2011 13:47:51 -0700 (PDT), "George P."                     |
|<george.priv@gmail.com> wrote:                                             |
|                                                                           |
|>Surprisingly, while it went through series of dramatic transitions        |
|>(f90 to f08),  it seems that F community is not obsessed with backward    |
|>compatibility as much as C community.  Compilers are able compile and     |
|>link to old legacy code but for those who writes software there is a      |
|>new format.                                                               |
|>                                                                          |
|>Anyone knows how widely it is still being used and what is                |
|>demographics of it?                                                       |
|                                                                           |
|Fortran is definitely still being used. I have at times lurked on          |
|comp.lang.fortran and it is at least as active as this group (I think more |
|active). And yes, starting with Fortran 90 the language was utterly        |
|transformed and is now reasonably modern. I believe the latest version     |
|(Fortran 2008) is even object oriented."                                   |
|---------------------------------------------------------------------------|

It was almost decided for the upcoming SPEC CPUv6 that the only
languages allowed would be Fortran; C; and C++. Fortunately, I
successfully argued that Ada should be allowed, and I mentioned
SofCheck AdaMagic.

|---------------------------------------------------------------------------|
|"My impression is that Fortran is still primarly used in its traditional   |
|area of numeric computation where C is considered an upstart language. In  |
|fact in a head-to-head comparison between C and Fortran it is common for a |
|Fortran program to outperform an equivalent C program. I've explored this  |
|effect myself with a toy program that does Gaussian elmination. Thus people|
|interested in maximum numeric performance are drawn to Fortran."           |
|---------------------------------------------------------------------------|

VHDL would outperform Fortran.

|---------------------------------------------------------------------------|
|"Ada could also be a contender in this application area but Fortran's array|
|operators are so nice and modern Fortran compilers are so mature that the  |
|language is hard to beat when it comes to numerical applications.          |
|                                                                           |
|In any case, don't joke about Fortran as if it's some kind of dinosaur. It |
|will just make the people in the Fortran community roll their eyes in      |
|disgust... or amusement. :)                                                |
|                                                                           |
|Peter"                                                                     |
|---------------------------------------------------------------------------|

You could educate this ignoramus: "Dr." David Sinclair of Dublin City
so-called University:
WWW.computing.DCU.Ie/~davids/

In the academic year 1999-2000 he tried to convince me that the only
reason someone still used FORTRAN was because of legacy code, and that
all new number-crunching code should be in Java!

Re: Fun with C

[Martin]

On Apr 25, 12:00 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 4/25/11 1:06 PM, Paul Colin Gloster wrote:
>
> > It was suspected in John R. Anderson; and Robin Jeffries, "Novice LISP
> > Errors: Undetected Losses of Information from Working Memory",
> > "Human-Computer Interaction", Volume 1, 1985 that people can
> > successfully learn to overcome minor problems, but when they later are
> > trying to solve harder problems then they make simple mistakes which
> > they had already learnt to not make.
>
> The impact of typos and other glitches seems a most interesting criterion
> for error classification and how a language facilitates ease of checking.
>
> > Anyway, the C example explicitly involved  int  and  unsigned int  and
> > there is no guarantee that  int  is  signed int  though it is with
> > many compilers.
>
> That int is signed is defined by the language C, I think.
> C99, § 6.2.5

Keep reading:

C99, §6.7.2

"5. Each of the comma-separated sets designates the same type, except
that for bit-fields, it is implementation-defined whether the
specifier int designates the same type as signed int or the same type
as unsigned int."

Now, I can see at least 2 ways this could be read...the imp-def
appears to be imp-def! ;-)

-- Martin

Re: Fun with C

[Paul Colin Gloster]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1217 bytes --]

Martin <martin.dowie@BTOpenWorld.com> sent on April 25th, 2011:

|---------------------------------------------------------------------|
|"[..]                                                                |
|                                                                     |
|C99, §6.7.2                                                          |
|                                                                     |
|"5. Each of the comma-separated sets designates the same type, except|
|that for bit-fields, it is implementation-defined whether the        |
|specifier int designates the same type as signed int or the same type|
|as unsigned int."                                                    |
|                                                                     |
|Now, I can see at least 2 ways this could be read...the imp-def      |
|appears to be imp-def! ;-)                                           |
|                                                                     |
|-- Martin"                                                           |
|---------------------------------------------------------------------|

Mr. Dowie,

Thank you for the amusing observation.

Re: Fun with C

[Maciej Sobczak]

On Apr 25, 9:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> No, it is a catastrophic approximation because linear system cannot
> oscillate.

What? A simple hanging spring can oscillate while being purely linear.
There are also capacitors connected with coils, etc.

> Take Newtonian mechanics and use it to describe the computer hardware as a
> physical system.

Easy:

http://www.youtube.com/watch?v=yzJqYl9EHgA

See also related videos, they are all fun. And instructive.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Fun with C

[George P.]

On Apr 25, 4:46 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On Apr 25, 9:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
> > No, it is a catastrophic approximation because linear system cannot
> > oscillate.
>
> What? A simple hanging spring can oscillate while being purely linear.
> There are also capacitors connected with coils, etc.
>

I guess he meant sustained oscillations.?

Re: Fun with C

[Dmitry A. Kazakov]

On Mon, 25 Apr 2011 13:46:40 -0700 (PDT), Maciej Sobczak wrote:

> On Apr 25, 9:09�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> No, it is a catastrophic approximation because linear system cannot
>> oscillate.
> 
> What? A simple hanging spring can oscillate while being purely linear.

That system is not linear.

>> Take Newtonian mechanics and use it to describe the computer hardware as a
>> physical system.
> 
> Easy:
> 
> http://www.youtube.com/watch?v=yzJqYl9EHgA
> 
> See also related videos, they are all fun. And instructive.

As well as contests on throwing mobile phones.

What I meant was: take the i486 and describe its [electric] behavior by
means of Newtonian mechanics. Of course it need not to be a detailed
description, only a sketch how it could be done considering that its
components (electrons etc) are rigid bodies.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Nasser M. Abbasi]

On 4/25/2011 11:18 PM, Dmitry A. Kazakov wrote:
> On Mon, 25 Apr 2011 13:46:40 -0700 (PDT), Maciej Sobczak wrote:
>
>> On Apr 25, 9:09 am, "Dmitry A. Kazakov"<mail...@dmitry-kazakov.de>
>> wrote:
>>
>>> No, it is a catastrophic approximation because linear system cannot
>>> oscillate.
>>
>> What? A simple hanging spring can oscillate while being purely linear.
>

> That system is not linear.
>

One should really attribute linearity or not to the equations that
describes the motion of the system.

The pendulum itself is just the pendulum, and saying that
the pendulum itself is not linear, I do not think is very exact,
but I know you meant the equation of motion when you said that.

So, now lets talk then about the equation of motion.

Again, under small angle approximation, the equation of motion
of the pendulum can be approximated to linear one.  When
the angle is large, then the  approximation is not a good one,
and one must use the non-linear equation of motion to make
better prediction of its motion.

So, we back to square one. We make a mathematical model
of the physical problem, and if the approximation we make
to this model seems to give good results for our needs, then
that is the model we should use.

One can use GR equations (10 highly non-linear coupled PDE's [1])
to describe the equation of motion of the pendulum, and
after making all the approximations needed to account for
slow motion of the pendulum blob (relative to speed of light :),
its small mass (relative to earth) hence small space-time curvature,
and after numerically solving them, one will get the same results
within a tolerance of error that can be ignored for all
practical reasons, as the one we get with a simple model based
on F=ma and small angle approximation.

So, you can use GR to solve the pendulum problem, and I can
use F=ma, and in the end, we will get the same results
for all practical reason, except I used a very simplified
model, and you used a very complicated model, of the same
physical problem. What matter is if the result of the model
agrees well to the observed behavior.

Any way, this is how engineers look at things :)

--Nasser
[1]http://en.wikipedia.org/wiki/Einstein_field_equations

Re: Fun with C

[Dmitry A. Kazakov]

On Mon, 25 Apr 2011 23:58:37 -0700, Nasser M. Abbasi wrote:

> On 4/25/2011 11:18 PM, Dmitry A. Kazakov wrote:
>> On Mon, 25 Apr 2011 13:46:40 -0700 (PDT), Maciej Sobczak wrote:
>>
>>> On Apr 25, 9:09 am, "Dmitry A. Kazakov"<mail...@dmitry-kazakov.de>
>>> wrote:
>>>
>>>> No, it is a catastrophic approximation because linear system cannot
>>>> oscillate.
>>>
>>> What? A simple hanging spring can oscillate while being purely linear.
> 
>> That system is not linear.
> 
> One should really attribute linearity or not to the equations that
> describes the motion of the system.

> The pendulum itself is just the pendulum, and saying that
> the pendulum itself is not linear, I do not think is very exact,
> but I know you meant the equation of motion when you said that.
> 
> So, now lets talk then about the equation of motion.
> 
> Again, under small angle approximation, the equation of motion
> of the pendulum can be approximated to linear one.  When
> the angle is large, then the  approximation is not a good one,
> and one must use the non-linear equation of motion to make
> better prediction of its motion.
> 
> So, we back to square one.

I am not. The Ptolemy's system is a fair approximation of planet movement.
Moreover, it is asymptotically correct, and mathematically represents the
first ever example of harmonic analysis (a very important tool in
engineering). All that does not make it "right". The Copernican system,
which is plain numerically wrong, and also wrong from the relativity theory
point of view, is taught as a "truth". You cannot ignore the context.

> We make a mathematical model
> of the physical problem, and if the approximation we make
> to this model seems to give good results for our needs, then
> that is the model we should use.

Yes, except the cases where results cannot be verified, and discarding the
context makes anything unverifiable. Models you are talking about exist in
a larger context taken for granted. For example, you presume that laws do
not change with the time etc. Just consider models where time would be a
function of some system parameters. There is an infinite number of models
fitting given system. Among these only models consistent with more
fundamental laws and principles are considered. Empiric models are
subordinate. You can consider deploying such a model (like F=ma) only after
stating its conformance to a more fundamental theory (the relativity
theory). As an engineer you also must show the boundaries within your
empiric model can be used.

> Any way, this is how engineers look at things :)

You mean those programming in C? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Maciej Sobczak]

On Apr 26, 8:18 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > What? A simple hanging spring can oscillate while being purely linear.
>
> That system is not linear.

Taking into account your further response to Nasser, I take that you
mean the *real* hanging spring.

OK.

But then, I don't see anybody in the whole world who could explain how
it works (the more details, the more shaky it is), not mentioning the
i486 CPU. In which case I no longer understand what you are trying to
prove in this thread.

> What I meant was: take the i486 and describe its [electric] behavior by
> means of Newtonian mechanics. Of course it need not to be a detailed
> description, only a sketch

OK, so welcome back to simplified models. Hanging spring is a linear
system then. :-)

> how it could be done considering that its
> components (electrons etc) are rigid bodies.

It's pointless.

It was not designed at this level of detail (higher-level abstractions
and reusable design modules were used instead), so there is no point
in describing its behaviour at this level.
In which case I again don't understand what you are trying to prove.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Fun with C

[Dmitry A. Kazakov]

On Tue, 26 Apr 2011 13:57:32 -0700 (PDT), Maciej Sobczak wrote:

> On Apr 26, 8:18�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> What? A simple hanging spring can oscillate while being purely linear.
>>
>> That system is not linear.
> 
> Taking into account your further response to Nasser, I take that you
> mean the *real* hanging spring.

No, I mean that x(t) =A sin(2Pi f t) + x0 is not a linear function of time.
I didn't mean effects non-ideal pendulums have.

>> What I meant was: take the i486 and describe its [electric] behavior by
>> means of Newtonian mechanics. Of course it need not to be a detailed
>> description, only a sketch
> 
> OK, so welcome back to simplified models. Hanging spring is a linear
> system then. :-)

No, it is not. Linear meant to be its position. For this the acceleration
must be 0. You used "linear" in the sense that one of the forces is a
linear function of position. That does not give you a linear solution.

>> how it could be done considering that its
>> components (electrons etc) are rigid bodies.
> 
> It's pointless.
>
> It was not designed at this level of detail (higher-level abstractions
> and reusable design modules were used instead), so there is no point
> in describing its behaviour at this level.
> In which case I again don't understand what you are trying to prove.

In XIX century a physicist would claim that knowing all initial states and
velocities [and electric charges] of particles he would be able to describe
i486 (running Linux etc) with any given precision. Today, we know that he
could not. Which is the whole point. Newtonian mechanics fails to explain
how a simple (single core! (:-)) processor works. In fact it cannot
describe a single transistor.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Georg Bauhaus]

On 4/27/11 10:00 AM, Dmitry A. Kazakov wrote:

> In XIX century a physicist would claim that knowing all initial states and
> velocities [and electric charges] of particles he would be able to describe
> i486 (running Linux etc) with any given precision. Today, we know that he
> could not. Which is the whole point. Newtonian mechanics fails to explain
> how a simple (single core! (:-)) processor works. In fact it cannot
> describe a single transistor.

Can you describe the effect of a set of interconnected
computer transistors using Boolean functions?

Re: Fun with C

[Dmitry A. Kazakov]

On Wed, 27 Apr 2011 10:19:36 +0200, Georg Bauhaus wrote:

> On 4/27/11 10:00 AM, Dmitry A. Kazakov wrote:
> 
>> In XIX century a physicist would claim that knowing all initial states and
>> velocities [and electric charges] of particles he would be able to describe
>> i486 (running Linux etc) with any given precision. Today, we know that he
>> could not. Which is the whole point. Newtonian mechanics fails to explain
>> how a simple (single core! (:-)) processor works. In fact it cannot
>> describe a single transistor.
> 
> Can you describe the effect of a set of interconnected
> computer transistors using Boolean functions?

That depends on what you understand under "effect." Considering a model
where elements are ideal switches, no, I cannot describe it using Boolean
functions. With switches I can build an oscillator, that would break the
model. Oscillators are incomputable.

But all that is beyond the point. The first computers were mechanical.
Recently it was claimed in c.l.a. that quantum computing too would be
Turing complete. Maybe it would, but that could not make quantum mechanics
a Newtonian one.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[David Thompson]

On Thu, 21 Apr 2011 15:27:40 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

> On 4/21/2011 2:58 PM, Georg Bauhaus wrote:
> > Suppose you could do the following in C. I trust that
> > C programmers would find this really cool:
> >
> > #include <stdint.h>
> >
> > enum Color {Red, Green, Blue};
> > typedef uint8_t rgb_intensity;
> >
> > int main(void)
> > {
> > rgb_intensity things[enum Color]; // This Here
> > return 0;
> > }
> 
> That doesn't work for C because a variable of an enum type
> may hold any integer value up to the number of bits taken

s/up to/up to at least/

> by the largest enumerator (with a variation for negatives
> that isn't important here). The C enum concept is meant to
> encompass literals used as bit masks as well as singular
> values.

However, for the many C enums that are just sequential integers -- 
the default -- you can do this:

enum Color { Red,Green,Blue, Color_BOUND };

some_t array [Color_BOUND]; // Red..Blue are valid subscripts

This helps *some* especially in maintenance. 

Re: Fun with C

[Maciej Sobczak]

On Apr 27, 10:00 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >>> What? A simple hanging spring can oscillate while being purely linear.

> No, I mean that x(t) =A sin(2Pi f t) + x0 is not a linear function of time.

You got it backwards. Completely.

The above equation does not define the spring mechanics. It only
describes the *observable effect* of this mechanics. In other words,
harmonic oscillation is not a cause of spring movement, it is a
consequence of the spring being a linear system. The spring itself has
no idea that it should oscillate at all.

Let's bring some Ada back to this discussion:

with Ada.Text_IO;

procedure Spring is

   Initial_Position : constant := 0.0;
   Initial_Velocity : constant := 10.0;
   Spring_Rigidity  : constant := 1.0;
   Mass             : constant := 1.0;
   Time_Unit        : constant := 0.1;

   Position : Long_Float := Initial_Position;
   Velocity : Long_Float := Initial_Velocity;

   procedure Show_Position is
      P : Integer := 40 + Integer (Position);
      Off_Screen : Boolean := False;
   begin
      if P <= 0 then
         P := 0;
         Off_Screen := True;
      end if;
      if P >= 79 then
         P := 79;
         Off_Screen := True;
      end if;

      for I in 1 .. P loop
         Ada.Text_IO.Put (' ');
      end loop;

      if not Off_Screen then
         Ada.Text_IO.Put ('*');
      else
         Ada.Text_IO.Put ('!');
      end if;
      Ada.Text_IO.New_Line;
   end Show_Position;

   procedure Compute_New_Position is
      Force : Long_Float;
      Acceleration : Long_Float;
      Shift : Long_Float;
   begin
      Force := -1.0 * Position * Spring_Rigidity;
      Acceleration := Force / Mass;
      Velocity := Velocity + Acceleration * Time_Unit;
      Shift := Velocity * Time_Unit;
      Position := Position + Shift;
   end Compute_New_Position;

begin
   loop
      Show_Position;
      delay Time_Unit;
      Compute_New_Position;
   end loop;
end Spring;

The above program is a discrete simulator of a purely linear system.
The sine function is never used there and the program has no freaking
idea that it should oscillate in a harmonic way. Yet it does. Enjoy!

I don't care about the exact math, but as far as I understand it,
purely harmonic oscillations (that is, a single component in the
spectrum) come from purely linear systems. If the underlying system is
not linear, then the resulting oscillation (if it exists at all) will
include additional harmonics. Try to mess with the equations in the
above program, like make the force a square function of position or
make force dependent also on velocity, etc. and the oscillation will
become less pure. I leave to math geeks to come up with exact Fourier
spectrum for each such tweak.

In which case I still don't understand what you have failed to prove.
But hey, at least the discussion is related to Ada again. :-)

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Fun with C

[Dmitry A. Kazakov]

On Thu, 28 Apr 2011 00:02:36 -0700 (PDT), Maciej Sobczak wrote:

> On Apr 27, 10:00�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>>>> What? A simple hanging spring can oscillate while being purely linear.
> 
>> No, I mean that x(t) =A sin(2Pi f t) + x0 is not a linear function of time.
> 
> You got it backwards. Completely.
> 
> The above equation does not define the spring mechanics.

It is not an equation, it is a solution of some second-order differential
equation [equations themselves can be linear or not, which is unrelated to
the issue].

> It only describes the *observable effect* of this mechanics.

BTW, the only effects are the observable ones.

> The above program is a discrete simulator of a purely linear system.

No, what you gave was a numeric solution of the differential equation.
Whatever technique used to solve it, that does not change the nature of the
system, obviously. (Numeric solutions are not only non-linear, they are not
continuous)

> The sine function is never used there and the program has no freaking
> idea that it should oscillate in a harmonic way.

Where you saw a program that used the sine function? There is no such thing
on digital computers, only approximations of. What a surprise, these
approximations use +, -, *, / math and rational numbers! Does it make sine,
rational, linear? No.

> In which case I still don't understand what you have failed to prove.
> But hey, at least the discussion is related to Ada again. :-)

Indeed. My thesis is no need to know C in order to learn Ada!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Peter C. Chapin]

On Thu, 28 Apr 2011 09:41:51 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:


>> The above equation does not define the spring mechanics.
>
>It is not an equation, it is a solution of some second-order differential
>equation [equations themselves can be linear or not, which is unrelated to
>the issue].

It's not unrelated to the issue at all. A system is called a "linear
system" because it is described by a linear differential equation. That's a
matter of definitition. Of course you can use the term "linear system" to
mean something else, but that will make it hard for you to communicate with
others... as evidenced by this thread.

Peter

Re: Fun with C

[Hyman Rosen]

On 4/28/2011 1:13 AM, David Thompson wrote:
> On Thu, 21 Apr 2011 15:27:40 -0400, Hyman Rosen<hyrosen@mail.com>
> wrote:
>> That doesn't work for C because a variable of an enum type
>> may hold any integer value up to the number of bits taken
>> by the largest enumerator (with a variation for negatives
>> that isn't important here). The C enum concept is meant to
>> encompass literals used as bit masks as well as singular
>> values.
>
> s/up to/up to at least/

C++ restricts the permitted values, as per 7.2/6:
     For an enumeration where e{min} is the smallest enumerator
     and e{max} is the largest, the values of the enumeration
     are the values of the underlying type in the range b{min}
     to b{max}, where b{min} and b{max} are, respectively, the
     smallest and largest values of the smallest bit-field that
     can store e{min} and e{max}.

     On a two's-complement machine, b{max} is the smallest value
     ≥ max(|e{min}|-1,|e{max}|) of the form 2**M-1; b{min} is 0
     if e{min} ≥ 0 and -(b{max}+1) otherwise.

Re: Fun with C

[Dmitry A. Kazakov]

On Thu, 28 Apr 2011 06:24:45 -0400, Peter C. Chapin wrote:

> On Thu, 28 Apr 2011 09:41:51 +0200, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> wrote:
> 
>>> The above equation does not define the spring mechanics.
>>
>>It is not an equation, it is a solution of some second-order differential
>>equation [equations themselves can be linear or not, which is unrelated to
>>the issue].
> 
> It's not unrelated to the issue at all. A system is called a "linear
> system" because it is described by a linear differential equation. That's a
> matter of definitition.

Not really. Your definition is derived from this one:

http://en.wikipedia.org/wiki/Linear_system

which is applied to an open system with an input and output.

I meant a closed system, which motion is described by a linear function of
time. The definition above cannot applied to a close system, only to some
parts of.

Nobody so far argued that sine is a linear function because it is a
solution of a linear differential equation. OK, let it be linear, my point
is that it still would be inappropriate to use linear x instead of "linear"
sin(x) to describe motion of a pendulum.

[This reminds me "fruitful" discussions about "arrays" of C. Why should it
always end this way?]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Nasser M. Abbasi]

Speaking about C again, I found this article

"Ten Reasons to Teach and Learn Computer Programming in C"

http://iel.ucdavis.edu/publication/WhyC.html


"1. C is one of foundations for modern information technology (IT) and computer science (CS)."

I think that is true.

"2. C is the most commonly used programming language in industry.

True again.

"3. C is the language of choice for programming embedded and mechatronic systems with hardware interfaces"

I think we all can agree on this. C is more popular that Ada in this area.

"4. C is one of the most commonly used programming languages in colleges and universities."

True also.

"5. C excels as a model programming language."

I would probably argue about this being very accurate.

"6. C is the base for all other programming languages."

There is some truth to this.


"8. C is a standardized programming language with international standards."

I would not argue against this.

"9. Computer programming is becoming a necessary skill for many professions."

Very true.


"10. Computer programming can develop student's critical thinking capabilities."

True also.

I think the author makes many points that seem to be valid, yet somehow
I can't agree that these are still good reasons to teach programming
using C at schools.

I learned Pascal for programming at school, and I think that was a good thing (tm).

Any way, I thought some here might like to see the above article given
this topic is all about C and such ;)

--Nasser

Re: Fun with C

[J-P. Rosen]

Le 03/05/2011 03:19, Nasser M. Abbasi a �crit :

Interesting to see how true facts can be diverted by omission.

Mainly, the issue is not whether C can be used for teaching, but whether 
it is the best vehicle for teaching. Quite different

> Speaking about C again, I found this article
>
> "Ten Reasons to Teach and Learn Computer Programming in C"
>
> http://iel.ucdavis.edu/publication/WhyC.html
>
>
> "1. C is one of foundations for modern information technology (IT) and
> computer science (CS)."
>
> I think that is true.
But not the only one.

> "2. C is the most commonly used programming language in industry.
>
> True again.
The implicit assumption is that "most used" implies "best for teaching". 
I would challenge that.

> "3. C is the language of choice for programming embedded and mechatronic
> systems with hardware interfaces"
>
> I think we all can agree on this. C is more popular that Ada in this area.
Certainly not the domain you want to start teaching with.


> "4. C is one of the most commonly used programming languages in colleges
> and universities."
>
> True also.
Agree, unfortunately.

> "5. C excels as a model programming language."
>
> I would probably argue about this being very accurate.
C was never defined as a modeling language, that statement is very 
surprising.

> "6. C is the base for all other programming languages."
>
> There is some truth to this.
This is totally wrong, at least for the "all" part. There is a C family 
of language, there is also an Algol family of languages (including 
Pasca, Ada and Eiffel), a Lisp family of languages, etc.

This statement is typical of people who have never been exposed to other 
than the C family of languages. Only people who have knowledge of many 
different languages should make statements like this.


> "8. C is a standardized programming language with international standards."
>
> I would not argue against this.
True, but far from being the only one.

> "9. Computer programming is becoming a necessary skill for many
> professions."
>
> Very true.
But not related to C as a teaching language.


> "10. Computer programming can develop student's critical thinking
> capabilities."
>
> True also.
But also not related to C as a teaching language.

> I think the author makes many points that seem to be valid, yet somehow
> I can't agree that these are still good reasons to teach programming
> using C at schools.
Note that except for 4), nothing in these points is related to C's 
ability of being a vehicle for teaching. My main objection, from the POV 
of many years of teaching, is that one of the most difficult notions for 
beginners is pointers - and you can't do much in C without pointers.

> I learned Pascal for programming at school, and I think that was a good
> thing (tm).
Strongly agree :-)

Re: Fun with C

[Ludovic Brenta]

"J-P. Rosen" <rosen@adalog.fr> writes:
>> "4. C is one of the most commonly used programming languages in colleges
>> and universities."
>>
>> True also.
> Agree, unfortunately.
>
>> "10. Computer programming can develop student's critical thinking
>> capabilities."
>>
>> True also.
> But also not related to C as a teaching language.

The problem is that teaching C will teach students not to think! or
rather, to think uncritically and simply going with the herd like
lemmings.

-- 
Ludovic Brenta.

Re: Fun with C

[Dmitry A. Kazakov]

On Tue, 03 May 2011 08:15:03 +0200, Ludovic Brenta wrote:

> The problem is that teaching C will teach students not to think! or
> rather, to think uncritically and simply going with the herd like
> lemmings.

I disagree. I think it does teach students, alas to mostly *wrong*
practices. Unfortunately this is sometimes more damaging than just innocent
ignorance.

Also, a premature exposing to C brings a lot of critical thinking towards
other languages and techniques. It would be unfair to blame C for that,
because this attitude is rather derived from its position of strength, than
from the language itself.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Fun with C

[Georg Bauhaus]

On 5/3/11 3:19 AM, Nasser M. Abbasi wrote:
> Speaking about C again, I found this article
>
> "Ten Reasons to Teach and Learn Computer Programming in C"
>
> http://iel.ucdavis.edu/publication/WhyC.html

A. The article demonstrates a stunning absence of teaching criteria.
Which I would argue is a Must when you write about teaching,
right?
(J.-P. Rosen mentions a few issues.)

B. The article bases its claims on a number of logical fallacies.
Which is a paradox when a CS teacher writes about teaching programming.
  
C. The article does reflect
(a) the author's attitude  when approaching the means of teaching
(b) choices when making a career

D. The article does not give details of what it means for a student
to be competitive, although it does allude to apparently serving a
segment of the labor market. But, empirically challenged, is C in
your CV worth as much as say, C++ or Labview? Does it matter how
well you actually program in C?


> "1. C is one of foundations for modern information technology (IT) and computer science (CS)."
>
> I think that is true.

We should know about the foundations, hence C.
What about the other foundations of IT?

At which point on the way towards general foundational knowledge
are students capable of learning from C? More importantly, what
do they learn?  Good things or bad things?


> "2. C is the most commonly used programming language in industry.
>
> True again.

Same.

  
> "3. C is the language of choice for programming embedded and mechatronic systems with hardware interfaces"
>
> I think we all can agree on this. C is more popular that Ada in this area.

Based on the same ubiquity in embedded programming, teachers must then
suggest assembly language, too.  Why does he restrict his conclusion
(in 3.)to be C?   (Fallacy)


> "4. C is one of the most commonly used programming languages in colleges and universities."
>
> True also.

The author does not present evidence. This is simply not acceptable
in an academic setting (ucdavis.edu).  Looking at

"Based on my teaching, research, and industrial experience, I believe..."

we might expect to read about teaching, research, and industrial
experience founding the belief.  Alas, he doesn't bother.

(C being taught at universities is not my experience. But
this is hardly an argument. Do we have data?)


> "5. C excels as a model programming language."
>
> I would probably argue about this being very accurate.

Paragraph 5 has much of a text template where C and other languages
would be interchangeable.  Besides that, and in accordance with
its template characteristic, the argument does, again, not give
a single reason that favors C.

There are no comparisons with languages considered modeling languages.
He claims that studying C can serve as a foundation.  He gives no evidence
that C is a good or better foundation for modeling than just about
anything.


> "6. C is the base for all other programming languages."
>
> There is some truth to this.

And there are consequences of the part that is true about C
being the base of other languages.
(a) Ruby 1.8 and characters.  Does not work, been hard to correct.
(b) Language work need to bridle C's open ends.
(c) Porting C, hence languages, works in theory, less so in practice.

Of course, the quantifier "all" is not just wrong, it is deceiving.

> "8. C is a standardized programming language with international standards."
>
> I would not argue against this.

How does ISO standardization relate to teaching?  Java is not ISO
standardized.  How does ISO relate to being a competitive student?
He considers "competitive" important, but writes against Matlab
and Mathematica.  (Logical Inconsistency)


> "9. Computer programming is becoming a necessary skill for many professions."
>
> Very true.

As Dmitry Kazakov has recently explained, programming is not just
a "skill for...", it is a profession. When professional programs
are needed, you need professional programmers, don't you?


> "10. Computer programming can develop student's critical thinking capabilities."
>
> True also.

"...can be trained in C".
can not be trained in not-C?

(Fallacy)

Do we want future programmers to be trained is solving
accidental problems whose cause is really nothing more than
a language deficiency here and there, e.g. C's lack
of expressibility at the fundamental data type level?


> I can't agree that these are still good reasons to teach programming
> using C at schools.

Yes.

This article is a joke by all scientific standards.

The author does not compare, even though he claims to know
alternatives. He does not give reasons where reasons are
expected, "Reason" is a word in the article's title.
There are many logical errors.

Alas, marketing always outweighs what is intrinsic to teaching.
Also, marketing easily defeats the logical habits of computer
scientists when rhetoric is needed to overcome the embarrassing
state of, by the looks of it, pedagogical ignorance.

Re: Fun with C

[Simon Wright]

"Nasser M. Abbasi" <nma@12000.org> writes:

> "Ten Reasons to Teach and Learn Computer Programming in C"
>
> http://iel.ucdavis.edu/publication/WhyC.html

Interesting that a lot of the time he talks about "C/C++". Such wildly
different languages!

Re: Fun with C

[Bill Findlay]

On 03/05/2011 07:05, in article ipo5up$h78$1@dont-email.me, "J-P. Rosen"
<rosen@adalog.fr> wrote:

[much that I agree with]

> Le 03/05/2011 03:19, Nasser M. Abbasi a �crit :
>> "6. C is the base for all other programming languages."
>> 
>> There is some truth to this.
> This is totally wrong, at least for the "all" part. There is a C family
> of language, there is also an Algol family of languages (including
> Pasca, Ada and Eiffel), a Lisp family of languages, etc.

To say nothing of FORTAN and COBOL!

C is in fact the Morlock descendent of Algol, via CPL (which was heavily
Algol-influenced), and BCPL.

Ada, of course, is the noble scion of the family. 8-)


> This statement is typical of people who have never been exposed to other
> than the C family of languages. Only people who have knowledge of many
> different languages should make statements like this.

This [original] statement is about as ignorant as the claim I once saw in
some Linux kernel documentation, to the effect that virtual memory was
introduced by the VAX 11/780.

 
>> I learned Pascal for programming at school, and I think that was a good
>> thing (tm).
> Strongly agree :-)

But not as good a thing as learning via Ada would have been (I speak from
personal experience of teaching both to beginners).

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Fun with C

[David Thompson]

On Thu, 28 Apr 2011 09:41:57 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

> On 4/28/2011 1:13 AM, David Thompson wrote:
> > On Thu, 21 Apr 2011 15:27:40 -0400, Hyman Rosen<hyrosen@mail.com>
> > wrote:
> >> That doesn't work for C because a variable of an enum type
> >> may hold any integer value up to the number of bits taken
> >> by the largest enumerator (with a variation for negatives
> >> that isn't important here). The C enum concept is meant to
> >> encompass literals used as bit masks as well as singular
> >> values.
> >
> > s/up to/up to at least/
> 
> C++ restricts the permitted values, as per 7.2/6: <snip>

C++ kinda does; C doesn't. 

C++ makes each enum type a distinct type _implemented_ as some
'underlying' integral type with the additional constraint you quoted,
plus restriction on conversion, and ability to overload. Trying to
convert a value outside that range is 'unspecified' which means an
implementation can use whatever it wants, and needn't document or
diagnose; every C++ implementation I've seen just uses the
out-of-range value up to the range of the underlying type, which gives
the same effect as C although not officially guaranteed.

C makes an enum type _be_ an integer type, with all the properties
including value range of that type. To be exact it says  'compatible',
and some other places in C 'compatible' is weaker than identity, but
for enum there I see no detectable difference. A C99 implementation
can have extended integer types, which could cover all bit widths, but
usually it provides, and uses for enums, only a few. In fact in C 
it is easy and common for the compiler to just use type 'int' for all
enum types. (In C enums can't exceed int, so this is always safe,
though not always optimal; in C++ they can, but the underlying type
can exceed int only if necessary. Of course on many machines nowadays
int and long are the same size anyway, and C++1X with long long hasn't
been approved yet last I looked.)

Re: Fun with C

[wilso]

On Sun, 17 Apr 2011 18:26:13 -0400, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> wrote:

> On 4/17/11 9:35 PM, Elias Salomï¿œo Helou Neto wrote:
>
>> Someone has written a line of code without knowing what it does. Is it
>> a language problem? Not that C is spectacular, but blaming the
>> language here is not fair. Minimally competent C programmers do know
>> about such conversions.
>
> OK, that's a claim.  Michael Barr seem to have found results
> contradicting it if the "minimum" is what you minimally
> find with professional C programmers. In his netrino.com embedded
> C quiz, he found that US takers got at D+ on average.
> That's a real world, observable minimum, then.
>
> I suggest turning to observable facts and away from
> normative ontology for a moment.  Towards justifiable
> language design.
>
> Whenever a statistical phenomenon is observed,
> many start looking for correlations and hypotheses.
> Here, we have errors related to the / operation and
> the promotion rules of C's $6.3.1.  Is there a correlation?
> Will the correlation between error rates and language
> rules  be the same if using another language?
> Is that other language intrinsically better or worse, then?
>
> If there is a correlation between the frequency of a number
> of programming errors (in this case related to +,-,*,/ etc)
> and the way the corresponding part of the programming language
> is defined (in this case operand treatment), then I suggest
> the following
>
> Hypothesis 1:
>
> A language A is better designed than another B if,
> after comparable introduction to the languages,
> programmers of an A-group make fewer mistakes than
> programmers of a B-group when implementing the same
> algorithm.
>
> If so, then competent, informed language *design* will have to
> consider expected error rates when defining the language.
> Because the definitions affect error rates.
>
> A second perspective:
>
> Definition: The complexity of / (or another language feature) is
> the number of concepts that a human mind will have to connect
> properly in order to use / (or another language feature) correctly.
>
> Assumption:  Programming is a human activity.
> Since programs express human ideas, clear means of expression reflect
> programmer intentions better than formally implicit means that
> in addition depend on statements outside the language, as is the
> case with C's fundamental types.
>
> I suggest, then,
>
> Hypothesis 2:
>
> A language A is better designed than another B if an
> understanding and using the language properly is less complex,
> that is, in order to express the same algorithm,
>
> (a) it requires thinking about fewer interconnected, possibly
> implicit concepts and
>
> (b) depends less on statements outside the language.










a number of studies of this sort were done in the 70s.
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Fun with C

[Yannick Duchêne (Hibou57)]

Le Mon, 09 May 2011 01:41:20 +0200, wilso <leon.winslow@notes.udayton.edu>  
a écrit:
>> In his netrino.com embedded
>> C quiz
I just did the test, and get 9 correct answers over 10. Is that enough to  
win the “How to Prioritize RTOS Tasks DVD” ? :D

Hope someone will create the same for Ada in the future… the price could  
be a cool e-Book from Jean-Pierre Rosen :D

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Fun with C

[Yannick Duchêne (Hibou57)]

Le Fri, 20 May 2011 12:41:53 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> the price could be a cool e-Book from Jean-Pierre Rosen :D
I was to mean “priZe”, sorry.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]