Newsgroups: comp.lang.python,comp.lang.tcl,comp.lang.scheme,comp.lang.misc,comp.lang.perl
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!news.sei.cmu.edu!cis.ohio-state.edu!rutgers!newsserver.jvnc.net!howland.reston.ans.net!swrinde!news.uh.edu!uuneo.neosoft.com!nmtigw!peter
From: peter@nmti.com (Peter da Silva)
Subject: Re: Comparing syntaxes  (Re: What language would you use?)
Message-ID: <id.6ALE1.TW6@nmti.com>
Sender: peter@nmti.com (peter da silva)
Organization: Network/development platform support, NMTI
References: <39b7ha$j9v@zeno.nscf.org> <39mi58$aeu@brachio.zrz.tu-berlin.de> <id.33KE1.GY@nmti.com> <39pel5$qls@brachio.zrz.tu-berlin.de>
Date: Wed, 9 Nov 1994 22:01:42 GMT
Lines: 79
Xref: glinda.oz.cs.cmu.edu comp.lang.python:2551 comp.lang.tcl:21636 comp.lang.scheme:11122 comp.lang.misc:18991 comp.lang.perl:38476

In article <39pel5$qls@brachio.zrz.tu-berlin.de>,
Reimer Behrends <behrends@buran.fb10.tu-berlin.de> wrote:
> If readability was a concern, the designers of C failed remarkably.

In your opinion.

> o C encourages cramming as much code as possible on a single line.

It does? I have certainly seen people who write "Basic in C" with gobs
of stuff per line, but it's hardly typical and not what I'd call good
programming style.

Just like Fortran, it's not the least difficult to write Basic in any
language. At worst I'll agree that C allows you to cram a lot more stuff
on a line than some languages. That's not the same as encouraging it.

>   A common culprit is the comma operator.

I've seen the comma operator used like this a handful of times.

> o There are too many 'common idioms' in C. To multiply a variable by 2,
>   I've seen x+=x, x*=2 and x<<=1.

The idion is "x *= 2". The others are dubious microoptimizations.

> And this is just a simple case. Check
>   the section in K&R on argc/argv processing for more details. And why
>   does both char *argv[] and char **argv work, but not char argv[][]?

Because a pointer isn't an array. If you think of a pointer as an array
you'll lose.

>   Imagine the subtle difference between void *f() and void (*f)(). Etc.

I haven't seen a *better* declaration syntax than C's for complex
declarations. Making * a prefix rather than a postfix operator was a
mistake, yes. I'll grant you that one. Given the lack of prior art, I
can't ding them too hard for that.

> o There are way too many precedence levels in C.

I'll buy this one.

> o #ifdef THIS, #ifndef THAT. No comment. And of course, the preprocessor
>   in general. ("Why doesn't isprint(*p++) work? Oops, it's #defined as
>   ((c)>=' ' && (c)<=0x7e)." "Strange. The call of foo() matches the
>   declaration, but the compiler complains. Oh, I see. Somebody put a
>   #define foo debug_foo in a header file and debug_foo has an additional
>   argument.")

Macro abuse abounds in any language that allows macros. I've seen some
really gross examples in Lisp. Someone came up with an example that looked
like Tcl, almost, with infix expressions embedded in strings and things like
that. Unlike Tcl, though, that stuff could only be used in special places
because it was a macro.

> : Because "increment X by Y" is a very common idiom, while "feed X through F"
> : is a rarely used one?

> Actually, ++x is just a special case of x = f(x) with f(x) = x+1, so it
> can't be that rare.

I'm talking about "how humans write code", not "how pure mathematicians
write proofs". Incrementing is a common idiom. The general case isn't. It
rarely is.

[analogy with cicero deleted: analogies are like instant coffee]
> in simpler entitities. Of course, YMMV. The 'semantic noise' argument
> can be reduced to handling temporary variables in general. If you can do
> this, there's no problem here. If you can't, you should give up
> programming. Actually, I'm quite tempted to shout 'straw man' here.

Go ahead. See my other example of code that looks like that but clearly would
be made far worse by creating temporaries OR by getting rid of the +=.
-- 
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U`
1601 Industrial Blvd.     Sugar Land, TX  77478  USA
+1 713 274 5180                       "Hast Du heute schon Deinen Wolf umarmt?"
