7 ms·

I've seen this a lot when someone wants to add "workflow automation" or "scripting" to their app. The most success I'd had is embedding either Lua or Javascript

I've seen this a lot when someone wants to add "workflow automation" or "scripting" to their app. The most success I'd had is embedding either Lua or Javascript (preferably Lua) with objects/functions from the business domain available to the user's script. This is what games do too. I think it's a great way to dodge most of the work. For free you can support flow control, arbitrary boolean expressions, math, etc.

brunospars 2y ago
i yearn for an alternate reality where every unix command/service had the same syntax and a lua interpreter.
- geocar 2y ago
  You should take a look at arcan, it's almost exactly that: http://arcan-fe.com http://arcan-fe.com - https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lashcat9/ https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lash... - https://arcan-fe.com/2024/09/16/a-spreadsheet-and-a-debugger-walks-into-a-shell/ https://arcan-fe.com/2024/09/16/a-spreadsheet-and-a-debugger... I am not using it as a daily driver, because, emacs, but I keep an eye on it because, well, emacs.
- m463 2y ago
  I'm sorry you get our reality where it is nested quotes, parentheses, dollar signs and backslashes all the way down.
  - brunospars 2y ago
    I lol'ed .
- alganet 2y ago
  https://github.com/oasislinux/oasis https://github.com/oasislinux/oasis It's not perfect, but it's clean and moves in this lua direction.
tonyedgecombe 2y ago
I've done both. I embedded VBScript/JScript in an app via Microsoft's Active Scripting[1] interfaces and wrote a template language that grew to contain typical programming language constructs. Looking back it was the VBScript/JScript functionality that caused me the most problems. Especially when I migrated the whole app from C++ to .Net. [1] https://en.wikipedia.org/wiki/Active_Scripting https://en.wikipedia.org/wiki/Active_Scripting
atoav 2y ago
One pitfall that is so obvious it hurts (but I have seen people fall into it), goes a bit like this: 1. We have a python application 2. We need a configuration format, we pick one of the usual (ini/toml/yaml/...) 3. We want to allow more than usual to be done in this config, so let's build some more complex stuff based on special strings etc. Now the thing they should have considered in step 3 is why not just use a python file for configuration? Sure this comes with pitfalls as you now allow people who write the config to do similar things than the application, but you are already using a programming language, why not just use it for your overly complex configuration? For in house stuff this could certainly be more viable than writing your own parser.
- 10000truths 2y ago
  Because now, anything that wants to read that config has to be written in Python. You've chained yourself to a stack just for a dynamic config. I ran into this issue at a previous job, but with a service that leaned heavily on hundreds of Django models. It made it impossible to use those models as a source of truth for anything unless you used Python and imported a heavyweight framework. It was the biggest blocker for a C++ rewrite of the service, which was really bad because we were having performance issues and were already reaching our scaling limits. Declarative configs are preferable for keeping your options open as to who or what consumes them. For cases where config as code is truly necessary, the best option is to pick something that's built for exactly that, like Lua (or some other embedded scripting language+runtime with bindings for every language).
  - lifeisstillgood 2y ago
    I would tread carefully around this (although you know the specifics !). Simply being tied to one language is rarely a bad thing - at a certain point in a company size growth, having a common language and set of tools (logging, dbase wrappers etc) acts as a force multiplier beyond individual team leads preferences. I would be interested in exactly what scaling issues you hit but I would ask if Inwere financing the company if overcoming scaling problems in python would cost less and lead to better cadence than a migration to C++
whstl 2y ago
I find that the #1 reason people add those "simpler than Lua" homegrown languages in Enterprise is to allow non-programmers to program. This not only has a tremendous cost to develop (compared to something like embedding Lua) but it also creates the worst kind of spaghetti. One of the most unhinged pieces of software I have ever seen was the one from a fintech I worked with. Visual programming, used by business specialists. Zero abstraction support, so lots of forced repetition. No synchronous function call, so lots of duplications or partitioning to simulate it. Since there were two failed versions, there are three incompatible versions of this system running in parallel and migration from one to the other must be done manually. The problem is about 90% of the business rules were encoded into this system, because business people were in a hurry. People wanted a report but didn't want to wait for Business Intelligence? Let's add "tags" to records so they appear on certain screens, and then remove them when they shouldn't anymore. In the end the solution was adding "experts" to use it, but the ones who actually knew or learned any programming would just end up escaping to other companies.

brunospars 2y ago

i yearn for an alternate reality where every unix command/service had the same syntax and a lua interpreter.

geocar 2y ago
You should take a look at arcan, it's almost exactly that: http://arcan-fe.com http://arcan-fe.com - https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lashcat9/ https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lash... - https://arcan-fe.com/2024/09/16/a-spreadsheet-and-a-debugger-walks-into-a-shell/ https://arcan-fe.com/2024/09/16/a-spreadsheet-and-a-debugger... I am not using it as a daily driver, because, emacs, but I keep an eye on it because, well, emacs.
m463 2y ago
I'm sorry you get our reality where it is nested quotes, parentheses, dollar signs and backslashes all the way down.
- brunospars 2y ago
  I lol'ed .
alganet 2y ago
https://github.com/oasislinux/oasis https://github.com/oasislinux/oasis It's not perfect, but it's clean and moves in this lua direction.

tonyedgecombe 2y ago

I've done both. I embedded VBScript/JScript in an app via Microsoft's Active Scripting[1] interfaces and wrote a template language that grew to contain typical programming language constructs. Looking back it was the VBScript/JScript functionality that caused me the most problems. Especially when I migrated the whole app from C++ to .Net. [1] https://en.wikipedia.org/wiki/Active_Scripting https://en.wikipedia.org/wiki/Active_Scripting

atoav 2y ago

One pitfall that is so obvious it hurts (but I have seen people fall into it), goes a bit like this: 1. We have a python application 2. We need a configuration format, we pick one of the usual (ini/toml/yaml/...) 3. We want to allow more than usual to be done in this config, so let's build some more complex stuff based on special strings etc. Now the thing they should have considered in step 3 is why not just use a python file for configuration? Sure this comes with pitfalls as you now allow people who write the config to do similar things than the application, but you are already using a programming language, why not just use it for your overly complex configuration? For in house stuff this could certainly be more viable than writing your own parser.

10000truths 2y ago
Because now, anything that wants to read that config has to be written in Python. You've chained yourself to a stack just for a dynamic config. I ran into this issue at a previous job, but with a service that leaned heavily on hundreds of Django models. It made it impossible to use those models as a source of truth for anything unless you used Python and imported a heavyweight framework. It was the biggest blocker for a C++ rewrite of the service, which was really bad because we were having performance issues and were already reaching our scaling limits. Declarative configs are preferable for keeping your options open as to who or what consumes them. For cases where config as code is truly necessary, the best option is to pick something that's built for exactly that, like Lua (or some other embedded scripting language+runtime with bindings for every language).
- lifeisstillgood 2y ago
  I would tread carefully around this (although you know the specifics !). Simply being tied to one language is rarely a bad thing - at a certain point in a company size growth, having a common language and set of tools (logging, dbase wrappers etc) acts as a force multiplier beyond individual team leads preferences. I would be interested in exactly what scaling issues you hit but I would ask if Inwere financing the company if overcoming scaling problems in python would cost less and lead to better cadence than a migration to C++

whstl 2y ago

I find that the #1 reason people add those "simpler than Lua" homegrown languages in Enterprise is to allow non-programmers to program. This not only has a tremendous cost to develop (compared to something like embedding Lua) but it also creates the worst kind of spaghetti. One of the most unhinged pieces of software I have ever seen was the one from a fintech I worked with. Visual programming, used by business specialists. Zero abstraction support, so lots of forced repetition. No synchronous function call, so lots of duplications or partitioning to simulate it. Since there were two failed versions, there are three incompatible versions of this system running in parallel and migration from one to the other must be done manually. The problem is about 90% of the business rules were encoded into this system, because business people were in a hurry. People wanted a report but didn't want to wait for Business Intelligence? Let's add "tags" to records so they appear on certain screens, and then remove them when they shouldn't anymore. In the end the solution was adding "experts" to use it, but the ones who actually knew or learned any programming would just end up escaping to other companies.