Hacker News Reader

Comment by throwaway17_17 | Hacker News Reader

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)?

View on HN

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:

    : +FIELD  OVER + SWAP CREATE , DOES> @ + ;
    : FIELD:  ALIGNED  1 CELLS +FIELD ;

Usage:

    \ Shape struct
    0
        FIELD: SHAPE.WIDTH
        FIELD: SHAPE.HEIGHT
        FIELD: SHAPE.AREA
    CONSTANT %SHAPE
    
    \ Example shape
    CREATE SQUARE
            1 , 1 , 1 ,

    \ Get height
    SQUARE SHAPE.HEIGHT ?
    
    \ Get area
    SQUARE SHAPE.AREA ?
    
    \ Set width
    2 SQUARE SHAPE.WIDTH !
    2 SQUARE SHAPE.AREA !

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.

> 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

ANS Forth (the somewhat controversial Forth standard) does have strings.

ANS Forth also has structures (records). I see gforth also has its own alternative. [0][1]

I believe you're right that ANS Forth has nothing akin to namespaces or modules.

[0] https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/For...

[1] https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Str...

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.

Awesome! Happy databasing!

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 also believe that this commercial bent Forth has is contributing to it's decline

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.

I think this is also true, but authors could have open sourced application code. Some of it has, esp with Forth standardization .

However, even so, there is just very little Forth application code available as open source.

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.

Why is there _any_ open source?

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.

With industrial and medical equipment, it falls into the category of strict liability.

https://www.law.cornell.edu/wex/products_liability

https://www.biren.com/blog/2020/september/defective-machiner...

> 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.

EHR systems are not medical devices and fall into a different category than pacemakers, spinal nerve stimulation, and similar.

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?

https://www.reichandbinstock.com/blog/strict-liability-for-d...

https://www.whiteandwilliams.com/resources-alerts-Medical-De...

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6173549/

https://biotech.law.lsu.edu/courses/drugsf02/rest_3_6.htm

> (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.

[0] https://casetext.com/case/brown-v-superior-court-5

[1] https://casetext.com/case/hufft-v-horowitz

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.

This is 100% flamebait. I’m disappointed that the replies think this is serious or true in any way.

Some of the best Forths, like VFX Forth, are commercial.

Open Firmware was Forth based and got relatively wide industry adoption. I’d say that counts as viable actual programming.

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.

That 1 1 + isn't too different (to me) from (+ 1 1) which has a different sort of beauty to it.

Incidentally, the oldest surviving language on a unix system uses this syntax (and predates C): https://en.wikipedia.org/wiki/Dc_(computer_program)

http://webarchive.loc.gov/all/20100506231949/http://cm.bell-...

> 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.

http://www.ultratechnology.com/chips.htm

https://en.wikichip.org/wiki/novix/nc4016

> 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.

https://en.wikipedia.org/wiki/RTX2010 ( https://news.ycombinator.com/item?id=8611274 )

> The RTX2010, manufactured by Intersil, is a radiation hardened stack machine microprocessor which has been used in numerous spacecraft.

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.

I wrote a barebones Forth. Little plug: https://gitlab.com/mcturra2000/cerbo/-/tree/master/forth/v3 I haven't touched it for a year or two, though.

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.

Reply on news.ycombinator.com