a few thoughts on the future

[David Goehrig]

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@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[John Comeau]

Hi David, the page is all but content-free using Firefox 2 (Iceweasel)
on Debian lenny/sid. It just shows:

NewScript.org
Copyright © 2009 David J. Goehrig <dave@...>

On Fri, May 1, 2009 at 10:30 AM, David Goehrig <dave@...> wrote:

> 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@...
> For additional commands, e-mail: colorforth-help@...
> Main web page - http://www.colorforth.com
>
>

--
John Comeau <jc@...> http://jc.unternet.net/
"A place for everything, and everything
all over the place"

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

[Charles Turner-3]

On May 1, 2009, at 3:18 PM, John Comeau wrote:

> Hi David, the page is all but content-free using Firefox 2 (Iceweasel)
> on Debian lenny/sid. It just shows:

Looks plenty fine with DEVON agent/Apple WebKit. The bulk of the page  
in Javascript, so you might want to start looking there...

Best, Charles


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

[David Goehrig]

-=-=- dave@... -=-=-

On May 1, 2009, at 3:59 PM, Charles Turner <vze26m98@...>  
wrote:
>
> Looks plenty fine with DEVON agent/Apple WebKit. The bulk of the  
> page in Javascript, so you might want to start looking there...
>
> Best, Charles


Due to lack of some key HTML 5 features and screwy Ajax support I am  
not touching ff2 or ie with a ten ft pole.

Newscript provisionally supports ff3.08 and up (but that has known  
bugs). For best viewing pleasure I recommend safari 4 beta actually.  
I will also support google's chromium browser as soon as I get a  
stable nightly build out of their repo.

If you have o3d installed a new version will allow you to take  
advantage of the v8 plugin js engine.

Hope this helps.

Dave

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

[vaded]

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@...>
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@...
> For additional commands, e-mail: colorforth-help@...
> Main web page - http://www.colorforth.com
>

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

[David Goehrig]

On Fri, May 1, 2009 at 10:02 PM,  <vaded@...> wrote:
>
> I cannot help but wonder if the future of colorForth has been hindered
> by an absence of applications.

If by applications you mean a functional TCP/IP stack and drivers for
some popular network cards, I'd say yes.  If you mean  applications by
microcontroller projects developed with it, because the current code
is Intel only and highly non-trivial to port, then also yes.  If you
mean applications as in word processing, photo manipulation, and AV
centers then not so much.

> But am I wrong in thinking if we could connected to the internet and have a web browser, people would look up and take notice?

Well we already have several colorforths connected to the internet and
"no one" has really noticed, but popularity has never been a good
indication of quality either (cough Walmart cough cough).  There was a
webbrowser develop for some of the forth chips an few years back
according to Jeff Fox's site, but even if I'm successful in writing my
own webbrowser I expect the total market share it will get is those
people who are using the browser to edit NewScript.

Personally, what I think would get people to take notice is if we
developed educational material, that allowed young kids to learn to
program, and solve problems using computers.  Supposedly, forth can be
taught to a novice programmer in a matter of hours to a degree that
will allow them to do some useful programming.  Now that we have
several colorforth  inspired environments that are available to anyone
with web browser, that would probably go a lot further to promote
thoughtful programming.

Most people in the world don't know Java, Lisp, or C.  But we could
probably teach them colorforth :)

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