forked from cheng/wallet
53 lines
2.3 KiB
Markdown
53 lines
2.3 KiB
Markdown
|
---
|
||
|
|
title: Scripting
|
||
|
|
---
|
||
|
|
|
||
|
|
Initially we intend to implement human to human secret messaging, with
|
||
|
|
money that can be transferred in the message, and the capability to make
|
||
|
|
messages public and provably linked with an identity
|
||
|
|
|
||
|
|
But obviously we are eventually going to need bot responses, and bot
|
||
|
|
scripts that can interact with the recipient within a sandbox. Not wanting
|
||
|
|
to repeat the mistakes of the internet, we will want the same bot language
|
||
|
|
generating responses, and interacting with the recipient.
|
||
|
|
|
||
|
|
There is a [list](https://github.com/dbohdan/embedded-scripting-languages) of embeddable scripting languages.
|
||
|
|
|
||
|
|
Lua and python are readily embeddable, but [the language shootout](https://benchmarksgame-team.pages.debian.net/benchmarksgame/) tells us
|
||
|
|
they are terribly slow.
|
||
|
|
|
||
|
|
Lua, however, has `LuaJIT`, which is about ten times faster than `Lua`, which
|
||
|
|
makes it only about four or five times slower than JavaScript under
|
||
|
|
`node.js`. It is highly portable, though I get the feeling that porting it to
|
||
|
|
windows is going to be a pain, but then it is never going to be expected to
|
||
|
|
call the windows file and gui operations.
|
||
|
|
|
||
|
|
Lisp is sort of embeddable, startlingly fast, and is enormously capable, but
|
||
|
|
it is huge, and not all that portable.
|
||
|
|
|
||
|
|
ES (JavaScript) is impressively fast in its node.js implementation, which does
|
||
|
|
not necessarily imply the embeddable versions are fast.
|
||
|
|
|
||
|
|
Very few of the scripting languages make promises about sandbox
|
||
|
|
capability, and I know there is enormous grief over sandboxing JavaScript.
|
||
|
|
It can be done, but it is a big project.
|
||
|
|
|
||
|
|
Angelscript *does* make promises about sandbox capability, but I have
|
||
|
|
absolutely no information its capability and performance.
|
||
|
|
|
||
|
|
Tcl is event loop oriented.
|
||
|
|
|
||
|
|
But hell, I have an event loop. I want my events to put data in memory,
|
||
|
|
then launch a script for the event, the script does something with the data,
|
||
|
|
generates some new data, fires some events that will make use of the data, and
|
||
|
|
finishes.
|
||
|
|
|
||
|
|
Given that I want programs to be short and quickly terminate, maybe we
|
||
|
|
do not need dynamic memory management and garbage collection.
|
||
|
|
|
||
|
|
Lua is slowed by dynamic memory management. But with event
|
||
|
|
orientation, dynamic memory management is complete waste, since your
|
||
|
|
only memory management is allocating continuation objects to be fired on
|
||
|
|
the next event - which is to say, all memory management is explicit, when
|
||
|
|
an event handler detaches.
|