Hacker News new | ask | show | jobs
by claytongulick 1109 days ago
That's been the argument against higher level languages since punch cards.

Sure, there may be problems, yet somehow the internet runs.

Coding in asm is fun, and a good skill to have for when you need it - but most of the time, you don't.
1 comments
TheLoafOfBread 1109 days ago
The problem is not higher level language. The problem is that you are essentially running dual-stack firmware with twice as complexity and twice as problems.

And C vs assembly comparison is irrelevant. You are running assembly represented by C, but not interpreting C in assembly written VM.

link
claytongulick 1109 days ago
Then I guess you'd better avoid any sort of embedded libc implementation too.

Or fadecandy, or any external library.

I've been through hell in embedded systems land debugging chipmaker-supplied C compiler problems.

Should I just write it all in asm then? I've certainly made that choice for some projects.

The point is, at some point you just want to get things done and you have to trust your tool chain.

link
TheLoafOfBread 1109 days ago
You are completely missing my point. When I have C code and compile it, I will have opcodes which processor can run. All my bugs are going to happen only in C code and I can debug those using one debugging probe.

When I have embedded scripting, then I have C code which represents my VM and I have also scripts. Then I am hunting for a bug in C code and script itself. I need two debugging stacks to get the problem solved. Sure you can say that I can run scripts on my PC, but what if everything works on my PC, but the moment I will load it on the target, script will crash? Then without proper debugger I am screwed.

link
mmoskal 1109 days ago
DeviceScript comes with a source-level debugger for the VM code.

Indeed, if you add C code and that crashes it maybe harder to debug than a pure C system, however it wasn't my experience while developing DeviceScript - it was either clearly a bug in C that didn't really depend much on the bytecode, or an exception in DeviceScript which you debug just like in TypeScript.

We also support Jacdac [0] which makes it possible to put the C code on a different MCU, isolating the problem and adding traceability. (You can also run Jacdac server on the same MCU)

[0] https://microsoft.github.io/jacdac-docs/

link
HumanOstrich 1107 days ago
I appreciate your engagement throughout this post, including how you are gently educating the naysayers.
link