Embedded systems that EEs code for are like this. I have to explicitly opt into processes and objects in Keil RTX. I also get to control memory layout.

Abstraction layers are terrible when you need to understand 100% of the code at all times. Doesn't mean they're not useful.

Heck, the language for just implementing mathematical rules about system behaviour into code exists. It's called Matlab Simulink.

▲

nec4b 4 days ago | parent [-]

You are comparing a personal computer with a general purpose OS running 100s of processes and 1000s threads with a small micro-controller with a single process compiled together with an OS running at most a couple of threads. My PC has 100s of apps that need to coexist on the same hardware at the same time, your micro-controller only runs 1 designated app for eternity.

▲

vernrVingingIt 4 days ago | parent [-]

Sure. The hang up here is SWEs belief those abstractions must be stored as some syntax they know; C, Python, RoR, Linux, Elixir... whatever.

There is zero obligation to capture the concept of memory safety in traditional software notation. If it was possible to look inside the hardware at runtime no one is going to see Rust syntax.

At runtime it's more appropriate to think of it as geometric functions redrawing electrical state geometrically to avoid collisions. And that's where future chip and system state management are headed.

Away from arbitrary syntax constructs with computational expensive parsing rules of the past towards a more efficient geometric functions abstraction embedded in the machine.

	▲	jcgl 4 days ago \| parent \| next [-]
		> The hang up here is SWEs belief those abstractions must be stored as some syntax they know What does it matter how it's "stored"? I think (hope?) that most SWEs know that that syntax and its semantic aren't how things work on the metal. Storage format of the syntax seems pretty irrelevant. And surely you're not suggesting that SWEs should be using a syntax and semantics that they...don't know. So what's the better, non-traditional-software notation? Your conceptualization does sound genuinely intriguing. However, it seems like it would by necessity be non-portable across architectures (or even architecture revisions). And I take it as given that portable software is a desirable thing.
	▲	baq 3 days ago \| parent \| prev [-]
		> The hang up here is SWEs belief those abstractions must be stored as some syntax they know Contracts need to be written down to be effectively enforced. We don’t like a he said she said in software, right?