Re: [Algorithms] Complexity of new hardware

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

> Wouldn't that be a tough sell? You'd already be competing 
> with free implementations of LUA, Python, JavaScript and 
> their ilk on the low end, and built-in languages like 
> UnrealScript on the high end. While middleware for something 
> like mesh exporting and animation (Granny) or something like 
> networking or AI make sense, because there is no good free 
> library for those areas, the scripting language market seems 
> full of entrenched competitors with a zero dollar price point.

Maybe "scripting language" is the wrong term. I'm thinking of something that
sits between the low-level C/C++ "details" and the high-level, LUA-style,
scripting - probably for the purpose of enabling easier multithreading of
gameplay style code (rather than engine-side code).

I'm not saying you can't extend this language in either direction, but
that's where I see the most use of it (YMMV). :)

> > 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.
> 
> Doesn't this bring us back full circle? I recall a statement 
> from a month ago saying that we all need to think differently 
> about how we put together massively parallel software, 
> because the current tools don't really help us in the right 
> ways... That's not just games, mind you, but business 
> software is often less performance critical, and server 
> software already has a reasonable parallelization strategy 
> with data and service federation (and 800-way CPU boxes like 
> those from Azul...).

Yep, agreed.
My point was more whether the best way forward would be with a new language
or whether new/different programming techniques for existing languages
(which means C++, I guess) would be better.

Cheers,
Andrew.