The Plan to Singularity is ©1999 and ©2000 by Eliezer S. Yudkowsky.  All rights reserved.

Next: 2.2: Technological timeline
Up: 2.1: Component technologies
Prev: 2.1.1: The "Aicore" line Monolithic

2.1.2: The "Flare" line

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 XML.

NOTE: 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 itself.  (3).

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 language.

Flare has four primary purposes:

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).

Next: 2.2: Technological timeline
Up: 2.1: Component technologies
Prev: 2.1.1: The "Aicore" line