When writing software, I test my code using a *compiler* (GCC, rustc) or an
*interpreter* (Node, PyPy). I write in an *editor* (vim, VSCode), which probes
my code via *static analyzers* (tree-sitter, LSP). I interact with programs in
a *debugger* (LLDB, RADDBG), which pulls from *debug symbols* (PDB, DWARF). My
tools act in isolation, and rarely communicate. Developers have built a
collection of opaque, individual tools, which can be used in various langauges
and environments. Before now, I was okay with this. But after working in one
language and one environment for a long time, the separation between the tools
felt less practical. I wanted a unified language and dev kit. That's something
that already exists in many places, but doesn't really have a name.

So I'd like to popularize the term *language machine*.

A language machine is a programming language with a defined environment. A user
puts code into the machine, the machine runs the code, and the code can then
interact with the machine. Code can modify itself and read its own structure.
Language machines also typically provide a display API, so it's easy to create
interfaces. From there, editors, debuggers, and analyzers can be written and
modified in user-space. The OS lingo is no mistake - language machines tend to
look a lot like virtual machines running fantasy operating systems.

[Emacs] is the classical example. All scripting is done in Emacs Lisp, and you
can interface directly with the interpreter. Emacs also provides text display,
which means all programs share a cross-platform UI layer. Users have built text
editors, email clients, and web browsers in Emacs - all improved by the open
system. This provides a great developer experience and incredible freedom:

> Emacs can be understood as a unique tool for free thought, i.e. imaginative
> effort limited only by mastery of tools and techniques, empowered and
> uncoerced. [...] it becomes difficult to imagine using anything else unless
> forced or obligated, because other 'similar' software is bound by more or
> less well-intentioned constraints of givenness, and trades some amount of
> freedom for immediate utility, i.e. trades fulfillment for satisfaction.
> - Wax Banks, [bare metal (the emacs essay)]

I'm frustrated that dev tools don't feel like creative tools. The existing
fractured ecosystem is the reason, and this is the fix. In the same way a guitar
is an instrument for music, a language machine is an instrument for computing.

It's not just Emacs. [Oberon] is a machine that runs the Oberon language and
displays text. In the UI, middle clicking on a word runs the Oberon function
with that name, so a save button is just the text "save". [Picotron], the
successor to Pico-8, is a machine that runs Lua at a fixed clock-rate with a
pixel display. It's essentially a modifiable game engine, where all the tools
and editors are built in the engine itself. Even web browsers could be seen as
Javascript machines, with an HTML display for both browser UI and user UI.