Don't we have enough languages already? This is a fair question. Here we'll explain why we created Monte and what's interesting about it.
Because Security Matters
Secure distributed computing should not be hard. Computers are getting faster, smaller, more connected, and more capable, but when it comes to security, everything is broken. A major cause is the "water balloon" design philosophy of contemporary languages and frameworks: Security is only enforced at the edges of programs, and not within the structure of programs themselves. Monte takes the object-capability paradigm of E  and expands on the approach, delivering a powerful and expressive language.
Can we reuse existing languages?
Disciplined use of existing languages such as Java and ECMAScript can be used to build object capability systems, but the standard practices and libraries are not compatible with this discipline. We believe that nothing short of a capability-safe-by-construction language can enforce capability discipline.
Monte, like E before it, has dramatic advantages for secure distributed systems:
- Capability-based security enables the concise composition of powerful patterns of interoperation--patterns that enable extensive cooperation even in the presence of severely limited trust.
- Monte promises benefit from a promise-pipelining architecture which ensures that most deadlocks cannot occur. [*]
- Monte offers cryptographic services directly to its users, easing the use of good cryptographic primitives.
Because Readability Matters
The origin of Monte's name
The Monte language has its roots in the E and Python languages. We took "Monty" from "Monty Python", and put an "e" in there. Thus, "Monte".
Monte wraps its strengths in a Python-like syntax to make it quickly comfortable for a large number of software engineers.
Because Stability Matters
Monte is dynamically typed , like Smalltalk, rather than statically typed, like Java. Users of Perl and Python will immediately recognize this is an advantage; Java and C++ programmers may not be so sure. Fortunately, Monte inherits two forms of contract-based programming from E: :ref:`guards<guards>` and :ref:`interfaces<interfaces>`.
Monte is dynamic in three ways:
- Dynamic Typing
- The type of a variable might not be known until runtime, and "types are open".
- Dynamic Binding
- It is possible to pass a message to an object that will never able to handle that message. This provides a late-binding sort of polymorphism.
- Dynamic Compiling
- Monte can compile and run Monte code at runtime, as part of its core runtime.
While "arbitrary code execution" is a notorious security vulnerability, Monte enables the fearless yet powerful use of multi-party limited-trust mobile code.
Object Capability Discipline
A :dfn:`capability` is a reference to an object and represents authority to invoke methods on the object. The key to supporting dynamic code execution without vulnerability is :dfn:`object capability discipline`, which consists of:
- Memory safety and encapsulation
There is no way to get a reference to an object except by creating one or being given one at creation or via a message; no casting integers to pointers, for example.
From outside an object, there is no way to access the internal state of the object without the object's consent (where consent is expressed by responding to messages).
- Primitive effects only via references
- The only way an object can affect the world outside itself is via references
to other objects. All primitives for interacting with the external world are
embodied by primitive objects and anything globally accessible is immutable
data. There is no
open(filename)function in the global namespace, nor can such a function be imported. The runtime passes all such objects to an :ref:`entrypoint<entrypoints>`, which then explicitly delegates to other objects.
Why not Monte?
Monte assumes automatic memory management; the current reference implementation uses the PyPy garbage collector, and any other implementation will have to choose a similar scheme. As such, it is not a good language for low level machine manipulation. So do not try to use Monte for writing device drivers.
Monte's performance is currently quite unfavorable compared to raw C, and additionally, Monte's target niches are largely occupied by other dynamic languages with JIT-compiler-based runtimes, so it is not a design goal to compete with C or other memory-unsafe languages.
While Monte's usable and most architectural issues are resolved, it is still undergoing rapid development. See :ref:`roadmap` for details.
Quick Start Docker Image
If you have Docker installed, the quickest way to get to an interactive prompt
to run some Monte code is
docker run -it montelang/repl. This container
provides the essentials needed for most examples in this documentation.
A container with a shell and the full set of Monte development tools is
available on Docker Hub as well,
If you don't want to use Docker, the other supported environment requires the packaging/build tool Nix. It can be installed on Linux and OSX from their installer script:
curl https://nixos.org/nix/install | sh
Alternately, you can install it manually from tarball, DEB, RPM, etc.
Builds of Monte from source are straightforward, using Nix:
git clone https://github.com/monte-language/typhon/ nix-env -f typhon -iA monte
Once that's set up, you can install Monte by running:
nix-env -i monte
Interacting with the Monte REPL
Monte has a traditional "Read - Evaluate - Print Loop", or REPL, for
exploration. Invoke it as
monte repl. For example:
>>> 1 + 1 2 >>> "abc".size() 3
Getting Help about an Object
Monte strives to provide useful error messages and self-documenting objects:
▲> help(Ref) Result: Object type: RefOps Ref management and utilities. Method: broken/1 Method: isBroken/1 Method: isDeepFrozen/1 ...
Editor Syntax Highlighting
Emacs and Flycheck
Use Atom to install the package language-monte.
Support and Feedback
Or come say hi on IRC, in #monte on irc.freenode.net!
Miller, M.S.: Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. PhD thesis, Johns Hopkins University, Baltimore, Maryland, USA (May 2006)
See also a history of E's ideas.
|[*]||As with all sufficiently complex concurrency systems, deadlock is possible. That said, it has not been observed outside of specially-constructed pathological object graphs.|
|||in formal type theory, Monte is unityped.|