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