Popular posts

I agree whole-heartedly with Arpit Mohan: the era of having proprietary languages is behind us. I've seen the following scenario play out a half-dozen times in my career:

1. Somebody (let's call him 'Steve') gets the bright idea: "We should make our API scriptable so that users can customize our product!"
2. Steve (or somebody else) thinks: "I took a compilers class. It was super fun. I can make a 'little language' that does the job nicely."
3. Said 'little language' gets incorporated into the product, and users start to build things with it.
4. Users notice that the 'little language' is missing features like looping constructs, clear variable scoping rules, closures, OOP support, an async call mechanism, etc., and they start clamoring for them.
5. Steve tries to add the requested features, but gets frustrated because his original design—which never anticipated the need for such things—is too brittle to support them cleanly.
6. Steve starts stacking dirty hack upon dirty hack in an attempt to add the requested features. The 'little language' isn't so little any more, and it becomes a breeding ground for pernicious bugs.
7. Steve discovers that being the 'scripting guy' is a lot less fun than he thought it would be, and leaves for a job at ACME Enterprises Inc.
8. Steve's coworkers are stuck supporting a half-baked scripting language for years after his departure.

In the 21st Century, the likelihood that zero existing scripting languages will meet the demands of your product is pretty small, so... the most responsible approach, in my opinion, is to try (partially) integrating at least three existing scripting languages before giving up. This page provides a list of likely candidates. If you're not sure where to start, just pick these three:

• Python (with pybind11)
• Lua (just use its C API, or possibly Sol)
• Javascript (via Duktape)

Choose a common, high-value scenario and add scripting support for it using these three scripting languages. Evaluate the results, then pick the one the team likes best and add more thorough bindings to your API. At the end of the day, you will probably find that it works fine for your needs. If not, the exercise will, at a minimum, expose the pain points of existing languages, and provide data to justify development of a home-grown scripting language.

I'm pretty biased on this after getting burned a few times by well-meaning colleagues who got permission to design their own 'pet' language and then disappeared, saddling the rest of the team with the burden of supporting their 'Franken-script'. I'm sure there are cases where a home-brewed scripting language is justified, but... I've not personally run into them in my neck of the software development woods...