Magik

Magik is a dynamically typed, object-oriented programming language created at Smallworld to build and extend the Smallworld Geographic Information System (GIS). It is an unusual survivor: a proprietary, application-specific language from 1990 that is still actively used and developed more than three decades later, because the software it powers — today GE Vernova’s Smallworld platform — remains one of the most widely deployed GIS products in the utility and telecommunications industries. Almost everyone who writes Magik does so to customize Smallworld, which means the language and the product have always been inseparable.

History and Origins

Magik was designed and implemented in 1989 by Arthur Chance at Smallworld Systems Ltd., a company founded in Cambridge, England. It was introduced commercially in 1990 as the foundation of the Smallworld GIS. The motivation was practical: the team wanted to build a large, highly interactive, data-rich application, and the mainstream systems languages of the day — Fortran and C — were poorly suited to rapid, exploratory development of that kind of software. Rather than bolt a scripting layer onto a C core, Smallworld did the reverse and built the whole product in a new high-level, object-oriented language with an interactive development environment, an image-based runtime, and libraries oriented toward geospatial data.

That decision shaped the company’s identity. Smallworld grew into a leading vendor of GIS for network industries, and in 2000 it was acquired by GE Energy (the deal was announced in August and completed in October that year). Through GE’s subsequent reorganizations the product passed through GE Digital and then to GE Vernova, the energy business that became an independent company in April 2024. Across all of those ownership changes, Magik remained the language in which Smallworld is written and customized.

Design Philosophy

Magik is most easily understood as a relative of Smalltalk. It shares Smalltalk’s central ideas: nearly everything is an object, the language is dynamically typed, code is developed and run inside a persistent, image-based environment, and behavior is invoked by sending messages to objects. Like Smalltalk, Magik favors an interactive, incremental style — you compile a method into a running image and immediately try it — over the edit/compile/link/run cycle of C.

Where Magik differs is in its object model and its syntax:

• Exemplar-based objects with multiple inheritance. Magik does not have classes in the Smalltalk sense. Instead it uses exemplars — prototypical objects that define slots (instance data) and methods — and a new instance is cloned from an exemplar. The model supports multiple inheritance and polymorphism, which suits the deep, branching type hierarchies of a large GIS data model.
• Dynamic but strong typing. Variables are not declared with types and can refer to objects of any kind at runtime, but operations are checked against the actual object, so type errors surface as runtime conditions rather than silently misbehaving.
• Underscore keywords. A distinctive surface feature is that Magik’s reserved words are written with a leading underscore — _method, _endmethod, _if, _then, _else, _for, _loop, _endloop, _self, _return, and so on. This was a deliberate choice so that ordinary English words could be used freely as identifiers without colliding with the language’s keywords.

Key Features

Assignment and syntax

Magik uses << as its assignment operator and supports C-style compound forms such as +<<. Comments begin with #, and symbols (interned name constants, used heavily as keys and identifiers) are written with a leading colon:

_method employee.print()
    # write sends text to the current output
    write("Name: ", _self.name)
    write("Salary: ", _self.salary)
_endmethod
$

Here _method ... _endmethod defines a method on the employee exemplar, _self refers to the receiving object (much like self/this), and the trailing $ is the statement terminator that the interactive environment uses to know a chunk of code is complete.

Exemplars and slots

New object types are typically created with a slotted exemplar, which declares the object’s data slots and the exemplars it inherits from. Methods are then defined against that exemplar:

def_slotted_exemplar(:employee,
    {
        {:name,   _unset},
        {:salary, _unset}
    })
$

_unset is Magik’s equivalent of a null/undefined value. From an exemplar like this, instances are cloned, their slots populated, and methods invoked by sending messages.

Procedures, closures, and iteration

Magik treats procedures as first-class values: a _proc ... _endproc block creates an anonymous procedure (a closure) that can be stored in a variable, passed around, and invoked. Iteration is built around generators and the _for ... _over ... _loop construct, with the _gather and >> (emit) mechanisms used to produce sequences of values lazily. These functional features make it natural to express the data-traversal logic that a GIS does constantly.

Image-based, byte-compiled runtime

Historically, Magik source was compiled to a custom bytecode and executed by the Magik Virtual Machine, with program state captured in an image file that bundles compiled code together with the live object session — again echoing Smalltalk’s image model. Development is interactive: a running image is extended and modified method by method.

Evolution

The most significant change in Magik’s history is the move to the Java Virtual Machine. In July 2012, Smallworld’s developers announced that they were porting the language to run on the JVM, and the successful hosting was reported later that year. This matured into the Smallworld 5 generation (around the mid-2010s), in which the original Magik VM was supplanted by the JVM: Magik source now compiles to Java bytecode and runs in the same execution environment as Java. The headline benefit is interoperability — because Magik and Java compile to the same bytecode and share a runtime, Magik code can call Java libraries directly, opening the large Java open-source ecosystem to Smallworld developers while preserving decades of existing Magik code.

Tooling has modernized alongside the runtime. Where Magik was traditionally edited in Emacs with a dedicated Smallworld integration, a Visual Studio Code extension (published in the GE Smallworld / OpenSmallworld ecosystem) now provides syntax support, compilation, debugging, linting, and a class browser, bringing the language into a contemporary editor.

Current Relevance

Magik is a niche language by any global measure, but within its domain it is entrenched. Smallworld is among the most widely used GIS platforms for utilities and network industries — electric, gas, water, and telecommunications operators use it to model the connected networks that are the core of their business — and that software is built and customized in Magik. As long as Smallworld is in production at utilities worldwide, there is ongoing demand for Magik developers to extend data models, write business rules, and integrate the GIS with other enterprise systems. The JVM migration has, if anything, lengthened the language’s runway by letting Magik coexist with modern Java tooling rather than standing apart from it.

Why It Matters

Magik is a striking example of a company building its entire product on a purpose-designed language and sustaining that bet for over thirty years. It demonstrated, well before dynamic object-oriented languages were mainstream, that a Smalltalk-style interactive, image-based, multiple-inheritance language could be the foundation of serious, large-scale commercial software — not just a research curiosity. Its survival through multiple corporate owners and a complete runtime change (from a bespoke VM to the JVM) shows how a language tightly coupled to a successful product can outlast far more popular general-purpose languages. For the utilities that run the world’s electricity, gas, water, and telecom networks, Magik quietly remains the language in which a great deal of critical infrastructure data is managed.