Re: [Algorithms] Complexity of new hardware

[Andrew V. <and...@ni...>]

Yes, I think there is.
But I think you'd be competing with (possibly lower-level) scripting
languages rather than engine level C/C++. Not that that's necessarily a bad
thing.
Of course, if you could get a language that interfaced correctly and
completely with all the existing SDKs on all platforms and you could use it
to write/generate code that ran in comparable time to equivalent C then it
could be a valid replacement for everything. But I reckon a script-style
language is a more feasible goal to start with.
 
There definitely needs to be a change to the way most games are written when
considering new hardware. It's perfectly possible that a new/different
language might be a good way to go - however, I'd be concerned that it would
introduce more complexity, i.e. if you already expect people to change the
way they program, is it too much to expect them to do so while also learning
a completely new language?
Maybe not - maybe the language can help the process?
 
Cheers,
Andrew.


  _____  

From: Sam Martin [mailto:sam...@ge...] 
Sent: 22 April 2009 11:05
To: Game Development Algorithms
Subject: Re: [Algorithms] 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:pal...@na...] 
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 (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.
 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________