Re: "Subtract C, add Ada"

[jmartin@oahu.cs.ucla.edu (Jay Martin)]

>: The problem is in the language definition, not in the choic of symbols.
>: C is one of the rare language I use to allow having an assignment after 
>: the if statement.  All other languages only allow for a boolean test.

>: I never saw a good reason for allowing this.

Right!

>I think there are three reasons:
> 1. It allows your code to be more compact. Many people think this is
>    a disadvantage, and so it is if the code will be read by comparative
>    novices, but it can improve readability to C experts who are 
>    expecting such tricks.
>
>    NB DONT confuse compactness with poor layout! I find that, for example:
>
>       while ((c = getchar()) == ' ')
>       {
>          /* count spaces */
>       }
>
>    is clearer than the 'expanded' alternative (to *me* :-).

"C expert" does not equal professional programmer.  Just because
someone can read arcane poorly designed code does not mean he is 
competent software engineer.  In fact, I would say that many C
programmers are basically are very incompetent and undeciplined
programmers. No one should write code to please idiots who want
tricks. 

Yuck:
-- We have a function that changes state "getchar()".
-- We have an boolean expression that has a side-effect to c.
-- We have to look twice at the expression to see that we are comparing
   the results of "getchar()" and not "c" (which is just there for
   the ride). 

How about:

loop
  GetChar(C);
  exit when (C /= ' '); 
  ...
end loop;

Sure it has an exit in the loop, it always cracks me up when
programmers who have side-effects galore in their programs start
whining about the "impurity" of having an exit in a loop

> 2. All expressions in C have a value. Conditional tests succeed on 
>    non-zero and fail on zero. Therefore, to maintain orthogonality, 
>    as far as possible, there is no reason to exclude an assignment 
>    expression from a condition.

But we are arguing that languages should not have side-effects in
expressions and thus an assignment should not an expression or sub-
expression or return a value.  So "All expressions in C have a value"
is not gospal it is just another bad language design decision made by
certain incompetent language designers (K&R).  The reason to not to
allow it is that it causes programming errors and terse garbage
code.  
   
> 3. Finally, I suspect, this can simplify the optimisation algorithms 
>    in the compiler.

Ack!  Compiler:
  Warning: Due to that you did not imbed your assignments in boolean
           expression on line 2432, this compiler cannot optimize 
           that statement. Sorry about that.

Again ignorance of compiler optimization abounds.  From what I have
seen the "too macho to trust the compiler" attitude dominates the
industry.  Processors have multiple processing units to schedule and
pipelines filled to minimize stalls.  I just don't see the "optimized
C" computational model as being relevant any more. 

(4)
>Personally, the lack of this sort of compactness in Ada, and things like
>pre- and post-increment/decrement are one of my minor gripes about the
>language. OK, its no big thing to write:

>    P(I) := Q(I);
>    I := I + 1;

>instead of
 
>    *p++ = *q++;

>but I actually *do* find the C representation easier/better etc. (perhaps
>I'm wierd?)

Yup, pretty weird.  Compactness/terseness does not equal better
readibility.   Arrays are higher level than pointers and will be bounds
checked by most adequate languages.  Pointer arithmetic in my opinion
is yet another crap idea from the K&R bozos.

Another C guy:

>BINGO!!!  Readability, like beauty, is in the eye of the beholder.  An
>instructor here made the statement "Pascal is easier to read then C".  I
>don't think so.  In fact I got a D on a midterm because of it.  I was
>the only person in my soph intro CS class using C instead of Pascal, so
>all the code fragments were in Pascal.  To this day, I still can't read
>Pascal's pointer syntax.  Readability is what you are familiar with.
>Both of the C code fragments are very familiar to me and I find *very*
>easy to read (except for the lack of white space in the first one).

Yeah, all things are relative, all is a matter of opinion, all ideas
are of equal merit, etc. (We don't want to upset anyone)

Got a D, good, at least some instructors out there care about
teaching programming / language design.  Wow! so mentally rigid can't
read Pascal's elegant pointer syntax.  Gee, maybe the professor might
just know more than you, maybe when you take a class you should
try to learn something.  Guess you didn't want to learn good
program structure and clean language syntax and semantics. 

>I am tired of novice C users always saying this construct is bad, and
>that construct is bad.  And I don't care to program in C using only
>constructs that a novice would understand at first glance.  Ours is a
>professional environment and certain level of proficiency should be
>expected.  If a high school kid off the street could program like an
>expert, then why are we getting degrees and such?

Again, we have a incorrect correlation here between "professional
programmer" and C hacker.  "Novices" here are equated with
incompetent programmers when they may just be expert software
engineers who fully understand good programming language and software
design.  Why should we want to become proficient in old poorly
designed languages which is hard to learn when we can learn something
that is well designed that we can learn quicker and also have better
productivity in the long run.  I can get no joy from becoming
proficient in crap.  In my opinion, no person should get a
computer science degree with out understanding the flaws of C and
other popular poorly designed languages and systems.    

Heh, (C Idiom == Idiotm)

>Writing ``for (p = head; p; p = p->next) { /* process list */ }''

Ptr := Head;
while (Ptr /= null) loop
  ...
  Ptr := Ptr.Next;
end loop;

(My Ada is rusty, I only program in C++ now)

>Is quite clear to me, but others will probably disagree.  But I find the
>way of reading a file in Ada to quite idiomatic.  At least I was
>taught to enclose the reading from the file in a loop with an exception
>handler w/in the loop.  When the exception would be raised when an attempt
>to read past EOF, then close the file and process what ever your read in.

Actually, depending on exceptions to catch the EOF condition is
bad Ada style as you are depending on an exception for normal program
control.
----------

Okay I was harsh.  But these "C" attitudes of programming are pretty
much the norm in industry and I find this very distressing.  In my
opinion, the Computer Science community must admit their total
failure to teach or even understand or form a consensus about
good software construction and programming language design.