And ArkScript was born. I wanted to keep it tiny, under a megabyte, with a few keywords to do everything.
I think I can say I achieve what I wanted to do, now we are working with a small team to improve the code, the documentation, and the standard library. The language is indeed small and fast (even if we can do better, and I'm still seeking for more speed), with immutability (with 'let'), and closures (note that we can read the data captured by a closure easily, as a small object, through for notation: object.field).
Would it be possible to write a REPL using ArkScript or use the compiler from within the language?
Also, I'm really curious how you got so many people to work on the language. How did you accomplish this?
Yes it's possible to launch a REPL by using the `-r` or `--repl` option when launching ArkScript executable.
A few people contributing on the language are people I know from some programming discord servers, and the others came to work on the project after discovering it thanks to the hacktoberfest tags I put on the issue.
Because I think (could be wrong) elm, purescript, clojurescript and few others are immutable.
Also, if you create objects by making all variables within a function scope accessible outside the function, do you have a means for private local variables that don't get exported?
For example, this is what FFI could look like in some language:
lib = ffi.load("kernel32)
lib.TerminateProcess.args = (ffi.voidptr, ffi.unsigned)
lib.TerminateProcess.returns = ffi.int
lib.TerminateProcess.callconv = "stdcall"
It's not a FFI but an interface using the VM API.
Since an example is worth a thousand words, here is a function for the http module, counting argument, checking the types and then using the values to create an http client (to make http requests to web servers): https://github.com/ArkScript-lang/modules/blob/refactoring/h...
I should definitly rename this part as stated in another comment, since the "FFI" isn't a real one, I messed up with the vocabulary
I used the Ackermann Péter fucntion, still the same parameters (3, 6), on spidermoney (js engine for Firefox 74.0, windows 10, i7 8k)
Thanks for the link, I'll definitely dig down into that!
WASM would just make everything more complicated for no good reason. You can't do JIT-compilation on the consoles or iOS, so it's not going be performing any better than a simple interpreter.
If you go the interpreter scripting route, what you really want is trivial and comfortable binding to native (engine) code. You likely want your engine functions to be intrinsics in the VM.
Otherwise, you'll want to go the AOT compiled scripting route, which offers better performance. Then you just do the "scripting" in C++ (UE4) or C# (Unity).
C# is a very performant and efficient language that I thought a lot more games would be written in top-to-bottom today, at least in indie circles. (Sure, performance tuning C# is a different art to C++ performance tuning, but it is a very similar art [know your data structures, keep an eye on your allocations, pool memory where you can].)
That "Safety isn't something game developers value highly" says a lot about why that C# bubble popped and C# right now is "merely" that weird scripting language choice for Unity.
The second reason is modding: World of Warcraft is scripted using Lua (like many games) and players can overwrite a lot of things via addons themselves being written in Lua.
It's also partly due to C++ being the Lingua Franca of game development - if it were a slightly less complicated/difficult to deploy language you could use both (I have built a toy GUI app that live compiles D code into an object file, and calls an entry point with a nice OOP interface into a made up data structure, it worked pretty well but I don't know much about games so I don't have much use for it). C++ is also ridiculously slow to compile (at it's beautiful worst) so having AI logic (say) in the main codebase is a bit of an issue for designers.
I think the scripting language was called Dyon.