Hacker News Reader

Comment by sitkack | Hacker News Reader

I really enjoy forth for interactive embedded development, it has one downside in the inability afaik to do static analysis of forth programs. Seeing a skilled engineer bring up a new multiboard system over a serial link in an afternoon and write system tests insitu had me sold. I did something similar years later with a hardware control application in Java by using Jython to get a remote low level repl.

Forth tends to be one step in bootstrapping a system, or it is so small that it is correct by observation. Forth is powerful, but the systems that use it should be held to a small size.

I think for the most part, Python/MicroPython now occupies the same place Forth once did in the embedded world. As MCUs get more capable and default to more memory, not only will higher level interpreted languages become the norm, low level languages can be integrated via Wasm, either compiled or interpreted on device.

View on HN

> As MCUs get more capable and default to more memory, not only will higher level interpreted languages become the norm, low level languages can be integrated via Wasm, either compiled or interpreted on device.

Not long ago, during the emergence of SoCs, this statement was uttered regarding Java, for both real time (JRT) and "regular" low-level applications. The story went, you could simply write Java and push it to your bytecode interpreter implemented in hardware. How convenient! It turned out differently. And now here we see Python, mPython, WASM, etc.

I think that nobody used it because nobody used it: The ecosystem didn't evolve along with the capabilities.

I really enjoyed the fits and starts of high level embedded programming, we see an analogous evolution in terms of high level hardware description languages. Bluespec, Chisel, nMigen, etc.

There was such a large barrier between the practitioners that were shipping (C/asm) vs high level folks (formal methods, functional programming, etc). We routinely brought up embedded DSP systems with a Forth based monitor. An idea can be excellent, but if it doesn't have an adequate host to spread or a vector it goes no where. Forth was awesome in Astronomy because it could spread there. Just like KX/KDB can spread in the financial ecosystem.

Folks are doing real work using micropython repls directly on hardware. You can go from idea to shipping something in an afternoon.

Folks might talk about power or resources, but both are a factor in Moore's law which still very much a thing. And the hot inner loop can be written with power and space in mind.

The pricepoint for an MCU that could run a high level stack was about 8-10$ 10 years ago, now it is less $1. In hindsight the ESP32-C3 will be an inflection point.

I am curious, is NASA looking at Wasm for space and aeronautics applications? What are your thoughts on high reliability languages? What are the current hot topics in autonomous probes? Are the same things that are going on with self driving vehicles also transferring to self navigating probes? How far away are we from <launch probes> and it just sends back interesting results? ;)

Java is still (as I understand it) very much a thing for EMV and possibly other smart-card applications (transport fare media?).

Yeah, I did some embedded dev using the Dallas TINI devices around 2000, 2001.

http://systronix.com/tini/tini_simm.htm

I think the JVM is in a lot more places that people realize.

> it has one downside in the inability afaik to do static analysis of forth programs

I believe it is possible with annotations, at least for basic checks, and assuming you don't go too crazy (e.g. returning a variable number of results depending on the inputs).

> I think for the most part, Python/MicroPython now occupies the same place Forth once did in the embedded world

Lua is a bit closer: REPL, quite efficient, and is not a kitchen sink. Python is more like BASIC (Beginner's All-purpose Symbolic Instruction Code).

I made a start on type inference for stack-based languages in the context of Joy, but I kind of wobbled off at the end: https://joypy.osdn.io/notebooks/Types.html#conclusion It turns out to be easier to work in Prolog.

This is really cool! I am so glad you have kept Joy alive. I remember when website reorgs would kick Manfred von Thun's website offline for months to then re-appear and disappear again.

Cheers! I'm not sure what made me pick it up, but it's grown on me. FWIW the Prolog version is here: https://git.sr.ht/~sforman/Thun/tree/master/source/thun.pl There's a bunch of junk in there, like a start on compilers. (I'm just messing around. Recursion is like an end boss that I know the strategy to defeat but I've been too lazy or busy to put in the work to implement it.) Fun fact: in Prolog the interpreter and the type inferencer are the same code! Also, I recently wrote an interpreter in Nim, more-or-less for kicks: https://git.sr.ht/~sforman/Bliss

I have a hunch that concatinative languages are important somehow. Have you seen "Compiling to categories"? http://conal.net/papers/compiling-to-categories/ He's converting Haskell into a point-free form (that's very similar to Joy) and then compiling that over various Categories to get several kinds of programs from one expression.

> As MCUs get more capable

Doesn't power consumption go up as MCUs get more capable?

Reply on news.ycombinator.com