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

241–250 of 260 posts

Re: Learn C The Hard Way

#241

Post by jwhite »

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…

Late to that party, but I'll give my $0.02 regardless.

I won't defend C: it's all that you say. I think one of the acknowledged reasons for C's longevity is that it is impedance-matched for UNIX because they grew up together, and for various reasons UNIX is popular with hackers; therefore C is popular. C is deeply rooted within UNIX, partly because the ABI has been so stable for so long. If you want to write a library for UNIX, you generally target C because anything else will run into a quagmire of cross-compiler incompatibility issues. That means all the good libraries on UNIX are written in C or present a C ABI/API. The easiest language to use a C library from is... C. Or C++. So application writers (and tool writers) have often favoured C as well, although the rise of interpreted languages such as Python, Perl, and Ruby has changed that a bit. Also, the C/C++ toolchains have tended to be more advanced than those of other languages.

So, C is still with us, but for reasons that don't have as much to do with its merits as a language as with its merits as a platform (when coupled with UNIX).

Re: Learn C The Hard Way

#242

Post by cturner »

Goladus wrote: post #240
cturner wrote: post #238

Earlier quoted context omitted.

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…

    Do you mean to reinforce that the language is not
    beginner-friendly, or are you really asserting that
    makes the language poorly-designed?
I was seeking to account to ramidarigaz why his CS classmates didn't understand pointers.

I think poor grammar is poor design - i.e. part of the type affects both variables (int), the other part doesn't (star).

The other issue is use of star to in one place to mean create reference, in others to mean dereference. That was the focus of my first post.

    from a design perspective that may simply be a
    tradeoff for some other advantage.
I've yet to see evidence of any. What sort of things were you thinking about?

Re: Learn C The Hard Way

#243

Post by Goladus »

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.

There are arrays. C defines types. When you declare a variable as an array of int, C knows that variable is of type "array of int" and treats that differently than if it had been declared as "array of pointers to int" or "array of char" or "pointer to array of pointers to pointers to int".

I spent many years believing it when people made exactly the assertion you have(see my other posts on this article), but it wasn't until I tried to build a C compiler myself how wrong it is to think of arrays this way. Yes, C gives you the power to reference memory in a more or less arbitrary way. That does not mean that the arrays you declare are not arrays.

Re: Learn C The Hard Way

#244

Post by Goladus »

burgerbrain wrote: post #232
zvrba wrote: post #231

Earlier quoted context omitted.

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.

No not really. What's really going on is that A has been declared as an array of 16 ints, while aa has been declared as a pointer to int. Those are different types, and C treats them differently sometimes (but not all times).

Re: Learn C The Hard Way

#245

Post by atakan_gurkan »

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…

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

Please do not put words in my mouth. I wrote "I see very little room for confusion" not "There is very little room for confusion". I tried to make it clear that I was talking about my personal experience; and I was talking about my personal experience since I was hoping it would help, not to defend the syntax of C.

Sometimes a particular point of view allows you to understand something; in some cases it makes the previously mystifying point "trivial" or "obvious". I am sorry that the POV that helped me so much does not help you at all.

Re: Learn C The Hard Way

#246

Post by emehrkay »

I jokingly made this suggestion to him on twitter. He posted a few "assignments" and we (I assume it was more than myself participating) posted pics of our console output.

This guy loves to program

Re: Learn C The Hard Way

#247

Post by cturner »

atakan_gurkan wrote: post #245
cturner wrote: post #238

Earlier quoted context omitted.

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…

>> 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. Please do not put words in my mouth. I wrote "I see very little room for confusion" not "There is very little room for confusion". I tried to make it clear that I was talking about my personal experience; and I was talkin…

I see, and thanks for clarifying.

The point of my earlier post was to describe strong reasons for people to have trouble with pointers.

Re: Learn C The Hard Way

#248

Post by burgerbrain »

Goladus wrote: post #244
burgerbrain wrote: post #232

Earlier quoted context omitted.

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.

No not really. What's really going on is that A has been declared as an array of 16 ints, while aa has been declared as a pointer to int. Those are different types, and C treats them differently sometimes (but not all times).

Aside from the additional information that the C compiler is capable of knowing about in the case of A, it is the same crap going on under the hood.

Re: Learn C The Hard Way

#249

Post by ori_b »

AnthonBerg wrote: post #234
regularfry wrote: post #139

Earlier quoted context omitted.

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.

The last project I tried that used qmake missed dependencies on generated files, and therefore needed make clean fairly often.

It's sad, but the best user experiences I've had were either hand-coded makefiles, or autotools (ick).

Re: Learn C The Hard Way

#250

Post by bandushrew »

llambda wrote: post #239
bandushrew wrote: post #218

Earlier quoted context omitted.

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…

heh. His reputation appears to be a many faceted thing.

I, for instance, have been genuinely impressed with his productivity and his output, his choice of projects and his code and am moved by that aspect of myself that values quality to think very highly of him.

You, on the other hand, appear to feel that the most important aspect of his output is the way he achieves the standards that you have set for him - judged by how he expresses himself towards those who he feels are being disrespectful or rude at him on the internet.

Just out of interest, do you believe that making a strongly negative personal judgment based on a 'fact' that is clearly incorrect and could be easily checked with just a few clicks is the act of a professional? do you meet your own high standards?

Post reply on HN