Re: [colorforth] a few thoughts on the future

[vaded@xxxxxxxxxxxxxx]

Forgive my offtopicness...

Very happy to hear about your project though.

I cannot help but wonder if the future of colorForth has been hindered
by an absence of applications.  I know I'm talking PC here and the
future of Forth is really on Mr. Moore's chips not intel ones. But am I
wrong in thinking if we could connected to the internet and have a
webrowser, people would look up and take notice?  Especially if it was
all done elegantly and small.





On Fri, 1 May 2009 12:30:42 -0400, "David Goehrig" <dave@xxxxxxxxxxxxxx>
said:
> 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.  Let me qualify "modern" as all those forths that
> have adopted Chuck's VM new style, with memory access registers, short
> stacks, and macro support.  The key issue for using these new forths
> is the editor.  Probably 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  took a page from
> Brad Nelson's Rainbow Forth and ported my NewScript environment to
> Google Apps.  To my knowledge, this is the 3rd "modern" forth that
> runs in a web-browser, after Charles Childers's Retro Forth, and
> Brad's Rainbow.  What we are seeing is that the easiest way to
> distribute Forth can be a webbrowser.  Chuck 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.  Charles' 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.
>  Brad'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 Teletype Corporation ASR 33
> Teletype was 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.  I've uploaded 2 video tutorials, and am working on more.  You
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
> Main web page - http://www.colorforth.com
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com