Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn C The Hard Way

learncodethehardway.org

Post reply on HN
Print view View original

151–160 of 260 posts

Re: Learn C The Hard Way

#151

Post by [deleted] »

eropple wrote: post #137
gregjor wrote: post #122

Earlier quoted context omitted.

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 ch…

Getting it or not is one thing, but I'd advocate keelhauling anyone who wrote that sort of thing in production. The "notational convenience" is more obnoxious than anything. But, then, I'm not particularly a fan of terseness for the sake of being terse.

[deleted]

Re: Learn C The Hard Way

#152

Post by Sapient »

zedshaw wrote: post #7
Sapient wrote: post #6

Having read a fair bit of LPTHW (though I had no actual interest in the language), I am really excited about this. One of the best things about LPTHW was the context it was written in, and if LCTHW is written in the same way, it should be a really awesome read!

That's the idea, although I'm going to assume you know how to use at least one programming language, and probably redirect total newbies to LPTHW if they don't. That should make it easier to ramp up in C and then do cool useful stuff with it.

That's awesome to hear. I actually know a bit of C, but it has been years since I used it - so this book seems like a good one to read to 'reboot' my C skills.

I'll definitely be waiting anxiously for you to finish.

Good luck!

Re: Learn C The Hard Way

#153

Post by contrast »

X-Istence wrote: post #130
hp wrote: post #121

Earlier quoted context omitted.

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.

When somebody directs "derogatory" remarks at themselves, it's called "self-deprecating". It's a good thing in many Western cultures at least, and demonstrates a degree of modesty. In this case, hp made it clear that he doesn't expect sympathy (or applause or whatever) for having written a lot of C. It's just something he mentioned because he thought it was relevant.

It is relevant - people not long out of school and talking at length about everything that's wrong with XYZ are tedious both to experts and experienced people generally. hp's comments on C use experience, clear reasoning, and absolutely no personal commentary whatsoever. This contrasts with the negative, personal and poorly reasoned attacks of people such as you.

I hope for your sake that you're asserting someone is "extremely" petty based on a mere self-deprecating aside because you're only a few years out of school and haven't learnt to communicate yet, and not just an old hand trapped an inability to relate to people with different opinions or role models. The world can always do with more talent and fewer martyrs.

Re: Learn C The Hard Way

#154

Post by justincormack »

wvoq wrote: post #119
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.

I don't intend to argue so much as to offer a data point: I suspect that most folks on this site learned C or something C-like early on, and have internalized its modus operandi. I have been learning C recently from a background of functional programming, and I find it scary and evil. FWIW, I enjoy programming very much, and have built some non-trivial stuff in several languages. Still, I found C extremely taxing. No…

It is possible to program C with a functional mindset, but the syntax does get in the way. The function syntax does not distinguish between parameters that are modified but you can by convention, and use of structs to bundle stuff up. You can pass function pointers liberally. In the end though the number of use cases for C is smaller now, and you should be able to avoid it for large projects and only use it for small pieces.

Re: Learn C The Hard Way

#155

Post by justincormack »

nitrogen wrote: post #149
eropple wrote: post #137

Earlier quoted context omitted.

Getting it or not is one thing, but I'd advocate keelhauling anyone who wrote that sort of thing in production. The "notational convenience" is more obnoxious than anything. But, then, I'm not particularly a fan of terseness for the sake of being terse.

I imagine terseness was a lot more valuable when everyone was programming on an 80x25 (or smaller) terminal or even punch cards. I've seen a few examples of code like this from early libc implementations of functions like strcpy, malloc, etc. Take a look at the source code of BSD libc -- some of that stuff is historic. I myself never got much into the terseness game, since apart from a brief stint using gwbasic and l…

This type of code used to run faster when compilers did less. It makes no difference now. I think that is why it has stuck around. I prefer to write C that uses array references where it makes things clearer.

Re: Learn C The Hard Way

#156

Post by justincormack »

irahul wrote: post #104
bad_wolf wrote: post #78

Earlier quoted context omitted.

If 19 is represented differently in binary on your platform than (leading zeros)10011, you are already quite screwed. You might be thinking of character representation for the later example.

No, I was thinking binary 19. Does C say the implementation is going to be 1s complements, 2s complements or whatever? Is there anything that says, for example, it can't be BCD?

Yes even though this is exactly why people want to use C now, to get exact binary behaviour.

Re: Learn C The Hard Way

#157

Post by cturner »

burgerbrain wrote: post #134
JoshTriplett wrote: post #80

Earlier quoted context omitted.

The negative connotations of the word aside, it seems perfectly reasonable to call C dangerous. Without that "danger", you couldn't write an OS kernel, a language runtime, or various other low-level code we need on our systems; on the other hand, when writing higher-level code that doesn't need that level of raw access, it seems useful to remove the possibility of a broad class of mistakes. See also Rusty Russell's r…

"Danger" minus the negative connotations is best pronounced "power".

gets()?

Re: Learn C The Hard Way

#158

Post by gregjor »

nitrogen wrote: post #149
eropple wrote: post #137

Earlier quoted context omitted.

Getting it or not is one thing, but I'd advocate keelhauling anyone who wrote that sort of thing in production. The "notational convenience" is more obnoxious than anything. But, then, I'm not particularly a fan of terseness for the sake of being terse.

I imagine terseness was a lot more valuable when everyone was programming on an 80x25 (or smaller) terminal or even punch cards. I've seen a few examples of code like this from early libc implementations of functions like strcpy, malloc, etc. Take a look at the source code of BSD libc -- some of that stuff is historic. I myself never got much into the terseness game, since apart from a brief stint using gwbasic and l…

The Go language tutorial and examples look right at home alongside K&R. Likewise jQuery and other Javascript libraries, where terseness is valued due to bandwidth rather than screen size.

The idiomatic C style is so natural to me now I don't see it as a defect to fix or a game I'm playing. It's how I learned to program in C because I learned from K&R, and if they aren't the authorities I don't know who is. When I see wordy and bloated Java-style code it reminds me of the years I spent writing COBOL. Ultimately, though, it's not efficiency or a desire to show off or confuse other programmers that influences my style. To me code that does what it needs to with no extra fluff is beautiful.

When I see

  while (*s++ = *t++) ;
I know what it does -- I don't need any comments or "descriptive" variable name or an explicit test for a null byte to make it clearer. If a programmer comes across a line of code that he or she doesn't understand the fault may be with the author, but it may be with the reader. In my experience there are a lot of unskilled programmers who quickly decide that any code they look at is badly written and should be thrown out. I don't think I should dumb down my code just so programmers less fluent with C can understand it. I have to consult a dictionary sometimes when I read Cormac McCarthy or Nabokov but I don't think they should write with easier words for my sake.

Re: Learn C The Hard Way

#159

Post by [deleted] »

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

[deleted]

Re: Learn C The Hard Way

#160

Post by gregjor »

justincormack wrote: post #155
nitrogen wrote: post #149

Earlier quoted context omitted.

I imagine terseness was a lot more valuable when everyone was programming on an 80x25 (or smaller) terminal or even punch cards. I've seen a few examples of code like this from early libc implementations of functions like strcpy, malloc, etc. Take a look at the source code of BSD libc -- some of that stuff is historic. I myself never got much into the terseness game, since apart from a brief stint using gwbasic and l…

This type of code used to run faster when compilers did less. It makes no difference now. I think that is why it has stuck around. I prefer to write C that uses array references where it makes things clearer.

Don't think so. Kernighan et al. are the first to say code should be clear first and made fast only if it matters. This is clear code. It may (or may not) be faster than an array-based version but that's not the point of the exercise in K&R -- the point is to teach how pointers work.
Post reply on HN