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.
Comments
Well, these things exist in the wild, and they're not as fun & cute as yours:
http://en.wikipedia.org/wiki/Expression_Language
http://docs.jboss.org/seam/latest/reference/en-US/html/elenh...
http://java.sun.com/products/jsp/reference/techart/unifiedEL...
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:
:) Seriously though. It's amazing what you can do in a script consists of nothing but tokens or "words", e.g. 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.