[fluxus] Game Oriented Assembly Lisp

[Dave Griffiths]

> I knew it existed, but I didn't know so much about it. Thanks!

interesting bit from this usenet posting:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/79084d68de29126e/dc50739114bc23f0?lnk=st&q=%22Scott+Shumaker%22&rnum=1#dc50739114bc23f0
makes the intent sound a lot like fluxus

  "Well, fast iteration times weren't merely due to the the listener -
   that was a nice touch, but only the tip of the iceberg.  We could
   basically dynamically link per-function or variable.  Effectively,
   you could hit a key while working in the IDE, and whatever function
   the cursor was on would instantly get compiled, sent across the
   network to the TOOL, linked and dropped into the game while it was
   running.  The whole process took a fraction of a second.  You could
   also do the same per-file.  This feature was sort of like Edit and
   Continue, but you didn't have to broken in the debugger - it could
   be done while the game was running.  This was insanely useful for
   programming gameplay, physics, and fx, as well as prototyping,
   visual debugging (just drop in some debug spheres or prints while
   you have the game in some interesting state), etc.  We also used it
   for dynamic code streaming - so only a fraction of the executable
   code was loaded at any given time (to conserve memory).

   It's astonishing at how much this ability changes your coding style
   - you gravitate to a much more iterative development process, and
   write small bits of code that evolve the codebase while the game is
   running.  It's obviously also much better for robustness and
   reliability, because you're testing out each little piece of code
   as it gets added (as opposed to writing a whole mess of code and
   trying to get it compiled and debuggged).  As for bugs, often you
   can fix them while the game is running and test out your changes
   instantly - this makes bugfix verification much easier. "