home   |   stacks treatise index   |   1. Intro: stack basics   |   2. subroutine return addresses & nesting   |   3. interrupts   |   4. virtual stacks   |   5. stack addressing   |   6. passing parameters   |   7. inlined data   |   8. RPN operations   |   9. RPN efficiency   |   10. 65c02 added instructions   |   11. synth instructions w/ RTS/RTI/JSR   |   12. where-am-I routines   |   13. synthesizing 65816 stack instructions   |   14. local variables, environments   |   15. recursion   |   16. enough stack space?   |   17. forming program structures   |   18. stack potpourri   |   19. further reading   |   A: StackOps.ASM   |   B: 816StackOps.ASM   |   Appendix C   |   D: My beef w/ C


6502 STACKS TREATISE


Appendix D:  My Problem With the C Programming Language  (You don't have to agree.)

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 #define declaration of a constant from looking like the start of a macro.


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).



<end of first private message to Ed>

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.

<end quote>


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 .)