3 ms·
I worked at a place that had a big Forth codebase that was doing something mission critical. It was really neat and cool once you finally got it, and probably h
by rpcope1 1y ago
I worked at a place that had a big Forth codebase that was doing something mission critical. It was really neat and cool once you finally got it, and probably hundreds or maybe thousands of people had touched it, worked on it and learned it, but the ramp was pretty brutal for your average developer and thus someone decided it would be better to build the same thing over with a shitty almost-C-but-not-quite interpreted language. It certainly made it easier for more people to understand and build, even if the solution was less elegant.
- kragen 1y agoThat sounds interesting! Do you have any tips for us on how to use Forth effectively? What was the codebase?
- rpcope1 1y agoHonestly, when I write forth now, which is usually for embedded targets, I've got a customized version of zforth that I've grafted some stuff like locals into. If it's a small program, it's better to not be afraid of things like globals, and just spend at least twice as much time factoring, writing comments and thinking than writing. It's important to read other people's Forth code and try to understand, as there's a zen and style that looks very different than how you'd write something like Java. It's freeing and enlightening once it clicks, but you have to fight a ton of the way you think about "normal" code. As far as the codebase, I probably shouldn't say too much (may it's been long enough now, but Idk), but all I'll say is that was a important part of things at a certain disk drive manufacturer.
- kragen 1y agoThat makes a lot of sense! Thanks! What were the most common mistakes you saw people new to Forth making? Being afraid of global variables is one of them, I infer.