[pjmlp]

There were a couple of C interpreters since the 1990's, including with REPL support, but apparently never took off, most likely a community culture issue, that doesn't seem much value using them, beyond being in a debug session.

[i_don_t_know]

I used to work on LabWindows/CVI an integrated C development environment. It included an "Interactive Execution Window" where you could build programs piecemeal. You added pieces of code, ran them, then appended more code, ran the new pieces, etc. It was as text window so you had more freedom than in a simple REPL.

It integrated with "Function panels". Function panels were our attempt at documenting our library functions. See the second link below. But you could enter values, declare variables, etc and then run the function panel. Behind the scenes, the code is inserted to the interactive window and then run. Results are added back to the function panel.

These also worked while suspended on a breakpoint in your project so available while debugging.

My understanding was that these features were quite popular with customers. They also came it handy internally when we wrote examples and did manual testing.

https://www.ni.com/docs/de-DE/bundle/labwindows-cvi/page/cvi...

https://www.ni.com/docs/de-DE/bundle/labwindows-cvi/page/cvi...

https://irkr.fei.tuke.sk/PPpET/_materialy/CVI/Quick_manual.p...

[pjmlp]

Thanks for sharing.

Yeah, I find this valuable regardless of the programming language, ideally the toolchain should be a mix of interpreter/JIT/AOT, to cherry pick depending on the deployment use case.

Naturally for dynamic languages pure AOT is not really worth it, althought a JIT cache is helpful as alternative.

[fluorinerocket]

There were so many things that NI did that were great. Debugging in LabVIEW was also very easy with probes, conditional breakpoints etc.

It's really too bad that it's more or less dead now