> 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.
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!
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.
> What does this say about Forth? Not much except that it isn't for me.
> I still find Forth amazing, and I'd gladly hack on it upon any opportunity. It still gives you the most bang for the buck – it implements the most functionality in the least space.
> As to using Forth as a source of ideas on programming and language design in general – not me. I find that those ideas grow out of an approach to problem solving that I could never apply.
Anyway Forth is one "existence proof", Arcfide's APL compiler is another.
To repeat: We could get the same value out of much less code than we do. If we had 1/100th of the code we could use the time and mental energy thus liberated to do other better things.
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.
"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/ 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.
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.
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/
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
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.
22 comments
[ 2.0 ms ] story [ 70.9 ms ] threadhttp://www.inventio.co.uk/LegacyIndex.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.
"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/
Maybe one of those two links is useful
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.
> What does this say about Forth? Not much except that it isn't for me.
> I still find Forth amazing, and I'd gladly hack on it upon any opportunity. It still gives you the most bang for the buck – it implements the most functionality in the least space.
> As to using Forth as a source of ideas on programming and language design in general – not me. I find that those ideas grow out of an approach to problem solving that I could never apply.
Anyway Forth is one "existence proof", Arcfide's APL compiler is another.
To repeat: We could get the same value out of much less code than we do. If we had 1/100th of the code we could use the time and mental energy thus liberated to do other better things.
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.
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/ 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.
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.
> 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/
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.