SCROLL DOWN FOR SCREENSHOTS & DOWNLOADS.
MettaScript is the front-end technology which provides a simple and easy-to-use interface for developing algorithms (and also for dealing with less-rational types of mathematical formulae).
In other words, MettaScript is a General Purpose Calculator.
The latest ALPHA QUALITY build of MettaScript is available here.
This build is an executable .jar file (e.g. run "java -jar metta-full-0.0.3-alpha.jar", substituting the version information from the build you downloaded).
The source code is included in the .jar file. The source is and can be extracted using an archiving tool. The editor as a whole does depend on some third-party libraries (see MettaScript Editor's "Help" menu for more information) but the core runtime and interpreter only depend on a recent version of the Java Runtime Environment.
The source is also mirrored on GitLab and GitHub, but it might be a bit of a pain to build (no Maven support yet, and the dependencies must be downloaded separately -
build.sh should give you some idea).
MettaScript has a number of benefits over other modern technologies, but which ones are more important will depend on your use case.
(I studied enough marketing to know that core benefits are important, but not enough to understand why most products focus on a single one.)
Compared to a programming language (e.g. Java or Python), it's easier to do math.
1in + 2cm (how would you do that in Java or Python?).
Bonus: It's also easy to use functional, procedural or object-oriented paradigms.
NOTE: The inches & centimetres example doesn't work yet (and, for that matter, such examples won't ever work perfectly for all cases). Stay tuned for more intuitive math functionality!
Compared to a spreadsheet platform (e.g. Microsoft Excel), it's easier to deploy & scale.
Bonus: It's also a lot easier to do math (it's based on traditional mathematical symbols, not mnemonics and cells).
Compared to an extension language, it's more flexible.
Example: You can automatically detect what functions the formula expects (e.g. to tell if a game script is for AI or for map setup, or to test for compatibility before running).
Bonus: It also has multiple reference implementations (at the moment, one for Java and one for C/C++/Pascal).
ZVM & ZSS are the preferred back-end technologies for deploying MettaScript formulae.
ZVM is the core virtual machine, while ZSS is the scheduler & communications system. (ZVM has nothing to do with IBM's z/VM or Infocom's Z-machine, by the way. It will probably be given a longer name prior to release.)
ZVM is written in pure C (but could also be used from C++ or Pascal) and is designed for any modern 32- or 64-bit computer architecture, from Web Browsers and toy hardware all the way up to Phones, PCs, supercomputers and robots.
ZSS is an additional layer built on top of ZVM's core virtual machine functionality. It provides input/output and multiprocessing capabilities which can be used to run stand-alone applications written in MettaScript. It can also be embedded in other applications written in C/C++/Pascal.
ZVM & ZSS are still under heavy development, and may not be released in the same (public) style as MettaScript. (Depending on how things pan out, they might become commercial products sold by subscription. However, rest assured, they will still be 100% public domain - once you get your hands on them, they're yours, and you can redistribute them freely under your own terms.)
Like MettaScript, ZVM's best benefits depend on what you're using it for. Since ZVM is more focused towards application deployment than general calculation, the core benefits described here are also a lot more specific and in-depth.
For developers, this means it's still very easy to get started with ZVM, but the overall picture for deployment and maintenance is simpler because the front-end tools are kept separate. (You don't have to include the front-end in your ZVM-based application, and you can use a customised front-end without necessitating changes to the virtual machine or application).
Have you ever wondered why computer programs always have to save things to files explicitly? Can't they just "remember" everything next time they open?
Of course they can!
This is how object-oriented programming was designed to work, and as well as being popularised to some extent by Smalltalk, these features have also been available in other places for decades. (Many LISP and FORTH implementations, as well as emulators and virtualisation packages, already feature integrated persistence).
Now, this functionality is more flexible than ever and also more easily accessible to the C/C++ universe! Now you can use persistence in a simple "remember everything all the time" kind-of way, or control it exactly to your liking by employing it on a per-object or per-document basis.
ZVM is small and lightweight by default, and should be comparable in size and portability to something like Lua or Duktape, but ZVM is also designed to cope with extremely large workloads, such as 3D movie rendering and robot navigation.
The key to scalability in ZVM is the design of the object identifiers, which are polymorphic (can store or reference objects of different types) and feature flexible inline representations (so compared to a traditional dynamically-typed virtual machine, less types of objects have to be "boxed" in a full object representation, and compared to a traditional statically-typed virtual machine, code doesn't need to be type-aware all the time in order to use efficient representations).
ZVM also differs to other virtual machines in it's full object representation, making it much faster and less memory-expensive to allocate, deallocate and query objects than using a traditional "malloc-like" allocator. Unlike certain other virtual machines (not mentioning any names here...), ZVM uses a precise garbage collector, so it doesn't waste time looking for object references in non-referential data such as byte arrays, and it can also (in the future) move objects around safely in order to reduce fragmentation, cache misses and memory usage.
ZVM is designed for massive text processing, beyond the scale of archive.org or the US Library of Congress. (Alexander the Great asked for a universal library, of which today's Internet is merely a crude approximation. If anybody is to know what he really had in mind, then they will require much more capable infrastructure.)
Not all of the pieces of the puzzle are in play yet - right now, ZVM's text processing capabilities are about on par with an onion, but here's a teaser of what's to come:
(If you're curious, the storage model combines ideas from the string package included with the Boehm-Demers-Weiser garbage collector with ideas from Smalltalk, whereas the language model is a Smalltalk-like incarnation of an extremely simple historical system of combining languages - think "what is ten times more obvious than Unicode?" or "what do you call a thick yellow line with no ends?".)