🚀 go-pugleaf

In article <BruEuz.GJJ@news.cso.uiuc.edu> tmkk@uiuc.edu (Khan) writes:
...
>May I point out that you're not putting down C, you're putting down a
>PERSON who *uses* C.

That was not my intent.

>>C is one of the unfriendliest languages I've come in contact with, especially
>>in the ways it is used by far too many people.
>
>You know, I always suspected that most of the C bashers in the world
>hate the language because they aren't posessed of the intellectual
>capacity to understand how to use it. People who think a for loop in C
>is confusing, for example. Based on your experience in writing an ANSI C
>compiler, I see that you are an exception to this rule. ;-)

I'm not sure how I'm supposed to take that!

I think that most of the people in the world who are "C bashers" are people
who have tried something else for a while, and gotten used to the benefits
it can offer. Because of other reasons they must use C, and they dislike the
lack of the things they are used to having. In my case it is strong type
checking, guarantees that something used has been explicitly defined, a
real 'for' loop that is easy to optimize, no need to worry that something
is a macro so that it doesn't do what it looks like it does, etc.

>Personally, I'd rather be "confused" by a C for loop than be genuinely
>confused at all the bizarre dialects that call themselves Pascal. I can
>port a Borland C program to Unix C or VAX C or even Atari 8-bit C with
>little trouble. The same can *not* be said of a Turbo Pascal program!

Not having suffered with much Pascal programming, I can't disagree. I base
my dislike of C on other languages that I find more useable than Pascal.

>Face it, ugly spaghetti code can be written in ANY language. Don't try
>to blame the language for a lack of skill on the part of the programmer.

Not quite true. For example, the language I've used at home for several
years doesn't have a goto, break or continue. I've never missed them. I've
also done in it just about every kind of programming you can think of, from
games to editors to databases to compilers.

>Agreed 100% - and don't forget *thorough* internal documentation! At the
>very least, the header comments for a function should identify all
>parameters and explain their use. Local variables should also have a
>brief comment next to their declarations. Finally, each block of code
>within the function should have its own small comment block.

I very rarely go that far. Instead I use conventions for names and I use
names that are long enough to properly describe what they do. My C code at
work will NOT compile using an outdated K & R C compiler.

>Looks like we're well on our way to writing a Usenet Manual of C Form
>and Style. ;-)

The company I work for spent a lot of effort on producing a style guide.
I followed it, and even changed some of my home programming style to match
it. Unfortunately, it wasn't properly enforced, and we ended up being stuck
with some code that is nearly impossible to maintain. So, A usenet style
guide might be a nice thing to have for those who want to do things "right",
but I doubt many hackers could be convinced to follow it.

--
Chris Gray   alberta!ami-cg!cg	 or   cg%ami-cg@CS.UAlberta.CA