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 and recommended it to many people. After reading through it for just an hour I decided that it needs to be taken down from its pedestal and relegated to history rather than vaunted as state of the art.
This seems a bit hyperbolic to me... I just read K&R several years ago during school (could definitely use a re-read) but remember absolutely loving it for the combination of brevity and density of information conveyed. I'm not much of a C programmer though so I don't really know. Could a modern C programmer respond / elaborate?
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 programming.
Keeping a book up to date takes a lot of effort, as I'm sure Zed (npi) appreciates. It's an old book, it has warts. As you stated, the density of information was what many people like about the book, so any replacement for it will have to replicate that. I don't think the criticism is unfounded though.
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.
actually that justification for memcpy is quite poor. usually, performance wise, it is quite easily beatable once you start using the hardware. most implementations I've seen loop byte copies in the most naïve way possible... almost every architecture supports 32-bit copies, most support more... :)
incidentally I've saved some .2-.8ms per frame in a "AAA" (I use the term loosely and with disgust) game title by replacing compiler generated assignment operator in one struct with an explicit 128-byte copy. copying individual bytes is slow, and the compiler is never as sufficiently smart as people claim.
in analagous cases involving memcpy, the fact that memcpy is not memmove saves much less than actually copying the data in a way that squeezes everything out of the data buses. :)
"almost every architecture supports 32-bit copies"
How much of that was true at the time that function was created?
Also, on 'just use memmove': it would not surprise me if ancient Unices used memcpy instead of inlining it to copy really small buffers (such as 14-byte-max filenames), not for speed, but for the byte savings (even if singular 'byte' is the correct way to phrase that). With small buffers, the overhead of that 'if' can become substantial.
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.
Your argument with permutations of inputs is wrong IMO - this argument can be used to claim that any functionality which calls user code (through callbacks, inheritance, whatever, functors) is also defective. Strictly it may be so, but the defectiveness is massively outweighed by the convenience - the most obvious example is calling a late-binding function - but it extends to easier to grasp examples like the C qsort function or EnumWindows in Win32.
Should we not make library calls because the programmer who wrote the library might have, maybe, possibly, screwed us over in some way perhaps, or because the mechanism can be broken with faulty input?
You trust, potentially, the same programmers every time you trust an executable loader to start running your code... which is pretty much every single time.
Aren't you as the person providing the application ultimately responsible for knowledge of what library calls work well and, thus, which you should use? I think Zed's cautionary statements are merely summarizing a bunch of his experiences, ultimately that this library call isn't worth using.
Permutations of input is not "wrong", its a valid mechanism for exposing unexpected/undefined behavior. "Massively outweighed by the convenience" is subjective and, in many circumstances, very suspect.
Your argument does not follow and is an illogical extension. I simply prove that it has a while-loop that won't terminate and use permutations to prove that. The logic proof is valid because I found an instance of the input that would cause it to not terminate.
You can't then extend my argument to mean that all functions should not be called. All functions with unterminated while-loops shouldn't be called, but not all functions.
I remember the gist of the critique being that the K&R book was perfect for the assumptions of its era, but can mislead people who aren't experienced enough to apply its lessons to the modern networked world
heh heh. Who would have expected mercy and respect from the guy that made the (paraphrased) "pro-mo-fo" website (first saw it at Atlassian conference about 2 weeks ago, pretty funny though perhaps a bit rude). I think the guy is more than willing to point out any practices now deemed harmful, tradition be damned. I'm over it.
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.
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"?
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.
No problem. I can't comment much on the initial comparison between tablature and fingering since I don't read tablature or more than the very basics of guitar.
It is true that if you map in the reverse direction, tablature can represent playable music even if it's not particularly expressive, while piano fingerings can not. (Well, I suppose you could write music with only piano fingerings and let the performer improvise, but I'm sure that's not the point of this discussion :)
Yes, string number/finger number positions are what I was referring to. And, as Goladus pointed out, getting stuck in those awkward positions definitely happens on piano, too.
No, it doesn't. Go find middle C. See how on the piano it's in the middle of the piano, and also in the middle of the grand staff? Now, find one of the many on the guitar. Not really in the "middle" are they? Even the left and right hand and the grand staff fit better. The location of submediant, inversions, arpeggios, distance in intervals, all map better on a piano than a guitar.
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() is still twice as safe as copy() and we ought to use it, but calling copy() "defective" is unfair unless you're willing to call the C language defective in general. And you can make that argument! I certainly like languages like Go that have pointers but no casting ints to pointers or pointer arithmetic, so the only remaining danger is pointers to memory that has been freed.
"Yes, you should always use strncpy() instead of strcpy() for instance, but that doesn't protect you from all bugs."
I agree with your argument, but I don't enjoy encouraging programmers to use strncpy and co... the reason is simple, I don't want to encourage programmers to stop thinking about their code. Not having to think about something is great, when laziness is acceptable (RAD, web development etc.) but not in the general case...
Most of the time, the programmer should be smart enough to not fall foul of the problems strncpy avoids. The argument against the copy function in "learn C the hard way" implies that the programmer doesn't understand the code, language, or platform particularly well...
Mine is a fundamentally flawed argument though... as much as I want to live in a world where people can write code properly, the truth is idiots will always be out there. Although, as such, I would rather my code did shoot them in the foot if they were stupid enough to load it up and point it that way before firing... :)
The knowledge is esoteric to what is being done. I know its convenient to believe so, but there are smart people that make mistakes. Misusing one of these methods isn't discouraged because its obvious, its discouraged because it fails in non-obvious ways. Ways that have probably cost humanity many man years of development time.
You're saying that the language should make the programmer's job harder, and that it's a mark of laziness to try to arrange things to make common mistakes less likely?
Human brain has very limited bandwidth. The more irrelevant bs it has to deal with, the less effective is in solving actual problems.
It's surprising that people otherwise living day and night dealing with bandwidth and capacity issues of software systems ignore their own limits on bandwidth and capacity and are willing to put up with random bs in the name of some macho industriousness.
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.
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.
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.
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.
I'm ditching ePub. It's a crap format that has a bewildering number of options and it seems every viewer wants to implement some different subset of them.
Glad to hear it. When people ask me about ePub/Mobi, I tell them that both formats are broken and that if I ever produce them it'll only be as a stupid marketing gimmick.
What we really need is a format that works across different devices. If only there were a portable document format that solved this problem...
This is a limitation of the device, not the format. Why do people expect to be able to read heavily formatted books on every device they own? For books made up mostly of natural language text, this might be a reasonable expectation, but technical books have a different set of design constraints that make them ill-suited to general e-readers.
This is a limitation of the device, not the format.
No it's not. The kindle works fine for programming books, I'm currently reading Bjarne's "The C++ Programing Language" on my kindle, on PDF actually. The book itself lies on my bookshelf but why would I bother to open it?
The PDF isn't tailored for the kindle but it has wide enough margins so that when you crop it it works quite well on the kindle. The kindle is not the limitation nor the problem.
The problem is rather the crippled format that you get in a fullsize PDF. What exactly are you going to read it on? Print it out? (seriously?). On your monitor? Not really... On your tablet? You're joking right, reading a book on a glossy LCD?
Having a book as a PDF is quite useless for other than using it as a reference.
Now I don't know about any potential issues with epub/mobi, and honestly I couldn't care less in this case. The site mentioned (and still does) that an ePub will be available and if so I kind of expected an ePub version of it, in my eyes that was an incentive to take the course.
If that isn't going to happen an ~A5 PDF will work great too, since there actually exist devices that you can read it on comfortably.
And I kind of have a hard time to see why the book, as it is portrayed in the HTML-version wouldn't be able to work as an epub - but OK, if that's the case (or if epub truly is just a mess) that's surely not the case for a portable-device-friendly-PDF.
Also, it really cracks me up to see someone talk about broken formats and in the same post make an argument for PDF.
What you mean is that heavily formatted books don't look good on Kindles. There's no general mapping from publication-quality documents (as supported by PDF) to crippled formats like ePub and Mobi. The problem is the device—or, rather, your expectations regarding the device—and not the format itself.
In case one does not want to spend $29, the free HTML book [1] (currently in beta) is good enough. I have been following along the book, and can vouch for it. It is a great way to learn to code in C.
EDIT: By posting the link to the book, I by no means meant that the videos are redundant. I would love it if more people en-roll for Zed's Udemy course and support him.
You can also compile the book into a PDF if you'd like. Zed made the code available so all it takes is the effort involved to install the right LaTeX modules.
Took part of an afternoon to figure out how to build it.
Zed Shaw has made the book available for free. It's perfectly acceptable to point that out (indeed, it's linked from the udemy summary anyway). If you need more than the book, you can pay for the course. This is why it is labelled a "companion". There is nothing morally bankrupt about using the resource that has been graciously given away for free: it seems evident that Zed Shaw intended the book to be free, so use that fact. If you need more, he believes it's worth $29 of your money to access the additional materials.
There's a really good argument to be made if the OP were linking to a bootlegged free version of a book that costs money, but it's really silly to criticize him for pointing out the free version of the free book on the thread about its companion course.
If the video course were free, what would you be willing to pay for additional course materials? (i.e. the book, exercise solutions, exclusive live sessions, etc.)
I'm not trying to be confrontational here. Online education/coursework/learning needs a pricing structure that makes sense. One that enables thousands of qualified instructors to participate without going broke in the process.
I think I understand Zed's "freemium" model in that context. But I disagree with his approach.
Our local high school district pays some teachers over a $100,000 a year. That's 3,448 students at $29 each -- per year. That's roughly equivalent to the entire student population!
Well, the course is just cheap now because it's in-progress. This lets me get it out for immediate feedback, find bugs, and test that it works with students. In the near future the price will change, but the HTML version will most likely still stay up because answering student questions in comments makes the book so much better.
Generally, a teacher making $100,000 teaches about 125. That's $800.00 per student per year (aprox. $5.00 per student per day). Teaching 30,000 requires a completely different infrastructure. @ $29.00 each, that's $870,000 per year -- roughly 6 teachers plus support staff.
5,000 students per instructor.
My point in all of this is that free is not free and that those who are willing to build courses and content at this scale need to be compensated somehow for their time.
Being able to make a living will draw more people. More instructors, more classes, more choices, better classes, better content, etc.
This is important point that seems to be missing from the online education discussion.
"Generally, a teacher making $100,000 teaches about 125."
Only if you count all the classes they teach every day. However, kids don't come to school for just one class a day. Each teacher gets 15 to 30 kids 8 times a day for 1/8th of the day (assuming 8 classes a day). Not that that's really the important point here...
"My point in all of this is that free is not free and that those who are willing to build courses and content at this scale need to be compensated somehow for their time."
He is getting compensated though. At $29.00 a pop. The fact that he puts free material out there will almost definitely raise his compensation, not lower it.
"More instructors, more classes"
You don't necessarily need or want this. If one teacher can teach xx,000 people in a given subject, the teaching market will start to resemble a more 'winner take most' market, allowing those who aren't as good at teaching to find use elsewhere.
It will also allow everyone to learn from the best instead of only 125 people who happen to be in the right school district.
Disruption happens when someone demonstrates that the existing system is flawed by creating a better system. It will cost what it costs. You sound like a traditional publisher complaining that they can't charge $20 for schlock and abuse authors anymore.
It amazes me that people invest 20 hours in reading a book and complain about the price. If we assume roughly $40/hr for a $80k programmer, this is about $800 worth of time you're investing. Does a "hard" investment of $29 (4%) really make that big of a difference?
I always use “let's assume roughly X/hour” as a joke.
You don't get paid for your spare time, except in opportunity cost. If someone applies 20 hours of their time at work, then yes, that's pocket change. If they apply 20 hours of their time at home, that's not time that they'd get paid for anyway, so the analogy is as foolish as the claim that every pirated copy of a movie would have been bought were it not for pirates.
Instead, I'm choosing between 20 hours of reading a book and maybe 20 hours of watching television (for example), which costs the electricity that the television consumes (since the cable or internet is paid for already). I suspect you'll find 20 hours of TV will cost less than $29. Or maybe it's 20 hours of running over the course of a couple of weeks. That's free, except maybe for the cost of the water to rehydrate. That's probably cheaper than $29, too. If you want to do the analysis in terms of how much it will earn you in the future, that's also valid I guess. But it complicates things, since it's hard to quantify how much the relaxation you get from watching TV or destressing from running is worth.
Let me just say, I don't think people should complain about the price of a good book when it's <$50-100 (depending on material). But the X/hour analogy only works if you're taking work time, and then many companies will often be willing to refund you that money anyway.
Last note: this isn't $29 for a book. It's $29 for a video course (though admittedly a non-HTML version of the book is thrown in at the end). The book itself is available for free, which is all that the OP was pointing out.
>You don't get paid for your spare time, except in opportunity cost.
Your free time is clearly worth more than your wage/salary. If your free time were worth nothing, it would make no sense to have it. You have extra time you could get another job possibly paying up to your existing rate.
Don't like the thought of taking a second job doing what you're doing now? That's because your time is worth more to you than that cash, by definition.
True, but by working for "roughly X/hour" you've established that the typical exchange rate for your time is roughly X/hour. If I were to ask you to do some work for my during your off time, I would have to pay about X ± X/2 depending on how you guarded your time. So what if someone only values their time at X/4? That's still $200 worth of spare time.
That's fair, if we're continuing a monetary analogy (which I did do).
My spare time is worth happiness/distraction to me. Not money. I will confess that in that particular regard, I may differ from some, or perhaps even most, others.
Doesn't make much sense anyway. So you make $40/hr, 40 hours a week. Well there is 168 hours in a week, subtract 40 from that and you have 128 hours those 40 hours must pay for.
As if that wasn't enough you have a lot of expenses that are flat-rate that you must pay regardless of how you spend your time (such as your rent).
All this is further assuming that your goal is to spend everything you make every month. Most probably put away some money to be able to buy a new car, travel etc. (or even just to be able to repair the car when it breaks)
by working for "roughly X/hour" you've established that the typical exchange rate for your time is roughly X/hour
Well, I've established that I'm willing to work that many hours for that rate. That doesn't mean I'm willing to work more hours at the same hourly rate. Most people I know value their spare time enough to expect a higher rate for working more time.
Maybe it's more about the absolute value of something than its relative value. These days, 29$ is a lot for me. That is not a statement that the book is too expensive or that I don't give it the value it deserves.
For what it's worth I plan to read the online beta then print out a bought PDF for easier reading.
I just scanned through the free HTML book and this looks definitely a good start for a modern "get started fast" book about C: everything is important about the language seems to be covered. Good work.
I'm excited - Learn Python the Hard Way completely jumpstarted me into what has become a large internal django site, and I refer back to it often. I really enjoy python, and I thank Zed for the straightforward aproach.
So even though I love python I want to see if the same technique can introduce me again to C, a language I never felt comfortable with.
No, I'm fully blocking and moderating comments. They are for serious students who need help, not drive-by netizens. In the past I had them open, but after the first two hits by HN or reddit I had to lock it down so that students wouldn't get thrashed.
FWIW i signed up to your udemy course, but I don't particularly feel like making a disqus account to also comment on the book, that's what's bothering me. I guess I will just abstain from commenting though, it's fair enough.
Learn Python the Hard Way is great, although I can't say I've read that many Python books, but I though his approach was a very good way to learn Python.
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.
I disagree with your disdain for IDEs... I hope that you are not totally misleading the people who will learn from your book because learning how to use the capabilities of Visual Studio or any decent IDE is very valuable. How are they going to debug complex graph data structures in their CS class if they don't have a great debugger? How are they going to understand the power of intellisense in modern programming? How are they going to learn about compiler flags without getting a headache? How much time are they going to waste compiling and linking with the commandline?
I like the no-copy-paste and straight notepad approach trust me. It works for everyone, it's a solid way to get these things into your brain. You need to write code, there's no way around it. But to tell people to never use IDEs because they are bad and they make you a bad programmer is BULLSHIT.
IDEs are bad for you. It's much better to simply use a real programmer's editor that you can craft into being what you need. In fact, I can usually take vim plus cscope, exuberant ctags, and ack and demolish any code base you throw at me. Similar with emacs and other power editors.
IDEs are usually useful if you're stuck using them to build GUIs or use specialized build tools they require.
Please dear wizard, here's a list of requirements for a fellow programmer that he can currently do with Visual Studio and wants to do the same with vim:
- find in files (in vim, not in bash)
- replace in files
- rename symbol (uh-oh...)
- quick open file in project (visual assist feature)
- list of files in project (not in directory)
- build system (something easy to use, not that make bullshit)
- go to declaration/definition ( sometimes I get a list of 30 matches from ctags, so I would like something that actually works )
- view call hierarchy (callers, callees)
- code completion (something that works and is easy to use, like in visual assist)
- watches
- breakpoints in disassembly
- step into disassembly
- memory view while debugging
- edit & continue
- memory (data) breakpoints
We're talking about large C/C++ codebases, obviously. You might get 50% of the features above after tinkering for a few days/weeks/months with your vim with (probably) much worse usability, when you could have used Visual C++ from the get-go and enjoyed a "real programmer's editor", as you put it.
This bullshit religion you are introducing only hurts potential programmers because instead of focusing on getting their job done they have to reinvent the wheel every time they have to write a line of code. I'm not saying it's a bad thing for a young mind to experience the horror of having to debug a 500.000 LOC codebase with a stone-age debugger, just for the kicks ("that's how your old man was programming back in the day, son"), but when you have to meet deadlines and release something going vim-only can quickly become a liability.
Sadly in Linux you don't have the luxury of Visual Studio and I've tried doing portable C/C++ in Windows (with cygwin and various make programs). It just doesn't work right.
But I agree with overall sentiment. We shouldn't try to make programming hard. It is hard already.
I do all of this with just vim and some tools, and I do it with any language, any text, anywhere on any machine in and OS without having to buy anything from anyone and I can change how all of it works any time.
How can IDE be bad for me? It's like saying a hammer is bad for me (Sure it is if I don't use it responsibly or correctly). And on C front I'd agree. There are no really good IDEs for C/C++ and the way they work/are used wouldn't benefit much from an IDE.
If you are more productive in IDE over text, what is the benefit of using text editor?
and what would they do if they cannot use this functionality, for example debugging something embedded, or something that cannot be debugged the way you pointed out
Nevertheless, Zed is helping lots of people out there who is eager to learn coding like me, I could imagine back in the days if you want to learn coding there are tons of resources out there, probably too many, that you don't know which one is good and it cost you money. Now, people like me can always go to his book finish the course and look for what is missing without spending a buck.
The video course is being worked on by me while I write the book, so expect it to be rough around the edges.
But, I say try going through the HTML version online, and as you do get stuck write comments to ask me questions. That's why I put it online for free, so that I get student feedback while I write the book.
Harvard's CS50 (cs50.net) is an introductory computer science course that teaches C. Full course (lecture videos + problem sets) is available free online.
It's funny how, I started getting annoyed seeing people still learning to code on books while free tutorials were starting to pop up everywhere on internet.
And now people are starting to charge for those tutorials. And I know people here in HN love Zed Shaw. But come on, there are hundreds of free great tutorials to learn C on internet.
I did look at this book a while ago, I was unable to make amendments to the code examples. early versions made common C gotcha mistakes, although of the more subtle and less disasterous kinds... starting with non-standard entry-point function signature and generally relying on non-standard features of particular compilers. fortunately someone else seems to have gotten there in the end... i'd be wary, simply because the author is (as much as I am a fan of much of his work) clearly not an experienced C programmer.
I am a very experienced C programmer, and I have full comments on any page. You find an error, drop a comment and I'll fix it immediately.
Chances are though, you're someone who read the K&R chapter, then went through nitpicking minor semantics about things like "NULL is 0" and then consider all the code broken in the book.
But, any errors you find, let me know and I'll fix them. Just don't call me an inexperienced C programmer.
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 and recommended it to many people. After reading through it for just an hour I decided that it needs to be taken down from its pedestal and relegated to history rather than vaunted as state of the art.
This seems a bit hyperbolic to me... I just read K&R several years ago during school (could definitely use a re-read) but remember absolutely loving it for the combination of brevity and density of information conveyed. I'm not much of a C programmer though so I don't really know. Could a modern C programmer respond / elaborate?
[1]: http://c.learncodethehardway.org/book/learn-c-the-hard-waych...