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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.