C's syntax (was Re: Python Formatted C Converter (PfCC))

[Grant Griffin]

William Tanksley wrote:
> 
> On Tue, 24 Oct 2000 20:42:24 +0100, Grant Griffin wrote:
> >Alex Martelli wrote:
> 
> >> But that doesn't mean I have to keep silent when somebody
> >> baldly asserts that C's syntax is "pretty good".  Yecch.  It's
> >> most definitely *NOT*!
> 
> >Just for curiosity, could you be a little more specific here?  Sure, C
> >has its several known pitfalls.  But those aside, what's so bad about
> >it's syntax overall?
> 
> The pitfalls, for one ;-).  C also makes pointers look terrible.

Yeah, I greatly appreciate reference parameters that C++ supplies for
passing stuff into and out of functions.  If there were such as thing as
"C+", that would be one of its features.

That being said, I think Python's paradigm of (being able to) return a
"list" (actually a "tuple") is a much better way to pass things out of
functions.  The fact that a C function can pass 0 or 1 return items is
very artificial: we routinely defeat that using pointer arguments or
references when we need to "return" multiple values.

> I don't mind the syntax, myself; the hard part for me is how incredibly
> poorly designed the standard library is.  A good library is able to catch
> mistakes; C's library usually 'detects' errors by corrupting memory and
> dying later.

Point taken, but my perspective, coming from MS Pascal (many years ago),
was that at least C _has_ a standard library!  The problem with Pascal
(which eventuall killed it, IMHO), was that the original language was
not complete enough to be truly useful; therefore, each vendor extended
it.  MS Pascal was a pretty good system (except for cryptic manuals...)
because it added on a good non-standard library--stuff you really
_needed_.  

> In fact, there's a type of testing in which all external interfaces are
> given semi-random parameters (chosen based on boundary conditions).  The
> goal is to get 100% detection of the bad parameters (it's okay to crash
> immediately).  C's library, when thus tested, detected almost none of the
> misuse.  It's a design flaw, not something a compiler can easily fix.

One really useful thing that MS Pascal did that I haven't seen any other
compiler do is reserve the most-negative integer (-32768, for a 16-bit
integer) as an "unitialized" value.  That mechanism uncovered bugs for
me on a regular basis.

> >Having written a lot of Pascal right before I learned C, I found C's
> >syntax to be quite a relief.  Isn't nice to type "{" rather than
> >"begin"?  (Or, better yet, to type nothing at all in Python?  <wink>)
> 
> True.  That's rather a minor quibble, though -- it's even better to type
> just 'end', or nothing at all.  It's BAD to get confused about whether a
> given statement is part of an IF (the distinction between blocks and
> statements following ifs), or to have a syntax in which it's easy to not
> notice that there's a semicolon at the end of the for loop, making it
> empty and making the block after it execute exactly once when the for loop
> completes.

If you're suggesting that C has a design flaw of allowing you to _not_
use blocks on decision and looping statements, then I agree.  However,
it has been my habit for many years to do so on every block-able
statement, and I never have the problem you describe.

I recently started using GNU's "Indent" program, and it works pretty
well--but one dopey thing it does is remove needless blocks!

> >And isn't it nice that the properties of a C "for" loop are very
> >simply--and flexibly--defined?--no arbitrary restrictions here.
> 
> Agreed.
> 
> >And why did Pascal ever need that bogus ":=" thing in the first place?
> 
> Well...
> 
> ><<designed by a guy who didn't use it much>>  Oh, and the C preprocessor
> >is a beautiful thing whose absence, in retrospect, makes Pascal seem
> >absolutely incomplete.
> 
> Ugh.  I HATE the C preprocessor.  Wouldn't it be beautiful to be able to
> parse the language using the language's own capabilities?  Or at least to
> be able to have some limited parsing and computation at compile-time?

I can see the value of that, to an extent.  But I really like the "dumb
substitution" that "#define" does.  I've worked with assemblers and
other tools where they had dopey restrictions on what you could and
couldn't substitute.  In a way, I think the text-substitution paradigm
is powerful in many ways for the fact that it _doesn't_ understand the
code!

> Once you play with Forth, you're pretty much ruined for any other
> language...  Even Lisp just doesn't cut it.

So why are you here? <wink>

I have friend who has tried hard to sell me Forth, and I've been trying
hard to sell him Python.  (What should I tell him?)

evangelistic-ly y'rs,

=g2
-- 
_____________________________________________________________________

Grant R. Griffin                                       g2 at dspguru.com
Publisher of dspGuru                           http://www.dspguru.com
Iowegian International Corporation	      http://www.iowegian.com