[nine_k]

To sum up Chuck Moore's quotations: you write code that takes all of the machine, and you got to write all of the code. If you have this, you can squash out all abstraction and build the ideal solution directly.

This may hold true for small-scale hardware like controllers. They have a well-defined set of tasks, small enough to fit in your head.

This means that you have a certain trouble sharing the code with your colleagues, making the bus factor of your project closer to 1, and lowering the usefulness of code reviews.

This means that you have trouble sharing code with yourself in your next project.

You become tightly coupled do the machine. This is, on one hand, liberating, you can do anything easily. But this is also limiting, because you spend your mental resources on optimizing for this particular machine.

I personally think that deep optimization is something that the machine should do, they are better than humans at this most of the time. And humans should do want machines currently can't.

[Twisol]

My takeaway was that you're always writing against a machine. The difference is whether you're writing against a physical hardware machine or an abstract virtual machine. OSes and VMs abstract over existing machines and present a virtual interface for the sake of portability, but they're still themselves machines.

You're still coding against a machine, and you still have to spend time learning the vicissitudes of that machine. But you also have the impedance mismatch between the virtual machine you're developing against and the physical machines you intend the software to run on. All software abstractions are, to some extent, leaky.

[astrobe_]

> This may hold true for small-scale hardware like controllers. They have a well-defined set of tasks, small enough to fit in your head.

People usually insist that software should be modular, so that you don't have to have millions of lines of code in your head when making a local change. That's what drove the procedural evolution and later the OOP evolution.

So if you're a good boy/girl/etc. you write your million-LOCs PC application as modules that are manageable for (ideally) a single person. Then you need an extra programmer to glue the modules together.

> This means that you have a certain trouble sharing the code with your colleagues, making the bus factor of your project closer to 1, and lowering the usefulness of code reviews.

Where does Forth prohibit peer reviews and pair programming? If you have a bus factor of 1, it is because you don't want to pay the price of increasing it. It has nothing to do with Forth; plenty of projects in super-high hyper-readable projects have a bus factor of 1.

> This means that you have trouble sharing code with yourself in your next project.

Not really. It's easier to copy/paste/hack Forth code. The code is more compact for various reasons: point-free style makes it less verbose, you tend to factor more intensively and you code exactly what you need.

> You become tightly coupled do the machine. This is, on one hand, liberating, you can do anything easily. But this is also limiting, because you spend your mental resources on optimizing for this particular machine.

No, that's the other way. When you code e.g. for a little-endian, two's complement CPU then you don't have to worry about big-endian and sign magnitude. You are actually also optimizing programmer's cycles too.

Being tightly coupled to the machine is what embedded programming really is about. Embedded programming is often about writing esoteric values at occult addresses in order to bang out bits on an SPI bus. Running a Python program on Debian on a rPI is not really embedded programming.

[rcombine]

It kinda sounds to me like Forth wants to be used in the context of embedded programming, then.

[astrobe_]

Not only. Checkout Forth Inc. last year's projects [1]. In one of them, Forth is used everywhere from micro-controllers to the monitoring PCs.

[1] https://wiki.forth-ev.de/doku.php/events:ef2018:forth-in-tha...