Learn C The Hard Way • Hacker News Board

Re: Learn C The Hard Way

#181

Post by Goladus » Sun, Jul 03, 2011, 1:37 PM UTC

DannoHung wrote: post #111

The biggest problem with C is not the language C, for it is a small and mostly simple language with a few warts (I'm looking at you, pointer syntax), it is the ecosystem into which you are thrust when you first use it. That is, the ecosystem of, "What can I include without dicking around with compiler and linker settings, which I do not care to learn very well because I am just starting?", and the ecosystem of, "Why…

> The biggest problem with C is not the language C, for it is a small and mostly simple language with a few warts (I'm looking at you, pointer syntax), it is the ecosystem into which you are thrust when you first use it.

The language C is a big problem for beginners, though. Pointer syntax is not just a tricky optional feature, it's necessary for a number of common tasks including defining functions and passing parameters. The type system is also important, not intuitive and rarely taught effectively. Countless times I read or was told that the syntax for referencing arrays was the same as referencing a pointer in memory, but nobody ever bothered to clarify or reinforce the idea that arrays are still a distinct static type.

Pointers and types are fundamentals and anyone who was lucky enough to learn them early on might not understand how hard it can be to figure this stuff out on your own and how difficult it is to actually use C before you do.

Re: Learn C The Hard Way

#182

Post by antirez » Sun, Jul 03, 2011, 1:39 PM UTC

JoshTriplett wrote: post #91

When I first learned C, I did so under DOS, an environment in which you could declare a pointer to video memory, make a magic call, and start drawing graphics. I found that a memorable way to learn pointers. Sadly, doing that in the modern world requires quite a bit more setup.

This is how I learned C as well (demo coding), and a book like that makes a lot of sense IMHO: learning C with computer graphics. Now this would probably be SDL based, but as long as the user receives the initial help to get started with a simple Makefile and the calls to get a window, it will be a lot similar to the old times of int 10h.

Cheers, Salvatore

Re: Learn C The Hard Way

#183

Post by [deleted] » Sun, Jul 03, 2011, 1:42 PM UTC

cturner wrote: post #161

ramidarigaz wrote: post #11

Earlier quoted context omitted.

Many of the friends I made in my CS classes were terrible with pointers. I never really understood why they didn't grasp pointers, but it was a major stumbling block for them in C/C++

I never really understood why they didn't grasp pointers The root of the problem is the language designers' loose use of star. "star something" is contained in a phrase that means one thing at declaration, "star something" has a different meaning the rest of the time. #include void eg(int i) { int *j = &i; // "huh? Put the address of i into *j?" *j = *j + 1; printf("%d\n", *j); } int main() { eg(4); } With more detai…

[deleted]

Re: Learn C The Hard Way

#184

Post by antirez » Sun, Jul 03, 2011, 1:43 PM UTC

irahul wrote: post #56

zedshaw wrote: post #18

Earlier quoted context omitted.

Yes, actually people are deathly afraid of C thanks to other language inventor's excellent marketing against it. There's a few things that you need to really nail to be good at C, and they're difficult things, but it's not "dangerous" like people keep claiming.

C is difficult, yes. Dangerous - I don't know in what sense. I manage to get more exceptions in my Python, Ruby code, owing to undefined variables or incorrect types, than I get segfaults in C. The main issue with C is it takes some time before you are ready to take it head on. An experienced C programmers would have his repertoire of generic data structures library with time complexity guarantees (programs without h…

what I keep repeating about that is why the C standard guys don't freaking update the libc with a new version of the C standard? Deprecating the old silly stuff like strcat() (the libc is full of bad calls) and adding lists, hashes, btrees, good dynamic strings lib, and so forth. An huge step forward for C... without even touching the core language.

Re: Learn C The Hard Way

#185

Post by atakan_gurkan » Sun, Jul 03, 2011, 1:44 PM UTC

cturner wrote: post #161

ramidarigaz wrote: post #11

Earlier quoted context omitted.

Many of the friends I made in my CS classes were terrible with pointers. I never really understood why they didn't grasp pointers, but it was a major stumbling block for them in C/C++

I never really understood why they didn't grasp pointers The root of the problem is the language designers' loose use of star. "star something" is contained in a phrase that means one thing at declaration, "star something" has a different meaning the rest of the time. #include void eg(int i) { int *j = &i; // "huh? Put the address of i into *j?" *j = *j + 1; printf("%d\n", *j); } int main() { eg(4); } With more detai…

To avoid this sort of thing, I use:

    #include 
    void eg(int i) {
        int *j; // "j is a pointer and (hence) *j is an int"
        j = &i; // "Put the address of i into *j? Yup"
        *j = *j + 1;
        printf("%d\n", *j);
    }
    int main() {
        eg(4);
    }

Perhaps this is because I am just used to it, but I really see very little room for confusion here. The common usage avoids confusion, if you do not insist on assignment at the time of declaration.

To address your second confusion, just keep in mind that strings are char arrays and an array's name is actually a pointer. Again, I find this very straightforward.

Re: Learn C The Hard Way

#186

Post by rat » Sun, Jul 03, 2011, 1:50 PM UTC

rat wrote: post #170

rpearl wrote: post #22

Earlier quoted context omitted.

As a teaching assistant for a class ( http://www.cs.cmu.edu/~410/ ) where students write a whole lot of code in C, please introduce the address-of (&) operator and explain how to obtain pointers without using malloc(). Do this before the concept of the heap is ever introduced at all. Be careful when explaining the compiler and how a program actually runs. I've found that a lot of student problems come from "the compi…

can you get around the second without typeof(a gnu extension)?

at least if you stick to macros

Re: Learn C The Hard Way

#187

Post by Goladus » Sun, Jul 03, 2011, 1:52 PM UTC

speckledjim wrote: post #138

zedshaw wrote: post #105

Earlier quoted context omitted.

I'm glad you got so much about how my book is written from a few paragraphs in an unfinished manuscript for it.

You should stop thinking everyone is attacking you. I think you'd be happier. Really though, there's no content here. The fact it's been voted to #1 on hackernews shows just how bad things are. Items should be upvoted on their merit, rather than who did them. Someone writing another book about programming C isn't newsworthy.

If you know a really good beginner-oriented C programming book that is not K&R I would love to see it.

Re: Learn C The Hard Way

#188

Post by brown9-2 » Sun, Jul 03, 2011, 2:00 PM UTC

thebooktocome wrote: post #164

speckledjim wrote: post #138

Earlier quoted context omitted.

You should stop thinking everyone is attacking you. I think you'd be happier. Really though, there's no content here. The fact it's been voted to #1 on hackernews shows just how bad things are. Items should be upvoted on their merit, rather than who did them. Someone writing another book about programming C isn't newsworthy.

I don't really understand your comment. 1. The post is about Zed's draft; is it really so far of a leap to interpret hp's remarks as a criticism of the book? 2. Is this a fair paraphrase? "Everyone here isn't attacking you, also, your draft sucks and shouldn't have been posted on HN."

I think hp is making more of a comment about the general state of C books rather than this one.

Re: Learn C The Hard Way

#189

Post by Goladus » Sun, Jul 03, 2011, 2:05 PM UTC

ramidarigaz wrote: post #11

rpearl wrote: post #5

Do people really think C is some mysterious, inscrutable language? "To many programmers, this makes C scary and evil." Is this actually true for people? I find C code generally very easy and straightforward to understand; there's not any magic behind the scenes, like there is in any language that's more "high level" than C.

Many of the friends I made in my CS classes were terrible with pointers. I never really understood why they didn't grasp pointers, but it was a major stumbling block for them in C/C++

I can't speak for your friends, but while I had zero problems with pointers conceptually, I still had trouble using them in C. The problem wasn't the simple case of declaring a pointer and taking its reference, the difficulty came when the programs got complex and required agreement between function declarations, actual parameters in calls, and use within the functions.

Re: Learn C The Hard Way

#190

Post by adestefan » Sun, Jul 03, 2011, 2:13 PM UTC

ramidarigaz wrote: post #11

rpearl wrote: post #5

Do people really think C is some mysterious, inscrutable language? "To many programmers, this makes C scary and evil." Is this actually true for people? I find C code generally very easy and straightforward to understand; there's not any magic behind the scenes, like there is in any language that's more "high level" than C.

Many of the friends I made in my CS classes were terrible with pointers. I never really understood why they didn't grasp pointers, but it was a major stumbling block for them in C/C++

Mainly because variable declarations are "backwards" in C. People try to read code left to right, but C declarations should be read right to left. Pile one things like the dual use of the static keyword, typedefs, and having multiple consts in a declaration figuring out the type of a variable can be a real chore. Dan Saks has a great article that hits on just the issues with const. http://dansaks.com/articles/1998-06%20Placing%20const%20in%2...