TITLE: A Good Language Conserves Programmer Energy
AUTHOR: Eugene Wallingford
DATE: August 31, 2013 11:32 AM
DESC: 
-----
BODY:
Game programmer Jeff Wofford wrote
<A HREF="http://www.jeffwofford.com/?p=1495">
   a nice piece</A>
on some of the lessons he learned by programming a game in forty-eight
hours.  One of the recurring themes of his article is the value of a
high-powered scripting language for moving fast.  That's not too
surprising, but I found his ruminations on this phenomenon to be
interesting.  In particular:

<BLOCKQUOTE><EM>
 A programmer's chief resource is the energy of his or her mind.
 Everything that expends or depletes that energy makes him or her less
 effective, more tired, and less happy.
</EM></BLOCKQUOTE>

A powerful scripting language sitting atop the game engine is one of
the best ways to conserve programmer energy.  Sometimes, though, a
game programmer must work hard to achieve the performance required by
users.  For this reason, Wofford goes out of his way not to diss C++,
the tool of choice for many game programmers.  But C++ is an energy
drain on the programmer's mind, because the programmer has to be in
a constant state of awareness of machine cycles and memory consumption.
This is where the trade-off with a scripting language comes in:

<BLOCKQUOTE><EM>
 When performance is of the essence, this state of alertness is an
 appropriate price to pay.  But when you don't have to pay that price
 -- and in every game there are systems that have no serious
 likelihood of bottlenecking -- you will gain mental energy back by
 essentially ignoring performance.  You cannot do this in C++: it
 requires an awareness of execution and memory costs at every step.
 This is another argument in favor of never building a game without a
 good scripting language for the highest-level code.
</EM></BLOCKQUOTE>

I think this is true of almost every large system.  I sure wish that
the massive database systems at the foundation of my university's
operations had scripting languages sitting on top.  I even want to
script against the small databases that are the <EM>lingua franca</EM>
of most businesses these days -- spreadsheets.  The languages
available inside the tools I use are too clunky or not powerful, so
I turn to Ruby.

Unfortunately, most systems don't come with a good scripting language.
Maybe the developers aren't allowed to provide one.  Too many CS
grads don't even think of "create a mini-language" as a possible
solution to their own pain.

Fortunately for Wofford, he both has the skills and inclination.  One
of his to-dos after the forty-eight hour experience is all about
language:

<BLOCKQUOTE><EM>
 Building a SWF importer for my engine could work.  Adding script
 support to my engine and greatly refining my tools would go some of
 the distance.  Gotta do something.
</EM></BLOCKQUOTE>

Gotta do something.

I'm teaching our compiler course again this term.  I hope that the
dozen or so students in the course leave the university knowing
that creating a language is often the right next action and having
the skills to do it when they feel compelled to do something.
-----