As you learn Forth, it learns from you (1981)(jupiter-ace.co.uk)
jupiter-ace.co.uk
As you learn Forth, it learns from you (1981)
https://jupiter-ace.co.uk/Forth_general_practical_computing8108.html
71 comments
What are your main lessons from Forth for API design? Is it something you could summarize?
There have been some great responses that cover the gist of it, but to add a couple more mundane specifics:
- Build up the thinnest abstraction that lets you express a solution in the problem domain.
- Allow the API user to express their intent, and not be focused on mechanics they don't need to understand to get the job done.
- Focus on getting the interfaces right before the implementation is perfect.
- A clean interface will allow you to make drastic changes to the implementation without the API consumer becoming aware.
- Build up the thinnest abstraction that lets you express a solution in the problem domain.
- Allow the API user to express their intent, and not be focused on mechanics they don't need to understand to get the job done.
- Focus on getting the interfaces right before the implementation is perfect.
- A clean interface will allow you to make drastic changes to the implementation without the API consumer becoming aware.
Not the OP, but for me one of the main lessons from Forth is that the boundary between high and low level code can be as thin as you make it. With Forth, you can define high level words using low level primitive words. You then weave these low level words together at a high level. After you have written a correct solution at a high level, bottlenecks can be optimized out by introducing new low level words. It's like you are solving a problem by designing an instruction set specifically for that problem. But unlike a hardware ISA, you can add new instructions tailor made for the specific problem you are presently solving.
Paul Graham has described lisp as a tool for writing fast programs fast (that's the gist at least). IIRC, he clarifies that each fast is a phase. Lisp allows you to write a fast, high level, prototype that might have poor runtime performance and then you refine the prototype so that the compiler can generate fast machine code.
Forth is similar but feels closer to the machine than Lisp because of the stack based threading model. In Forth, you often don't need manual memory management _or_ garbage collection and you can easily extend the system with new low level words. But it does require you to think differently about your program design so that it fits the stack based vm model.
Historically, Forth has been implemented in assembly but you can write a Forth that targets any host. The truly mind expanding thing is that you, an individual, can write a Forth compiler and you can also write it in such a way that it has multiple targets. For example, you can generate native, jvm and js targets from the same underlying source. Usually this can be done by translating the forth generated AST to source code for another high level language. This allows you to write a fast high level language quickly without getting bogged down in writing, say, fast x86 codegen or a garbage collector. To get started, you just target the host language with the best high level properties that you need (which will be problem and context specific). I don't enjoy writing c, but I have no problem translating to c if I need to for performance or for syscall access.
To illustrate the practical power of this. Suppose that you have an important subcomponent of your system that was written in, say, Node.js. It turns out that this is a critical bottleneck that cannot easily be optimized in javascript. You don't want to rewrite the whole system, but you do want to rewrite that component and have it seamlessly interoperate with the existing system. You could write a small Forth DSL for that subcomponent. This Forth will target javascript initially. You translate the subcomponent into Forth and reuse all of the existing tests (that were presumably also written in javascript). Then you rewrite the tests in Forth so that the entire subcomponent is now written in Forth. Now you write a new backend that translates to say, c or rust with node bindings. You can run the native implementation against a native implementation of the test suite since they're both written in high level Forth at this point. Then you can flip the switch between the native or javascript implementations and be confident that both implementations are identical because they have the same high level description.
Once you start seeing things this way though, you start realizing that you can write Forth style code in any language (and the reverse is also true). Forth is as much about a process for solving programming problems as it is a specific, concrete language. This is also why there is the old adage "once you've seen one Forth, you've seen one Forth."
Paul Graham has described lisp as a tool for writing fast programs fast (that's the gist at least). IIRC, he clarifies that each fast is a phase. Lisp allows you to write a fast, high level, prototype that might have poor runtime performance and then you refine the prototype so that the compiler can generate fast machine code.
Forth is similar but feels closer to the machine than Lisp because of the stack based threading model. In Forth, you often don't need manual memory management _or_ garbage collection and you can easily extend the system with new low level words. But it does require you to think differently about your program design so that it fits the stack based vm model.
Historically, Forth has been implemented in assembly but you can write a Forth that targets any host. The truly mind expanding thing is that you, an individual, can write a Forth compiler and you can also write it in such a way that it has multiple targets. For example, you can generate native, jvm and js targets from the same underlying source. Usually this can be done by translating the forth generated AST to source code for another high level language. This allows you to write a fast high level language quickly without getting bogged down in writing, say, fast x86 codegen or a garbage collector. To get started, you just target the host language with the best high level properties that you need (which will be problem and context specific). I don't enjoy writing c, but I have no problem translating to c if I need to for performance or for syscall access.
To illustrate the practical power of this. Suppose that you have an important subcomponent of your system that was written in, say, Node.js. It turns out that this is a critical bottleneck that cannot easily be optimized in javascript. You don't want to rewrite the whole system, but you do want to rewrite that component and have it seamlessly interoperate with the existing system. You could write a small Forth DSL for that subcomponent. This Forth will target javascript initially. You translate the subcomponent into Forth and reuse all of the existing tests (that were presumably also written in javascript). Then you rewrite the tests in Forth so that the entire subcomponent is now written in Forth. Now you write a new backend that translates to say, c or rust with node bindings. You can run the native implementation against a native implementation of the test suite since they're both written in high level Forth at this point. Then you can flip the switch between the native or javascript implementations and be confident that both implementations are identical because they have the same high level description.
Once you start seeing things this way though, you start realizing that you can write Forth style code in any language (and the reverse is also true). Forth is as much about a process for solving programming problems as it is a specific, concrete language. This is also why there is the old adage "once you've seen one Forth, you've seen one Forth."
I didn't use FORTH long, maybe for a year, (back when 8080s were The Thing), but I remember my first reaction (after learning about Reverse Polish) to it: it was like using assembly language, but without the pain.
(Moved to 6502; don't recall having a version for that.)
(Moved to 6502; don't recall having a version for that.)
I think a lot of recent Forths (at least outside of the embedded space) have been written in C or C++ rather than assembly now that the processors are incredibly complicated. Of course, you can write forth on anything including the JVM or in Python...etc.
I think jonesforth is the most popular implementation teaching implementation: https://github.com/nornagon/jonesforth/blob/master/jonesfort...
Factor might be a counterexample if one considers it a Forth, the VM is in part implemented in C++: https://github.com/factor/factor
I think it's portability and ease of development rather than CPU architecture complexity that makes someone pick C/C++ over assembly when implementing a Forth system. Because the Forth won't need much of the assembly language or obscure CPU instructions, the complexity of the architecture won't really matter to whoever is implementing it.
Factor might be a counterexample if one considers it a Forth, the VM is in part implemented in C++: https://github.com/factor/factor
I think it's portability and ease of development rather than CPU architecture complexity that makes someone pick C/C++ over assembly when implementing a Forth system. Because the Forth won't need much of the assembly language or obscure CPU instructions, the complexity of the architecture won't really matter to whoever is implementing it.
JonesForth is popular for teaching, but most implemented Forths people talk about on r/forth seem to only be written in ASM if the target is embedded. Portability, simplicity, and the complexity of modern processors just seem to make ASM less of a good option these days. I'm no forth expert though...mainly a lurker.
I don't know what "r/forth" is. Some conference?
I'm absolutely not an expert, just a long time enjoyer of some classic Forth books and certain concatenative languages.
I'm absolutely not an expert, just a long time enjoyer of some classic Forth books and certain concatenative languages.
r/forth is a subreddit - so https://<reddit url>/r/forth
OK, so a web forum then. I avoid Reddit, I don't believe in corporations as stewards of web forums.
Reddit has issues, but searching for topic + "reddit" is one of the only remaining ways to make Google not a piece of steaming ad-infested garbage. For example, if you want to find the best budget rollerblades, Google will happily serve you page after page of auto-generated garbage. On reddit you can find real enthusiasts giving recommendations.
Also ...ycombinator isn't exactly just a community run bulletin board either. Although HN not being ad infested is absolutely amazing. Also the simple design.
Also ...ycombinator isn't exactly just a community run bulletin board either. Although HN not being ad infested is absolutely amazing. Also the simple design.
Yeah, I'm not going to the Internet and ask about things I'd like to buy, I'm going to ask my friends or take a chance on second hand stuff. A SearxNG instance that hardly ever serves up Google responses and Wikipedia are my main search engines outside systems I control.
Sure, I'm not really using this as a web forum, I'm not here for the community.
Sure, I'm not really using this as a web forum, I'm not here for the community.
It sounds like you almost want to live off grid completely (I'm exaggerating a bit based on your response - it's not meant to be condescending either btw...hard to convey tone online).
I certainly get that itch sometimes after the person at the coffee shop asks me if I've downloaded the app for the 50th time. No, I don't want 45 apps on my phone just so I can get a tiny discount or a free coffee each year.
Regarding the comment on asking friends. I think that has some value, but it assumes that you know someone for everything you're interested in or that they have the same kind of purchasing power or ideas as you. The Internet can be helpful there if you're interested in the best bang for the buck for a newbie, or the best product period once you've spent more time.
I certainly get that itch sometimes after the person at the coffee shop asks me if I've downloaded the app for the 50th time. No, I don't want 45 apps on my phone just so I can get a tiny discount or a free coffee each year.
Regarding the comment on asking friends. I think that has some value, but it assumes that you know someone for everything you're interested in or that they have the same kind of purchasing power or ideas as you. The Internet can be helpful there if you're interested in the best bang for the buck for a newbie, or the best product period once you've spent more time.
They just said it was like the LSD of programming languages. Your question is kind of like "What are your main takeaways from LSD? Can you summarize?" which realllly misses the point.
I don’t think so. There are many ways to describe how a mind altering experience with LSD would change how you relate to yourself and your environment. I am curious how Forth changed parent’s approach to programming.
You can describe LSD, or a novel programming paradigm, just as well as you can describe Beethoven's 5th symphony in words.
The amount of lost bits of information makes the explanation totally worthless, even though you technically can explain it. The point is it's a waste of time. You won't understand LSD, Beethoven or Forth until you have tried them.
The amount of lost bits of information makes the explanation totally worthless, even though you technically can explain it. The point is it's a waste of time. You won't understand LSD, Beethoven or Forth until you have tried them.
Probably in a similar way to learning Haskell, assembly, Erlang, data-oriented design, 4k demo programming, or any other thing that is unconventional enough that your normal patterns don't work and you are forced to expand the set of ways you know how to program.
Not OP, but I would only partially agree with that statement. Sure, learning all those things is mind altering. If you only know Java or Python...Haskell is very unusual.
However, the Forth experience and reading about legends like Chuck Moore (at least for myself), just gave me this feeling that most of our problems come from software bloat and having these infinite abstraction levels where nobody ever truly understands what in the world is going on anymore. Such a system is ironically more efficient from a developer's perspective (at least until you run into weird bugs and edge cases) as developers just basically glue together libraries and only need surface level understanding to get something running. Another option might be to design your own hardware and then a simple forth system on top of that which exactly solves the problem and nothing else. The implementor would have laser level understanding of the design choices. Of course, there are other issues such as how to maintain such a unicorn, even if it is beautiful and elegant. Today, we have lovecraftian horrors with huge swaths of people working together to keep all the abstraction levels working together and hope there aren't any leftpad incidents.
However, the Forth experience and reading about legends like Chuck Moore (at least for myself), just gave me this feeling that most of our problems come from software bloat and having these infinite abstraction levels where nobody ever truly understands what in the world is going on anymore. Such a system is ironically more efficient from a developer's perspective (at least until you run into weird bugs and edge cases) as developers just basically glue together libraries and only need surface level understanding to get something running. Another option might be to design your own hardware and then a simple forth system on top of that which exactly solves the problem and nothing else. The implementor would have laser level understanding of the design choices. Of course, there are other issues such as how to maintain such a unicorn, even if it is beautiful and elegant. Today, we have lovecraftian horrors with huge swaths of people working together to keep all the abstraction levels working together and hope there aren't any leftpad incidents.
Low level "machine sympathetic" programming is just one type. If you restrict yourself to it, you'll be no better than the programmer who's restricted to any other type. All these abstractions didn't spring out of nowhere - in many cases they make for very flexible software that is cheap to create. Go learn both ends. And the middle. And the weird outliers.
Agreed. I stated above that abstraction hell has its benefits. At the end of the day though you mainly are just slapping components together with that and not understanding how the problem truly works.
In my industry we do a lot of optimization and the standard technique is to not reinvent the wheel and to use a solver (e.g. Gurobi) where you give the silver your decision variables and constraints and have it quickly return the optimal decisions. This is great, but costs a lot of money (the best solvers are almost entirely commercial) and you treat a core part of your program entirely like a black box and you also have to fight things like the license manager and so on. Another option is not to create your own generic solver that solves all problems, but rather a solver that solves just your problem. The one company I know that does this has been enormously successful and their product is incredibly fast and lightweight with zero dependencies besides Windows (really cool). The only negative is that now the application is tightly connected to his own solver and they can't just switch it out easily with a different one like most people can. It's all a set of tradeoffs at the end of the day.
In my industry we do a lot of optimization and the standard technique is to not reinvent the wheel and to use a solver (e.g. Gurobi) where you give the silver your decision variables and constraints and have it quickly return the optimal decisions. This is great, but costs a lot of money (the best solvers are almost entirely commercial) and you treat a core part of your program entirely like a black box and you also have to fight things like the license manager and so on. Another option is not to create your own generic solver that solves all problems, but rather a solver that solves just your problem. The one company I know that does this has been enormously successful and their product is incredibly fast and lightweight with zero dependencies besides Windows (really cool). The only negative is that now the application is tightly connected to his own solver and they can't just switch it out easily with a different one like most people can. It's all a set of tradeoffs at the end of the day.
>having these infinite abstraction levels where nobody ever truly understands what in the world is going on anymore
s/infinite abstraction levels/Rube Goldberg contraptions/
s/infinite abstraction levels/Rube Goldberg contraptions/
Lol. Probably a more apt description.
I really wish techies would stop whinging about "bloat".
All those abstractions are necessary in order to do software engineering of real-world systems at scale. Forth lets Chuck Moore put something together quickly in very little code, that serves Chuck Moore's needs adequately well, but... Chuck Moore isn't the average person, let alone the average developer. Chuck Moore doesn't need, for example, a file system; why have one if you can just memorize the sector numbers for everything on disk?
A lot of the "bloat" in modern computing consists of things necessary in order to make computers tractable for ordinary people. This is as true for things like Electron[0] as it is for C and conventional operating systems vs. Forth on bare metal. And if technology doesn't work for people, it doesn't work.
[0] Electron has enabled a Cambrian explosion of cross-platform apps by vastly reducing the time and effort it takes to develop such an app. Developer effort is often the costliest part of software; by that metric, Electron has probably saved billions of dollars, despite consuming hundreds of megabytes that would otherwise be wasted anyway.
All those abstractions are necessary in order to do software engineering of real-world systems at scale. Forth lets Chuck Moore put something together quickly in very little code, that serves Chuck Moore's needs adequately well, but... Chuck Moore isn't the average person, let alone the average developer. Chuck Moore doesn't need, for example, a file system; why have one if you can just memorize the sector numbers for everything on disk?
A lot of the "bloat" in modern computing consists of things necessary in order to make computers tractable for ordinary people. This is as true for things like Electron[0] as it is for C and conventional operating systems vs. Forth on bare metal. And if technology doesn't work for people, it doesn't work.
[0] Electron has enabled a Cambrian explosion of cross-platform apps by vastly reducing the time and effort it takes to develop such an app. Developer effort is often the costliest part of software; by that metric, Electron has probably saved billions of dollars, despite consuming hundreds of megabytes that would otherwise be wasted anyway.
All those abstractions are necessary in order to do software engineering of real-world systems at scale.
No, they're not.
No, they're not.
This is both vague and speculative though. Vague because you have made no specific claims that could be evaluated one way or the other. Speculative because you have said nothing about Forth.
You cannot make engineering decisions based on "it'll change how you program." There are several concrete examples of turning imperative code into pure monadic code that contains less boilerplate and is less noisy with Haskell's do notation. Exhaustiveness checking, encoding invariants in types, those all have good examples that one can read and agree or disagree with. Surely there are concrete examples that one can give about Forth too?
You cannot make engineering decisions based on "it'll change how you program." There are several concrete examples of turning imperative code into pure monadic code that contains less boilerplate and is less noisy with Haskell's do notation. Exhaustiveness checking, encoding invariants in types, those all have good examples that one can read and agree or disagree with. Surely there are concrete examples that one can give about Forth too?
It's metaphysical. Like learning a foreign language widen your perspective. It's a particular insight you gain about the act of programming that makes you realize that you've been boxing yourself to a very small imperative/oop space.
Writing C code feels like writing a rule book, writing java feels like designing a lego set, writing lisp feels like writing proof, writing prolog feels like writing puzzles. Writing forth feels like writing a dictionary, then after that you write a few sentences. They're different feeling, but forth is one of the most flexible as you can go up and down from the most basic units to the high level ones. As another comment has mentioned, you can program forth where the basic units are elements from another language, and construct a dsl/dictionary out of it. Then switch the basic units while retaining your business logic for a faster implementation without a full rewrite.
Writing C code feels like writing a rule book, writing java feels like designing a lego set, writing lisp feels like writing proof, writing prolog feels like writing puzzles. Writing forth feels like writing a dictionary, then after that you write a few sentences. They're different feeling, but forth is one of the most flexible as you can go up and down from the most basic units to the high level ones. As another comment has mentioned, you can program forth where the basic units are elements from another language, and construct a dsl/dictionary out of it. Then switch the basic units while retaining your business logic for a faster implementation without a full rewrite.
Not just the realization you were boxed into a space, but also knowledge of stuff inside a different box. The more boxes you have the ability to access, the better.
The creator of Forth wrote this:
> I wish I knew what to tell you that would lead you to write good Forth. I can demonstrate. I have demonstrated in the past, ad nauseam, applications where I can reduce the amount of code by 90% percent and in some cases 99%. It can be done, but in a case by case basis. The general principle still eludes me. -- Chuck Moore
https://www.ultratechnology.com/moore4th.htm
You might appreciate other quotes from the above page.
> I wish I knew what to tell you that would lead you to write good Forth. I can demonstrate. I have demonstrated in the past, ad nauseam, applications where I can reduce the amount of code by 90% percent and in some cases 99%. It can be done, but in a case by case basis. The general principle still eludes me. -- Chuck Moore
https://www.ultratechnology.com/moore4th.htm
You might appreciate other quotes from the above page.
API design is something relatively concrete though. One can provide examples of pre-Forth and post-Forth design.
Several literary careers have been made on summarizing the main takeaways from LSD.
In my experience, the value of a trip isn't what you take away from it; it's the things that you can't take with you. Nobody really wants to see a whole slideshow of your vacation photos; it'll never compare to being there.
There is a large contingent of people that claim to know about X because they read a good book on it, which is ludicrous nonsense. Indeed the most unique things of any experience is what you cannot put into words.
Language is a very lossy compression algorithm, and some concepts aren't even computable in the first place (i.e feeling and emotions)
Language is a very lossy compression algorithm, and some concepts aren't even computable in the first place (i.e feeling and emotions)
[deleted]
If several literary careers have been made summarizing it, and it still is not adequately summarized, that proves the point.
Here is a link to the byte magazine issue that inspired the above article.
https://archive.org/details/byte-magazine-1980-08/page/n2/mo...
For people interested in Forth I think this is a nice intro: https://ratfactor.com/forth/the_programming_language_that_wr...
When I read old articles like this, I start wondering what the story was behind all those companies mentioned. Stackworks Forth, Alan Ashley Assembler. You almost never hear of a company which is still around.
Was it actually possible, back then, to make a living selling Forth for CP/M computers? Or Assemblers? Did Stackworks have an office, with a jaded-looking middle-aged secretary who put out her cigarettes in an ashtray on her desk, before she picked up when the phone rang? A glad-handling salesman who came back to the office every few weeks before going out to sell?
I don't think it has been possible to sell a compiler which isn't a loss-leader in a bundle for what, 30 years?
Or were these side hustles? Alan Ashley, was his day job being a math teacher or something, and he did this to round out his budget?
The industry was a heck of a lot smaller back then, but these old articles mention way more different companies. Seems like before all these behemoth monopolies there was a lot more air to breathe.
Was it actually possible, back then, to make a living selling Forth for CP/M computers? Or Assemblers? Did Stackworks have an office, with a jaded-looking middle-aged secretary who put out her cigarettes in an ashtray on her desk, before she picked up when the phone rang? A glad-handling salesman who came back to the office every few weeks before going out to sell?
I don't think it has been possible to sell a compiler which isn't a loss-leader in a bundle for what, 30 years?
Or were these side hustles? Alan Ashley, was his day job being a math teacher or something, and he did this to round out his budget?
The industry was a heck of a lot smaller back then, but these old articles mention way more different companies. Seems like before all these behemoth monopolies there was a lot more air to breathe.
'70s and '80s you would advertise in computer magazines. At the bottom of each ad as a little number, and in the magazine was a tear-out postcard that went back to the magazine. The postcard was filled with little numbers; you would circle the number associated with and ad, and the company would send you information about their company, price lists, etc.
The '70s and early '80s, it was CP/M, TRS-80, Apple ][ software. By the mid '80s and into the early '90s it was all one-person shops that were making custom UI controls for Windows 3.1. Tree and list controls were popular, plus some database connectors. By this time there were small companies making C++ libraries to make Windows programming easier, I remember Zinc and Zapp. They were wiped out when Visual C++ came out with Microsoft Foundation Classes.
The '70s and early '80s, it was CP/M, TRS-80, Apple ][ software. By the mid '80s and into the early '90s it was all one-person shops that were making custom UI controls for Windows 3.1. Tree and list controls were popular, plus some database connectors. By this time there were small companies making C++ libraries to make Windows programming easier, I remember Zinc and Zapp. They were wiped out when Visual C++ came out with Microsoft Foundation Classes.
The first developer tool I ever bought was Develop-64, an assembler for the Commodore 64 by a company called French Silk software. I was around thirteen years old and I figured this was some big professional company. Much later, I realised it was basically one guy and there was no way this was a full-time job. I think these tiny shops were pretty common back then, basically hobbyists trying to monetise their creations.
At the same time, disassemblers were handy tools for figuring out how things were done. Could be very learnful. Then they mysteriously went away for some reason.
It would depend on the generation of CP/M. CP/M 1.0 and 1.1 had Gary Kildall dealing with it when he came off duty from a nuclear submarine. CBASIC (from Compiler Systems aka Gordon Eubanks) dated from the same period and was also a part time activity for a nuclear sailor. CP/M 3.0 was mature - you had a lot of professional compiler companies like Prospero, Borland, FTL, and HiSoft, but by that stage. Some of them, like Prospero and HiSoft dated back to the CP/M 2.2 era, and I got the impression that they had three or four staff.
Thanks for the view back into history. I was kinda under the impression that this side-hustle thing was new. Apparently its not only old, but was an essential part of the technological progress we've had since then.
I knew some acquaintances back in the day (late 80s/early 90s) who had a company selling X servers. It wasn't a big operation (maybe half a dozen people total) and it worked out of a small office in the industrial section of Ft. Lauderdale (a fairly seedy looking neighborhood to say the least). But they made a decent living for maybe a decade or so and had some fairly big customers.
Commoditize your complement. If you sell operating systems, it pays to make compilers a commodity so that everyone can write programs for your operating system. This is true even if you aren’t “selling” the OS in the traditional sense of the word.
The alternative is a world where developer tools are expensive, and thus only the rich can program their own computer.
The alternative is a world where developer tools are expensive, and thus only the rich can program their own computer.
> I don't think it has been possible to sell a compiler which isn't a loss-leader in a bundle for what, 30 years?
I agree and personally feel that this is unfortunate and that we are in some ways imprisoned using mediocre to bad compilers by our collective refusal to pay for better ones.
I agree and personally feel that this is unfortunate and that we are in some ways imprisoned using mediocre to bad compilers by our collective refusal to pay for better ones.
Eh, the ones made by one or two people working part time and selling them as shareware weren't necessarily better than what we have available now. They may have been good enough for their time, but probably wouldn't cut it today.
And the ones made by corporations were prohibitively expensive. As a teenager wanting to learn, or a hobbyist making programs for fun, would you really pay $4500 for a compiler to tinker with projects in your spare time? There's one reason hardly anyone uses Delphi anymore. By the time they finally released a Community Edition, there was no community left that had grown up learning Pascal.
And the ones made by corporations were prohibitively expensive. As a teenager wanting to learn, or a hobbyist making programs for fun, would you really pay $4500 for a compiler to tinker with projects in your spare time? There's one reason hardly anyone uses Delphi anymore. By the time they finally released a Community Edition, there was no community left that had grown up learning Pascal.
i agree that we should have a better model as a society to produce things like compilers, but having a direct retail relationship with a closed source provider was pretty nasty.
because of tooling, large code bases, and weak standardization they had a huge amount of lockin. and only a single narrow funnel in which to address deficiencies.
and while certainly on a lower tier than EDA seats, werent super cheap. they usually had limited platform support. while they did optimize better for their targets, otherwise they were poorer systems than gcc, with all its warts.
because of tooling, large code bases, and weak standardization they had a huge amount of lockin. and only a single narrow funnel in which to address deficiencies.
and while certainly on a lower tier than EDA seats, werent super cheap. they usually had limited platform support. while they did optimize better for their targets, otherwise they were poorer systems than gcc, with all its warts.
I'm a vintage computer collector and the Jupiter Ace would be the holy grail of my collection. Has anyone seen one in real life?
A Jupiter Ace was my second computer, when I was 14 or 15, after a Sinclair ZX81. Great little computer, but compared to the Spectrum that came out around the same time, it had a worse keyboard, only black and white graphics and 3KB of RAM. Because it used Forth, you could do quite a lot in 3KB, but it was still a bit limiting. I think mine was a very early one, because it had some added soldered wires on the board, correcting some errors.
Mine got modified quite a bit over the next couple of years. Extra RAM. Some dumpster diving got me several keypads with good quality keys. I took them apart and made a proper keyboard to replace the original dead rubber monstrosity.
I made a parallel I/O port out of TTL logic and veroboard. And then temporarily my Ace rode about on the top of a fairly flaky micromouse exploring mazes. It didn't win any prizes but it did get me an A in O-level Technology.
My school was throwing out an old teletype, so I scavenged that. Then I modified the parallel I/O port to output +/- 12V on one pin, and wrote software to bit-bang RS232 at 110 baud. Back before the Internet, just finding the specs for RS232 was not so simple - our local library was a bit limited in that way - but I got there in the end. A lot of guesswork and trial and error. I don't think anyone made a printer for the Ace, so I may have had the only one. Being able to print code listings really helped.
The first summer I wrote a whole load of games, mostly in Forth, but sometimes Forth just wasn't fast enough. I got a copy of "Mastering Machine Code on Your ZX81", and learned Z80 machine code. If there was an assembler available, I didn't have it, so this was all hand-assembled. Getting jumps right was a total pain, as was debugging. Generally, it either worked first time, or you started from scratch again. Usually I got there in the end.
I sold those games through a ad in "Your Computer" magazine, and earned back the price of the computer several times. But recording and shipping tapes one at a time got tedious really fast, so I didn't take that any further.
Somewhere over the years, with my parents moving house multiple times, the Ace disappeared. Many years later, I found one on Ebay, and still have it. But somehow I never fell back in love with it - it just wasn't as good as I remembered my one rather non-stock one being at that formative time in my life.
Mine got modified quite a bit over the next couple of years. Extra RAM. Some dumpster diving got me several keypads with good quality keys. I took them apart and made a proper keyboard to replace the original dead rubber monstrosity.
I made a parallel I/O port out of TTL logic and veroboard. And then temporarily my Ace rode about on the top of a fairly flaky micromouse exploring mazes. It didn't win any prizes but it did get me an A in O-level Technology.
My school was throwing out an old teletype, so I scavenged that. Then I modified the parallel I/O port to output +/- 12V on one pin, and wrote software to bit-bang RS232 at 110 baud. Back before the Internet, just finding the specs for RS232 was not so simple - our local library was a bit limited in that way - but I got there in the end. A lot of guesswork and trial and error. I don't think anyone made a printer for the Ace, so I may have had the only one. Being able to print code listings really helped.
The first summer I wrote a whole load of games, mostly in Forth, but sometimes Forth just wasn't fast enough. I got a copy of "Mastering Machine Code on Your ZX81", and learned Z80 machine code. If there was an assembler available, I didn't have it, so this was all hand-assembled. Getting jumps right was a total pain, as was debugging. Generally, it either worked first time, or you started from scratch again. Usually I got there in the end.
I sold those games through a ad in "Your Computer" magazine, and earned back the price of the computer several times. But recording and shipping tapes one at a time got tedious really fast, so I didn't take that any further.
Somewhere over the years, with my parents moving house multiple times, the Ace disappeared. Many years later, I found one on Ebay, and still have it. But somehow I never fell back in love with it - it just wasn't as good as I remembered my one rather non-stock one being at that formative time in my life.
Oh man, those were fun times. I started with a Model 15 TTY (for ham radio). When I got my first 8080 machine (statuc RAM was an expensive extra), I learned a lot by making a PC board to convert 45bps (5-bit characters) to 110bps Baudot (using 2 crystals). Then teaching the 8080 to table-convert baudot to ASCII (from a 'ring buffer' filled using interrupts).
The good old days, before layers of 'protection' got baked in (Apple II vs Mac).
The good old days, before layers of 'protection' got baked in (Apple II vs Mac).
There's one in the Cambridge computer museum: https://www.computinghistory.org.uk/det/1332/Jupiter-Ace/
Steve Vickers, one of the founders of Jupiter Cantab, was my university lecturer back in the 90s. He taught a very obscure course in mathematical structures, and in a sense was both the first and last (a decade and a half later) to teach me computer science. Previous comments: https://news.ycombinator.com/item?id=23760382 https://news.ycombinator.com/item?id=26375986
Steve Vickers, one of the founders of Jupiter Cantab, was my university lecturer back in the 90s. He taught a very obscure course in mathematical structures, and in a sense was both the first and last (a decade and a half later) to teach me computer science. Previous comments: https://news.ycombinator.com/item?id=23760382 https://news.ycombinator.com/item?id=26375986
I've seen one once at a HamFest or something.
There are kits out there to make your own though:
https://www.tfw8b.com/product/minstrel-4d-turbo-jupiter-ace-...
There are kits out there to make your own though:
https://www.tfw8b.com/product/minstrel-4d-turbo-jupiter-ace-...
several on ebay, here's one:
https://www.ebay.com/itm/115272079823?itmmeta=01J10WB15JY1KF...
https://www.ebay.com/itm/115272079823?itmmeta=01J10WB15JY1KF...
For only 1600 pounds.
Do you have any OpenBoot/OpenFirmware machines like the Sun4 or early SPARCstations? I was wondering what they were like as pure Forth machines.
I'm not a Forth programmer, but I used to be a Sun sysadmin. From what I recall, the Forth code on a SPARCstation is interpreted and pretty slow.
These docs support that: https://docs.oracle.com/cd/E19455-01/816-1177-10/816-1177-10...
The system supports FCode, which is processor-independent byte code. This allows expansion devices (like a card or peripheral) to bring with them their own platform-independent device drivers, which is pretty cool. So you could make a disk controller card and then any system that you plug it into could boot off it, no matter the CPU architecture.
Anyway, the point is, since it was mainly used for booting and diagnostics, I don't think they put much effort into performance. For it to be an actually good Forth environment, I think you'd want to have some way to run Forth programs as native code, either by adding the option to JIT the FCode instead of interpreting it or by adding a compiler that compiles Forth source to native.
Also, I believe the old PowerPC Macs (like G3, G4, and G5) used Open Firmware, so if you wanted this Forth experience, you have that option in addition to Sun workstations.
These docs support that: https://docs.oracle.com/cd/E19455-01/816-1177-10/816-1177-10...
The system supports FCode, which is processor-independent byte code. This allows expansion devices (like a card or peripheral) to bring with them their own platform-independent device drivers, which is pretty cool. So you could make a disk controller card and then any system that you plug it into could boot off it, no matter the CPU architecture.
Anyway, the point is, since it was mainly used for booting and diagnostics, I don't think they put much effort into performance. For it to be an actually good Forth environment, I think you'd want to have some way to run Forth programs as native code, either by adding the option to JIT the FCode instead of interpreting it or by adding a compiler that compiles Forth source to native.
Also, I believe the old PowerPC Macs (like G3, G4, and G5) used Open Firmware, so if you wanted this Forth experience, you have that option in addition to Sun workstations.
> Also, I believe the old PowerPC Macs (like G3, G4, and G5) used Open Firmware, so if you wanted this Forth experience, you have that option in addition to Sun workstations.
So did the OLPC-1 where the non-FOSS nature of "Open" Firmware was a bit alien.
So did the OLPC-1 where the non-FOSS nature of "Open" Firmware was a bit alien.
The text mode on the framebuffer was terrible on most machines, too.
Still, stop-a and then e.g. 3719 824 + 53 * . when you needed a little bit of arithmetic help was always a possibility ;)
Still, stop-a and then e.g. 3719 824 + 53 * . when you needed a little bit of arithmetic help was always a possibility ;)
The G4 did indeed support Open Firmware: I had an MDD.
[deleted]
Mitch Bradley was the author of a great deal of that Forth; his CForth is on GitHub : https://github.com/MitchBradley/cforth
(It might be easier than finding an old Sun machine)
(It might be easier than finding an old Sun machine)
At my local fine-fare (80s uk superstore) they sold computers in a 'concession' stand.
They sold Jupiter Aces. Wish I had the money back then to get one!
They sold Jupiter Aces. Wish I had the money back then to get one!
Doing the opposite works for me.
I always start out defining the ideal API I want to solve a problem and then solve the problem using the not-yet-implemented API. I then implement the API recursively by adding lower level API’s that makes it easy to solve the higher level API problem. And most of the time I already have a lower level API from a previous project I can easily reuse and perhaps expand.
So I don’t start with the database moving towards the biz logic. I start with the biz logic moving towards the DB (if needed). It works really well.
I think this is similar to how experienced Lisp developers work. Starting out defining a new “language” (a bunch of functions) that makes it easy to solve the problem and then recursively implementing it. However I work in C++ and Typescript not Lisp.
I always start out defining the ideal API I want to solve a problem and then solve the problem using the not-yet-implemented API. I then implement the API recursively by adding lower level API’s that makes it easy to solve the higher level API problem. And most of the time I already have a lower level API from a previous project I can easily reuse and perhaps expand.
So I don’t start with the database moving towards the biz logic. I start with the biz logic moving towards the DB (if needed). It works really well.
I think this is similar to how experienced Lisp developers work. Starting out defining a new “language” (a bunch of functions) that makes it easy to solve the problem and then recursively implementing it. However I work in C++ and Typescript not Lisp.
Are there any Forth variants that have static typing? Or more generally, are there any interesting type systems that target stack-based machines?
I think StrongForth, Cat and Kitten are all statically-typed, stack-based languages:
https://www.stephan-becher.de/strongforth/
https://github.com/cdiggins/cat-language
https://kittenlang.org/
https://www.stephan-becher.de/strongforth/
https://github.com/cdiggins/cat-language
https://kittenlang.org/
Java?
FORTH compilation is typically minimal (bit of a defining feature really), so there is no static (i.e. compile-time) type verification or much any optimization.
O.t.o.h., the JVM is stack-based and has been used for a plethora of programming languages, many statically typed.
FORTH compilation is typically minimal (bit of a defining feature really), so there is no static (i.e. compile-time) type verification or much any optimization.
O.t.o.h., the JVM is stack-based and has been used for a plethora of programming languages, many statically typed.
Forth has integers and that's about it. You can have words that interpret the integers and e.g. show you characters instead, but it's usually just a thin cover over the numbers.
The JVM is stack-based and static typing rather common in the languages that runs on it.
Factor has dynamic typing, though I haven't thought much about that, it kind of stays in the background. It's more a tool for problem solving than a description of some type theory: https://factorcode.org/
The JVM is stack-based and static typing rather common in the languages that runs on it.
Factor has dynamic typing, though I haven't thought much about that, it kind of stays in the background. It's more a tool for problem solving than a description of some type theory: https://factorcode.org/
There are Forths with richer types than just that -- it's not just one language, after all. I've never heard of statically typed Forth; the stack is a filthy pile, after all. But nothing stops you from writing an allocator, container types, etc..
I think one could macro in some type system on top of a collection type in Factor if one wanted to.
Don't really see the point, though. Static on-the-nose typing tends to shine when a lot of people need to do quick edits to large amounts of code, settings where code is never done, and that's not exactly where Forth-like languages are a good fit. They're more for settings where few people think long and hard and experiment a lot until the right solution is found and then it's done, I think.
In practice I often find the shape of data to be good enough and don't feel a need to also put names to it. It might be convenient to invent a type to carry some constraint, like UserNicknameString that can only be up to 200 4 byte characters (or whatever the big emoji chars in Unicode are) and no more, but that can also be solved functionally. As far as I'm aware no one has yet created a serious ERP or social media product in a Forth-like language, so maybe the perks that come with having an ontology of ten thousand types keeping things in check are still illusory for the hardcore forthers.
Don't really see the point, though. Static on-the-nose typing tends to shine when a lot of people need to do quick edits to large amounts of code, settings where code is never done, and that's not exactly where Forth-like languages are a good fit. They're more for settings where few people think long and hard and experiment a lot until the right solution is found and then it's done, I think.
In practice I often find the shape of data to be good enough and don't feel a need to also put names to it. It might be convenient to invent a type to carry some constraint, like UserNicknameString that can only be up to 200 4 byte characters (or whatever the big emoji chars in Unicode are) and no more, but that can also be solved functionally. As far as I'm aware no one has yet created a serious ERP or social media product in a Forth-like language, so maybe the perks that come with having an ontology of ten thousand types keeping things in check are still illusory for the hardcore forthers.
https://thinking-forth.sourceforge.net is worth reading, even if you have no desire to ever program any Forth.