23 ms·

[edit: moved from another parent where it was less on-topic] Considering how much of the actual programming in embedded isn't so much programming in C but meta

by usrusr 6y ago

[edit: moved from another parent where it was less on-topic] Considering how much of the actual programming in embedded isn't so much programming in C but metaprogramming in C preprocessor I wonder if 1:1 replacing this with another language/conditional compile pair would really be smartest move. It could be very interesting to embrace the fact that you are writing a program that writes a program instead of pretending that it's all one language. Don't hide the two-stage nature of embedded development, radically rip them apart. The first stage could be so much more than an afterthought if you elevate it from macro replacement to a type-heavy behemoth like, I don't know, a Scala DSL tailored for generating target-specific C/Rust/whatever source from a template. A template that interleaves precompilation and target language, like C source already does, but with a proper language for the first stage instead of a glorified find/replace sequence. This would have to happen in the form of cross-pollination from the web world because they have decades of learning from mistakes in markup generating code and almost half as much in dealing with the ergonomics of anything-to-js transpilers. I suspect that if you'd separate all the customary compile time logistics into its own, distinct preparatory stage it would be much easier to get different languages from the ubiquitous "a compiler backend exists, but..." to actual pragmatic usability.

zozbot234 6y ago
Rust has plenty of support for compile-time code generation of all kinds. It's generally viewed as something that should be done only as a last-resort, but it's there and fully supported.
- weinzierl 6y ago
  Do you know good resources for learning about these options?
  - estebank 6y ago
    The book has a good intro to their capabilities: https://doc.rust-lang.org/stable/book/ch19-06-macros.html https://doc.rust-lang.org/stable/book/ch19-06-macros.html There are blog posts exploring some of the use cases for them, but it depends a lot on what you want to do.
weinzierl 6y ago
I like how you describe it as "the two-stage nature of embedded development" because that is what in reality it really is. In my opinion replacing the preprocessor with another code generator wouldn't be the best path forward though. I have worked with a bunch of code generators and it has always been a crutch. I think something that ties in with the target language and is aware of the syntax of the target language, like Rust macros, has many advantages. At the same time I do not know enough about Rust macros yet to tell if they are really powerful enough to help here.
bborud 6y ago
The problem of embedded isn't really a lack of implementation languages but rather that the ones that are being used are not very conducive to correctness and that the tooling and operating systems / SDKs / frameworks are awkward. Much of embedded programming is about coping with quirky hardware and nudging bits and bytes around. And coping with rather sloppily put together tooling that requires a lot of hand-cranking. Introducing higher level languages doesn't really solve this. If anything, it would make things worse because it would focus attention where the problem isn't. Adding lots of complexity by adding transpilers for a bunch of languages just makes things more complex and does nothing to solve the actual problems. (Slightly orthogonal: just look at how horrid Zephyr becomes due to Python-based build tools that keep breaking things with every release. Choosing Python actually made things worse because Python brings its own unmitigated problems. It screws up your day even before you get to do any programming)
- joezydeco 6y ago
  just look at how horrid Zephyr becomes due to Python-based build tools that keep breaking things with every release Whew. I’m glad it wasn’t just me that thought this. Zephyr devs seem really blind to this. And the swap to CMake didn’t help things.
pjmlp 6y ago
Stuff like this already exists, for example from Bosch. https://blogs.itemis.com/en/eclipse-mita-bringing-software-development-for-the-iot-to-a-higher-level https://blogs.itemis.com/en/eclipse-mita-bringing-software-d...

by usrusr 6y ago

zozbot234 6y ago

Rust has plenty of support for compile-time code generation of all kinds. It's generally viewed as something that should be done only as a last-resort, but it's there and fully supported.

weinzierl 6y ago
Do you know good resources for learning about these options?
- estebank 6y ago
  The book has a good intro to their capabilities: https://doc.rust-lang.org/stable/book/ch19-06-macros.html https://doc.rust-lang.org/stable/book/ch19-06-macros.html There are blog posts exploring some of the use cases for them, but it depends a lot on what you want to do.

weinzierl 6y ago

I like how you describe it as "the two-stage nature of embedded development" because that is what in reality it really is. In my opinion replacing the preprocessor with another code generator wouldn't be the best path forward though. I have worked with a bunch of code generators and it has always been a crutch. I think something that ties in with the target language and is aware of the syntax of the target language, like Rust macros, has many advantages. At the same time I do not know enough about Rust macros yet to tell if they are really powerful enough to help here.

bborud 6y ago

The problem of embedded isn't really a lack of implementation languages but rather that the ones that are being used are not very conducive to correctness and that the tooling and operating systems / SDKs / frameworks are awkward. Much of embedded programming is about coping with quirky hardware and nudging bits and bytes around. And coping with rather sloppily put together tooling that requires a lot of hand-cranking. Introducing higher level languages doesn't really solve this. If anything, it would make things worse because it would focus attention where the problem isn't. Adding lots of complexity by adding transpilers for a bunch of languages just makes things more complex and does nothing to solve the actual problems. (Slightly orthogonal: just look at how horrid Zephyr becomes due to Python-based build tools that keep breaking things with every release. Choosing Python actually made things worse because Python brings its own unmitigated problems. It screws up your day even before you get to do any programming)

joezydeco 6y ago
just look at how horrid Zephyr becomes due to Python-based build tools that keep breaking things with every release Whew. I’m glad it wasn’t just me that thought this. Zephyr devs seem really blind to this. And the swap to CMake didn’t help things.

pjmlp 6y ago

Stuff like this already exists, for example from Bosch. https://blogs.itemis.com/en/eclipse-mita-bringing-software-development-for-the-iot-to-a-higher-level https://blogs.itemis.com/en/eclipse-mita-bringing-software-d...