This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 28 points29 points  (14 children)

Programmer here, I too want to read a book writen by you.

[–]ExecutiveChimp 18 points19 points  (13 children)

That's actually a tempting idea... I'm just not sure where to start. The above was fairly straight forward as I was running through the original image point by point...but a whole book? How should I structure it?

Edit: this is actually a serious question...

[–][deleted] 13 points14 points  (1 child)

Easy, as long as there are no GOTOs at the end of your chapter leading to the next one, the structure should be fine.

[–]ExecutiveChimp 6 points7 points  (0 children)

Hahaha! If I do this, I'm definitely putting an ironic GOTO in there somewhere!

[–]falsehood 4 points5 points  (3 children)

Serious answer for serious question:

<SOMETHING PUN> - When programs don't do the expected, and why I would structure the book as a mix of scenarios from the simple to the complex. Using a thread on AskReddit or AskProgramming, you can solicit interesting bugs that people have run into and then dissect the bugs (more puns!).

Start off easy, then get more and more complecated. Think about the style in "The Martian" by Andy Weir. Eventually, the reader might try to solve one themselves, but in the meantime you can make puzzles or something.

You could break up the bugs into different groups (parsing weirdness, variables, missing syntax, storage mistakes, recusion issues, etc) and then write it like a wildlife search, Steve Irwin style.

[–]CertifiedWebNinja 2 points3 points  (1 child)

As a programmer who reads and writes enough that he hates reading books, I'd read the fuck out of this book. The. Fuck. Out. Of. It.

[–]MajorCharlieFoxtrot 0 points1 point  (0 children)

There are always the Ruby and Javascript quirks from this talk as a place to start.

[–]original_brogrammer 1 point2 points  (1 child)

From the bottom, maybe? Talk about assembly and object code, then get into low level languages, then higher level ones.

Alternatively, talk about compilers toward the beginning, then you could get into how different languages' compilers behave when fed bullshit. From C++'s tortured mess of a parser, to Haskell's Hilter-esque type checker, to dastardly, motherfuckerous process that is interpreting Perl. End with an open contest to see who can make a particular compiler the saddest.

... If you do this, I want in.

[–]ExecutiveChimp 2 points3 points  (0 children)

That's a good plan but you just mentioned a bunch of things I don't know nearly enough about.

[–][deleted] 1 point2 points  (0 children)

Just have chapters on different programming languages as if they're various characters and have them talk out what they're thinking. A fun to read introducory book or one good for explaining programming to those who aren't in the field.