I always find "English like" languages difficult, as if there's the effort of translating my thoughts twice. Somewhat like how one might learn a language & try translating it to their native tongue, but to be fluent one has to directly translate the new language to the abstract symbols of the mind, which is _not_ words in the native tongue
What I'm suggesting here is that programming languages are closer to mapping to our mind's abstract representation of programs as graphs than prose is. Prose is optimized for communicating things in the real world, not specifying programs, which tend to be elaborate filing systems
That's the issue one has programming in English without bringing up the difficulty of actually writing a good parser for English & having multiple people agree on its interpretation. If I'm programming in English, let it be my English, not yours
That looks promising on initial inspection of e.g https://github.com/CTSRD-CHERI/beri/blob/master/cheri/trunk/... , although possibly a bit more imperative than I had in mind - still has for(). If I was working on HDL commercially I'd definitely give it a deeper look.
- Verilog replacement with composite types, explicit state/functional separation and pipelining assistance
- "English like" language designed with reading aloud in mind
- typesafe macro assembler with memory safety assistance