>> As a rule, scripting languages don't surpass "real" programming languages when doing the same work and with both languages free to elect their own optimized solutions;

theoretically, they can't - can they?

i dont know much about speed of programming languages and such but i know that the scripting language Skookumscript is on its own not faster than c++ but with some optimizations some certain tasks that are completed in "human time" basically meaning completed over a couple of frames, and dont have to be refreshed every tick can in theory perform 100 times better in skookumscript than c++. http://forum.skookumscript.com/t/skookumscript-performance/500

so it is possible for scripting languages to outperform real languages, but apart from some certain parts of certain languages real languages should always perform better

You cannot speak about "speed of a language", it's a nonsense term.

A language expresses a description of how to solve a problem. It has no speed in itself.

Implementations of languages however can be compared for speed. I can compare visual studio with gcc, and decide which one is faster. I can compare C Python with Lua 5.3 (afaik there is only one implementation), and see which one is faster.

However you do this with 2 concrete implementations of the language(s), and for a concrete set of test-programs. Generalizing to all possible programs, or all possible implementations of a language is very hazardous to say the least.

thats actually what led me to asking this question on gameplay as i was wondering why I cant just do it in c++ and not a scripting language

You can but it costs you a 10 to 50 times more lines of code.

Not necessarily -- its true that many scripting languages are compact or have features (e.g. actor-model, prototypal inheritance model) that lend themselves to scripting game entities and game interactions, but that does not mean that writing gameplay code in C++ has to more difficult or more verbose for the people "scripting" the gameplay elements, albeit in C++.

If you were to use C++ for gameplay code, you might not take any special effort if yourself or the entire team is fluent in C++ (and the engine); if you have less-experienced people "scripting" gameplay through C++, then your goal as an engine programmer would be much like any other task -- provide an API, or indeed an embedded domain-specific language, that makes it easy for client code "scripts" to express high-level intent while encapsulating the low-level details away; In practice, this ends up being not much different than the work of integrating a scripting language with your engine, though you might be providing more of the cogs and widgets yourself. The payoff is that, done well, your "scripting" staff gets many of the productivity, expressivity, sandboxing, and hand-holding benefits that stand-alone scripting languages are known for.

Indeed. This is basically the argument I try to make when I hear that you cant use C++ because the people doing the scripting have limited knowledge of programming and using native code will be too hard or whatever. If you know that the scripters or gameplay programmers or whoever only need a subset of functionality, then the engine should provide them with the appropriate API for that purpose. You can even implement a runtime compiled C++ type solution if they really dont want to work with a compiler. It's entirely possible to get close to the simplicity of a scripting language without taking on any of the negatives associated with them. The problem with scripting languages is that people tend to focus on the front-end benefits and dont realize the magnitude of the back-end drawbacks.

This is the sort of thing i was looking for because right now my "Team" is just two people and both of us are pretty good at c++ and we dont have plans to have more programmers on our team so thats why i was wondering why not just use c++ for gameplay code. if you know that no inexperienced c++ programmer will be usinng it.

>> As a rule, scripting languages don't surpass "real" programming languages when doing the same work and with both languages free to elect their own optimized solutions;

theoretically, they can't - can they?

i dont know much about speed of programming languages and such but i know that the scripting language Skookumscript is on its own not faster than c++ but with some optimizations some certain tasks that are completed in "human time" basically meaning completed over a couple of frames, and dont have to be refreshed every tick can in theory perform 100 times better in skookumscript than c++. http://forum.skookumscript.com/t/skookumscript-performance/500

so it is possible for scripting languages to outperform real languages, but apart from some certain parts of certain languages real languages should always perform better

You cannot speak about "speed of a language", it's a nonsense term.

A language expresses a description of how to solve a problem. It has no speed in itself.

Implementations of languages however can be compared for speed. I can compare visual studio with gcc, and decide which one is faster. I can compare C Python with Lua 5.3 (afaik there is only one implementation), and see which one is faster.

However you do this with 2 concrete implementations of the language(s), and for a concrete set of test-programs. Generalizing to all possible programs, or all possible implementations of a language is very hazardous to say the least.

I wasnt trying to say that skookumscript is always faster than c++ or vice versa, i was merely stating or trying to say that it is possible for a scripting language to outperform a "real" programming language given the right situations/conditions. Also i dont know anything testing different languages peformance in different compilers and IDEs i was just trying to Show the findings of another programmer when comparing performance between c++ and skookumscript. As the the guy i was talking to asked whether it was possible for a scripting language to outperform a "Real" programming language

Not necessarily -- its true that many scripting languages are compact or have features (e.g. actor-model, prototypal inheritance model) that lend themselves to scripting game entities and game interactions, but that does not mean that writing gameplay code in C++ has to more difficult or more verbose for the people "scripting" the gameplay elements, albeit in C++.

Many custom scripting languages are basically just stripped down C-syntax anyway. :)

There is no reason you _have_ to use a scripting language.

From my view, as a small scale developer with our own engine, I've always seen adding a scripting language as just unnecessary extra work and more stuff to maintain.

Our engine needs a proper C++ API anyhow, so why spend the extra work adding another API, which most likely will just be a subset of the engines true capabilities.

Also increases the work to add new features.

Plus you have an extra layer of code that can introduce bugs, while it also often makes debugging harder.

And when you try to push the boundaries of what the scripting language is capable of, it can get messy...

I imagine the cost-benefit will be better in a larger organisation where you have a lot of people that need to implement game specific stuff, and you also have a support organisation to keep the scripting language with enough features and debugging tools to be useful.

With just a few people, where everyone is part engine part game implementers, and everyone already know C++ well, there is little reason to use a scripting language.

Not necessarily -- its true that many scripting languages are compact or have features (e.g. actor-model, prototypal inheritance model) that lend themselves to scripting game entities and game interactions, but that does not mean that writing gameplay code in C++ has to more difficult or more verbose for the people "scripting" the gameplay elements, albeit in C++.

Many custom scripting languages are basically just stripped down C-syntax anyway. :)

There is no reason you _have_ to use a scripting language.

From my view, as a small scale developer with our own engine, I've always seen adding a scripting language as just unnecessary extra work and more stuff to maintain.

Our engine needs a proper C++ API anyhow, so why spend the extra work adding another API, which most likely will just be a subset of the engines true capabilities.

Also increases the work to add new features.

Plus you have an extra layer of code that can introduce bugs, while it also often makes debugging harder.

And when you try to push the boundaries of what the scripting language is capable of, it can get messy...

I imagine the cost-benefit will be better in a larger organisation where you have a lot of people that need to implement game specific stuff, and you also have a support organisation to keep the scripting language with enough features and debugging tools to be useful.

With just a few people, where everyone is part engine part game implementers, and everyone already know C++ well, there is little reason to use a scripting language.

Thanks for the reply

I imagine the cost-benefit will be better in a larger organisation where you have a lot of people that need to implement game specific stuff, and you also have a support organisation to keep the scripting language with enough features and debugging tools to be useful.

With just a few people, where everyone is part engine part game implementers, and everyone already know C++ well, there is little reason to use a scripting language.

This is exactly what several of the posts were talking about.

When you are working on a large project, something where the cost of rebuilding and restarting takes 10 minutes or so, and you have a large number of people working on the project, it makes a lot of sense to build and maintain the system.

Let's assume a big project and the scripting system saves an average 5 minutes each time a build is needed. And let's say that an average of 3 builds per person per day since some people seldom make changes. Consider you may have 200 people using the scripting system on a project for 2 years. So 5 minutes saved per build * 3 builds per person per day * 200 people * 400 days = 1200000 minutes saved = 20000 hours saved = 10 work years saved. Even if it takes a full work year to build the system it is still a worthwhile gain.

Now lets assume a small project. Small projects typically have fast builds, so lets say an average of 30 seconds saved each build. And let's say 10 builds per person per day since they are so closely involved with the implementation. Two people using the scripting system for one year. So 0.5 minutes saved per build * 10 builds per person per day * 2 people * 200 days = 2000 minutes saved = 33 hours saved. For such a small team it doesn't really make sense to invest in creating a scripting system unless it can be implemented within a day or two.

Not necessarily -- its true that many scripting languages are compact or have features (e.g. actor-model, prototypal inheritance model) that lend themselves to scripting game entities and game interactions, but that does not mean that writing gameplay code in C++ has to more difficult or more verbose for the people "scripting" the gameplay elements, albeit in C++.

Many custom scripting languages are basically just stripped down C-syntax anyway. :)

There is no reason you _have_ to use a scripting language.

[...stuff I agree with....]

With just a few people, where everyone is part engine part game implementers, and everyone already know C++ well, there is little reason to use a scripting language.

Yep, totally agreeing with that. My comment was that many custom scripting languages are just stripped down C-syntax anyway, so people might as well just use C++ which already contains that syntax, and more useful features as well! :)

(unless they have need of the benefits scripting provides)

thats actually what led me to asking this question on gameplay as i was wondering why I cant just do it in c++ and not a scripting language

You can but it costs you a 10 to 50 times more lines of code.

Not necessarily -- its true that many scripting languages are compact or have features (e.g. actor-model, prototypal inheritance model) that lend themselves to scripting game entities and game interactions, but that does not mean that writing gameplay code in C++ has to more difficult or more verbose for the people "scripting" the gameplay elements, albeit in C++.

If you were to use C++ for gameplay code, you might not take any special effort if yourself or the entire team is fluent in C++ (and the engine); if you have less-experienced people "scripting" gameplay through C++, then your goal as an engine programmer would be much like any other task -- provide an API, or indeed an embedded domain-specific language, that makes it easy for client code "scripts" to express high-level intent while encapsulating the low-level details away; In practice, this ends up being not much different than the work of integrating a scripting language with your engine, though you might be providing more of the cogs and widgets yourself. The payoff is that, done well, your "scripting" staff gets many of the productivity, expressivity, sandboxing, and hand-holding benefits that stand-alone scripting languages are known for.

Indeed. This is basically the argument I try to make when I hear that you cant use C++ because the people doing the scripting have limited knowledge of programming and using native code will be too hard or whatever. If you know that the scripters or gameplay programmers or whoever only need a subset of functionality, then the engine should provide them with the appropriate API for that purpose. You can even implement a runtime compiled C++ type solution if they really dont want to work with a compiler. It's entirely possible to get close to the simplicity of a scripting language without taking on any of the negatives associated with them. The problem with scripting languages is that people tend to focus on the front-end benefits and dont realize the magnitude of the back-end drawbacks.

This is the sort of thing i was looking for because right now my "Team" is just two people and both of us are pretty good at c++ and we dont have plans to have more programmers on our team so thats why i was wondering why not just use c++ for gameplay code. if you know that no inexperienced c++ programmer will be usinng it.

Then I see no reason why you shouldnt just use C++ for all your code. And if you really need to be able to edit the code without re-compiling, you can consider this project:

https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus/wiki

I dont know much about speed of programming languages and such but i know that the scripting language Skookumscript is on its own not faster than c++ but with some optimizations some certain tasks that are completed in "human time" basically meaning completed over a couple of frames, and dont have to be refreshed every tick can in theory perform 100 times better in skookumscript than c++. http://forum.skookumscript.com/t/skookumscript-performance/500

so it is possible for scripting languages to outperform real languages, but apart from some certain parts of certain languages real languages should always perform better

From the thread you linked:

Fundamentally, well-written C++ will be of course faster than any executed scripting language, but in practice SkookumScript (which itself is written in C++) can beat naive C++ in performance due to its ability to easily time slice operations (meaning code doesn't run every frame but only every few frames).

You have to be careful how you define "outperform" -- One of the creators of SkookumScript, which I have no doubt is very performant for a scripting language, is saying right here (bold) that its a fundamental truth that well-written C++ will beat SkookumScript (he does not even say "highly optimized"), and (italics) goes on to explain that SkookumScript can beat naive C++ (I take that to mean neither architecturally, algorithmically, nor locally optimized C++) because it has built-in time-slicing such that it does less work. While that built-in time-slicing is a nice feature (its an example of those kinds of programming models beneficial for scripting that I mentioned before) and its great to have ready-at-hand, its not an apples-to-apples comparison; You can do time-slicing in C++, you just have to write it (C++ coroutines which unfortunately landed in a Technical Specification rather than C++17 proper, but is already shipping as a preview in VS2015 Update 2, make this almost trivial), and it sounds like he's not even ruling out that non-time-sliced, but optimized C++ could best them.

That you can write straight-forward SkookumScript that will beat naive C++ is certainly noteworthy, and a valuable feature -- but you shouldn't take from that that it "outperforms" even average C++ -- its creators are not boasting that claim.