Live data from Hacker News

Learn C The Hard Way by Zed Shaw

udemy.com

41–50 of 100 posts

Re: Learn C The Hard Way by Zed Shaw

#41
post #36
post #32

Earlier quoted context omitted.

memcpy is just fine because it has a size parameter. I think you mean strcpy(), which does cause defects.

Yes I guess that would be more appropriate. Again, it comes down to the "give it the right inputs" argument. At some point you have to trust the user of the function to call it correctly.

Well I explain all the many reasons this is the wrong way to think about it in the end.

Re: Learn C The Hard Way by Zed Shaw

#42
What I really like about LCTHW (after reading K&R and then just not doing anything with it) was starting you out using the tools and best practices right from the beginning. Make and valgrind up front. It got me over the hump of syntax&language --> actually using.

Re: Learn C The Hard Way by Zed Shaw

#43
post #40

Earlier quoted context omitted.

I watched the intro on udemy. Very cool. You talked about installing xcode. For newer osx versions, people may be able to install just the [command line tools for xcode][1], which is only about 170MB or so. It might save some people from waiting around for the full xcode. [1]: http://kennethreitz.com/xcode-gcc-and-homebrew.html

Yes, I have to update to point people there. Apparently also the latest xcode is missing a bunch of stuff people might need and requires separate downloads of those pieces. I forget what but it's still annoying.

I think the command line tools are now installed (and downloaded) from inside excode once you have xcode installed. Certainly an irritant.

Just looked at it:

  preferences -> downloads -> command-line-tools

Re: Learn C The Hard Way by Zed Shaw

#44

I was wondering how this compares with or compliments K&R, when I came across [this section][1] of the book that seems to slap it in the face. Here's a section from the second paragraph: You see, "K&R C" is actually riddled with bugs and bad style. Its age is no excuse. These were bugs when they wrote the first printing, and the 42nd printing. I hadn't actually realized just how bad most of the code was in this book…

Just a little something that irked me:

Guitar however is a weird instrument that doesn't really work with notation, so guitarists have an alternative notation called "tablature".

This is incorrect. Guitar works perfectly fine with standard notation. It may be somewhat difficult to figure out fingerings if the music isn't arranged for guitar, but it's not much harder than playing piano without fingering information. I agree with the overall analogy (that tablature is initially easier than sheet music, but ultimately restrictive), though.

Re: Learn C The Hard Way by Zed Shaw

#45
post #44

I was wondering how this compares with or compliments K&R, when I came across [this section][1] of the book that seems to slap it in the face. Here's a section from the second paragraph: You see, "K&R C" is actually riddled with bugs and bad style. Its age is no excuse. These were bugs when they wrote the first printing, and the 42nd printing. I hadn't actually realized just how bad most of the code was in this book…

Just a little something that irked me: Guitar however is a weird instrument that doesn't really work with notation, so guitarists have an alternative notation called "tablature". This is incorrect. Guitar works perfectly fine with standard notation. It may be somewhat difficult to figure out fingerings if the music isn't arranged for guitar, but it's not much harder than playing piano without fingering information. I…

Huh, really? I always figured piano had an unambiguous mapping from pitch to keys, whereas guitar typically has 2 or 3 possible fingerings for a given pitch. I find it pretty easy to get stuck with awkward positions on my first few times through a guitar piece--except those in which transitional notes are annotated with fret positions. Is that what you mean by "arranged for guitar"?

Re: Learn C The Hard Way by Zed Shaw

#47
post #25

Earlier quoted context omitted.

That page has examples and detailed explanations to support the criticism.

The problem is that the examples and explanations don't justify the level of castigation. Yes, you should always use strncpy() instead of strcpy() for instance, but that doesn't protect you from all bugs. The example of a safercopy() still relies on the assumption that the pointers given to it are valid, and that assumption is just as impossible prove as the assumption that copy()'s input strings are valid. Safercopy…

Criticizing individual library functions independently from the language as a whole seems fair to me.

Re: Learn C The Hard Way by Zed Shaw

#48
post #31

Just a warning to everyone, like the book this course is in development as I write the book. It's covering a lot of the chapters, but I have to go back and clean up some videos and do the final ones. That's why the price is low for now.

What's your method for making the ePub version of your books? I'm considering writing a custom program for my own stuff, but I'd love to be able to use something off the shelf.

Re: Learn C The Hard Way by Zed Shaw

#49
post #32
post #29

Earlier quoted context omitted.

It's a bit like claiming memcpy() is bugged because it can crash your program. Well, true, it is good style to program defensively against memory corruptions, buffer overflows etc, and in that respect K&R may teach students bad habits. I think it's a bit much to say that it should never have been written like that, as at the time people knew so much less about building complex projects, sources of error and defensive…

memcpy is just fine because it has a size parameter. I think you mean strcpy(), which does cause defects.

Nah, memcpy shouldn't exist (just not for buffer overflow reasons). memcpy is there because someone got their knickers in a twist over possibly being a few cycles faster than memmove, even though the chances that actually matters is tiny, while the chances that you'll accidentally use memcpy when your memory overlaps is much larger.

Re: Learn C The Hard Way by Zed Shaw

#50
post #45
post #44

Earlier quoted context omitted.

Just a little something that irked me: Guitar however is a weird instrument that doesn't really work with notation, so guitarists have an alternative notation called "tablature". This is incorrect. Guitar works perfectly fine with standard notation. It may be somewhat difficult to figure out fingerings if the music isn't arranged for guitar, but it's not much harder than playing piano without fingering information. I…

Huh, really? I always figured piano had an unambiguous mapping from pitch to keys, whereas guitar typically has 2 or 3 possible fingerings for a given pitch. I find it pretty easy to get stuck with awkward positions on my first few times through a guitar piece--except those in which transitional notes are annotated with fret positions. Is that what you mean by "arranged for guitar"?

The mapping from pitch to keys is (generally) clear, but what isn't clear unless you are fairly skilled is the mapping from keys to fingers. eg:

    Beat 1: root-position C-Major triad (C,E,G) fingers: (1,3,5)
    Beat 2: first-inversion a-minor triad (C,E,A) fingers: (1,3,?)
If the pattern is legato or fast and you can't lift up your hands, playing both G and A with the 5th finger will be difficult for most players. The easy solution is to finger the first triad with (1,3,4) or (1,2,4) so you can move 4 to 5. The latter being preferred if possible, to reinforce the weak 5th finger. (1,2,5 is probably the most natural fingering for the a-minor6 triad)

This is a trivial example, of course. With real music it's usually much more complicated and learning how to handle fingering challenges is one of the more important things you learn as a student of piano. Even classics often have fingering suggestions included, if not by the original composer than by subsequent editors.

Post reply on HN