The Ecstasy language (XTC^[1]) is the reference language implementation for the XVM.

Ecstasy and the XVM exist in a technology field filled with existing knowledge an experience. It was our intention, in designing the Ecstasy language, to leverage as many existing concepts and design idioms as we could from the most-used languages and technologies, so that someone with existing knowledge in the field would immediately feel at home both reading and writing in the Ecstasy language.

However, despite our careful effort to make Ecstasy look and feel like well-known languages, there are dramatic differences in the Ecstasy language and its underlying design, and understanding each of these differences (and the careful design and rationale for each choice) will take both time and effort.

The purpose of this language specification is to organize and enumerate the design of the language, and to act as reference material for the language. Be forewarned: Reading a language specification is a difficult way to learn a language, but on a positive note, it is quite effective.

All designs have priorities, but only some designs begin with the end in mind. When priorities are not explicitly stated, it is easy to chase the priorities that most effectively combine compulsive emotional appeal with apparent ease of implementation, in lieu of the priorities that are most valuable to the intended audience of the design. In order to create a coherent design that serves the intended audience, this specification began with a conscious discussion about priorities, and a series of explicit decisions as to what those priorities would be:

1. Correctness, aka Predictability. The behavior of a language must be obvious, correct, and predictable. This also incorporates The Principle of Least Surprise.

2. Security. While generally not a priority for language design, it is self-evident that security is not something that one adds to a system; security is either in the foundation and the substrate of a system, or it does not exist. Specifically, a language must not make possible the access to (or even make detectable the existence of) any resource that is not explicitly granted to the running software.

3. Composability. High-level computer languages are about composition. Specifically, a language should enable a developer to locate each piece of design and logic in its one best and natural place.

4. Readability. Code is written once, and referenced many times. What we call “code” should be a thing of beauty, where form follows function.

5. Lastly, a language must be recursive in its design. There is no other mechanism that predictably folds in complexity and naturally enables encapsulation. It’s turtles, the whole way down.

Undoubtedly, the largest change in software in the past few decades has been cultural and not technological. The term “open” has long been used for marketing commercial software that had some slight yet often-only-theoretical potential for interoperability with other commercial software. Today, most core software components, libraries, operating systems and applications are available in complete source code form for use under open source or software libré license, and many of the specifications and standards – including languages and execution systems – that enable interoperability are similarly open and available. From an economic standpoint, it would appear that the demand for a fundamental set of software standards and components being available as a public good eventually out-weighed the cost of creating and managing that public good (even in some cases lacking any consistent centralized authority!), and the cost of reverting to private goods for that fundamental set of software standards and components is unacceptable for all but the most especial of requirements.

It is in this spirit that the Ecstasy specification (XTC/XVM) and source code will be made available, with its ideas and concepts often inspired from the visions of others, and – if any prove worthwhile – its own ideas and concepts freely available for re-use and recycling as the reader sees fit. To accomplish this, the source code will be made available under both a permissive open source license (Apache v2) and a software libré license (GPL v3), and the specifications will be made available under the permissive Creative Commons CC-BY-4.0 license.

None of these ideas occurred in a vacuum. The initial inspiration for this effort was the Java Virtual Machine, which was groundbreaking in its timely fusion of brilliance and pragmatism, and which is described in beautiful detail by the Java Virtual Machine Specification and the related Java Language Specification. Older languages such as C, C++, Python, and Erlang left their own indentation on our thinking as well. Many concepts of the XVM will be familiar to Smalltalk programmers, who to this day righteously espouse that all subsequent programming advances were already present in and perfected by Smalltalk, which unfortunately met its untimely demise as the result of a vast right-wing conspiracy. More recently, languages such as C#, Ruby, Scala, Go, Ceylon, and Kotlin have stretched our imaginations, each with their own pragmatic preview of a potential programming future, and with systems of execution such as the Sun Hotspot JVM, Microsoft CLR, Google V8, and LLVM managing to occasionally exceed even the scope of imagination with their practical ingenuity.

XTC is an abbreviation for XVM Translatable Code, and is also known as “Ecstasy” ↩