quote:
After reading through the article again (the first time I found it I only skimmed through it), I noticed it does mention they compiled all the programs to native code so it''s not running interpretted.
Then it would seem to me that they''re comparing compilers instead of languages.
I was under the impression that the sited study was more about development time than execution time. I have no doubt that in the proper domain, Lisp is an order of magnitude faster than C in terms of development effort.
I won''t argue that JAva is as hard to program in as C++. But my personal experience is that UnrealScript is much harder to program in that Java. US has a simpler syntax and all that, but there is very little documentation on it, so it takes me twice as long to do something because I don''t have a million resources I can glance at to get the solution.
I dunno, just my opinion. It just seems to me that programmers, game programmers especially, re-invent the wheel simply because they can.
quote:
I dunno, just my opinion. It just seems to me that programmers, game programmers especially, re-invent the wheel simply because they can.
Heh. You are certainly right about THAT! That's the main reason why I opted for using python instead of developing my own language/interpretter/compiler/runtime.
Java is a good language, and it's well documented. If you're using a JIT runtime, it's probably the fastest (execution-wise) of the scripting options. It just doesn't seem to be well suited to the task.
Take care, Bill
[edited by - Siebharinn on April 28, 2002 7:28:43 PM]
Hey, I coded x-script. It is currently totally interpreted, Im in the process of developeing a VM for it though. The VM will be out this summer early. Scripting language are very nice because they can be embedded into an application and allow the user of the application to customize the functionality of that application. Thats my main application of Scripting languages. Users should have some control without having the C/C++ source.
Reality Makes Me XiC I don''t do talk, I code: passion is my feul. Use my programs, experience beauty. http://www.x-i-c.com/
My point is Java has a virtual machine already built, it uses op codes, JIT technology, and C++ and Java can communicate back and forth using JNI very easily.
Python, or whatever probably have the same thing (I''ve not used python before so I can''t say for sure).
Yet, from the posts I see on this board, people writing games often are hell bent on creating their OWN scripting language... Why?
Especially in an amatuer project, every added task you add to your TO-DO list exponentially effects whether or not you will actually finish the project.
For people who enjoy writing their own scripting language, make that your project, not a game. Then write a simple demo to show off your scripting language. But people who want the GAME to be their focus, really should look into using existing technology.
Plus, people at SUN have spent millions trying to make Java execute fast, a developer who is writing their own language in their spare time, as a step in building a game, is NOT going to get better results.
I must admit that I''ve just started playing with Java in terms of a scripting language - I''d previously shied away from it because I''d thought that it looked hard - it''s actually very easy to implement, when you''ve deciphered the documentation. It''s advantages seem to be great, especially the point that it''s reasonably established already & has a lot of librarys avaible. I''ve now made myself a class that allows me to init the java VM in two lines using the class & to execute a void (void) method in three lines.
Of course I always intend to roll my own scripting language some time & have tried others, especially spidermonkey.
I use an interpreted bytecode. I made the assebler AND dissasembler in VB while the interpreter is a huge C++ switch() statement that executes untill the script finishes (no sissy classes or function pointrs for opcodes here!!!)
It can do basic math using ''regiters'' as variables and can call external functions to change the game using the registerd as paramiters. Most of the memory is read-only for the program, but there is RAM for data and variable storage
It does exactly what I need it for, accept events from ships or timers and can change the gamestate using logic
