Live data from Hacker News

Learn C The Hard Way

learncodethehardway.org

121–130 of 260 posts

Re: Learn C The Hard Way

#121

Earlier quoted context omitted.

I think the level of self-promotion and/or other-people-promoting-him is the key factor. Not really the supposed productivity. I know many people who get a lot done, both for day jobs, for contract work, as a hobby, as entreprenurial ventures, etc. but 99.9% never hits the front page of HN on a regular basis like Zed's activity seems to. Which doesn't lessen what he does and his skills, but it does pull back the came…

I personally have no idea why this stuff hits this site that often. Take this for instance: It is a half-finished manuscript that I announced in a tweet to people who follow me on twitter and asked for it. Already at the top of this set of comments is a dickhead saying he's such a bad ass 'cause he's changed "half a million lines of C code" and he thinks I'm not writing the book correctly because I'm being too low le…

hey, I was just idly chattering about C and the way people in general often approach it. Not intended to be a review of an unwritten book or imply that you plan to approach it in any particular way.

I am a bad ass of course. But I thought it was relevant to the comment that I've written a lot of C.

Re: Learn C The Hard Way

#122
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++

K&R chapter 5.5, Character Pointers and Functions, explains pointers and shows how they are used in C. It's probably the clearest explanation of pointers ever written, and it doesn't require any understanding of hardware or assembly language (though that would help).

I remember reading those three pages over and over and experimenting with the code until I got it. I probably spent several days studying the pointer chapter back when I was a teenager. The light bulb eventually went on and C pointers made sense -- until learning C my programming experience was mainly with time-shared BASIC. The stepwise refinement of an indexed array version of strcpy() to a pointer-based version is a masterpiece of programming writing -- I still refer programmers I am mentoring to that chapter.

Finishing the strcpy() example with the one-liner

  while (*s++ = *t++) ;
the authors write "Although this may seem cryptic at first sight, the notational convenience is considerable, and the idiom should be mastered, because you will see it frequently in C programs." I've found that programmers either get that line of code or they don't, and those who don't haven't mastered their craft.

Re: Learn C The Hard Way

#123
post #114

Earlier quoted context omitted.

Maybe he's referring to how identifiers with leading underscores followed by a capital letter are reserved in C++ (I'm not sure if they are in C)...

Oho. Followed by a capital letter ? Interesting. I always thought that "all identifiers with a leading underscore were reserved". I just consciously ignored it, and have never had a problem in years. But I was also always using member variable names like "_children", "_childCount", etc, not "_Children".

In fact, here's a reference: http://msdn.microsoft.com/en-us/library/e7f8y25b(v=vs.80).as... (It's in a "Microsoft Specific" block but says it's part of the ANSI C standard.) It applies to C, and it also applies to identifiers staring with two underscores.

Re: Learn C The Hard Way

#124

Earlier quoted context omitted.

I think the level of self-promotion and/or other-people-promoting-him is the key factor. Not really the supposed productivity. I know many people who get a lot done, both for day jobs, for contract work, as a hobby, as entreprenurial ventures, etc. but 99.9% never hits the front page of HN on a regular basis like Zed's activity seems to. Which doesn't lessen what he does and his skills, but it does pull back the came…

I personally have no idea why this stuff hits this site that often. Take this for instance: It is a half-finished manuscript that I announced in a tweet to people who follow me on twitter and asked for it. Already at the top of this set of comments is a dickhead saying he's such a bad ass 'cause he's changed "half a million lines of C code" and he thinks I'm not writing the book correctly because I'm being too low le…

You're the dick Zed. The guy (hp) barely mentioned what you were doing at all and was just offering some general advice on C. You take it like a personal attack on your manhood.

You're always defending yourself against dreamed up conspiracies. You have a serious martyr complex.

Re: Learn C The Hard Way

#125

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++

For me, the indirection of pointers was one of the fundamental CS concepts that required real effort to understand. Before that point, I had never clearly separated the concept of a variable and its value. It took a huge conceptual leap to think about a variable that didn't hold a value, but rather, the location of a value. It took some serious mental gymnastics to deal with pointers n-levels deep. Mind you, this was…

Actually learning about the stack was one of my big 'aha!' moments. I sorta' knew it existed, but I didn't really comprehend it.

Re: Learn C The Hard Way

#126

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…

C++ has the same issues.

To add another example, binary only distributions (e.g. some commercial software) bring their dependencies with them, meaning that you have to use roughly the same environment (compiler version, stl) to use them.

Libraries work a lot better in VM languages.

Re: Learn C The Hard Way

#127
post #85
post #82

Ohloh says I've changed at least half million lines of C code ( https://www.ohloh.net/accounts/rhp/positions/total ) Play me a tiny violin ;-) What kinda bugs me is that whenever people go to teach C, they make out like it _has_ to be a low-level exercise, as if writing in C suddenly means you can't use abstract data types or object-oriented style or name your functions properly or have Unicode support. For example,…

C shouldn't be used for anything other than low level programming these days. There are other higher level programming language that would make your job a whole lot easier. Some programmers, like me, are stuck maintaining legacy C application code, but I wouldn't wish that fate for new programmers looking to learn C as another tool in the belt.

Other uses of C besides low level programming is:

1. Building static libraries. 2. Building so and dll. 3. Binding those so/dll with higher level languages like Ruby, Python, Perl and PHP.

That is my main use of C these days. I always write the IO, user interface code in higher level languages and put all processing code in a so or dll written in C.

Re: Learn C The Hard Way

#128
post #126

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…

C++ has the same issues. To add another example, binary only distributions (e.g. some commercial software) bring their dependencies with them, meaning that you have to use roughly the same environment (compiler version, stl) to use them. Libraries work a lot better in VM languages.

In addition, C++ has a whole pile of other problems too.

Re: Learn C The Hard Way

#129

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…

> Oh my god so many configuration settings!

There are many alternatives for you that offer 1click build/deployment.

Re: Learn C The Hard Way

#130
post #121

Earlier quoted context omitted.

I personally have no idea why this stuff hits this site that often. Take this for instance: It is a half-finished manuscript that I announced in a tweet to people who follow me on twitter and asked for it. Already at the top of this set of comments is a dickhead saying he's such a bad ass 'cause he's changed "half a million lines of C code" and he thinks I'm not writing the book correctly because I'm being too low le…

hey, I was just idly chattering about C and the way people in general often approach it. Not intended to be a review of an unwritten book or imply that you plan to approach it in any particular way. I am a bad ass of course. But I thought it was relevant to the comment that I've written a lot of C.

When your second sentence is: "Play me a tiny violin ;-)" it isn't just idly chattering. It comes across as extremely petty and derogatory.
Post reply on HN