Re: [Algorithms] Complexity of new hardware

[Pal-Kristian E. <pal...@na...>]

Gregory Junker wrote:
> NaughtyDog tried -- you have to admit that Lisp *in theory* should be
> perfectly suited to game development: it's core design intent is list
> processing (indeed, it's the name), which arguably games *are*, and it's
> functional, which ought to be perfect for increasingly data-parallel game
> technology designs. If the syntax is just "too weird" -- that can be
> changed, while leaving the core language design intact (again, GOAL). 
>
> http://www.gamasutra.com/features/20020710/white_02.htm
>   
I'll have to correct you in some of your assumptions. Goal:

    * Was imperative and not (very) functional. For instance, it didn't
      support closures.
    * Had okey (but not great) object-oriented support.
    * Had good introspection qualities (except where you didn't need to
      have it).
    * Had an excellent macro processor, corresponding to Lisp.
    * Had excellent support for fibers.
    * Made use of the REPL style of programming, including on-line
      updates of code and data.
    * Was an excellent assembler, since you had register scope as well
      as access to macros and direct access to "high-level" data types.
    * Was quite a poor code generator (but it didn't matter because of
      the above).
    * Had no visual debugger, but the REPL and on-line updates usually
      negated the need for one.

Goal was a great system - one that we still greatly miss. If we had to 
make a Goal2, then we'd probably:

    * Use an SML-ish or Scala-ish surface syntax, while trying to retain
      the power of Lisp macros.
    * Introduce stronger typing features, which is difficult, given the
      need for REPL and hot updates.
    * Do more in terms of high-level optimization, though LLVM might
      negate the need for some of that.
    * Go towards a more functional style, especially due to current
      generation hardware's need for concurrency.

Before anyone jumps up and down, no - we're probably never going to get 
around doing this. We simply don't have the time to spend too much 
effort on such an en devour.

Thanks,

PKE.

-- 
Pål-Kristian Engstad (en...@na...), 
Lead Graphics & Engine Programmer,
Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.

"Emacs would be a far better OS if it was shipped with 
 a halfway-decent text editor." -- Slashdot, Dec 13. 2005.