Wartbed:Architecture/Scripting
From Dark Omen Wiki
(Difference between revisions)
(→Community Comments) |
|||
| Line 101: | Line 101: | ||
If however, it's merely to avoid recompiling then some of the options above start to make more sense, although you'd be adding runtime overhead and code complexity. [[User:Rob|Rob]] | If however, it's merely to avoid recompiling then some of the options above start to make more sense, although you'd be adding runtime overhead and code complexity. [[User:Rob|Rob]] | ||
| + | |||
| + | :Thanks for the comments, Rob! Yeah, I basically agree with you. Many add scripting to their engines because "it is the thing to do", or "to make it easier for the content developers". But a programming language is always a programming language, and non-programmers will not necessarily have an easier time in a script language than the native one. For those times visual tools are generally better. | ||
| + | :Some things will be better suited to scripting though. For instance translating the DO CTL scripts. ANd for those times we want a language that is easy to use and understand, easy to integrate into the engine(s), fast to parse and execute, and powerful. | ||
| + | :Falcon and ChaiScript are, as you say, as complicated as many "real" languages. But they also have a very appealing syntax: ChaiScript reads more like a nicer Ruby and Scala. Lua, which however is the most common scripting language today, is actually not very good. The syntax is cumbersome and its code is in my experience very bug-prone. You can't easily express advanced constructs without verbose syntax, and you need to know the entire language before you can script. That's especially why I'm extra keen on ChaiScript and FalconPL atm. | ||
| + | :Really, bring on the comments! I really appreciate them! | ||
| + | :[[User:Mikademus|Mikademus]] 17:41, 17 February 2010 (UTC) | ||
Revision as of 17:41, 17 February 2010
As of yet, there is no need for scripting.
Options for script languages include
| Script language | Notes | Maturity | Embeddability | Ease of using from C++ | Language complexity | Script parsing/execution | Platforms | Licence |
|---|---|---|---|---|---|---|---|---|
| LUA | Designed for C for maximum portability. Some hoops (local wrappers) must be hopped for C++ integrations. | Well done | High | Easy | Medium. Sparse semantics. Procedural and OO paradigms. Vanilla but not particularly aesthetic syntax. | Fast | Most | |
| AngelScript | No notes yet | Medium rare | High | ??? | ??? | Fast? | ??? | |
| Ruby | No notes yet | Well done | Cumbersome? | Lowest | Higher. Single-paradigm, extreme OO design. CLosures, lambda, mix-ins. Very appealing and human-readable semantics and syntax. | Slower | All? | |
| Python | No notes yet | Well done | ??? | Low | High. The German of script languages: extremely well equipped libraries, has everything you'll ever need, but can be butt ugly. | Slow | All | |
| Minimal | Git download location | Rare | ??? | ??? | ??? | ??? | ??? | |
| Falcon Programming Language | Designed for maximum speed using C++. | Medium rare | High | ??? | High: Multi-paradigm: supports procedural, object oriented, prototype oriented, tabular, functional and message oriented programming models. Coroutines, multithreading, compile-time metaprogramming, reflection. Virtual file system. Small standard library. Mostly strict and clean style, functional code slightly messy. | Fast | Win,Linux, OSX | Dual: Either FPLL (similar to LGPL/MIT), or GPL |
| ChaiScript | Designed for C++ integration. Very easy to integrate into application - ca. three lines! Dynamically type scripting language inspired by Ruby and Scala. Type-safe inside C++. | Medium rare | Very high. | Easy | High: lambda, everything-is-an-object, closures; OO, functional, procedural and message paradigms.Very appealing syntax. Library is an exposure of C++ methods and STL types. | ??? | Source for Win, Linux, OSX. | Liberal and permissive home-cooked licence. |
Current favourites=
| 1st place | ChaiScript |
| 1st runner up |  |
| 2nd runner up | Angelscript |
| 3rd runner up | LUA |
Dream language: Ruby, if it would be fast enough interpreted and embedded
Community Comments
Seems to me that there would be little point implementing some of these scripting languages, since they aren't really a lot simpler than C++.
If the idea is to facilitate third party editing, then something that is approachable for those with little programming experience would be preferable.
If however, it's merely to avoid recompiling then some of the options above start to make more sense, although you'd be adding runtime overhead and code complexity. Rob
- Thanks for the comments, Rob! Yeah, I basically agree with you. Many add scripting to their engines because "it is the thing to do", or "to make it easier for the content developers". But a programming language is always a programming language, and non-programmers will not necessarily have an easier time in a script language than the native one. For those times visual tools are generally better.
- Some things will be better suited to scripting though. For instance translating the DO CTL scripts. ANd for those times we want a language that is easy to use and understand, easy to integrate into the engine(s), fast to parse and execute, and powerful.
- Falcon and ChaiScript are, as you say, as complicated as many "real" languages. But they also have a very appealing syntax: ChaiScript reads more like a nicer Ruby and Scala. Lua, which however is the most common scripting language today, is actually not very good. The syntax is cumbersome and its code is in my experience very bug-prone. You can't easily express advanced constructs without verbose syntax, and you need to know the entire language before you can script. That's especially why I'm extra keen on ChaiScript and FalconPL atm.
- Really, bring on the comments! I really appreciate them!
- Mikademus 17:41, 17 February 2010 (UTC)
