faq.html

<h1>Frequently Asked Questions</h1>

<div class='pull-right alert alert-warning' style="margin: 15px; text-align: center;">
  <img src="/static/img/me.png" alt="me" class="img-responsive" width="224px" height="264px"/>
  <p><small>Me &bull; In the snow.</small></p>
</div>


<h2>Who are you?</h2> <hr/>

<p>Hello, my name is Daniel Holden. I'm from the UK, living in Montreal, and working in the games industry doing research into how Machine Learning how it can help games scale, in particular in the area of Character Animation.</p>

<p>You may know me from one of my other projects such as <a href="http://libcello.org">Cello</a> or <a href="https://github.com/orangeduck/Corange">Corange</a>. As well as hacking on C, I enjoy writing short stories, digital art, and game development.</p>

<p>You can take a look at my <a href="http://theorangeduck.com/">personal website</a>. Or you can <a href="https://twitter.com/anorangeduck">follow me on twitter</a>.</p>


<h2>Why don't you teach arrays in this book?</h2> <hr/>

<p>With an already steep learning curve arrays seemed like a convenient omission to make. Teaching arrays in C is a very easy way to confuse a beginner about pointers, which are a far more important concept to learn. In C, the ways in which arrays and pointers are the same, and yet different, are subtle and numerous. Excluding fixed sized arrays, which have different behaviour altogether, pointers represent a superset of the behaviour of arrays, and so in the context of this book, teaching arrays would have been no more than teaching syntactic sugar.</p>

<p>Those interested in arrays are encouraged to find out more. The book <a href="http://c.learncodethehardway.org/">Learn C the Hard Way</a> takes the opposite approach to me, and teaches arrays first, with pointers being described as a variation. For those interested in arrays this might prove useful.</p>


<h2>Why do you use left-handed pointer syntax?</h2> <hr/>

<p>In this book I write the syntax for pointers in a left-handed way <code>int* x;</code>, rather than the standard right-handed convention <code>int *x;</code>.</p>

<p>Ultimately this distinction is one of personal preference, but the vast majority of C code, as well as the C standards, are written using the right-handed style. This is clearly the default, and most correct way to write pointers, and so my choice might seem odd.</p>

<p>I picked the left-handed version because I believe it is easier to teach to beginners. Having the asterisk on the left hand side emphasises <em>the type</em>. It is clearer to read, and makes it obvious that the asterisk is not a weird operator or modification to the variable. With the omission of arrays, and multi-variable declarations, this notation is also almost entirely consistent within this book, and when not, it is noted. K&R themselves have <a href="http://blog.golang.org/gos-declaration-syntax">admitted</a> the <a href="https://www.bell-labs.com/usr/dmr/www/chist.html">confusion</a> of the right-handed syntax, made worse by historical baggage and rogue compiler implementations of the early years. For a learning resource I believe picking the left-handed version was the best approach.</p> 

<p>Once comfortable with the method behind C's declaration syntax, I encourage programmers to migrate toward the right-handed version.</p> 


<h2>Why are there no Macros in this Lisp?</h2> <hr/>

<p>By far the biggest gripe conventional Lisp programmers have with the Lisp in this book is the lack of Macros. Instead of Macros a new concept of Q-Expressions is used to delay evaluation. To conventional Lisp programmers Q-Expressions are confusing because their semantics differ subtly from the quote Macro.</p>

<p>I use Q-Expressions instead of Macros for a couple of reasons.</p>

<p>First of all I believe them to be easier for beginners than Macros. When evaluation is delayed it is always explicit, shown by the syntax, and not implicit in the function name. It also means that S-Expressions can never be returned by the prompt or seen in the wild. They are always evaluated.</p>

<p>Secondly it is more consistent. It no longer requires the concept of Macros, but instead transforms quoted expressions to become the dominant, more powerful concept that does everything needed by either. With Q-Expressions there are only <em>Functions</em> and <em>Expressions</em>, and the language is even more homo-iconic than before.</p>

<p>Finally, Q-Expressions are distinctively more powerful than Macros. Using Q-Expressions it is possible to pass an argument to a function that evaluates to a Q-Expression, making input arguments capable of being dynamic. In conventional Lisps passing an expression to a Macro will always pause the evaluation, and so the arguments cannot be dynamic, only symbolic.</p>


<h2>Where are the answers to the exercises?</h2> <hr/>

<p>There are none. In the real world no one is going to pass you an answer booklet, or check your work for you. Ensuring your code does as <em>you</em> intended is an essential skill to learn. Some readers ask for the answers because they are concerned that they might not have done <em>the right thing</em>. But testing <em>the right thing</em> in this case is just testing understanding of the question; a pretty pointless exercise. Additionally there is not always a wrong or right way to approach the <em>Bonus Marks</em>. They are intended as suggestions to help people check their understanding, or to explore other ideas and thoughts.</p>

<p>If you want to do a <em>Bonus Mark</em> question but are unsure what it means, feel free to send me an e-mail and I will try to clarify it! Otherwise don't fret over the answer. Giving it a try is the important part, not getting it right!</p>


<table class="table">
  <tr>
    <td class="text-center"><a href="contents"><h4>&bull; Contents &bull;</h4></a></td>
  </tr>
</table>