One of my favorite games was written in Forth. STARFLIGHT, released in 1986 for IBM PC. (Though most of my playtime is on the Sega Genesis port).
It fit on two 360K floppy disks and managed to have 270 star systems and 800 fully explorable planets (well, the gas giants would kill you if you landed on them).
Forth was one of the first languages I learned because I looked up what languages my favorite games used. I knew some C/C++ and that was the most common answer. But when I saw my favorite game used Forth, surely it must be an amazing language. It is a pretty amazing language. Very fun to learn and eye-opening to me at the time as to what a language could be. It was a really fun learning experience, though I've never used it for anything very complex. I can see how it could be pretty un-scalable for teams, every Forth codebase seems to turn into its own unique language.
Forth also requires very minimal resources to implement which can be fun in constrained environments. Here it is on a TI-84+ calculator[0] or even a computer in The Powder Toy.[1]
The runtime design is a little quirky but straightforward and you can extend the system as you execute (or even change interpreter semantics), or add optimizations such as some form of JIT quite easily.
The "constrained environment" is the rub. In the old days, supporting a time sharing dev environment for 30 users (with 2K dedicated memory each), or getting to a functional self-hosted prompt before the floppy drive spun up to full speed, or fitting a dev environment in a single jumbo packet, etc. were not only cool, but were technically required.
We have megahertz and gigabytes and "embedded" systems with MMUs and filesystems at our disposal, so I'm guessing the time when forth was a solution has long since past.
> the time when forth was a solution has long since past.
It depends on the problem.
If it's education, I'd argue Forth still has a place. Writing a Forth compiler is a manageable project for a single developer.
Restricted resource creative projects, in code and other mediums, may help with teaching and creativity. I don't have research on that, and it isn't my idea, that credit should go to multiple others.
I've always thought this really-well-written old post by Yosef Kreinin is quite enlightened regarding the reality of Forth (even if a bit snarky, as usual from him):
Then find all the little half-truths in that post.
I think this part sums up the problem with Forth quite well:
> I defined the instruction set in a couple of hours. It mapped to Forth words as straightforwardly as possible [...] but it was harder than we thought. Presumably that was partly the result of not reading "Stack Computers: the new wave"
In other words: people too often confuse "simple" and "easy", think they don't need the experience of others, and then feel bad when they try and fail - and that post provides them with solace and a good excuses to quit when it happens with Forth. I don't mind them quitting Forth, but I'm more annoyed when they spread those half-baked "truths" about Forth.
True, for the record I really like Forth and have had a go at implementing a forth like language interpreter (well maybe more than one go...). Getting it to be simple is not easy but it's really instructive to try.
I regularly see Forth related material appear on HN. I love a lot of the concepts that get brought up in these article’s comments, particularly those that discuss the often small and personalized implementations of Forth that appear ubiquitous among those interested in Forth. However there doesn’t seem to be anyone who considers it a viable language for actual programming and a large portion of that seems to come from the personal implementations coupled with the proliferation of custom DSL’s that are reputed to spring up in any Forth program.
As a person working on a programming language design that is a little forth-like in presentation (it’s not stack-based), is it just the anecdotal experience of Forth that leads to the seeming incompatibility with producing complex software? Or does this seem to be inherent in Forth’s minimal syntax design (similar discussions also happen in Lisp discussions)?
I've written both Forth and Lisp for production systems. Both are very intolerant of lax software engineering practices. Because both are "language construction kits," you have to come to agreement with other members of your team about how you will create and document your DSLs, which is a step beyond the agreements you need with "ordinary" languages.
The big difference for me was that I couldn't even read my own Forth code after I had been away from it for a year; I had to first re-teach my brain to think like a stack machine. That was never a problem with Lisp. I can look at 10-year-old code I wrote in Lisp and re-understand it quickly (especially with the tools built in to Emacs that are quite helpful for Lisp code exploration).
Honestly I think that for many, Forth may be a bit too much of a green field to build upon.
Out of the box, out of the standard, there no real structured data type ala records, there's no strings, there's no modular coding construct. All of those can be added, but that's the trick. They have to be added. You also start getting into implementation specific stuff that, potentially, makes that kind of infrastructure not portable across implementations.
Not that portability is a huge concern, but it's a factor if you want to import someone else's implementation.
All of that can be overcome, but that they have to be overcome is part of the problem. Original scheme suffered from this as well, but look how far it's come over time. To the point that all "usable" schemes aren't really the 50 page R5RS versions anymore.
It also doesn't help that Forth niched its way into controllers and smaller systems. Forth had all of the availability advantages early on, perhaps even more so, than C, Pascal, etc. But, organically, Forth never caught on.
It's fair to say that Lisp suffered "not enough computer" issues early on to hinder adoption, but that's long past. But Lisp still suffers adoption, when pretty much every complaint about it is long buried -- save its syntax.
And I just think folks, again, organically, "wisdom of the crowds" don't like S-Exprs for code. They just don't like it. It's off-putting enough that folks look elsewhere.
Forth, in the end, suffers similarly. All of these demos and mini DSL examples look great. But they're contrived. Take a look at any Forth code you can find and see if you can make sense of it. Especially "modern" code, where we "know better" and aren't constrained by file size, or line size, or "screens" or "blocks".
Take a look at that Zen's github.
And try to make sense of it.
This is all barrier to entry, and most aren't willing to climb over it.
> Out of the box, out of the standard, there no real structured data type ala records, there's no strings, there's no modular coding construct. All of those can be added, but that's the trick. They have to be added.
There are structures, strings, etc in standard forth. And if you're using an older forth without structures here is a structures library in 2 lines:
I hate that I think you are probably correct. I especially think you hit a strong line of thought with the portions of Forth’s aesthetic and idioms that are very much a product of hyper constrained resources from the time period of its release. The issue of lack of standard library is a part of that time period effect as well, I think any new language has to come with some basics in 2022 which would have been extravagant prior to 1975 (maybe even later if C is any guide).
I really am drawn to a Forth—esque syntax, but i think that has more to do with the type theoretical and categorical semantics of my language and it’s projectional properties than simple appearance. Fortunately I don’t think I am ever going to release it, so I don’t have to worry about general acceptance.
I think factor https://www.factorcode.org/ fills in the need for a batteries-included and higher-level abstractions-provided stack-based language quite well.
While the language is not exactly popular right now, I think they are on the right track on what a modern stack-based language should look like.
Slight correction, FORTH-79 does indeed have first class string support. Forth strings are generally tuples of the form (start address, length) which are placed on the stack after definition.
The point of discussing these languages isn't always that you should plan to adopt it at your place of work tomorrow. Research into programming languages helps push the boundaries, and advances in PL research get adopted by mainstream languages eventually. Like how most high-level languages today support value assignment + destructuring, which came (as far as I'm aware) from more research-y ML languages.
And not all research is done by university researchers. And not all of HN is solely industry practitioners. You just can't make huge assumptions about tech based on what you see on HN, basically. :)
With that said, PostScript is a stack language, x86 can be treated pretty similarly to a stack language, FreeBSD's bootloader used to be in Forth (may not be anymore, I don't know). And I hear it's used in constrained/embedded environments. So I don't mean to suggest it's not a practical language either.
I agree in full, and my comment was quite an over-generalization.
As a side note, you tweeted sometime this summer about how there were a load of hobbyist compilers and a lack of hobbyist databases, then in a response mentioned the largeness of the research/conceptual space for databases. Those tweets got me to put database design and implementation onto the top of my ‘read up on’ pile. So, thanks.
The reason Forth is not used in production is that its philosophy goes against that of commercial software. The goal of commercial software is to create complex and over-engineered solutions that will force people to pay in one way or another. Languages like C++, Java, Python, and Go are ideal for this. Forth is about creating very simple solutions in as little code as possible. It is better suited for embedded systems and prototype projects.
I disagree with the anti-commercial philosophy that Forth is supposed to have. E.g., there are no oss network stacks I could find written natively in Forth, but there might be a few commercial ones.
I believe there are a few very good Forth coders out there that have been working as consultants and much of the code is very proprietary and not available as open source. Otoh, there are tons of free Forth implementations, but they are really meant as a learning tool - it's fun and instructive to write a Forth.
I would disagree with this statement. The (earlier) history of Forth was that the original inventor would be contracted to implement it on new machines. That it took forever to spawn any kind of interest outside of his commercial activity speaks to Forths practical limitations i.e. every installation becomes a new, extremely opinionated language and we all know the aphorism about opinions.
Why would a company open source (or publish) the controller for... http://www.forth.org/svfig/kk/11-2017-LWagner.pdf ... industrial refrigeration controls, wireless spinal cord nerve stimulation, satellite communication dish positioning?
This isn't software that you're going to be sharing. It is in nearly every situation bespoke software for that specific industrial or medical application.
There are enough areas, libraries, whatnot, where it would be perfectly fine to share forth code.
I mean, look at device drivers for linux.
Doing this would really have helped the ecosystem, I suspect, because people would have tried to clean up their code a bit before throwing it on github, for instance. Not that examples that are on github today are all stellar.
Because those examples are medical and industrial devices.
The insurance issues that a manufacturer gets when people are provided the software to modify it becomes much more complicated.
It becomes much more difficult to insure a facility that has an industrial refrigeration unit where it is possible for people to change how it runs.
Note that this is an issue with industrial and medical systems - the insurance for these is such that the manufacture is liable unless they have taken every possible precaution to prevent misuse. From an insurance perspective, that includes keeping the source code closed.
This is a very different issue from consumer devices. An open source device driver tinkering causes the computer to overheat? "No warranty" is enough to disclaim that for consumer systems - not so with industrial devices where the tinkering person can kill someone and the company making the device is liable because this was a precaution they could have taken.
> Note that this is an issue with industrial and medical systems - the insurance for these is such that the manufacture is liable unless they have taken every possible precaution to prevent misuse.
Is that an accurate statement of the legal liability? If the vendor clearly states in the sales contract that it disapproves of unauthorised customer modifications, that such modifications will invalidate product safety and regulatory compliance testing, and that it excludes all liability for customers who ignore those warnings – and the customer does it anyway – why should they be liable?
> This is a very different issue from consumer devices.
I think it is indeed different, but in a different way than you think. Products sold directly to ordinary consumers, courts accept that most consumers won't read or won't understand the sale contract, and so are more likely to invalidate exclusions of liability contained therein. Industrial and medical devices are not sold directly to individual consumers; their purchasers are usually corporate entities (whether a business or a not-for-profit enterprise such as a hospital), which can be assumed to have ready access to legal counsel; and the staff of the entity involved in the purchase can be expected to have a professional level of understanding of the technology, safety/regulatory/compliance risks involved, etc. Given that, courts are far more likely to uphold exclusions of liability (including exclusions of liability for unauthorised customer modifications), than for a contract of sale to individual consumers.
Furthermore, the vendor can put in the sale contract that the customer indemnifies the vendor for any liability caused by the customer's unauthorised modifications. Such an indemnity is far more likely to be upheld in a B2B contract than a B2C one. And unlike the B2C case, the customer is likely to have significant financial resources, and its own liability insurance, making such an indemnity much more meaningful in practice. The vendor can also do customer due diligence, such as asking customers to provide evidence of their own liability insurance – something which is rarely practical in the B2C space.
> For the latter, California law provides options to Plaintiffs who pursue products claims against manufacturers, distributors, and others responsible for a defective product. These claims may allege:
> Design defects, which can include a lack of adequate safety devices (i.e. machine guarding, shut-off valves, etc.) or other potential hazards in a product’s design that a manufacturer could and should have known would increase the risk of foreseeable harm.
If it is foreseeable that "here's the source code to the industrial refrigerator controller" that someone might alter it and update it, then the manufacturer will have a harder time not being liable.
Similarly, "here's the spinal nerve stimulation controller" may be risky to have people get the source code to to modify on their own.
---
If you modify your car, and its not a design defect and something breaks, that's on you.
If you remove a throttle on the computer's CPU and melt the solder, that's on.
If you can reprogram a controller on an industrial device - that's on the manufacturer always.
Industrial and medical equipment falls in a different category for product liability than consumer devices.
> The Court’s ruling in Demara means the consumer expectation test may effectively be used to demonstrate the inappropriateness of a design for a broad range of products – even those which perform highly complex tasks in industrial settings – and hold manufacturers to higher standards.
Note that the manufacturer of an industrial or medical device is held to a higher standard of "not letting the customer do the wrong thing with it."
The issue is that at the end of the day, the manufacturer of industrial and medical equipment is liable for damages unless they take every possible foreseeable precaution to prevent the user of the device from inadvertently causing harm to themselves or others. That liability extends through resellers, rentals, and 3rd parties.
See https://www.druganddevicelawblog.com/2020/11/no-manufacturer... “No Manufacturer Liability for After Market Modifications” which reports on the case Lowe v. Cerner Health Services, 2020 U.S. Dist. LEXIS 218240 (E.D. Va. Nov. 20, 2020) - https://casetext.com/case/lowe-v-cerner-health-servs - a hospital customised an EHR system, and flaws in the hospital’s modifications was a contributory factor to plaintiff’s injury. The Court held that the EHR vendor was not liable for flaws in the hospital’s implementation (as opposed to the base product itself).
> Note that the manufacturer of an industrial or medical device is held to a higher standard of "not letting the customer do the wrong thing with it."
> The issue is that at the end of the day, the manufacturer of industrial and medical equipment is liable for damages unless they take every possible foreseeable precaution to prevent the user of the device from inadvertently causing harm to themselves or others.
You are essentially repeating the plaintiff’s contentions in that case, and the Court rejected them.
If you read the judgement, it simply turned on the application of standard Virginia product liability law - nothing in the case turned on what category of product an EHR is.
As far as I am aware, Virginia product liability law does not treat medical devices specially - they are subject to the same fundamental principles as any other product. Can you cite any sources to the contrary?
> (a) A manufacturer of a prescription drug or medical device who sells or otherwise distributes a defective drug or medical device is subject to liability for harm to persons caused by the defect. A prescription drug or medical device is one that may be legally sold or otherwise distributed only pursuant to a health-care provider's prescription.
> (b) For purposes of liability under Subsection (a), a prescription drug or medical device is defective if at the time of sale or other distribution the drug or medical device:
> (1) contains a manufacturing defect as defined in § 2(a) [i.e., when the product departs from its intended design even though all possible care was exercised in the preparation and marketing of the product]; or
The text you've quoted is from the "Restatement (Third) of the Law of Torts: Products Liability". That's not the actual law – that's a "Restatement" published by the American Law Institute (ALI), a body dominated by law professors, but also including some judges and practising lawyers among its membership. It is their summary of what they think the law is, mixed (in some cases) with their opinions on what the law ought to be. It is also trying to distill common general principles from the laws of all US states, so whatever it says may not be true in all states. They've found it helpful to have a section specific to prescription drugs and medical devices – but that doesn't mean that the fundamental legal principles regarding them are different from those applying to other products. Courts in the US frequently accept the ALI's "Restatements" as persuasive but not binding, and when they conflict with statute or relevant case law, the later takes precedence.
You appear to be claiming that "strict liability" is something specific to industrial and medical products – but under the law of many US states, "strict liability" applies to design defects in all products.
In fact, in the case of Brown v. Superior Court, 44 Cal. 3d 1049, 245 Cal. Rptr. 412, 751 P.2d 470 (1988) [0], the Supreme Court of California concluded that the the "strict liability" standard which applies to design defects in ordinary products should not apply to prescription drugs, because it threatened to increase the expense and risk of new drug development to the point that it might discourage it, thereby harming public health. A number of subsequent decisions, including Hufft v. Horowitz, 4 Cal.App.4th 8 (Cal. Ct. App. 1992) [1], extended that ruling to implantable medical devices. So, contrary to your assertions that medical devices are under some special legal regime which is stricter than that applicable to ordinary products, California product liability law is actually (at least in this regard) weaker for prescription drugs and (implantable) medical devices than for consumer goods, since it exempts them from one of the product liability rules which apply to almost every other category of goods.
Umm… no. What language is used on a project is typically two things: (1) did the manager hear it in a buzzword laden tech talk, (2) do the programmers assigned to the project know the language already. The only other one that comes up is typical only to those who have the power to choose and also the wisdom: is it the right tool for the job. On this, Forth will usually fail. There are a lot of tools the programmer would need to self implement. Unless he/she were working in an insanely constrained environment, Forth is likely not the best choice for maintainability and time requirements.
I haven't done much with Forth, so take this with a grain of salt.
Most corporate software development uses languages like Java, C#, Ruby, and Python that are all very similar to one another. Sure, some of them use different punctuation, but the basic tools you use to solve problems all involve putting pretty much the same words in pretty much the same order. It's easy for someone with one language to quickly pick up another.
Forth's syntax immediately pushes it into the "weird languages" category because almost all of the words are in a different order. "1 + 1" is now "1 1 +". That sets it far enough apart from Python/Ruby/Java/etc that a tech company isn't going to use it unless they feel really strongly about it. (AFAIK there isn't any big corporate push for Forth like there is for Go and Rust and stuff.)
The main audience for Forth is therefore hobbyists. I think the main reason why you see lots of handmade Forth implementations is because Forth is really easy to implement. It's a fun hobby project. And because Forth is simple, its community biases towards people who like writing simple software. If you want to write complex software in a weird language, you'll probably gravitate towards a complex language like Haskell or something.
Another reason why there are so many handmade Forth implementations is because it is almost more educational and rewarding to write a forth than it is to use one.
(For the reasons explored already upthread.)
I like forth, I've implemented two, and yet the most I've done with it is write toy programs, and use it to script a host program a few times.
> When the PDP-11 arrived, B was moved to it almost immediately. In fact, a version of the multi-precision `desk calculator' program dc was one of the earliest programs to run on the PDP-11, well before the disk arrived. However, B did not take over instantly. Only passing thought was given to rewriting the operating system in B rather than assembler, and the same was true of most of the utilities. Even the assembler was rewritten in assembler. This approach was taken mainly because of the slowness of the interpretive code. Of smaller but still real importance was the mismatch of the word-oriented B language with the byte-addressed PDP-11.
The main advantage of Forth is that it can be put in some very small places and run impressively fast.
> NC4016 (formerly NC4000) was a 16-bit stack machine microprocessor designed by Novix in 1985 primarily for the Forth programming language. The NC4016 directly executes the primitives of the high-level Forth programming language. The NC4016 was capable of executing typical Forth programs as much as 20 times faster than the Motorola 68000. Novix also offered the NC4000 Small C Compiler which was compatible with the NC4016 microprocessor.
> In 1988, the NC4016 design was licensed and improved by Harris Semiconductor which later rebranded the chip as the RTX2000, a radiation hardened version suitable for spacecrafts use.
Moore often talks about being a "1X" programmer, as opposed to a "10X" programmer. By which he means that he writes only a fraction of the code that others do.
I think it all boils down to specificity vs generality. Moore is specific. He solves one problem, not many. If he has a different problem, then he uses a different solution. By being tightly focussed on his one specific problem, there's many things he doesn't need. Like, he doesn't need a file system. He just stores data and code in blocks in the disk. You end up with a system that is small, tight, minimalist, does what it needs, and then stops.
That approach doesn't work if you want to make something more general-purpose, like a Linux kernel. It's not like Linus Torvalds is a nincompoop that somehow didn't realise that 90% of the code was unnecessary. Linux is popular because it solves a broad range of problems to a broad range of people.
Forth systems are unpopular because they solve the problem of one man. Not only that, that one man must have a mental model of how his whole system works. The upside is that the system is much simpler than a general-purpose one.
One could say that Forth is not just a language, but a whole philosophy as to how and what programs should be constructed.
> seeming incompatibility with producing complex software [...] inherent in [...] minimal syntax design [...] ?
Perhaps they are culturally associated?
Imagine a Forth bootstrap moving quickly on to C ABI and dynamic linking, to libpython and python ast vocabulary, and to numpy etc. Or a "parse all the languages" GLR/mixfix-expr/regex-token sandwich parser and some LLVM vocabulary. But ... that's not "doing Forth". Culturally.
Lisps could read `a[i] = 3` as sugar for `(setf (aref a i) 3)`, but don't. And for overlapping reasons, an organization for weeks struggles to even build its big CommonLisp thing (reader symbol conflict hell).
When a community doesn't much go somewhere, the path is unlikely to be smooth. And so a non-technical cultural challenge becomes something more.
Minimal syntax has value and power. Non-minimal syntax has value. So if there's one, but not the other, that seems notable, and perhaps a symptom of other issues around tooling up for complexity?
Some guy once said that Forth's fragility is its strength. It forces you to think in very simple terms.
"Zen" is a good way of describing Forth. Charles Moore often says things that seem like zen riddles in themselves, like Operating Systems are obsolete, you don't need local variables, you don't need structures, and a whole host of other things. It's very difficult to know what he's talking about without context, or why he thinks what he says.
I've toyed around with his colorforth, and given up. I doubt I'm the only one. It has cool stuff like you being able to change the fonts on the fly. It has a keyboard consisting of 25 keys (because 25 keys should be enough for anyone, apparently), which don't map onto a Qwerty keyboard (maybe Dvorak?) and has different modes based on colour. So I'm like "how the living fuck am I supposed to use this thing"? It's like trying to figure out the controls of some alien spacecraft.
It clearly works perfectly for Charles. He's clearly on some whole different level than the rest of us.
Forth is really fun to play with; before going back to using something that is a bit more practical. It has macro-like facilities. I find them very difficult to reason about. Forth seems like Lisp in terms of power, but at the opposite end of the spectrum in terms of size. Lisp is a complete language. Forth gives you a boxful of atoms that you assemble yourself.
It incorporates the notion of a token type. The idea is that you could write a recursive-descent compiler using it, although I hadn't pursued the idea much.
To give you an idea of the malleability of Forth: I got bored with creating variables one-by-one, so I defined a word called "vars:". Now I can create several variables at once, e.g.:
vars: foo bar baz
Here's an implementation (that works in my forth):
: VARS: begin parse-word dup while $create 0 , repeat drop ;
I simplified the implementation and made the idea more composable:
: VARS: line( $create 0 , )line ;
Done right, Forth looks like haikus. I'm not at that level, though.
I feel like it's one of the rarer.. esoteric? niche? or for me, aspirational languages on HN. A while back I stumbled across it, got interested, and have kept gforth and some rather aged ebooks on my pixel for those particularly aspirational moments of downtime. The philosophy of it really appeals to me.
Chuck Moore is pretty much the Buckminster Fuller of computing. Fuller's Dymaxion brand was associated with his idea of getting maximum utility out of minimum input (material, energy, etc.) and Forth's "energy" is much the same. Minimum runtime, minimum code, minimum CPU complexity, but combinatorially explosive power out of these things. You need to realign your brain to think in these terms -- how do I simplify my code further and make it do more? -- but people who have done this can do amazing things.
(Alan Kay is the Willy Wonka of computing; one can restate Joe Armstrong's banana-gorilla-jungle problem more whimsically: with Smalltalk you go into the shop to buy a candy bar but end up getting the whole chocolate factory, with everything you need to make every kind of confection staffed by Oompa-Loompas and ready to go.)
My only gripe with Forth is that whenever I ask Forth people "what software do you build in Forth?" they say "Forths". I guess that means they are making their own specific Forth for their purposes. I tried to make some basic TODO list style app that reads and writes to a file as a basic exercise and came up against some pretty major hurdles. Specifically, managing a dynamically changing list was basically a nightmare. When I asked a group of Forth programmers why it is so difficult they just said "Forth is not suited for that problem". So I suppose Forth is not seen as a general purpose programming language by Forth fans, but then what do they use it for?
Like others I indeed started with making my own Forth dialect (actually more than one try; and yes one of them could compile itself), but now it is my go-to scripting language. My latest script for instance was about converting some flat files format into an SQlite database. I also use it to prototype and test things, and I have a program that run and works for me 24/7. Can't really say more because it is partly work-related.
> Specifically, managing a dynamically changing list was basically a nightmare
So don't do it. Or do as everyone else does: use some C library/do it in C. You don't have to do everything in pure Forth, there's no law about that and being able (or not) to do anything in pure X doesn't prove anything.
Or just allocate 1Mb for your todolist file (or limit the number of entries) and accept that if you need more, you'll have to edit one constant in your program. I don't see anything wrong with that. Some of my scripts have hard-coded parameters and I can imagine a user would be reluctant to edit something in alien incantations, but I can also imagine using the flexibility of Forth to create a more familiar "syntax" and make it so that those parameters are in a separate script, so that it looks more-or-less like a configuration file to the profane.
You have no idea how we actually are narrow-minded, not creative and driven by habits about how things should be done. Forth won't get you a job, but at least it can open your mind and this reportedly is a portable (to other languages) quality.
Also, avoid "what if" - especially with practice programs you don't plan to actually use. "what if" is the FUD device by excellence.
> When I asked a group of Forth programmers why it is so difficult they just said "Forth is not suited for that problem"
The whole point of Forth is that it is, in essence, a recipe for a language you can make yourself. If your Forth is not suited to the problem, then adapt it. Forth is not a dogma.
> "what software do you build in Forth?" they say "Forths"
When you learn that Forth is a broad term that can mean a shell, programming language, application, operating system. compiler, editor, block system, style, etc..., it becomes a little clearer.
Those that ask of purpose of FORTH, is same as those that ask purpose of above mentioned things.
For me it's good to know the inner details of the tool I'm using.
And when I compile executable I know purpose of every byte in it. That's not possible with other languages like GO, that gives you 2MB hello world executable
There's program much like that in the book Starting Forth, called "File system"
it has 3 screens, if you take only what you need , you may be done in 1 or two screens, and you can store other data in that system like names and phone numbers.
trick is you erase record memory you don't need , which then gets reused on next record add, it checks if it is empty.
I do think there's a lot of value in forth as the "easiest" high-level language to implement on resource constrained systems, but there feels like a lot of sacrificing going on to use forth when you have other choices.
You can of course absorb these ideas and "get" what you want on a case-by-case in something like Python. You're one regex-replace away from turning `50 burgers` into `burgers(50)`, and then you call eval and you're good!
I have never heard of Wizard’s Bane, but that name being associated with why someone would learn Forth made me curious. So I search and find a result that says ‘where magic is volatile and he tames it with Forth.’
So, is the book ‘Wizard’s Bane’ actually focused on using Forth (or some ersatz programming language concept) to do magic? If so, that basically describes a huge part of an hypothetical RPG I’ve been designing on paper since college. Also, would you recommend the book to a fan of genre fiction?
I should have edited my comment to say programming language in general instead of forth specifically. It’s more the idea of using programming to do/control magic that I think sounds like a great premise.
As a lover of assembly, I really do love the typeless nature of Forth, great fun. Along with the stack-based computation. There were also cells which was like a heap from what I recall.
I taught myself some Forth, I ought to get back into it though!
It fit on two 360K floppy disks and managed to have 270 star systems and 800 fully explorable planets (well, the gas giants would kill you if you landed on them).
Forth was one of the first languages I learned because I looked up what languages my favorite games used. I knew some C/C++ and that was the most common answer. But when I saw my favorite game used Forth, surely it must be an amazing language. It is a pretty amazing language. Very fun to learn and eye-opening to me at the time as to what a language could be. It was a really fun learning experience, though I've never used it for anything very complex. I can see how it could be pretty un-scalable for teams, every Forth codebase seems to turn into its own unique language.
Also s-macke from HN reverse engineered the game:
https://news.ycombinator.com/item?id=13506903