3 ms·

Embedded programming on tiny devices hasn't gone away, but the part that seems rather old-fashioned nowadays about Forth's approach is assuming that the program

Embedded programming on tiny devices hasn't gone away, but the part that seems rather old-fashioned nowadays about Forth's approach is assuming that the programming environment has to be small and simple to run on the device. These days we program and interact with devices using a powerful machine like a laptop. Being able to do over-the-air updates can be very useful, and interactive debugging can be useful. But there's no reason you can't assume the UI and compiler are on a much more powerful computer that can run a web browser and whatever toolchain you need. So that means you can do things like autocompletion and static analysis, and that has effects on what kind of language features you'll want to have, even if the target machine and generated code is very small.

fsckboy 4y ago
you're right, there are "good" embedded systems, but there are still all sorts of 8 bit processors (some of them the same old suspects) with small on-chip memory embedded in devices. You think those christmas cards that play tinny music are running multivoice synths DSP through GPUs with 18 bit D/A and spare cycles, and will do autocomplete for you if you can get a terminal connected? uh uh.
- oh_sigh 4y ago
  No, but the people who programmed them probably did so on a linux machine with GBs of RAM and GHzs of CPU
- skybrian 4y ago
  I wouldn’t expect a terminal session at all in that case.
  - bitwize 4y ago
    Some very small computers can talk VT100 over RS232.
    - fsckboy 4y ago
      there's no problem with small computers talking over rs232, even a single bit wordsize (as on the original HP calculators) could pull it off, but thats moving the goalposts. i was replying to the context of embedded cpu chips that still to this day find it economical to not come with the required memory to hold the code for human interface niceties, because it was suggested that they didn't exist.
      - skybrian 4y ago
        You missed my point, actually. I wasn't suggesting a command-line shell that has autocomplete should run on the device. I was saying that you usually don't need any developer tools on the device at all. All you need is a way to upload firmware. All the developer tools can run on the laptop. You can run VSCode and work with tiny devices. This means that making developer tools small and simple to run on tiny devices has little point anymore, and languages don't need to be small and simple either.
bitwize 4y ago
> These days we program and interact with devices using a powerful machine like a laptop. These days? :) Using a powerful machine to program a weak machine has been a thing for decades. NES games were often developed on comparatively powerful, 32-bit machines like an HP 9000 connected to an in-circuit emulator which served as the game cartridge for purposes of testing. But being able to talk directly with a running system, even send it new definitions as you write them, is still profoundly powerful, even if you're doing the writing on your Ryzen-powered beast of a laptop. And part of the point of Forth is, you need far, far less machine than you think you do in order to have a suitably powerful, interactive programming environment.
- skybrian 4y ago
  By ”these days” I meant compared to the 1950’s and 1960’s and 1970’s when Moore worked on what became Forth, according to the article. Yeah, mostly before I was born :) I tinker with Arduino on microcontrollers and, so far, I’ve always uploaded new firmware over USB when I needed to add something new. After starting to use a WiFi-enabled device in a remote location, I can see the benefit of the libraries that allow you to upload new firmware remotely (“over the air updates”). It would allow me to define new commands pretty easily after adding a command line, which I haven’t needed yet. To want to define new commands on the fly, though, I think there would need to be a reason why you can’t just send another firmware update with the new commands, such as a lack of network bandwidth? I’m not saying aren’t situations where a Forth interpreter makes sense, but it seems pretty niche, even for embedded systems?

fsckboy 4y ago

you're right, there are "good" embedded systems, but there are still all sorts of 8 bit processors (some of them the same old suspects) with small on-chip memory embedded in devices. You think those christmas cards that play tinny music are running multivoice synths DSP through GPUs with 18 bit D/A and spare cycles, and will do autocomplete for you if you can get a terminal connected? uh uh.

oh_sigh 4y ago
No, but the people who programmed them probably did so on a linux machine with GBs of RAM and GHzs of CPU
skybrian 4y ago
I wouldn’t expect a terminal session at all in that case.
- bitwize 4y ago
  Some very small computers can talk VT100 over RS232.
  - fsckboy 4y ago
    there's no problem with small computers talking over rs232, even a single bit wordsize (as on the original HP calculators) could pull it off, but thats moving the goalposts. i was replying to the context of embedded cpu chips that still to this day find it economical to not come with the required memory to hold the code for human interface niceties, because it was suggested that they didn't exist.
    - skybrian 4y ago
      You missed my point, actually. I wasn't suggesting a command-line shell that has autocomplete should run on the device. I was saying that you usually don't need any developer tools on the device at all. All you need is a way to upload firmware. All the developer tools can run on the laptop. You can run VSCode and work with tiny devices. This means that making developer tools small and simple to run on tiny devices has little point anymore, and languages don't need to be small and simple either.

bitwize 4y ago

> These days we program and interact with devices using a powerful machine like a laptop. These days? :) Using a powerful machine to program a weak machine has been a thing for decades. NES games were often developed on comparatively powerful, 32-bit machines like an HP 9000 connected to an in-circuit emulator which served as the game cartridge for purposes of testing. But being able to talk directly with a running system, even send it new definitions as you write them, is still profoundly powerful, even if you're doing the writing on your Ryzen-powered beast of a laptop. And part of the point of Forth is, you need far, far less machine than you think you do in order to have a suitably powerful, interactive programming environment.

skybrian 4y ago
By ”these days” I meant compared to the 1950’s and 1960’s and 1970’s when Moore worked on what became Forth, according to the article. Yeah, mostly before I was born :) I tinker with Arduino on microcontrollers and, so far, I’ve always uploaded new firmware over USB when I needed to add something new. After starting to use a WiFi-enabled device in a remote location, I can see the benefit of the libraries that allow you to upload new firmware remotely (“over the air updates”). It would allow me to define new commands pretty easily after adding a command line, which I haven’t needed yet. To want to define new commands on the fly, though, I think there would need to be a reason why you can’t just send another firmware update with the new commands, such as a lack of network bandwidth? I’m not saying aren’t situations where a Forth interpreter makes sense, but it seems pretty niche, even for embedded systems?