introduction.tex

\chapter*{Introduction: The Cartesian Dream Of C}

\begin{quotation}

Whatever I have up till now accepted as most true and assured I have gotten
either from the senses or through the senses. But from time to time I have
found that the senses deceive, and it is prudent never to trust completely
those who have deceived us even once.

    \attrib{Rene Descartes, Meditations On First Philosophy}
\end{quotation}

If there ever were a quote that described programming with C, it would be this.
To many programmers, this makes C scary and evil.  It is the Devil, Satan, the
trickster Loki come to destroy your productivity with his seductive talk of
pointers and direct access to the machine.  Then, once this computational
Lucifer has you hooked, he destroys your world with the evil "segfault" and
laughs as he reveals the trickery in your bargain with him.

But, C is not to blame for this state of affairs.  No my friends, your computer
and the Operating System controlling it are the real tricksters.  They conspire
to hide their true inner workings from you so that you can never really know
what is going on.  The C programming language's only failing is giving you
access to what is really there, and telling you the cold hard raw truth.  C
gives you the red pill.  C pulls the curtain back to show you the wizard.
\emph{C is truth.}

Why use C then if it's so dangerous?   Because C gives you power over the false
reality of abstraction and liberates you from stupidity.


\section*{What You Will Learn}

The purpose of this book is to get you strong enough in C
that you'll be able to write your own software in it, or modify
someone else's code.  At the end of the book we actually take
code from a more famous book called \krc and code review it
using what you've learned.  To get to this stage you'll have to
learn a few things:

\begin{enumerate}
\item The basics of C syntax and idioms.
\item Compilation, make files, linkers.
\item Finding bugs and preventing them.
\item Defensive coding practices.
\item Breaking C code.
\item Writing basic Unix systems software.
\end{enumerate}

By the final chapter you will have more than enough ammunition
to tackle basic systems software, libraries, and other smaller
projects.


\section*{How To Read This Book}

This book is intended for programmers who have learned at least one other
programming language.  I refer you to
\href{http://learnpythonthehardway.org}{Learn Python The Hard Way} or to
\href{http://ruby.learncodethehardway.org}{Learn Ruby The Hard Way} if you
haven't learned a programming language yet.  Those two books are for total
beginners and work very well.  Once you've done those then you can come back
and start this book.

For those who've already learned to code, this book may seem strange
at first.  It's not like other books where you read paragraph after
paragraph of prose and then type in a bit of code here and there.  Instead
I have you coding right away and then I explain what you just did.
This works better because it's easier to explain something you've 
already experienced.

Because of this structure, there are a few rules you \emph{must} follow
in this book:

\begin{enumerate}
\item Type in all of the code. Do not copy-paste!
\item Type the code in exactly, even the comments.
\item Get it to run and make sure it prints the same output.
\item If there are bugs fix them.
\item Do the extra credit but it's alright to skip ones you can't figure out.
\item Always try to figure it out first before trying to get help.
\end{enumerate}

If you follow these rules, do everything in the book, and still can't
code C then you at least tried.  It's not for everyone, but the act
of trying will make you a better programmer.

\section*{The Core Competencies}

I'm going to guess that you come from a language for weaklings \footnote{If you
can't tell, I'm just teasing you.}.  One of those "usable" languages that lets
you get away with sloppy thinking and half-assed hackery like Python or Ruby.
Or, maybe you use a language like Lisp that pretends the computer is some
purely functional fantasy land with padded walls for little babies.  Maybe
you've learned Prolog and you think the entire world should just be a database
that you walk around in looking for clues.  Even worse, I'm betting you've been
using an IDE, so your brain is riddled with memory holes and you can't even
type out an entire function's name without hitting CTRL-SPACE every 3
characters you type.

No matter what your background, you are probably bad at four skills:

\begin{description}

\item[Reading And Writing] This is especially true if you use an IDE, but
    generally I find programmers do too much "skimming" and have problems
    reading for comprehension.  They'll skim code they need to understand
    in detail and think they understand it when they really don't.  Other languages
    provide tools that also let them avoid actually writing any code, so
    when faced with a language like C they break down.  Simplest thing to
    do is just understand \emph{everyone} has this problem, and you can fix
    it by forcing yourself to slow down and be meticulous about your reading
    and writing.  At first it'll feel painful and annoying, but take frequent
    breaks, and then eventually it'll be easy to do.

\item[Attention To Detail] Everyone is bad at this, and it's the biggest cause
    of bad software.  Other languages let you get away with not paying attention,
    but C demands your full attention because it is right in the machine and the
    machine is very picky.  With C there is no "kind of similar" or "close enough",
    so you need to pay attention.  Double check your work.  Assume everything you
    write is wrong until you prove it's right.

\item[Spotting Differences] A key problem people from other languages have is 
    their brain has been trained to spot differences in \emph{that} language,
    not in C.  When you compare code you've written to my exercise code your
    eyes will jump right over characters you think don't matter or that aren't
    familiar.  I'll be giving you strategies that force you to see your 
    mistakes, but keep in mind that if your code is not \emph{exactly} like
    the code in this book it is wrong.

\item[Planning And Debugging]  I love other easier languages because I can
    just hang out. I type the ideas I have into their interpreter and see results immediately.
    They're great for just hacking out ideas, but have you noticed that if you
    keep doing "hack until it works" eventually nothing works?  C is harder on
    you because it requires you to plan out what you'll create first.  Sure,
    you can hack for a bit, but you have to get serious much earlier in C than
    other languages.  I'll be teaching you ways to plan out key parts of your
    program before you start coding, and this will hopefully make you a
    better programmer at the same time.  Even just a little planning can smooth
    things out down the road.
\end{description}

Learning C makes you a better programmer because you are forced to deal with
these issues earlier and more frequently.  You can't be sloppy and half-assed
about what you write or nothing will work.  The advantage of C is it's a
simple language you can figure out on your own, which makes it a great language
for learning about the machine and getting stronger in these core programmer
skills.

C is harder than some other languages, but that's only because C's not hiding
things from you that those other languages try and fail to obfuscate.

\section*{License}

This book is free for you to read, but until I'm done you can't distribute it
or modify it.  I need to make sure that unfinished copies of it do not get out
and mess up a student on accident.