Re: A few questions about scripting
Douglas Cox <[email protected]>
| Newsgroups | gmane.games.devel.sweng |
|---|---|
| Message-ID | <[email protected]> |
As I've never been a big fan of dynamically typed languages (nor are most of the other programmers here), our language is strongly typed. There are many other benefits for running "script" through a VM such as much faster iteration and more capable edit-and-continue. There's also a much safer environment in our language (which is similar to C#), so far fewer pointer mistakes and incorrect array indexing are made. We're able to do a few things with references to data resources that would be quite annoying in plain C++, and we can easily generate reflection information for our classes. Even removing the need to deal with separate header and source files helps a bit in day to day code editing. And if you *need* an unsafe section to write some pure C++ code, that's possible as well. >From what we've seen with a more dynamically typed language, you end up having to play half way through a level to realize that you passed in the wrong parameter and get an exception/assert. I'd certainly rather have a compiler spit out an error before a programmer checks in something wrong, than have the entire project team run into it and have to figure out who they need to send a bug to. But again, that's us, and I guess we're in the pro-strongly-typed-language camp here. The luajit guys do seem to have some impressive benchmarks, so they might beg to differ on the dynamic languages are slow aspect. I'd love to be proven wrong, though -- that would be a bit of a grail you > had there, then :-) > Well, we are certainly trying our best, and that is certainly part of our motivation (the grail, not just proving you wrong :P). Then again, maybe I should have spent some more time learning Haskell... :P -doug On Wed, Apr 28, 2010 at 3:05 PM, Jon Watte <[email protected]> wrote: > through the VM for quick iteration, and if certain classes need to be >> compiled to machine code for that boost in speed near the end of a project >> we can compile it to C++ instead. But in the end, what we do > > > C++ excels at speed because it allows you to write a strongly typed, > statically resolved solution to whatever problem you have. Script languages > excel at productivity because they let you iterate quickly using weakly > typed, dynamically resolved solutions. > > I've always been very ambivalent-to-negative about this theory of compiling > scripts to C++. The reason is that the benefit from scripting languages is > often in their dynamism, duck-typing, late-binding etc. None of that is > "native" in C++, and if you compile C++ lines of code that just evaluate to > the VM byte codes, but still calls into the dynamic/reflective/hash-based > runtime, then the speed-up will be moderate at best. > > I'd love to be proven wrong, though -- that would be a bit of a grail you > had there, then :-) > > Sincerely, > > jw > > > -- > Americans might object: there is no way we would sacrifice our living > standards for the benefit of people in the rest of the world. Nevertheless, > whether we get there willingly or not, we shall soon have lower consumption > rates, because our present rates are unsustainable. > > > > _______________________________________________ > Sweng-Gamedev mailing list > [email protected] > http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com > > _______________________________________________ Sweng-Gamedev mailing list [email protected] http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com