And for those (not quite) following along at home, there's a link in there (or in one of the other related links) to Moore's talk at Strange Loop 2013:
[edit: I'm delighted to see a little more of this chip, after being rather exited about it when it was first announced/launched (just not quite 450USD exited). There are some fascinating notes on Moore's (now dead?) eval blog[1], such as the notes on driving a VGA display:
(I have strong, negative opinions about FORTH, having seen at close-hand a few disasters that resulted from using the language, but I have to credit FORTH for being achingly spare and rather pretty).
To add 'color' to the comments: I've got strong positive opinions about forth, when used properly. I've helped save several embedded/early-stage board bring-up projects with it.
More than one person has called forth a programmer "amplifier". If C++ has the capacity to blow off your whole leg, forth is more than capable of forming a black hole beneath you and sucking you in.
FORTH definitely seemed to be a kook amplifier. It tended to attract personalities who were unhinged and not very disciplined.
The episode that most sticks in my mind was when a cow-orker of mine at Atari tried to write a game in FORTH. He blew all his ROM space with runtime and framework and static bitmaps; game play was going to come later, as soon as he got his great FORTH-based game engine running. Ten months into a six month project, 20K into a 16K ROM and with frame times on the order of 5 FPS (utterly unplayable) he basically stopped giving his manager any status, and was fired. All this time, good performance, great game play and small code space were "just around the corner, like next week, maybe" because the magic of FORTH was going to save the day.
That was a near total failure of management, good engineering practice, scheduling and hiring, all at once.
At nearly the same time, a friend of mine was writing some great process-control stuff for another company, in FORTH. We had many conversations about the Atari programmer in question. My friend was pragmatic, conscious of his own faults, and probably the best FORTH programmer I've ever known.
"Not everyone can handle this stuff," he said.
A few years later I asked him if any of his FORTH code had survived when he left that company, and he smiled a little and asked me what I thought.
"They threw it all away, right?"
"Right."
I don't know how much that cost the company in question. Probably a lot.
In another case, there was a hardware bring-up engineer who wrote a bunch of tests and exercisers in FORTH. This was an initial win because he taught the hardware people FORTH, too, and they wrote a lot of their tests in it, and they were pretty productive. This was unarguably good stuff. But when it came to write native code drivers for the platform's OS we found all kinds of cycle-level timing issues that had been masked by FORTH's inner interpreter overhead, and I spent weeks chasing some of these, inserting magic NOP instructions to work around glitches.
So am I utterly negative about FORTH? No, it's a tool. I get really skeptical that you can ship a real product in it, though, and I think that FORTH's successes are in very specialized niches and not very visible.
Similar story here. Co-worker (German dude, very nice otherwise) was going to build OCR software from scratch using FORTH (1985 or so). After blowing the complete allotment of time for the project about a week before 'D' (demo) day I was asked if I could still make something that was demonstrable.
The problem wasn't all that hard actually so I wrote a bit of C code that did the job in about 2 working days...
Now, there is nothing wrong with FORTH per-se, it's a great little language and it has some elements that I think are super elegant, in the same way that I think LISP is super elegant (though I'd have a much easier time programming some problem in FORTH than in LISP simply because I have a lot more FORTH experience).
When I looked at the code I decided that FORTH was the wrong tool for that particular job, doing it in C (to great scorn of the original German dude who called C sneeringly a 'great' language because of the larger runtime) made the job very much easier.
The same 'it will work tomorrow' attitude was what kept the project going for all the time that went into it (multiple years), I think in part this was because the guy was so nice and a close buddy of one of the people that ran that place. But when push came to shove the un-elegant sledgehammer of C rammed that particular nail in in record time.
Image processing in FORTH is not the best fit, though I can see some ways in which you could make it fit. Maybe if I tried my hand at it by tomorrow I could have a working prototype ;)
FORTH has one serious problem. Like your friend said, "Not everyone can handle" it. In organizations that hire programmers based on buzzword compliance and cost, it's only natural all FORTH code would be rewritten in something more... popular. It's true FORTH successes are most visible in not very visible niches. There was a time every Sun and Apple computer came with a FORTH interpreter in ROM and most SPARC-based servers probably still do.
The biggest problem is that FORTH seems to be a 'loner' language, I've yet to see it be used efficiently by a team of any size. It's always one guy. And that one guy will make or break the project.
I believe that this stems from Forth being imperative (which is hard to handle itself) and that main control is done using two global structures (data and return stack).
You have two very very global variables to arrange your control flow.
Nothing is pure and everything can affect anything. It is very hard to reason and to draw borders.
That's misrepresenting FORTH considerably I think. The data available to a forth primitive is typically on the top of the stack. That's just the same in every other language, it's just a parameter passing convention that most languages share. The problems with trying to write image processing code with FORTH is that pushing an image on the stack or modifying it in place somewhere in memory is a bad match with the language primitives. So you then have to do a whole pile of plumbing to abstract out that little detail.
FORTH excels at control jobs and other embedded tasks.
I've found that forth works best when you use it to create a DSL for your problem domain, and you write your application code in that DSL. That DSL becomes the critical abstraction that helps prevent your codebase from becoming an unusable/unmaintainable mess. This isn't a new idea; the book that got me thinking about when/how to use forth was (oddly enough) http://thinking-forth.sourceforge.net/ . It's a good read even if you never intend to build a forth project.
As a side note, I've done image processing with forth: I helped build a commercial HD video camera with it that shipped in the mid 2000s, and I found it well suited once we had the problem reasoned out well enough to build our DSL. Overall the product ended up being composed of forth/C/hand written assembly, and a bunch FPGAs. We shipped things with < 10 people, and I think the interactive/extensible mindset that forth gave us helped us get the product out the door successfully.
Oh, man, is this ever the problem with Forth: the absolute delusion, ruthlessly reiterated by Moore and the Faithful(Forthful?) that the only reason Forth hasn't taken over the world is that everyone other than the Faithful are too stupid to get Forth and see how completely superior it is to everything else. The only time I ever said "Forth rocks!" is how easy it made getting through those college "design a computer and a usable programming environment" classes, because a dead simple stack based arch + Forth gets you a solid C.
There was a time every Sun and Apple computer came with a FORTH interpreter in ROM
And there's a reason they don't any more. It was a pretty interesting way of enumerating device capabilities, and a terrible way of abstracting device driver details, which was why it was there. Having tried to beat Sun OpenFirmware Forth into making SBus device drivers "easier", I guess I fall into the "too dumb" category, because it was a disaster.
In a time where basic was alpha and omega in consumer micros, a british company decided to ship their cheap micro with a forth implementation. Needless to say it wasn't very successful, but I wish I had one.
I'd been curious about this one since it was released in the early 80's. I wrote an emulation in python to satisfy my curiosity. (https://github.com/deadsy/py_z80) My general conclusion was that the hardware wasn't good enough (monochrome competing with the ZX Spectrum's color) and that Forth didn't offer enough advantages over BASIC to warrant significant usage. It's an interesting design though, and it's good to see how they built their Forth system in an 8K ROM.
I actually came across your project the other week, looking for a python Z80 emulator. Commendable work, though I have yet to try it, since you had already covered my intended use of it by making an Ace emulator.
I read some interview with the guys that designed the machine, and their stubbornness in not going for color video and pushing for forth kind of mirrors some of the sentiments about forth programmers shared here. They were definitely primarily engineers with little regard for the benefits of being conventional, which I can appreciate.
And quite a few failures. Another one that I just remembered: The first Atari pinball machine, 4 X 4, was attempted in FORTH. They gave it up and re-wrote it in assembly.
The Atari coin-op group had an internal version of FORTH that was actually pretty whizzy; one or two guys spent a fair amount of time on it. But no games actually shipped that used it.
There's always been a persistent rumor that some of the vector-based Atari coin-op games like Battlezone were written in FORTH, but I've never been able to definitively confirm or refute that. (I can find messages out on the net from the mid-90s with people talking about this, but no actual replies from people who would know.) I always liked the idea, although I don't think I really like FORTH that much.
(Those who remember MUCKs like TinyMUCK might have actually used a FORTH variant: MUF. I actually wrote a couple of MUF programs, although by that point the language supported lists and dictionaries so it wasn't quite so headbangingly tough for those of us who do not have stack-based brains.)
FORTh seems to have MUCH more than its share of failures. Also, zealots, who are (in my experience) unreasoning and deaf to counter-arguments. FORTH also does not seem to scale to large projects very well (I'm guessing that the number of large, long-lived projects in FORTH is very, very small compared to contemporary languages like Pascal and C).
You choose the colors you want to use, but in all reality you will likely never use this esoteric dev environment. As a side, I have seen numerous close-hand disasters in Java and C too. The problem is usually between the keyboard and chair.
I'm deuteranomalous too, and I first thought, "I can distinguish these colors easily, I'm glad they chose colorblind-friendly colors". Then I read the color list and realized there were more colors than I thought.
I remember there was a quite intense discussion about ColorForth discriminating color blind users (HN or ./ would be the kind of place where this type of discussion exists, but I can't remember which).
... I also remember reading that C. Moore added the syntactically significant coloring to help with his own visual impairment.
http://blogs.msdn.com/b/ashleyf/archive/2013/09/21/chuck-moo...