In video game development, I see a recurring workflow: Prototype in script, then when the script yields behavior you want, either keep it as script or, if performance is insufficient, rewrite in compiled code.
Also, programmers forced to use a scripting language complain when the scripting language lacks sufficient debugging features, like variable inspection and breakpoints. Often, debugging devolves into printfs or traces.
I wonder, then, about writing translators that translate from script into C++. Depending on the language features, that could be pretty straightforward. The features of scripting languages that don't readily fit into C++ include these:
Dynamic typing. C++ is statically typed, whereas most scripting languages popular in video game development (and elsewhere) are dynamically typed.
Garbage collection. C++ requires explicit calls to "delete" (unless you use reference counting), whereas most scripting languages not only do not require "delete" -- they usually lack it.
Coroutines / generators: C++ lacks this, to the point where their concepts are somewhat unfamiliar to a lot of C++ programmers that I work with. In scripting languages, they're often used to create iterators.
Higher order functions: Again, C++ lacks this, but aside from its connection to coroutines/generators, I'm not sure how often they're used in scripts, whether or not the language supports them.
Most or all of these issues can be dealt with by having a runtime kernel that supports these features. But then one wonders whether you would see much performance gains; presumably the slowness came from the use of these features, not from the execution of the algorithm itself.
So I wonder whether it would be useful to make a scripting language that lacks these features, or has a restricted version of them such that translation into C++ is more straightforward. Certainly it is possible to concoct such a language, but at some point you would end up reconstructing some subset of C++, at which point I wonder if it's useful to have that in script.
So this raises the question: Why (or when) is scripting better than using a compiled language? Is the benefit from the dynamic features, or is it because you the build process is faster?
I'd appreciate a response from anybody with evidence or opinions about this topic.
Subscribe to:
Post Comments (Atom)
1 comment:
Maya's MEL programming language lacks all the features you've mentioned. The massive library of built in functions would be the problem in converting MEL code to standard C.
It appears at first glance that MEL supports dynamic typing but it really doesn't. If you declare an un-typed variable, then the type is resolved based on the first expression assigned to it. This occurs when the procedure is converted to byte-code.
Memory management is lacking in MEL completely, you don't really have any way to free a variable from memory. Once you make a global it sits in memory until you exit Maya. MEL doesn't support pointers, so all the variables local to a procedure will be free when the procedure returns.
If you think of the Maya scene as the MEL heap, then new and delete directly turn into "createNode" and "delete" commands.
Some language features that keep MEL from being a strict sub-set of C:
- dynamic arrays
- string is built-in type
- switch on strings
- catch exceptions (*note 1)
I definately think that the build speed is the valuable aspect of MEL. Maya added support for Python scripting a few years ago, with equivalent functionality. So Maya developers have a choice that supports the higher-level features, and many aren't making the switch as quickly as might be expected. The sole advantage of MEL as this point is faster execution speed.
note 1: MEL cannot throw exceptions, it can only catch them. Almost every built in Maya command can and will throw an exception, even for trivial errors that don't need to be handled. These exceptions will halt the execution of the current script, if not manually caught.
Post a Comment