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

231–240 of 260 posts

Re: Learn C The Hard Way

#231

Post by zvrba »

burgerbrain wrote: post #135
wvoq wrote: post #119

Earlier quoted context omitted.

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…

If you're thinking of arrays as second class citizens, you're thinking of the language incorrectly. Rather you should realize there are no arrays, only pointers to chunks of memory and arithmetic operations.

You're wrong; there ARE arrays: make int a[16], *aa; and compare sizeof(a) with sizeof(aa). The confusion arises from the fact that the VALUE of an array is a pointer to its first element. When you consider that C is a pure pass-by-value language, everything fits nicely into place.

Re: Learn C The Hard Way

#232

Post by burgerbrain »

zvrba wrote: post #231
burgerbrain wrote: post #135

Earlier quoted context omitted.

If you're thinking of arrays as second class citizens, you're thinking of the language incorrectly. Rather you should realize there are no arrays, only pointers to chunks of memory and arithmetic operations.

You're wrong; there ARE arrays: make int a[16], *aa; and compare sizeof(a) with sizeof(aa). The confusion arises from the fact that the VALUE of an array is a pointer to its first element. When you consider that C is a pure pass-by-value language, everything fits nicely into place.

sizeof behavior is just icing over what is really going on. You might as well argue that arrays really exist because we have the [] operator.

Re: Learn C The Hard Way

#233

Post by zvrba »

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…

Programming boils down to paying attention to details. C is an extremely small, simple, predictable and malleable [] language that makes you painfully aware of that fact. For me, it is a pleasure to read well-written C code, for example the NetBSD kernel. There's a lot to learn there about elegance and good design.

[] malleable in the sense of bottom-up programming and defining your own "vocabularies". When I develop in C (and C++) I usually solve the problems 75% bottom-up and 25% top-down. With bottom-up approach, it is easy to stay focused at the problem at hand and write mostly bug-free code. The "top-down" bits just put pieces of the puzzle together.

Re: Learn C The Hard Way

#234

Post by AnthonBerg »

regularfry wrote: post #139
leon_ wrote: post #129

Earlier quoted context omitted.

> Oh my god so many configuration settings! There are many alternatives for you that offer 1click build/deployment.

There are so many, in fact, that choosing one becomes a confusing array of choices in itself.

Hah! Exactly.

There is one that I can recommend, for the record, at least for C++:

Qt's QMake.

Re: Learn C The Hard Way

#235

Post by brianmatter »

zedshaw wrote: post #105
hp wrote: 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,…

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

hey, you don't know me or shite, but you're a fucking cool guy. probably the most generous dude i've ever not met. cheers!

Re: Learn C The Hard Way

#236

Post by brianmatter »

mkramlich wrote: post #99
arkitaip wrote: post #12

Zed, your level of productivity is truly inspiring. The best of luck to you.

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…

can you name 2? doubt it...

Re: Learn C The Hard Way

#237

Post by [deleted] »

roel_v wrote: post #191
cturner wrote: post #161

Earlier quoted context omitted.

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…

That's because of the (visually) 'wrong' use of * (wrong in the sense that it's unintuitive). The key is that * is part of the type of the declaration, not of the variable; an int* is not an int. So int *j = &i; is more correctly expressed and easier to understand when written like int* j = &i; The only reason to put the * in front of the variable name is when declaring several pointers in one line. So the solution i…

[deleted]

Re: Learn C The Hard Way

#238

Post by cturner »

atakan_gurkan wrote: post #185
cturner wrote: post #161

Earlier quoted context omitted.

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…

    I really see very little room for confusion here.
I don't understand how you reach that conclusion. You might understand it, I don't see how you can say there is very little room for confusion.

Yes, if you know about declaration follows use, it makes sense.

Yes, if you "keep in mind that strings are char arrays and an array's name is actually a pointer" then it makes sense.

You can get by by knowing to avoid some constructs.

If you know how the c compiler works, pointers make sense.

If you know C then you know C.

But when you're new to the language, you don't know these things and that's what this part of the thread is discussing.

Another responder wrote:

    The key is that * is part of the type of the
    declaration, not of the variable; an int* is
    not an int.
The grammar is structured as though it's not. Consider this:

    int* c, d;
Since star is part of the type, if the language was designed well then both of them would be int pointers. But in that case, only c is. d is an int. Awful.

Re: Learn C The Hard Way

#239

Post by llambda »

bandushrew wrote: post #218
llambda wrote: post #166

Earlier quoted context omitted.

Why is it that every comment I read by you is either you whining about being treated unfairly or you attacking someone who supposedly "attacked" you? Are you honestly that insecure? Do you read every comment as though it is in some way attempting to degrade your image? Here you denigrate the HN community, saying it doesn't generate a significant amount of traffic for your site or whatever, and then go on to say you w…

A quick look through Zed's comment history tells me that the % of posts he has made that could fit your description is roughly 1%. So Im going to go with you having a selection bias. OTOH I do appreciate your vigorous defense of the HN community, too many people just dont care about implied insults to their self identified tribal group. Go llambda!

You're probably right. I've only seen a couple of his recent comments in threads related to his projects or site (and that thread about the GitHub community). So I no doubt have a selection bias; I suppose it's worth noting his reputation proceeds him, deserved or otherwise.

Nonetheless it's disheartening to see self-proclaimed "professionals" (I use this term loosely for while a person may be employed professionally this is not a guarantee a given individual will behave professionally: they are distinct things) who are well known throughout the community, behave like trolls. And even more so when they decide it's appropriate to take a shit on this community.

Well I will always try my best to preserve what I value. It's in my nature I guess. So thank you. :)

Re: Learn C The Hard Way

#240

Post by Goladus »

cturner wrote: post #238
atakan_gurkan wrote: post #185

Earlier quoted context omitted.

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…

I really see very little room for confusion here. I don't understand how you reach that conclusion. You might understand it, I don't see how you can say there is very little room for confusion. Yes, if you know about declaration follows use, it makes sense. Yes, if you "keep in mind that strings are char arrays and an array's name is actually a pointer" then it makes sense. You can get by by knowing to avoid some con…

> if the language was designed well

Do you mean to reinforce that the language is not beginner-friendly, or are you really asserting that makes the language poorly-designed? If it's the latter, you should really at least explore some other factors before making the conclusion. It seems to me that it's a relatively minor distinction once you know it, so from a design perspective that may simply be a tradeoff for some other advantage.

Post reply on HN