Richard Bucker

risky embedded scripting languages

Posted at — Jan 17, 2014

I have been working on two opposing ideas. (1) implementing a scripting language [could be a DSL] in an application framework in order to improve development time deferring code translation to runtime. (2) implementing a framework with a non trivial code generator as part of the build process. Both are particularly difficult when considering the maturity model¬†as it pertains to testing, QA and more importantly security. Both static and dynamic elements are difficult to verify.The one idea that I have latched onto is “configuration as code”. While considering the embedded approach I realized that command line argument(s) and configuration files, etc… are no different embedded scripting languages. They are simply a DSL of another nature. Once you get past the CLI there could be an endless number of configuration opportunities. Each with it’s own challenges. Just think about all of the Window’s registry hacks. Embedding the config parameters in the code (encrypted or not) makes the hacking harder.The second idea is actually much better. I have imagined that the framework could be instrumented across all of the applications that were build with it. It also means that other protections from inside the framework could bubble up to the user space. Test cases are fewer, smaller, easier to write, and verify.The problem with the maturity model is that there is an implied rigor or “proof” that a vast majority of development teams never get to. Transitioning to a maturity level adds a great deal of friction to the complete development process. From inception to deployment.UPDATE: While I’m not advocating re-compiling or transcoding GO this is an interesting topic. A recent interview with big thinkers several language gurus; one said knowing one and only one programming language was not ideal.