Re: Complexity of new hardware

Here's a fairly crazy idea, but I'd like to put it out there anyway: Is there a middleware market for something like GOAL?

 

Frankly, I have no idea whether it could make money - I'm not interested in worrying about this at the moment (and it's off topic). But I am interested in finding out whether the industry would actually be interesting in adopting one or more domain-specific languages in games development?

 

As an example, I've been particularly impressed by Haskell. It's a pure, strictly-typed "lazy" functional language and looks like a good fit in many ways. I won't rattle on about how cool it is here, but suffice to say I think it warrants some attention. The slightly iffy state of its C compatibility currently lets it down (IMHO), but I think some sort of "Haskell for games dev" project/compiler/code generator is a not totally insane idea.

 

Any thoughts?

 

Cheers,

Sam

 

From: Pal-Kristian Engstad [mailto:[email protected]] 
Sent: 21 April 2009 20:44
To: Game Development Algorithms
Subject: Re: [Algorithms] Complexity of new hardware

 

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 ([email protected]), 
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.

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p

_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list