Hi,
I'm evaluating scripting languages and I have some questions.
I'd like to see if there are language design notes or proposals where angelscript users can talk about the future. I mean that there are always possibilities to include or exclude some feature from the language, to add missing features, etc. Is angelscript language standardized somewhere, are new versions based on roadmap? Is there place where users can discuss about the language itself?
I read some articles in angelcode.com and I'm quite impressed about the language. Static typing is something is very like and scripting language with static types is really nice feature compared to others.
Now here are my questions (detailed):
1. C++ Wrappers.
I seen the interface for wrapping existing code into angelscript. To be honest I can imagine better interface than "text definitions", of course text definitions are quite good for developer, but if we start talking about automatic bindings then this is needless overhead which takes space and application startup-time. Is here some chance to define binary bindings interface?
2. Jit compilation.
I read carefully documentation where the author says that if you want to use JIT compiler then byte-code must contain some special instructions. This means that I can't compile angelscript in one machine, send byte-code to other and compile it using JIT (because the machine which compiled the code know nothing about how it will be interpreted)?
If true I think that this has to be fixed. I wrote a tool called AsmJit which I can use in future to make a jit-compiler for x86/x64 platform. I think that jit-compiled angelscript can beat any scripting language, because it's statically typed - this is great advantage of angelscript design and performance is factor that can spread it into other applications.
I'm also interested what means synchronizing states with angelscript VM, I need to do this per function or there is some jit-entry and jit-leave stage?
3. Language.
Is there chance for implementing some features like operator overloading and anonymous delegates? I seen these features in C# and I think they are really useful. Mainly anonymous delegates for connecting objects together (ideal for gui/web).
Thanks for answers!
Angelscript language design and feature
Author
Not to discourage your choice, as AngelScript is a fine language, but could you explain what attracts you to AS?
From what I've seen, AS is quite close to C++/Java -- While this looks great to you, as a real programmer, designer types most often aren't programmers. It may or may not be the case that your scripters and level designers (who may simply be you, yourself) are comfortable with "real" programming languages, so be sure you're choosing a scripting solution that's easy and intuitive for that audience, not just yourself.
I'm also sensing some underlying emphesis on execution speed, which is a bit of a red-flag to me as it may be unduly influencing your decision; while execution speed is important, it's also true that if execution speed becomes an issue then you're probably using scripting to solve the wrong problems. Keep it clearly in mind what problems scripting is generally meant to solve: To allow less-technical designers to customize behavior, to avoid unnecessary recompilation and to prototype and iterate on ideas quickly and easily. Conversely, your points of concern seem to indicate that you're more concerned that the language is similar to languages which you currently hold in high esteem.
I was quite guilty of this myself against another scripting language, javascript, until this past week. While javascript certainly does have its problems and warts (probably more than any other successful language, in fact) when you begin to understand it and find the core language and patterns that make it sing (as well as avoiding its problems) its actually quite a nice language. The problem, for me, though, had always been that it was too dis-similar from any other language I liked for me to give it a chance, or even to evaluate it honestly. It was only last week that I forced myself to give it a chance due to a new interest in writing web games in pure HTML5 (No flash, no plugins) -- after a few days research and reading I've come to realize what a suprisingly pleasant, and different, language it really is.<br><br>Keep your mind open while also focussing on the needs of the audience.
From what I've seen, AS is quite close to C++/Java -- While this looks great to you, as a real programmer, designer types most often aren't programmers. It may or may not be the case that your scripters and level designers (who may simply be you, yourself) are comfortable with "real" programming languages, so be sure you're choosing a scripting solution that's easy and intuitive for that audience, not just yourself.
I'm also sensing some underlying emphesis on execution speed, which is a bit of a red-flag to me as it may be unduly influencing your decision; while execution speed is important, it's also true that if execution speed becomes an issue then you're probably using scripting to solve the wrong problems. Keep it clearly in mind what problems scripting is generally meant to solve: To allow less-technical designers to customize behavior, to avoid unnecessary recompilation and to prototype and iterate on ideas quickly and easily. Conversely, your points of concern seem to indicate that you're more concerned that the language is similar to languages which you currently hold in high esteem.
I was quite guilty of this myself against another scripting language, javascript, until this past week. While javascript certainly does have its problems and warts (probably more than any other successful language, in fact) when you begin to understand it and find the core language and patterns that make it sing (as well as avoiding its problems) its actually quite a nice language. The problem, for me, though, had always been that it was too dis-similar from any other language I liked for me to give it a chance, or even to evaluate it honestly. It was only last week that I forced myself to give it a chance due to a new interest in writing web games in pure HTML5 (No flash, no plugins) -- after a few days research and reading I've come to realize what a suprisingly pleasant, and different, language it really is.<br><br>Keep your mind open while also focussing on the needs of the audience.
This is the right forum to discuss the AngelScript library and the scripting language. I'm the author of AngelScript, and I listen closely to suggestions for future improvements.
AngelScript is not a standardized language, it is my own invention, though I'm not really trying to create a new language, only an easy to use scripting solution. Most of the language features are inspired by more grown up languages, such as C++, Java, C#, and D. There is no fixed roadmap for the library or the language, but you can follow my plans on the WIP page.
1. C++ Wrappers
A binary interface with C++ would be possible, but it is extremely difficult to make portable as there is no standard for it. Each compiler has it's own way of doing things.
Still, I'm willing to give this a chance if you'd like to contribute with the effort to make it work.
2. JIT compilation
The JIT compilation interface currently built for AngelScript is not meant to replace the VM, only to enhance the execution speed. This means that the JIT compiled code will still be executed by the VM and it must have points to release control back to the VM to allow suspension of the execution, etc.
I would very much like to enhance this in the future to allow more flexibility to what the application can do with the JIT compilation.
3. Language
Operator overloading is already supported, as SiCrane pointed out. Delegates will most likely be supported in the future.
---
This is a comment that I've seen quite often, and I can't quite understand it. The difficulty in programming is normally not the language but the logical thinking required to make it do what you want.
Someone with absolutely no programming experience will be able to learn pretty much any language just as easily, given that he has documentation and examples to learn from.
The difficulty in learning scripting for a game or application is definitely not the language, but rather the interface that the game or application exposes to the scripts.
The difference between statically typed and a dynamically typed language is the trade-off between compile time verifications versus runtime verifications. It may require a bit more up-front thinking from the programmer to write a correct program, as the compiler will not accept wrong types, but on the other hand there is much less runtime troubleshooting needed to fix incorrectly written programs due to mismatching types.
I fully agree with this.
---
The choice of a scripting library should be based on your and your team's needs. Choose the library that will aid you the most in accomplishing your goals.
But never understimate your audience. Interested modders will always find a way to do what they want regardless of your choice of scripting language. You just need to create the game or application that will attract them.
AngelScript is not a standardized language, it is my own invention, though I'm not really trying to create a new language, only an easy to use scripting solution. Most of the language features are inspired by more grown up languages, such as C++, Java, C#, and D. There is no fixed roadmap for the library or the language, but you can follow my plans on the WIP page.
1. C++ Wrappers
A binary interface with C++ would be possible, but it is extremely difficult to make portable as there is no standard for it. Each compiler has it's own way of doing things.
Still, I'm willing to give this a chance if you'd like to contribute with the effort to make it work.
2. JIT compilation
The JIT compilation interface currently built for AngelScript is not meant to replace the VM, only to enhance the execution speed. This means that the JIT compiled code will still be executed by the VM and it must have points to release control back to the VM to allow suspension of the execution, etc.
I would very much like to enhance this in the future to allow more flexibility to what the application can do with the JIT compilation.
3. Language
Operator overloading is already supported, as SiCrane pointed out. Delegates will most likely be supported in the future.
---
Quote:
From what I've seen, AS is quite close to C++/Java -- While this looks great to you, as a real programmer, designer types most often aren't programmers. It may or may not be the case that your scripters and level designers (who may simply be you, yourself) are comfortable with "real" programming languages, so be sure you're choosing a scripting solution that's easy and intuitive for that audience, not just yourself.
This is a comment that I've seen quite often, and I can't quite understand it. The difficulty in programming is normally not the language but the logical thinking required to make it do what you want.
Someone with absolutely no programming experience will be able to learn pretty much any language just as easily, given that he has documentation and examples to learn from.
The difficulty in learning scripting for a game or application is definitely not the language, but rather the interface that the game or application exposes to the scripts.
The difference between statically typed and a dynamically typed language is the trade-off between compile time verifications versus runtime verifications. It may require a bit more up-front thinking from the programmer to write a correct program, as the compiler will not accept wrong types, but on the other hand there is much less runtime troubleshooting needed to fix incorrectly written programs due to mismatching types.
Quote:
I'm also sensing some underlying emphesis on execution speed, which is a bit of a red-flag to me as it may be unduly influencing your decision; while execution speed is important, it's also true that if execution speed becomes an issue then you're probably using scripting to solve the wrong problems. Keep it clearly in mind what problems scripting is generally meant to solve: To allow less-technical designers to customize behavior, to avoid unnecessary recompilation and to prototype and iterate on ideas quickly and easily. Conversely, your points of concern seem to indicate that you're more concerned that the language is similar to languages which you currently hold in high esteem.
I fully agree with this.
---
The choice of a scripting library should be based on your and your team's needs. Choose the library that will aid you the most in accomplishing your goals.
But never understimate your audience. Interested modders will always find a way to do what they want regardless of your choice of scripting language. You just need to create the game or application that will attract them.
Author
Hi Ravyne,
thanks for the post. Angelscript impressed me mainly because of static typing. This is feature that is not so widely seen in scripting languages. Personally I'd like to experiment with it in spare time, I'm working on very big library called Fog-Framework (http://code.google.com/p/fog/) and ability to make it completely scriptable is very promising to me. There are people that want to use this library for X window manager and some other applications, also scripting is good opportunity for showcases. Personally I'm going to write interesting piece of software with it (interesting to me;-).
You said that performance shouldn't be considered, but if we stay with javascript then you should notice performance battles between engines/browsers. They are making impossible things to improve javascript speed, but there are borders. Statically typed languages have different borders so javascript will be always slower than compiled languages like C#/Actionscript. So here I think that investing time to learn angelscript is good choice, because if the speed will be bad there will be always possibilities to improve it (there are big libraries like LLVM which can optimize to the death)..<br><br>BTW: Look at my projects in google-code (AsmJit / Mathpresso / Fog), performance is my blind side;)
thanks for the post. Angelscript impressed me mainly because of static typing. This is feature that is not so widely seen in scripting languages. Personally I'd like to experiment with it in spare time, I'm working on very big library called Fog-Framework (http://code.google.com/p/fog/) and ability to make it completely scriptable is very promising to me. There are people that want to use this library for X window manager and some other applications, also scripting is good opportunity for showcases. Personally I'm going to write interesting piece of software with it (interesting to me;-).
You said that performance shouldn't be considered, but if we stay with javascript then you should notice performance battles between engines/browsers. They are making impossible things to improve javascript speed, but there are borders. Statically typed languages have different borders so javascript will be always slower than compiled languages like C#/Actionscript. So here I think that investing time to learn angelscript is good choice, because if the speed will be bad there will be always possibilities to improve it (there are big libraries like LLVM which can optimize to the death)..<br><br>BTW: Look at my projects in google-code (AsmJit / Mathpresso / Fog), performance is my blind side;)
Author
Quote:
AngelScript is not a standardized language, it is my own invention, though I'm not really trying to create a new language, only an easy to use scripting solution. Most of the language features are inspired by more grown up languages, such as C++, Java, C#, and D. There is no fixed roadmap for the library or the language, but you can follow my plans on the WIP page.
No problem to me, I like the syntax and it seems that it took a lot of time to design it and write it!
Quote:
1. C++ Wrappers
A binary interface with C++ would be possible, but it is extremely difficult to make portable as there is no standard for it. Each compiler has it's own way of doing things.
Still, I'm willing to give this a chance if you'd like to contribute with the effort to make it work.
Currently I have too many open projects, but if I choose angelscript then I'm sure that we will talk about this topic more deeply. It's very good to me that doors are open.
Quote:
The JIT compilation interface currently built for AngelScript is not meant to replace the VM, only to enhance the execution speed. This means that the JIT compiled code will still be executed by the VM and it must have points to release control back to the VM to allow suspension of the execution, etc.
I would very much like to enhance this in the future to allow more flexibility to what the application can do with the JIT compilation.
This is okay, only the thing I wanted to advise is that enter-jit/leave-jit should be through some gateway and not per function. Personally I think that JIT compiled function should look like compiled function by C++ compiler (standard prolog/epilog, exception unwind tables).
BTW: Is there a JIT compiler (or some reference one) for AS? I didn't find any.
Quote:
Operator overloading is already supported, as SiCrane pointed out. Delegates will most likely be supported in the future.
I know, sorry I missed it. Delegates would be nice, currently this is feature I'm missing.
Quote:
The difference between statically typed and a dynamically typed language is the trade-off between compile time verifications versus runtime verifications. It may require a bit more up-front thinking from the programmer to write a correct program, as the compiler will not accept wrong types, but on the other hand there is much less runtime troubleshooting needed to fix incorrectly written programs due to mismatching types.
Exactly, upgrading dynamically typed code is sometimes big pain (the worst case is deployed application with run-time error).
BTW: The library I'd like to wrap is here (http://code.google.com/p/fog/), it's big project which I'm developing in my spare time.
Thanks for the answers, now it's time for experiments;)
Author
I'd like to say that I embedded first data type - String:) I'm using UTF-16 so it was needed to read more than only first pages of manual.
Some ideas - I think that CScriptBuilder shouldn't be mentioned in the first AS example, show user how AS works, not wrapping it to addon classes, I think that it's quite easy to understand and mainly messing first example with addons is something that should be avoided. Just my feeling.
I'm using 64-bit Linux and when compiled with -O2 it didn't work (segfault when calling native function). I created cmake project and set -O0 for as_callfunc_xxx.cpp file. It works now. There is problem that GCC is trying to optimize such code and it's invalid after optimizations, I think that fixing this bug should be priority, maybe I can help with it. It's always game with fire when managing stack manually in C++. I'm sure that rewritting as_callfunc_x64_gcc.cpp will do the job.
Also it seems that calling native function is quite expensive, is there somewhere speed comparison to other languages? (But this is not important to me, it can be solved by using JIT compiler)
And lastly, I found that I need one feature - class inheritance. Is this solved? The solution my assigning methods more times is not clean for me. I think that simple inheritance should be supported - just adding super-class id and using super-class methods. Many other languages support single inheritance only. If there is something I can do to have this in next version tell me.
Some ideas - I think that CScriptBuilder shouldn't be mentioned in the first AS example, show user how AS works, not wrapping it to addon classes, I think that it's quite easy to understand and mainly messing first example with addons is something that should be avoided. Just my feeling.
I'm using 64-bit Linux and when compiled with -O2 it didn't work (segfault when calling native function). I created cmake project and set -O0 for as_callfunc_xxx.cpp file. It works now. There is problem that GCC is trying to optimize such code and it's invalid after optimizations, I think that fixing this bug should be priority, maybe I can help with it. It's always game with fire when managing stack manually in C++. I'm sure that rewritting as_callfunc_x64_gcc.cpp will do the job.
Also it seems that calling native function is quite expensive, is there somewhere speed comparison to other languages? (But this is not important to me, it can be solved by using JIT compiler)
And lastly, I found that I need one feature - class inheritance. Is this solved? The solution my assigning methods more times is not clean for me. I think that simple inheritance should be supported - just adding super-class id and using super-class methods. Many other languages support single inheritance only. If there is something I can do to have this in next version tell me.
Quote:Original post by p_k
And lastly, I found that I need one feature - class inheritance. Is this solved? The solution my assigning methods more times is not clean for me. I think that simple inheritance should be supported - just adding super-class id and using super-class methods. Many other languages support single inheritance only. If there is something I can do to have this in next version tell me.
Not to my knowledge.
Although I don't find that this is a problem. Most of my polymorphic classes that need to be registered contain the followign static methods:
static void registerType(asIScriptEngine* engine){ registerMethods("this class", engine); Base::registerMethods("this_class", engine); // etc...}static void registerMethods(const char* name, asIScriptEngine*);static void registerMembers(const char* name, asIScriptEngine*);This way registering a class hierarchy is not a big deal, although I don't use big hierarchies anymore or I don't need to expose them to angelscript.
Author
Hi SiS-Shadowman,
I know about this solution, but for me it's rather workarount than serious solution. I'd like to implement this feature myself, but it need some time to understand how AS works;) I think that adding single inheritance model shouldn't be hard.
I know about this solution, but for me it's rather workarount than serious solution. I'd like to implement this feature myself, but it need some time to understand how AS works;) I think that adding single inheritance model shouldn't be hard.
It would be necessary to support multiple inheritances too, which is quite common in C++.
Virtual inheritance isn't supported, but it's not used very often so it's not a big problem. It would be necessary to detect and give an error in case the user tries to register a class with virtual inheritance though.
Virtual inheritance isn't supported, but it's not used very often so it's not a big problem. It would be necessary to detect and give an error in case the user tries to register a class with virtual inheritance though.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
