Could someone clarify why you'd want to have a JavaScript engine in your C/C++ Project?
Is the idea if you have a desktop app executable wrapper and you could include this engine to start building desktop apps in JavaScript?
I don't think I have a clear understanding of this type of use case or how this will be used, please share.
The only thing I can think of is you could use this JS engine allow folks to code in JS, instead of C/C++, that actually interface with C/C++ APIs? Examples anyone?
There are lots of reasons to want some form of scripting language embedded inside a C++ project. This is the primary use case for Lua, especially in game development. For example
- In a game, write quest logic in the scriptable language so that game devs can tinker with quest design without recompiling the game binary.
- "plugins" (usually UI plugins of some kind). Games like Elder Scrolls Online and World of Warcraft allow for 3rd parties to write UI extensions in Lua.
- Any other logic that you want to run and frequently modify without modifying the binary.
There are other great uses-cases that I can't think of right now, hopefully others can help.
Scripting in game development is also very helpful for programmers when bug fixing. I've had the situation where a game designer told me about some bug in an elaborate mission, and instead of playing through the entire mission to recreate the one thing that breaks, I could quickly with a few lines script the small scenario necessary to create the bug. (eg. spawn a car, attach car to road, make the car drive through the intersection, hit crash)
Any non-trivial JS code is likely to be closely tied to the original platform/runtime for which it was meant, and thus hard to port. (Vs. purely computational)
I have experience of porting JS code from one environment to another. First I was using Delphi Application with MS Active Scripting and MS JScript Engine then moved to nodejs on linux, then back to windows on nodejs, and still have JS code originally written for MS Active Scripting. With nodejs vm module you may create needed context. I also was successfully using socket.io and code on top of it with MS Active Scripting based application by implementing simple WebSocket wrapper to Delphi component.
A big one for me is networking (using other high level languages as well). It frees you from having to worry about buffer overflows and other exploits, as long as you deal with all untrusted data in the sandbox and only pass your resulting data between the high and low level languages as something like UTF-8.
It also greatly simplifies logic because you can do pattern matching and filtering (similar to Erlang) more concisely than in C.
I think that coroutines are on the verge of replacing callback hell so we'll start to see patterns from Go begin to show up in other languages, perhaps embedded in this way. The browsers dragged their feet for years by not implementing generators and yield (in ECMAScript 6) and set javascript back immeasurably, so being able to go around them with embedded libraries will be huge.
In a more generic sense, since 10% of a program causes 90% of the slowdown, there is little speedup to be gained by using C in the real world, especially if it's mostly using system calls that are already optimized. Some examples of this are how a high level language like php has succeeded in the server world even though it's not particular fast or elegant, and how Objective-C is often still slow even though it's low level (because programmers sometimes do too much with their "bare hands" rather than building upon heavily optimized libraries like C++'s Boost). I think this explains the rapid adoption of Swift, which is basically another high level language in place of a more painful low level one but providing similar performance.
A embedded script engine is good for fast development, fast modification, fast experiment, and adding some app-specific DSL. E.g. in a C++ game, changing some rules or some config would take a re-compile of the project, deployment, and restart. Moving the game logic, rule, map layout, asset, config, etc, to the embedded script engine would allow immediate changes via reloading of the script while the game is running.
For embedding, you need some small language with small runtime. Something like Scheme/Lisp/Lua would work. Something like Python is not suitable. Lua is popular in the gaming scene because of its small size and its well designed architecture for embedding. Looks like Javascript is getting there.
This is a wild overgeneralization. Civ4 used Python as its embedded scripting layer to great success.
(Me, I just use C# as a scripting layer inside of a C# application. On desktops, the content C# is compiled or read from cache at runtime, but on other platforms I can include the scripting libraries as project references and have them incorporated into stuff like Mono's AOT linker. http://github.com/eropple/exor )
Low-level (like, just about assembly, maybe slightly higher) workloads that require high performance or are annoying to do any other language.
What is C++ good at?
All of the stuff C can do, but also bolting on a weirder type system, generics, metaprogramming, and a whole bunch of other stuff. It's fast, but rapidly becomes a festering tumor of functionality.
It's a katamari of design features, and even though it exposes a lot of awesome high-level abstractions the fact that it still allows working at the C level prevents it from being compelling.
What about JS?
Javascript is dynamically typed, which is terrible in many ways but bloody useful for quickly getting shit done. It is a functional language with prototypical inheritance, and so naturally lends itself to high-level programming...with regexes and functions as first-class objects, and a really pretty simple type system.
It sucks at high-performance stuff, but it allows for a lot of clever and very brief code.
So, if you want high-performance and the power of high-level abstractions, it makes sense to use C and JS--each a fairly small language well-suited to its problem domain. C++ would require too much annoying work on both sides of the problem.
A good workload for this would be: in-game scripting, network message transforms, simple command-line utilities, game engine writing, numerical library writing, asynchronous IO processing..basically, any application where you can easily separate out the low-level primitives from a flexible high-level solution description.
~
Then again, for all of what I'd said, I think you might as well just be using Erlang or Elxiir. :)
Did you coin this phrase? It's a fascinating, evocative, and quite possibly accurate description of many of the systems I find most frustrating. In any case, thank you for bringing a smile to my face today :)
It's handy for creating DSLs. For example, I'll point to SpringRTS, an open-source RTS gaming engine.
There are three concerns that make an embedded language good:
1) Lockstep multiplayer. Each player has a full copy of the gamestate on their client. Every action performed against the gamestate is done in sync on every machine in a deterministic fashion and order. This means that any custom code must be written with preserving sync in mind - something as simple as rand call on the clients would break sync. So Lua allows the engine developers to properly restrict the users to only use libraries and language constructs that will respect the sync (it fails at this, but it's a goal and Lua helps with that).
2) Code from peers. Users develop code for other users - widgets that help on the user-interface and games for each other to play. A sandboxed environment is a must.
3) Graceful failure. If a widget fails it doesn't bring down the whole engine with a segfault.
The main one for me is portability to mobile devices. I've recently built a web project with python/flask where the meat of the logic was done in serverside JS in V8. This needed to be offline capable on mobile, so when the time for that came we only had to port the Flask shell and DB logic to Obj-C while the renderer / update mechanism etc. would just work in JavascriptCore.
I guess it would allow you to ship the core of your software compiled as C/C++, and then system-integrators/sysadmins/hackers would script against your APIs in a higher-level language. No need to recompile or for users to see your source code.
Embeddable, small-footprint JS allowing the masses to script things with sounds pretty useful!
I love this. There are a ton of web developers out there who know JavaScript, and there are a ton of scripting systems written in Lua. It makes a lot of sense to add support for putting (what I'm assuming is) the most widely distributed programming language on earth in your C/C++ app.
Is the idea if you have a desktop app executable wrapper and you could include this engine to start building desktop apps in JavaScript?
I don't think I have a clear understanding of this type of use case or how this will be used, please share.
The only thing I can think of is you could use this JS engine allow folks to code in JS, instead of C/C++, that actually interface with C/C++ APIs? Examples anyone?