a few thoughts on the future

After re-reading all of Jeff Fox's excellent site this week, it struck
me that his email exchange with Sean Pringle about the Flux and Aha
editors strikes at the heart of the issue in using "modern" forths for
productive work. =A0Let me qualify "modern" as all those forths that
have adopted Chuck's VM new style, with memory access registers, short
stacks, and macro support. =A0The key issue for using these new forths
is the editor. =A0Probably the greatest contribution colorforth has made
to the world of forth is it challenges our preconceptions of what an
editor can and should be.

Recently my server crashed, dead harddrive, and I =A0took a page from
Brad Nelson's Rainbow Forth and ported my NewScript environment to
Google Apps. =A0To my knowledge, this is the 3rd "modern" forth that
runs in a web-browser, after Charles Childers's Retro Forth, and
Brad's Rainbow. =A0What we are seeing is that the easiest way to
distribute Forth can be a webbrowser. =A0Chuck in 1993, in his 1x Forth
talk, mentioned that he thought that the application du jour was a
webbrowser, and it seems that the application du jour is now Forth in
a web browser.

What these forths all have in common is that they are attempting to be
accessible. =A0Charles' Retro Forth was brilliant in that the same VM
could run on a wide variety of programs, and that the code that worked
in the minimalistic webbrowser version, could also run as native code.
=A0Brad's Rainbow Forth in its Google Apps incarnation allows for
multiple programmers to collaborate in a shared space, using an
interface very similar to Chuck's beautiful colorforth interface.

What struck me about all of these interfaces though, is that they're
still basically stuck in 1968, when a=A0Teletype Corporation ASR 33
Teletype=A0was considered hi-tech.  While we've added multiple screens
of colored text, we've not really advanced beyond the idioms of 1978's
DEC VT100 terminal.  When working on NewScript, I wanted to break out
of the tyranny of the terminal metaphor (pun intended). I wanted to at
least reach the level of 1995 and David Ungar's Self environment,
specifically the environment described in "Programming as an
Experience: The Inspiration for Self"
(http://research.sun.com/self/papers/programming-as-experience.ps.gz)
If you haven't read that paper, I highly recommend it.  Playing around
with the old Self demo environment provides an even better idea of
where programming could go than even the latest and greatest Smalltalk
environments.

I recently ran a few experiments and found that our cellphones are now
fast enough that we can compile native forths in their web-browsers!
I was able to compile a native binary on my iPhone using only its
scaled down Safari browser.  What this means is that we can build
software just about anywhere, using tools that everyone already has.
If you can compile a native forth in your web-browser, and save it to
a USB key, which you can then boot on any computer, you've solved the
"OS" problem.  And if your forth has a webbrowser implemented in it,
you've closed the circle.

Personally, I'm planning on using my colorforth inspired NewScript for
production work.  My goal is to build an eco-system in which kids all
over the world can contribute their own bits of code (read Objects /
forth dictionaries) to a shared repository that is browsable and
usable by all.  I am in the process of porting the compiler to just
about every chip I can get my hands on, and am planning on using it
for programming several embedded products currently in development.
As such, I'm not so much interested in writing a new forth for the
sake of writing a new forth, but because the fundamental problem was
one of writing a better editor.

The design principles for my new interface are based on notions of
direct manipulation and persistence.  A programmer should experience
objects as if they were persons, places, or things with actual names.
Data is data, and can live on the stack or in on the heap.  Objects,
however, are actors with proper names, and we refer to them directly.
Object code, itself, is just data that lives on the heap, and need not
reflect the object model we use at edit time.  As such, the idioms
used at edit time are also based on the notion of objects as being
tangible things.  In fact, I've been designing the interface with the
assumption that the default method of input is a touch screen, and
that the text input may as well come from a soft-keyboard or voice
input.  Tangible editing, rather than writing text to create a
dictionary, you touch and drag.  To add words to the dictionary, you
simply drag them to the dictionary.  To remove words from a
dictionary, rather than typing "forget word", you simply pull it out.

In this sort of interface colorforth really shines.  Words with small
definitions are easy to display and manipulate, you don't have
function definitions that are screens long like in other languages.
It is easy to imagine using speech recognition to input colorforth
source code on an iPhone, rather than using a dinky soft-keyboard.
But more over, it is also easy to imagine editing colorforth
dictionaries on a huge multi-touch display, and speaking your code
into the ether.  And this is not sci-fi, it is where the NewScript
interface is actually going.  We've already built our wall projector,
and all that we have left to do is finish the hooks for our Wii-remote
& webcam hack to control the mouse.  Once I get some voice recognition
software working, text input will be done too!

One thing that Jeff and others mention repeatedly in the articles on
his site is that an engineer should start with a blank sheet of paper
when designing a new solution to a problem.  Rather than trying to
take existing code and shoe-horning and gluing bits together, the
"thoughtful programmer" should approach the design with fresh eyes.
In that spirit, the NewScript editor begins with a blank page, and
almost no words.  In fact, the core language supports numbers and 44
instructions, everything else is built on top of that.  The
core-language, itself, is actually defined in an object, which can be
mutated, removed, or replaced entirely.

But just because you start with a blank sheet of paper, that doesn't
mean you can't benefit from designs you've made before, or were made
by other people.  To that ends, the NewScript editor contains an
inventory of every object (read dictionary) you have ever created.
You can browse how your dictionaries change over time, reinstate any
historical version at any time, and every change you or anyone else
makes is automatically saved and archived.  More over, each user has
their own "channel" which provides basic chat service, and publishes
their objects for all to use.  The idea is that programming is not
just a solo-activity, where lone artists must struggle on their own,
but rather a collaborative effort, where many hands can make any task
light.  As I've been tele-commuting/tele-contracting for the past 6
years, I've become painfully aware at how horrible existing
collaboration tools are for collaboration.  By making collaboration an
intrinsic aspect of the experience of programming, we can change how
we approach writing colorforth.

The most unfortunate innovation that I've introduced to NewScript is
that I've broken with the forth tradition of having a singular
dictionary (or dual compiler / macro dictionaries).  Rather, I'm using
a stack of "objects" which are essentially little forth dictionaries.
The reason for this is it makes collaboration easier.  Rather than
focusing on what block you put your code, editor assembles source code
in its own mutli-partitioned block space, and the target object memory
is free to be used in any manner you wish.  To invoke a verb in an
object you need to use both the object's proper name, and the verb, in
an English style Subject verb combination:

4 Number even

As such, Number even is treated by the parser as a singular function
call.  This is not to say that Number is a compiling word that changes
the active dictionary, rather, the parser looks at 3 words at a time.
Why 3 words?  Because there are 3 forms of verb invocations:

4 Number even       ( call Number even)
4 Number even .     ( jump Number even - tail call optimization)
4 flag @ Number even ?  ( conditional jump Number even - jump to
Number even if tos is non-zero )

These forms exist largely to make it easy to reference code coming
from multiple sources, to reuse existing code, and to contextualize
your meaning.  It means you can share small individual objects rather
than huge dictionaries.  It also means you don't need to solve the
silly module import and collision problem you find in other languages.
 And I've also gotten rid of the IF THEN construction entirely, and
instead simply use nested definitions, and definitions that fall
through to the next as in colorforth.

So that's where I'm trying to take my colorforth.  Once the editor
hits version 1.0, I'm going to start working on 3 public available
applications:

1.) NewScript in NewScript - the environment implemented in itself
2.) a NewScript Webbrowser - browse the web using a webbrowser written
in NewScript that was compiled in a webbrowser
3.) a NewScript P2P Web Application Server - serve up web-pages from
you NewScript enabled webbrowser that compiled itself

I'm hoping to have it running on as much hardware as possible, and
since the current code base is <2000 lines of python and javascript, I
expect that all three of the apps above will require a total of about
half that code.

The beta is now open to anyone who signs up with a Google Account,
btw. =A0I've uploaded 2 video tutorials, and am working on more. =A0You
can start playing with it, evaluate code in the browser, and compile
Intel IA32 object memories at:

http://www.newscript.org/

If you do, feel free to leave me bug reports, suggestions, or beer.
Dave