Announcing Spritely Oaken
45 points by mplant
45 points by mplant
Engines are a Scheme idea introduced by Kent Dybvig and Bob Hieb. The basic concept is that the system runtime keeps track of how many units of computation (‘ticks’) have been executed, and when that number exceeds a certain limit (the amount of ‘fuel’ in the engine), it pauses execution and returns the unfinished task back to whoever started it. They can then decide whether to stop running the computation, or give it more fuel and carry on.
Some might know this idea as “gas”, a key component of Vitalik Buterin’s 2014 Ethereum whitepaper and the subsequently deployed cryptocurrency system. But Dybvig and Heib published in 1988! And, checking their reference section, they are building on earlier work on timed preemption, a basic concept you might recognized from multitasking operating systems. Buterin didn’t cite a source, but I doubt that “gas” was an independent reinvention.
See also Lua’s count hook. Or “ticks” on LambdaMOO. This sort of thing is old hat; I suspect it dates a long time back.
I don’t know exactly when the concept of “gas” was introduced but, for what concerns in computer science, the formalization of the semantics of a program as a sequence of atomic steps dates at least back to Plotkin’s A Structural Approach to Operational Semantics, where what is now commonly known as small-step operational semantics is described.
This formalization is then used in “step-indexed evaluators”, which are roughly akin to interpreters with gas. For example, something similar can be found here; if I am not mistaken, the first version of this book was released in 2011, a couple years before Buterin’s whitepaper.
Very cool to see this sort of development based on research, and using Scheme, no less!
Sounds kind of like an effect system plus capabilities. (Don’t some Lisps already have effects?)
Hardly a week goes by without yet another story of some rascal sharing a Minecraft mod pack on a forum or uploading a mod to the Steam Workshop which, in reality, exists to steal browser cookies or passwords.
Never really heard about one of these in World of Warcraft (Lua) - I once found one in another game with Lua mods, but it was nothing too bad.
Lua is typically used in an embedding context where the engine can control what effects are exposed to the VM, which means that the script engine can’t get access to file or network primitives without some sort of VM exploit. Of course it may be possible due to oversights that allow loading Lua C API modules, but it’s usually fairly suspicious to ship a simple mod with a DLL or other shared library.
Minecraft mods are just JARs that are loaded into the same unrestricted JVM instance as the game itself, and it’s not uncommon for JARs to opaquely package JNI shared libs which aren’t quite as facially obvious.
I think a better way of putting it is that Lua was carefully designed to make it easy to restrict the capabilities of code (whether embedded or not), whereas Java somehow despite its roots in browser applets just didn’t bother to build this into their execution model very gracefully.
I feel like the Java original authors were thinking about writing server & desktop stuff but it kinda got shoved into browser because gold rush reasons
At first it was supposed to be for PDAs and TV set-top boxes, but that didn’t pan out and Sun had to pivot to web applets within a couple years. That was the big success: that’s where the “billions of devices” came in. The desktop and server apps came significantly later.
Sure but you still benefit hugely from the ability to do sandboxing when writing desktop software.
That’s why you should demand open source Minecraft mods, or at least so-ancient-theyre-fully-analyzed closed mods.