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

Modern C [pdf]

icube-icps.unistra.fr

Post reply on HN
Print view View original

391–396 of 396 posts

Re: Modern C [pdf]

#391

Post by komali2 »

sn9 wrote: post #356
____nope wrote: post #297

Earlier quoted context omitted.

It's hard to teach an introduction to programming without teaching a particular language. If you have to pick a particular language, it makes sense to choose something the student is likely to use in the future. This is not hard to understand.

That's silly. If you can reasonably claim to know how to program, the choice of language largely doesn't matter. Someone who knows how to program in [first language] should be able to pick up how to program in any language one is likely to encounter in an industry position. So the first language should be one that gives the student a firm foundation from which one can become that competent. I've personally seen excel…

That's a big part of many bootcamps' marketing model. Start in web dev, move on to other things.

Re: Modern C [pdf]

#392

Post by komali2 »

khedoros1 wrote: post #288
ticviking wrote: post #280

Earlier quoted context omitted.

I suspect you are far more willing to learn by rote than some other students. For a particular kind of curious student, "just do it because you have to" is a very fast way to them checking out and doing nothing at all.

I held onto the promise of a forthcoming explanation (and read ahead in the book, anyhow). Honestly, someone who can't deal with a little ambiguity when starting out on a new technology isn't going to last long in the field anyhow, especially with the amount of self-learning that you end up doing.

Well, that's me in a nutshell though. If I don't get the answers I need soon, I get frustrated and it becomes nearly impossible to stay focused or motivated. With web development, I was lucky in that I had teachers that were willing to humor my curiosity, and I could also hop on the internet and IRC channels.

Self learning is the opposite of the classroom issues I had. I can start a webpack tutorial, it'll mention Make, and I can click links and chase down information, and just keep my stupidly ADHD brain entertained with more and more new new new things. This is how I have to learn things, apparently.

Re: Modern C [pdf]

#393

Post by sidlls »

junke wrote: post #368
sidlls wrote: post #211

Earlier quoted context omitted.

C makes it trivial to implement poorly, though. (Note: I'm playing devil's advocate here to some extent. My view is that safety is important, but lack of provable safety is not some terrible Demogorgon that we should hide in fear from. I think a lot of the concern over safety is valid, but in some contexts it's just overhyped.)

My view is that lack of provable safety should be resolved by defensive code (runtime checks). And then, you are safe (if safety is important in your code, which probably should by default in a professional setting).

I agree, it is solvable by defensive code. The vast majority of the time that code is perfectly sufficient. The number of people who don't die when the hundreds of thousands of things that don't go wrong when an embedded C-program doesn't crash or blow apart because of memory safety bugs daily demonstrates this. I don't think people understand just how much of our world is run, quite literally, by "not provably safe" code. It's not just C and C++, either.

Which is one reason why I don't buy the "memory safety" argument as a very strong one for adopting Rust. There are other much better reasons to do so for a certain class of programming, in my opinion.

Re: Modern C [pdf]

#394

Post by Retra »

spc476 wrote: post #387
Retra wrote: post #380

Earlier quoted context omitted.

The signature doesn't tell you that. If my API said int frobnicate(char*) and you make that kind of assumption, then your code may or may not work, depending on what the function does internally. You simply do not know whether I am operating on null-terminated char sequences or a single char. >Um ... how do you "happen" to have a pointer-to-char? char* text = "some text"; char* c = text[2] There you go. >And unknowin…

Your response to me shows you don't program in C all that much. I ran your code example through a C compiler and got: a.c:2: warning: initialization makes pointer from integer without a cast a.c:2: error: initializer element is not constant What you really want is: char * text = "some text"; char * c = &text[2]; which still doesn't prove your point because c is still pointing to a NUL-terminated string. If fronnicate…

A single typo doesn't tell you anything about my programming habits.

>which still doesn't prove your point because c is still pointing to a NUL-terminated string.

No, it's pointing at a char that happens to be part of a nul-terminated string. The semantic intent of that distinction is entirely lost because C fails to make a distinction. I could easily overwrite that nul, and it would no longer be the case. Then it's suddenly an array of chars, and everything pointing at it is now a new type of thing.

char* s = (char*) rand();

This also will point at a 'nul terminated string' with very high probability. Doesn't mean it is safe to call string functions on it...

>I might ask why the function requires a pointer to char for a single character instead of int frobnicate(char)

You could say the same about any pointer argument. Obviously pointers are useful for a reason. If frobnicate returned a char, I would just end up dereferencing a pointer to stick it back in the string it came from. Whether that is frobnicate's job or it's caller's job is a matter of API design, and should not be determined by C, especially when it makes no preference for any other kind of pointer.

>You are also shifting the argument, because in your original comment I replied to, the function you gave was to_upper

My arbitrary example function name doesn't matter one iota. Get over it, and stop being needlessly dense.

Re: Modern C [pdf]

#396

Post by ____nope »

sn9 wrote: post #356
____nope wrote: post #297

Earlier quoted context omitted.

It's hard to teach an introduction to programming without teaching a particular language. If you have to pick a particular language, it makes sense to choose something the student is likely to use in the future. This is not hard to understand.

That's silly. If you can reasonably claim to know how to program, the choice of language largely doesn't matter. Someone who knows how to program in [first language] should be able to pick up how to program in any language one is likely to encounter in an industry position. So the first language should be one that gives the student a firm foundation from which one can become that competent. I've personally seen excel…

My point is that you likely learned programming by learning the basics of file I/O in C or Python or something similar. You didn't sit down and learn all about automata theory etc. first. You need the context of what C.S. is used for before these things make sense to you, so you start by learning a bit of programming. Since you must be definition have A first language, why not pick one that is most likely to be used?
Post reply on HN