Submitted by “Originally published in 1978 and updated in 1988, The C Programming Language is considered a ‘must-read’ classic by most programmers and is generally known simply as ‘K&R’. To mark the publication of an ebook version of the 1988 second edition, we interviewed coauthor Brian Kernighan about the C programming language, the book, and future trends.” And an Oxford comma to boot. The way it should be.
That should be the way to teach programming. The exercises and assignments in programming classes are contrived and boring and not very pedagogical.
Nothing makes you learn better than by implementing standards, etc. I feel like I learnt more about programming by implementing stuff from standards, like a PDF parser, a DEFLATE decompressor and an HTTP/1.1 server than anything I had to write in university.
It also teaches you how to read documentation and figure out the author(s) intentions and implied requirements, and thus how to be better at technical writing and communication in general.*
* Seriously, has anyone tried to implement DEFLATE from the RFC? It is one of the least readable standards I know of.
Agreed. Not only would it be less boring, but some of my best low-level learning has come from implementing and optimizing a pure Python metadata-extracting GIF parser.
(I’m primarily a Python and PHP programmer, but the only existing Python imaging libraries decoded the entire image into memory when all I wanted was to check whether the GIF was animated, maybe count frames, and maybe do a quick, superficial corruption check.)
In fact, python -m cProfile -s cumulative gif.py … was where I got clued into how expensive syscalls are… and I’d already taken the entry-level and C/C++ programming courses my University offered.
(Sadly, I’d also read K&R when I had to make that discovery myself. It’s an excellent book but makes the assumption that some other resource has already taught you things like what a buffer overflow is and why it’s bad.)
Edited 2012-10-03 09:37 UTC
The biggest problem with RFCs is they usually don’t give a good introduction so people with no knowledge on the subject can’t wrap their mind around it.
In other words, a lof assume (deep) knowledge of other things.
Edited 2012-10-03 11:24 UTC
If you think that’s bad, try to write a program that outputs a bare-minimum font in OTF format (that will show up with the right names on more than one OS). It’s all written by people who assumes the readers will already know the general idea, none of the standards agree (or even address) what parts are optional vs. required, and certain parts (CFF, I’m looking at you) are horribly obtuse – not to mention that you have to guess which random old adobe-produced reference it’s actually documented in.
(And don’t get me started on the variable-length integer encoding used only in the CFF block. )
Edited 2012-10-03 12:33 UTC
You’ve piqued my interest and I’ll probably try it. I pretty much have the same experience with the PDF parser, in that Adobe “standards” “documentation” is really poor and all over the place.
The good thing about RFCs is that they do make it easy to look for references.
It’s immensely satisfying when it finally works, so go for it.
Admittedly, that’s true for any project where you can validate your code against existing real-world implementations – there’s a moment of joy the first time you actually manage to parse an image/the ELF headers/what have you – and the first time you make a font file that appears with the right names in all OSes.
Tip: Microsoft’s font validator made things easier. ( http://www.microsoft.com/typography/fontvalidator.mspx ). I still haven’t found anything that will validate the CFF block, though – and that’s the messiest part.
Edited 2012-10-04 08:26 UTC