My beef with C

This is just as off-topic as Appendix C, but related in the sense that I'm contrasting my experience with in the C language with that in Forth. Forth of course is RPN, using a user-accessible data stack, whereas C is algebraic, and it hides the stack usage from the programmer. This page is adapted from a 6502.org forum private message reply to BigEd (who gave me permission to use what he wrote) where he asked what I find to be the stumbling blocks with the language. He asked because of my post which said,

scotws wrote:
Yes, Forth has a brutal learning curve. I spent the first weeks yelling What?! at the screen so much I felt like the Tenth Doctor.
I found it quite easy myself, going through the book "Starting Forth." I had already been programming with my HP-41cx RPN calculator which might have helped a lot, but I liked the fact that there was no punctuation, no parentheses, and almost no syntax rules. Now I'm on about page 95 of [later finished] the K&R standard book on C, 2nd Edition, which Samuel Falvo recommended, and I cannot believe how such an incredibly idiotic language (ie, C) got accepted by the industry! I assume it took a good salesman taking advantage of perfect timing and other factors that just happened to line up. Samuel's words were, "C is a very simple language to learn. Just be careful, since C is also a terribly difficult language to master." I can't agree with it being simple to learn. Difficult to master, definitely. I have a million notes in the book. I can only take a couple of pages at a time, as it's so exasperating. IMO, C is an absolute disaster; and the C code in the book (which is supposed to be a model) looks to me like when you see the helicopter views of houses in Tornado Alley that have been turned into a pile of toothpicks by a tornado.

(That's not to say I haven't seen an awful lot of unreadable Forth code. I definitely have; but I blame that on the programmer, not the language. It especially drives me nuts when someone writes in such a way that you can't visually pair up corresponding structure words! Forth is said to make good programmers better, and bad ones worse.)

So here's my answer to BigEd, plus a little more now that I've finished the book. (I thought maybe the problem was a poorly written book, so I got a second book, "C Programming, Absolute Beginner's Guide," Third Edition, and read the first several chapters, but found the same thing. I will not be trying any further.)

Previously I used three different versions of BASIC, and it seems at first glance like C is somewhat understandable after that. I'm finding that to be true only of the ultra-basics though. In the prose text, I mostly understand what I'm reading, but not well enough to repeat it; and although code examples are supposed to clarify things, I often truly cannot understand some part of them. I just move on, hoping it will click later; but so far, I'm not finding that to be the case either. Perhaps reading the book a second time will help. I did not have that problem at all with the book "Starting Forth," where everything made sense immediately. In the K&R C book, I still have to look up certain things every time, like how to make the difference between a function definition and a function prototype, and how to make sure the compiler doesn't take it to mean a variable declaration, or how to keep a#definedeclaration of a constant from looking like the start of a macro.

Something like int could be the beginning of various different things which still confuse me...declaring an integer, saying a function returns and integer, (and I think there was something else).
Having a function return more than one output doesn't work well. (A Forth word can easily return any number of items on the stack, implicitly.)
I like what Chuck Moore (inventor of Forth) said, "If I want to take a letter, like 'a', and add 1 to it to get the next letter, it's none of the compiler's business to tell me I can't." I don't like the typecasting you're chained to in C. The absence of typecasting was one of the things I liked about Forth when I was learning it in 1990. I've seen the C advocates' claims, that it reduces bugs; but the fact remains that Forth programmers develop the application, bug-free, many times as fast as the C programmers do. I've never had problems keeping data types straight. I tend to think that if someone can't keep their variables' types straight, maybe they shouldn't be programming.
In C, you cannot define your own operators, new program flow control structures, etc.. Forth lets you make entirely new ones, as well as letting you overload existing ones.
The logical and bitwise AND, OR, etc. and their symbols are confusing. In Forth, I've never needed logical to be separate from bitwise.
% in a printf is entirely different from % as "mod". There are many things like this that are confusing.
One of the things I didn't like about BASIC, although I became very proficient in my HP-71 BASIC which was light years ahead of more-common BASICs like GWBASIC, was the piles of parentheses, and having to count them sometimes to find where an error lay. With C, I'm right back there again, counting parentheses and brackets. Sometimes you have to use empty ones too, "()". RPN and Forth don't use them except for comments, and you can use any characters in Forth names except <nul>, <BS>, <Esc>, <CR>, <LF>, the common string delimiter " and the delimiter)for embedded comments (ie, comments that aren't necessarily at the end of the line), and maybe one or two others I'm forgetting; so you could have a variable named °C(initial) for example, or even°C(@_t=0)which you definitely cannot do in C.
Table 2-1 on p.53, "Precedence and associativity of operators" is too long to remember without constant use. There's no such thing with RPN & Forth.
In C's switch...case structure, the cases can only be constants. You cannot calculate them in the running program, or fetch them from variables. And since you cannot extend the language, you cannot add something to have a single case be a range of inputs, or a set of inputs. The example on p.59 has:
```
            case '0': case '1': case '2': case '3': case '4':
            case '5': case '6': case '7': case '8': case '9':
                ndigit[c-'0']++;
                break;
```
In Forth, I would write:
```
        0 9  RANGE_OF  ASCII 0 - 1+  END_OF
```
(if I'm understanding what ndigit[c-'0']++ does.) Or, to make the compiled code shorter and faster, subtract 1 less instead of incrementing at the end.
I also don't like the fact that a variable cannot be a pointer, and vice-versa. The absence of such typecasting in Forth makes it more flexible, and yet Forthers can always finish bug-free applications much faster than the C crowd can. This "clarification" on p.94 is something I can understand but it will take a lot of practice and a lot of looking it up again before I'll remember it:
```
        int x = 1, y = 2, z[10];
        int *ip          /* ip is a pointer to int */

        ip = &x;         /* ip now points to x */
        y = *ip;         /* y is now 1 */
        *ip = 0;         /* x is now 0 */
        ip = &z[0];      /* ip now points to z[0] */
```
I do not understand the parts on pointers to pointers, or pointers to functions. Forth's way is so much easier and more flexible. In the Forth2020 facebook group, Don Golding wrote on 2/11/21,
Forth helps me build new products FAST! I am also an embedded C programmer, so I have used both languages. C is "job security" for programmers. It is hard to learn from scratch, cryptic, hard to read. Misplace a curly bracket and spend a lot of time finding the problem. The "scoping" requirement will drive you nuts! Try C pointers sometime, you will go home and kick your dog. Forth, BTW uses pointers in an intelligent way. You don't even know you are using them.
I find C's required punctuation very difficult to deal with. I hate it! Forth has no punctuation. The things that look like punctuation are actually words with very short names (or in a few cases, delimiters, like the"at the end of a string literal, or the ) at the end of an embedded comment), and you could even rename the words. For example, if (for some off-the-wall reason) you wanted to rename ; toEndDef(for "End the definition here"), no problem, because ; is a word, not punctuation. Some of the other short names which might not look like names to non-Forthers are' " . , ! @ # .R ." .( C, R@ >R R> \and you can make any additional ones you like, even define your own operators to add to the usual ones + - * / > < etc.. You can rename them too (or any Forth word, for that matter), or have them mean different things in different contexts—not that I do, but it can be done.

My biggest problem with it all is just that there are too many rules in C, and I don't always understand the examples in the book. I have to keep referring back to other parts of the book to look up something I'm just supposed to remember but I don't remember because there's no pattern to it (which is why I have a bazillion pencil notes in the book), and that sometimes I just can't understand what it's doing at all. (Again, I never had this problem when learning Forth.) It may say not to use incrementers at some point because you don't know if the compiler will evaluate the right side first or the left side, and the effect of the ++ will be different from one compiler to another. Here's one I don't see the problem with, on p.90:

Some care also has to be taken with parentheses to make sure the order of evaluation is preserved; consider what happens when the macro
    #define  square(x)  x * x    /* WRONG */
is invoked as square(z+1).

As we discussed the C v. Forth thing on the forum, I am coming to be more of the opinion that some people really are destined to think more one way than another, like it's inborn, not just a matter of background (although I understand the Korean language is RPN, making Forth more natural to Koreans). I had TI algebraic calculators before an HP RPN one, and I did a lot of BASIC also, and even took Fortran, before meeting Forth; yet the way I think definitely tends toward RPN and Forth. Others have some trouble with it. With those who use RPN calculators, they often want the stack displayed so they can see what's there. I have no need for that.

After I said this to Ed, he replied,

It's an interesting idea, that you might have an RPN brain! Certainly most people seem to be the other way around, finding RPN and Forth a bit of a hurdle.
As I say, I can't defend C as a perfect language. A friend of mine, a very clever fellow, was dabbling with C compilers, or with parsing C, and it turns out it is really horrible to write a parser for, if you want to be entirely correct. I suppose my position is that I don't know the language well enough to be too concerned about some of the darker corners. I was never too worried about pointers and address-of operators, although I did sometimes have to convert the ideas into the terms of assembly language—to know what's passed in registers, or on the stack, or what's an address and what is data.
It does feel to me like you're aiming to be a master at C, and finding that a challenge, whereas I tried to be a journeyman, and just about managed bare competence! Low standards making for an easier life, perhaps.

A related forum topic is "Ranting about development tools -- read it if you dare," started by Samuel Falvo who was a professional programmer at a social-networking site and had more languages under his belt than you can shake a stick at (a few dozen, IIRC), and is an extremely sharp cookie.

I have plenty of other beefs about C, but they're mostly about common C style and practice, not C requirements; so I'll let them slide, since it would be kind of like arguing over whose favorite color is best.

last updated May 19, 2022 Garth Wilson wilsonminesBdslextremeBcom (replace the B's with @ and .)