Flare is a proposal for a new programming language, the
first annotative programming language, in which programs, data,
and the program state are all represented as well-formed
At present, I don't even have a publishable Flare whitepaper.
I don't even have a finalized design. I am engaging in the sin of
aggravated vaporware because I have been told, and convinced, that the
timeline does not make any sense without knowing some of what Flare is
and what it does. Please consider all discussion of Flare to have
whatever degree of tentativeness and subjunctivity is required for that
discussion to be an excusable act of speculation.
Since I do have over half a megabyte of design notes, I use the present
tense in discussing properties of Flare. Those properties are no
longer tagged as "subjunctive" in my mental model, and using the present
tense feels more natural (1). No claim that the Flare design has been
finalized is implied.
XML is to Flare what lists are to LISP, or hashes to Perl. (XML
is an industry buzzword that stands for eXtensible
Modeling Language; it's a generic data format, somewhere between generalized
HTML and simplified SGML.) The effects are far too extensive to go
into here, but the most fundamental effect (2) is that XML is easy to extend and
annotate, and this property extends into Flare programs and the Flare language
Our own cognition is also annotative - we note arbitrary facts about
things, and think in heuristics that act on arbitrary facts about things.
An "annotative" programming language, which recognizes this fact, is thus
a higher-level language. "Higher-level" means "closer to the
human mind" - annotative thinking is reflected in annotative language,
just as object-based cognition is reflected in object-oriented languages,
just as procedures are closer to our mental representations than assembly
Flare has four primary purposes:
To protect our base by making large-scale software programs
easier to develop. Annotative programming is fundamentally more scalable.
Modules can comment on arbitrary objects without introducing compile-time
dependencies, and this in turn allows for the natural existence of certain
design patterns for self-organization
(4). Flare, if successful, should decrease "ablative
dissonance" (5) by an order of magnitude.
To accelerate the development of AI by providing
A modern replacement for LISP-the-language-of-AI, based on XML instead
of linked lists.
An annotative program format so that AIs can notice and manipulate source
code in a natural way. (6)
An extensible language architecture, so that (some versions of) Flare One
can have features necessary to self-understanding code, such as:
The ability to watch a program execute (interpreted instruction by interpreted
instruction) in another thread, or a lower layer of the interpreter, so
as to visualize what it does;
An XML-based program state that can be annotated, noticed, and understood;
Both of the above, in a natural way that allows J. Random Hacker to write
AI or use AI without three months of preliminary work.
The annotative architecture for notice-level functions. This
one is the real, fundamental reason for Flare; in order for the world-model
principle to work, arbitrary functions have to be able to notice facts
about the world and notice other functions' facts about the world.
It may be possible to implement limited AI without Flare, but it won't
feel natural. To start an innovative AI industry, there has
to be a working AI language.
To create the potential for the timeline described below.
XML is extensible, and so is the Flare language, and so are annotative
modules written in Flare, and so are scalable programs built from annotative
modules. Because of this basic extensibility (as well as a number
of features included with malice aforethought), it should be possible to
move along the timeline by the natural accretion of features. As
a secondary benefit, it will be easier to move along the timeline
in a coherent way if we're the ones doing the development. (8).
To jump-start the PtS plan by providing something to develop that
isn't as difficult as AI. Even if work in AI bogs down at any point,
work on Flare can continue. Likewise, it'll be easier to create a
smoothly functioning Singularity Institute if there's an ongoing project
whose progress isn't so dependent on basic research.
Influenced, but not commanded, by the worse-is-better
philosophy from LISP:
Good news, bad news, how to win big, I've divided up the implementation
stages into the 50%-right version that spreads like a virus (Flare Zero),
the single perfect gem (Flare One)... and also the total development environment
(Flare Two), followed by effective integration with the Aicore line (programs
in "Flare Three" are essentially thoughts in the AI).
The current stage is Flare Negative One. I have at least 500K
of notes on Flare, but I haven't put them into publishable form yet.
I don't have a Flare whitepaper available; I could probably get one together
in, say, a month or so. Since I don't have a complete whitepaper,
I was reluctant to say as much as I've said already. I don't want
any crippleware versions coming out and depriving Flare of its incremental
benefit. (I'm not worried about crippleware AIs for the simple reason
that anyone bright enough to implement any part of the Aicore line without
my help - no matter
what I post on the Web - is bright enough to
do their own navigation.) I'm also reluctant to engage in acts of
aggravated vaporware, but I've been convinced it's necessary (9).
1: In other words, I'm willing to include
humble disclaimers for the sake of form, but not to go to any actual authorial
4: E.g. intelligent binding of variables by keyword, or semantic
comments, and so on for about three pages (literally) of cryptic titles
5: A cool phrase from Vinge's A Fire Upon the Deep;
I use it to describe problems associated with scaling up the size of a
6: To notice and manipulate LISP, you
need to transform it into an alternate data structure that can have comments
attached. The LISP program syntax itself does not allow comments.
This sounds like a trivial programming problem when considered in isolation,
but having to operate on diversely formatted instances of what is theoretically
a single piece of data can easily be the difference between writing complex
tools naturally, and writing simple tools with great effort.
7: Again, you can theoretically do this with a Perl hash or a Java
hash or Python objects or any number of other things, but it's not natural
to the language. You can write C++ code in C, but it won't be pretty.
easier to create needed language features if you control a language.
It's easier to integrate AI and a programming language if you control both.
But this is not allowed to be an independent consideration, since that's
the hacker sin of fragmentation - the Not-Invented-Here Syndrome under
vaporware may be more of a hacker sin than a simple "The Flare parts of
the timeline work by magic. If you'd rather not take my word for
it, feel free to skip the Flare parts of the timeline." (This is,
in fact, what a previous version of this document said, almost verbatim.)
But you can't plan a future based on magic. I will be as speculative
as I must to draw a concrete line, to make the component technologies visualizable
as achievable goals. Those who object on the grounds of vaporware
consider themselves free to read the Flare timeline as speculation.
Those who object on the grounds of immodesty should consider themselves
free to read the Flare timeline as something that "somebody ought to do",
rather than as a claim that I will do so. Those who can't modify
their mental processes accordingly should consider themselves free to read
another Web page.