I hear ya. I consider Fexl to be at the extreme end of computational abstraction. The kind of things you reference are convenient tools for making certain lower-level things accessible from a high level sort of script.

I've used that approach in my work for many years with great success. I use ultra-simple domain-specific languages consisting of this syntax:

  token token token token ...

:) Seriously though. It's amazing what you can do in a script consists of nothing but tokens or "words", e.g.

  do_this 4 5
  do_that x "Hello there."

Where all filler such as #-comments and white space, even line breaks, are completely insignificant. I've made a lot of hay out of languages like that.

I even have a Turing-complete language in that form, and I can define "verbs" which access any sorts of machine functions I care to provide. It ends up looking a bit like Forth but I think more clear (coming from a biased judge of course). I'm actually tending to favor that token-based Turing-complete language over Fexl for doing real work. I'm not devoted to the idea of functional programming, I'm devoted to simple, powerful, flexible, and secure programming.

Strangely, the token-based languages make my application code more "language independent" -- meaning that I can write the interpreter in any language I want (C, Perl, etc.) and it really does not matter at all. I like to keep pushing as much application logic into the scripting language as possible. With the Turing-complete language it might even be feasible to do all of my application logic in it, leaving me with only a small residual interpreter written in C. But it remains to be seen if my Turing-complete token language can really scale well to that large body of application logic.