
ColorForth (2009) - JoelMcCracken
https://colorforth.github.io/cf.htm
======
carapace
One of the most impressive digital artifacts humans have yet produced, IMO.

Legend has it that Chuck Moore used to carry around his own 3D CAD system in a
deck of punch cards in his shirt pocket.

> Current software is shameful.

It's not pleasant but I have to agree. I'm ashamed of my industry.

Just yesterday I watched helplessly as an office manager and her boss
struggled with their computer for ten minutes to complete a task that would
have taken moments with paper. The divining of intent (the UI's embodied
intent, not their own), the careful collecting and passing on of _cargo-cult_
lore, groping blindly for the correct ritual to evoke the desired state on
their machine...

It's _our_ fault. I am ashamed.

ColorForth and things like Arcfide's self-hosting GPU APL compiler are
"existence proofs" that we can get the same jobs done with one or two orders
of magnitude less code.

Doing that would free up dev's mental and time resources to make better
software, i.e. spending time on the difficult and important chore of actually
modelling the users' processes and providing automation that measurably
improves their lives, rather than learning the next flash thing or reinventing
the wheel for the Nth time.

In other words, your software editing environment including your language
should allow for convergence and contraction of code. Refactoring (aka DRY by
those who must repeat themselves) is key, and Forth is notorious for
refactoring.

In Cybernetics there's a formal measure or concept called "variation". The
variation of code should be at most a small constant greater than the
variation in human problems the code is meant to solve.

~~~
yiyus
I totally agree with what you said, but I'm having problems to put it into
practice.

I spent years learning Forth (wrote some toy programs, collaborated with some
projects, even wrote my own interpreter) and for the last couple of years I
have been very interested in APL and derived languages (I like k's simplicity
and Dyalog APL's feature completeness, but I'm starting to like J more and
more). However, there is no way I can justify using any of this at work.

I cannot convince my colleagues that learning J or colorForth will help them
in their careers more than learning C++, Fortran or Python, because it won't
(I work in research, writing scientific software), and I cannot convince my
bosses that it will be more productive to forget about all those juicy
libraries in C++ and Python to rewrite everything in some esoteric language,
because in fact it will take me longer.

So, I guess it is also _my_ fault, but I have no idea how to change it.

~~~
carapace
"Don't worry Charlie, I've got my foot on the rail..."

I have a plan... There's a language, Joy, that combines the best parts of
Forth and Lisp. It's also simple enough to be (re)implemented in other
languages very quickly, so it can form a cross-runtime glue language and UI
macro system.

It's very good for refactoring, partial evaluation, etc. It seems to deliver
on the idea of mathematical programming.

I've implemented a simple GUI that takes innovations from the old Oberon OS
and Jef Raskin's "Humane Interface" to make a very simple but elegant user
interface. With Joy and this UI there are no separate "apps" or programs, only
one body of commands (words in Forth, functions, etc.) that can be "scripted"
by the user. Mouse interaction and CLI are unified. For example, you can click
on commands, and then make a "script" (a new command) out of the commands
after the fact.

All files are kept in a VCS including the current system state, and autosaved
after every change (so you can literally kick out the plug, plug it back in,
and keep going from where you left off.) Never lose work.

With Joy you wrap other systems and libraries and expose collections of
command words that then let the user use them at the "desktop" level.
Eventually I'll write parsers for other languages and translate them into Joy
to take advantage of the "convergence" to contract the total amount of code
(even as I add more capabilities.)

I was in the middle of implementing type-inference when I was bushwhacked by
compilers in Prolog.

The original thing that led me to all this was Dr. Margaret Hamilton's Higher
Order Software. (See "System Design from Provably Correct Constructs: the
beginnings of true software engineering" James Martin) Long story short,
adding type-inference to Joy makes it easy to derive correct software. (This
used to be a novel thing to say.)

If you want to check it out my project is here:
[http://joypy.osdn.io/](http://joypy.osdn.io/) Python, Prolog implementations.
The GUI is undocumented. There are two: ./gui uses Tkinter text widgets; ./vui
uses SDL via PyGame to draw to the screen directly and is meant to guide re-
implementation in Joy for a self-hosted IDE thing.

I'm just at the point where I'm going to start targeting "vertical niche" use
cases (i.e. interpreting MRI data using ML and finite element methods, etc.)
and get some user feedback. I'm not going to try to get _developers_ to use
it. I'm going straight to the users. If I don't tell them they are programming
they should be able to do it just fine on their own. If this works I'm going
to eat software, even as it eats the world.

~~~
yiyus
Joy is in my TODO list. I have only heard good things about it. I never got
into it years ago when I was more interested in concatenative languages
(neither I learnt cat, which I think is quite similar). Much more recently, I
stumbled upon it again in nsl.com. It seems like Steven Apter found the Joy
combinators very interesting and implemented them in other languages.

It looked like a totally dead language to me and this does not help with
motivation, but I should definitively check it at some point.

I will have a good look at your project too. It looks like something I may
like. It still looks quite far from something I may use at work, but I'd love
being wrong about that.

~~~
carapace
nsl.com is pretty amazing, I haven't seen it before, cheers!

> It seems like Steven Apter found the Joy combinators very interesting and
> implemented them in other languages.

Yeah. I'm convinced that Joy is somehow _important._ It has to do with
Category Theory maybe, but I'm not a good enough mathematician to say how. Be
sure to look at the Prolog implementation in the ./thun subdir. Something that
elegant has to be significant, eh?

As for using it at work, YMMV. You wouldn't use my project (not yet anyway.)
But I think it might makes sense to implement Joy as a library in other
languages, like Walker's ATLAST. "The painful path to programmability"
explains the idea: ATLAST Autodesk Threaded Language Application System
Toolkit by John Walker
[https://www.fourmilab.ch/atlast/](https://www.fourmilab.ch/atlast/)

------
Minkwhip
Rainbow Forth is an implementation of the colorForth dialect of the Forth
programming language designed to run under Linux or Windows.
[https://github.com/flagxor/rainbowforth](https://github.com/flagxor/rainbowforth)

------
dang
There have been HN threads on Chuck Moore's work and on GreenArrays, but
specifically about ColorForth all I could find was
[https://news.ycombinator.com/item?id=8219730](https://news.ycombinator.com/item?id=8219730)
from 2014. Plenty of scattered comments though:
[https://hn.algolia.com/?query=colorforth&sort=byDate&dateRan...](https://hn.algolia.com/?query=colorforth&sort=byDate&dateRange=all&type=comment&storyText=false&prefix&page=0)

------
mruts
I used to write pretty complex 2d games in RPL on my HP-50g in high school and
man, the density of the code was absolutely amazing. For some reason that I
can't quite explain, using a stack based system can produce shorter code than
any other paradigm (maybe besides APL and derived languages). But I also found
the programs to be almost impossible to read and modify even just a couple
days after writing.

There's no doubt that I'm nowhere near as smart as Chuck, but I don't think I
could handle a million line code base in Forth or RPL. Maybe the equivalent
million line C program would only be 10000 lines or something, but I'm not
sure I could handle that either.

I've thought about the problem of readability and understandability of RPN
languages and syntax, and I wonder where it comes from. I have a theory that
it relates to some fundamental structure of the brain and how we process
syntax and information, but I'm not sure. Also maybe it has to do with the
amount of (unnamed) context you have to keep in your head at one time.

------
msla
[https://colorforth.github.io/phil.htm](https://colorforth.github.io/phil.htm)

> I believe in objective right and wrong. It applies to computer code. There
> is a single right way to balance all the conflicting demands. There is a
> solution to the puzzle. The challenge is to find it.

This, I think, is important to understand before you say anything about how
you'd have done things differently. Taken to a limit, it implies Forth is a
very specialized kind of language, for solitary programmers working on
embedded systems; if nothing else, it forecloses on pair programming and other
team development techniques unless every member of the team but one is a mere
typist, or unless all members of the team are so _sympat_ that there's no
possibility of disagreement. Otherwise, intractable arguments are inevitable,
because if it isn't Right, it's Wrong.

------
g051051
I've tried a few times over the years to play with it, but couldn't make much
progress. The most recent version available is from 2001, and:

"But note that COLOR.COM can only run under DOS - not Windows. As you can see
above, it's 9 years old and I no longer know how to run it. The current
version is available at GreenArrays". But I can't find a ColorForth download
at GreenArrays. And the "9 years old" comment might be from 2002!

Edit: And the FTP site seems to be down, so I can't even download it any more.
However, I found a 2019 repo at SourceForge:
[https://sourceforge.net/projects/colorforth/](https://sourceforge.net/projects/colorforth/)

~~~
TazeTSchnitzel
I searched on github for colorforth and found
[https://github.com/narke/colorForth](https://github.com/narke/colorForth)
which links to
[https://sourceforge.net/projects/colorforth/](https://sourceforge.net/projects/colorforth/)

Maybe one of those two links is useful

------
kencausey
OK, but is there any effort to continue development now that Chuck Moore
appears to have retired for good?

~~~
yiyus
Yes.

[http://www.inventio.co.uk/LegacyIndex.htm](http://www.inventio.co.uk/LegacyIndex.htm)

------
jplayer01
Can anybody comment on what the quality of the code is like?

~~~
Impossible
Source code for the interpreter from the github link posted above
([https://github.com/narke/colorForth/blob/master/cf2019.asm](https://github.com/narke/colorForth/blob/master/cf2019.asm)).
Looks like decently well commented x86 assembly language written for a macro
assembler.

