Re: A few questions about scripting

On May 12, 2010, at 7:40 AM, Nick Trout wrote:

> 
> On 27 April 2010 10:41, Thaddaeus Frogley <[email protected]> wrote:
> Question:
> Arguably a developer implementing their game in C# or Java could be
> described as having written *all* of their game in a "scripting"
> language.
> Classifying languages can be tricky, and that's an interesting comparison. Technically I wouldn't say C# is a scripting language because the CIL the language is compiled into is for the benefit of the JIT code generator, i.e. it doesn't run on a VM. Whereas Java does compile into intermediate code that runs on a VM. However, because Java isn't a dynamic language I wouldn't classify it as a scripting language.

Microsoft's .Net implementation does include the ability to interpret CIL without subjecting it to JIT, although use of that is discouraged.  Sun's JVM has had a JIT for a very long time -- and their "HotSpot" JIT was touted as being a groundbreaking approach when it was introduced (in practice it was better, but not nearly as earth-shattering as they had hyped it up to be -- of course).

Both VMs will interpret code at first and only JIT code that's called enough times to justify the overhead of the compilation process.

In terms of "dynamic" language features, both .Net and the Java platform have been adding VM-level support for such features for some time, and have been exposing bits and pieces of that to their respective first-tier languages (C#/Java).

I think the distinction you are looking for is that the Java VM's instruction set and, and overarching design were crafted specifically to support the Java language and without regard for the need for things like JIT compilation, whereas Microsoft has asserted that CIL was designed from the beginning to facilitate JIT and to support a broad array of languages.


> Another point relevant to console developers might be whether the language generates code or runs on a VM. I.e. you couldn’t use a language that generates code because it breaches the rules.

Unity Technologies and the Mono Project faced this problem on iPhone -- no JIT, no interpreters (except for WebKit's JavaScript runtime).  They had to make an ARM backend for Mono's AOT (ahead-of-time) compiler, and rework it to support a mode that was "fully" AOT instead of just compiling individual assemblies to native code and using interpreted/JITted code to bind them together at runtime.  On top of that, IIRC, there was some reimplementing that needed to be done for a few things like delegates which had previously used runtime code generation features.

The end result though is pretty transparent to developers.  You write in C# or another .Net language and wind up with a native binary (plus a few metadata artifacts but that's rather beside the point).  You're missing a few features of the standard library, but that's about it.

-JF

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com