People, you are forgetting something.
dynamicaly-typed languages, and static-typed languages
can each be just as powerful as the other!
It is about the design of the underlying system, and the compiler. You have to have a strong error detection system, wether at run-time or at compile-time (depending on the where its needed). And, with a powerful debugger for the script language you can have all the tools you need to catch errors.
If you really think about it, you can see what I mean.
Anyone have questions?

Oluseyi, I totally agree, but what I mean is that, since both approaches have different uses, you should allow both, like VB does. If you''re writing a script that messes with the core mechanics of a game and has to be run every frame, I wouldn''t want to check the types for every time a variable is used. That''s pure wasting of CPU cycles. And when you''re building a system that is supposed to be solid, it''s much safer to have types checked at compile time. But to script a potion in an RPG or whatever, it''s great if you can just skip all of that, using variant-type variables. And it''s not that hard to implement if you already have dynamic variables; simply add some checks at compile time for fixed variables. So you don''t really have to chose one of them, you can have both, and they serve different purposes.

quote:

---

Original post by I_Animated
People, you are forgetting something.
dynamicaly-typed languages, and static-typed languages
can each be just as powerful as the other!
It is about the design of the underlying system, and the compiler. You have to have a strong error detection system, wether at run-time or at compile-time (depending on the where its needed). And, with a powerful debugger for the script language you can have all the tools you need to catch errors.
If you really think about it, you can see what I mean.
Anyone have questions?

---

You simply cannot argue that a specific error showing itself as a runtime error is better than getting a compile time error. With the compile time error, you don''t have to do any debugging at all, in the sense of examining control paths and function input/outputs of a running program, which is incredibly time consuming.

I''m not saying dynamic typing is bad, but you really want to be catching as many compile time errors as you possibly can to give you confidence that your program will not crash because of trivial typing errors. It''s obviously more complex than this, but it''s all about tradeoffs and trading in compile time errors for runtime errors is a big decision that should be justifyable in terms of your language and its problem domains.

I completely agree with you seanw, but can''t compile-time checking can be done on a dynamic-type language; or what ibrian originally suggested, that variables can have typed values.
Or, am I wrong?

quote:

---

Original post by Jotaf
Oluseyi, I totally agree, but what I mean is that, since both approaches have different uses, you should allow both, like VB does.

---

That''s one of the dumbest features of VB. Just because you can do something doesn''t mean you should.

quote:

---

If you''re writing a script that messes with the core mechanics of a game and has to be run every frame, I wouldn''t want to check the types for every time a variable is used. That''s pure wasting of CPU cycles.

---

It''s also pure ignorance. There are suprisingly few instances where the exact type of the operand needs to be determined prior to execution if you program appropriately. Take a look at PyGame.

If you''re going to argue this thing, inform yourself. Give me good reasons, not vague phobias and paranoia.

quote:

---

Original post by seanw
I''m not saying dynamic typing is bad, but you really want to be catching as many compile time errors as you possibly can to give you confidence that your program will not crash because of trivial typing errors.

---

There is a problem with this assertion: it runs counter to the purpose of scripting languages.

You want a statically compiled and executed language, use one. You want a scripting language, presumably precisely because it is evaluated at runtime, allowing for flexibility and interactivity, then accept the costs. Despite the constant ominous "trivial error crashing program" allusions, no one has supplied practical evidence to support this position.

quote:

---

Original post by Oluseyi
There is a problem with this assertion: it runs counter to the purpose of scripting languages.

---

Like I said in my previous post, you could trade in the compile time errors for runtime errors given a good enough reason. If it allows your scripting language to behave the way you want it to, then that''s a good enough reason.

quote:

---

You want a statically compiled and executed language, use one. You want a scripting language, presumably precisely because it is evaluated at runtime, allowing for flexibility and interactivity, then accept the costs. Despite the constant ominous "trivial error crashing program" allusions, no one has supplied practical evidence to support this position.

---

I''m simply talking about any function that takes a set of inputs that have to be of a specific ''type'' to work correctly. If you determine the type at runtime, you''re not going to find out if your inputs break the program because you are going to have to wait for the program to execute the code there. It simply is not feasible to exercise every possible control path to ensure there isn''t a typing problem somewhere.

Anyway, why does the fact you''re using a scripting language mean you can''t compile the code and check for typing errors? I don''t see how a scripting language and static compilation is mutually exclusive.

The impression I got from all the sources that talk about the implementation of a VM with dynamic types is that whenever a variable is manipulated, it needs to check the type, and possibly make a typecast or throw an error. I also can''t see another way to do it. So basically it''s a waste of CPU cycles, and serious game programmers lose their sleep over this very problem. So far you didn''t explain how it''s not a waste of CPU, or if it is, why it isn''t relevant. I was not too impressed with that site, I meant professional quality games - the ones that need speed above everything else. I would take your opinion seriously if your attitude didn''t make you sound like you worship Python and hate every other language (like VB). Read your post again. I thought this was a decent discussion so I really don''t want to be rude.

quote:

---

Original post by Jotaf
The impression I got from all the sources that talk about the implementation of a VM with dynamic types is that whenever a variable is manipulated, it needs to check the type, and possibly make a typecast or throw an error. I also can''t see another way to do it. So basically it''s a waste of CPU cycles, and serious game programmers lose their sleep over this very problem. So far you didn''t explain how it''s not a waste of CPU, or if it is, why it isn''t relevant.

---

If the scripting language is only operating at a high-level (eg expensive innerloop computations aren''t being directly executed in it), it should be ok for you to sacrifice a little speed if it makes something else easier for you. For example, dynamic types might make your scripts shorter or easier for your level designer to learn how to write, so it might be an acceptable tradeoff. So it might be a "waste of CPU cycles" on the player''s computer, but it might save you significant time and headaches whilst developing your game.

Game scripting languages should really only be passing on high level commands to your game engine anyway, which then carries out all the real work (eg the enemy getting shot event tells the enemy to move to a hiding place in the scripting language, then the engine takes care of the expensive path finding).

quote:

---

Original post by seanw
Game scripting languages should really only be passing on high level commands to your game engine anyway, which then carries out all the real work (eg the enemy getting shot event tells the enemy to move to a hiding place in the scripting language, then the engine takes care of the expensive path finding).

---

I agree, and I think thats an important point to take into consideration. It should probably go without saying, but it can be a challenge to find the right balance between flexibility and centricity (don''t know if I made that word up or not ), and keeping the script support focused and high-level.

For example, you mentioned that pathfinding should be controlled by the engine. I agree that at least the pathfinding "engine" or base formulas should be handled by the engine. Ideally, I believe the engine should handle the "expensive" part of pathfinding, but should still be fundamental enough to allow scripts to define precisely how pathfinding behaves.

Also, at what point does one seperate engine logic from surface logic? Where is the surface? Should the scripting language somehow be connected with the State Machine? Should the scripts derive from a centralized point, kind of like a Script Main() function/method, or should scripts simply be extensions of engine-defined modules?

These questions and others like them are questions I''ve been pondering that may have a direct impact on the final syntax.