From: Durant Schoon (durant@ilm.com)
Date: Tue Jul 17 2001 - 13:13:38 MDT
Well I, for one, am extremely excited by Flare. Not just for AI,
but because I like the concept of an annotative programming
language. Many years ago, Gerald Sussman's thesis HACKER (I think
it was called) attempted to automate the process of coding and
debugging ((in lithp, of courth)). I don't recall what limitations
he ran into (maybe I can look that up on-line, but I bet it'd be
hard to find), but I remember thinking that programs can really
be thought of as flow diagrams and that they should be represented
as such to take full advantage of everything we know about graph
theory, systems theory, etc. With Flare, a much better attempt
at this problem could be made. Programmatically reasoning about
the code will be a natural feature of the language itself adds
everything one should need to do the job right. Especially if
one of the limiting factors will be understanding the world
around one and that that problem would be being solved at the
same time.
Assertion:
XML will be the lingua franca of the internet. With XML Schema's
they finally got things right. My dream has always been to be able
to have a list object ['apple', 'orange', 'peach'] spit it out as
XML
<list>
<apple/>
<orange/>
<peach/>
</list>
and have it read by another program. Yes, I know we can unparse
or even share binary representations in memory more efficiently,
the point is to at least agree on one ascii representation. (XML
seems the right choice. It's powerful enough and has a lot of
backing.) Next, I'd want to graphically represent the list for
visual modification so that you'd have a visual debugger for
every language that has a compiler which communicates this XML
back and forth. XML is easy to manipulate. It will have
pervasive support and pervasive tools (generally it's not a
good idea to make technological predictions like these, but
this seems like a "sure thing" considering everyone behind
it W3C, Micro$oft, IBM, Sun, ... more of a sure thing than
Bluetooth anyway)
Ultimately, this thinking leads one to surmise encoding the
methods as well as the data in XML for portable computation. Why
not define insertion-sort once and for all and add a handful of
animations. Then someone invents a new language, say, Pliant, and
you just follow the insertion-sort template and bingo, you can
reuse the animated visual debugger. The fact that Flare can be
tweaked to be use either statically or dynamically typed means
that there is a very good chance that given an algorithm in Flare
for insertion-sort, you might be able to press a button and get
the isomorphic version of it in Pliant (assuming Flare is more
"feature"-full than Pliant is and yes this mapping might be very
difficult to use all of Pliant's idioms, whatever they happen to
be).
Another feature I specifically like about Flare is that FlareSpeak
is based on python, my favoritest language in the world, so I'd
be a happy camper to use it.
I'm probably not qualified to lead a Flare project, but I would
if I were. I definitely intend to contribute as much as I can
as a volunteer because Flare is in the direct path to what I want
to accomplish anyway (all in my limited spare time unfortunately,
so it should be noted that these ambitions probably greatly
outstrip my availability).
I'd like to implement a mini-Flare interpreter in the XML hobby
I'm working on now (in Java), so I'll just have to see if I get
anywhere or not. The good news is that lots of people will build
little parts of it and Eli can concentrate on building an FAI
(to build nano-fabs to save humanity and then finally go back
and document all that code ;-)
PS - Eli's document on the Causality pattern (in the same dir
as the Flare stuff:
http://intelligence.org/flare/
) Reminded me of the cross-cutting of Aspect Oriented Programming
languages like AspectJ, http://www.aspectj.com, though these are
not quite the same things.
PS -
Also a note to whomever leads Flare. If you have the situation of
<human>
<arm>left</arm>
<arm>right</arm>
</human>
XQL (which Eli duely noted on his web page) already has syntax
for distiguishing human/arm[0] from human/arm[1] (I don't remember
if that's exactly right, but it's close). If XQL becomes the
standard (it's a good candidate), it might be a good idea to
borrow liberally from it.
And away we go!
-- Durant Schoon
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT