I build lots of DSLs/configuration languages but Im pretty militant about killing them if requirements dictate a need for anything resembling loops or conditionals. Those are the the klaxon warning bells telling you that you should just be writing code/a library.
I tend to do a lot of data-oriented programming, including at the meta-programming level, which blends with the problem of configuration. A pattern I found that works well this use case and covers the whole clock is the following:
- DSL as functions T, args* -> T, where T is your configuration type — or, as I like to call it, a plan. Since under function composition it's insensitive to composition order (associativity of the monoid), you can layer DSL functions on top of each other freely.
- Literal values as implicit functions. Once the plan is built and before it is run/compiled/interpreted, I cast any literal value in the datatype to a function returning that value. It's a design principle that allows me to hard-code behavior when a literal value is not enough by just swapping it with a lambda.
- Once this kind of homogeneity is ensured, and given the points above, I can extend my DSL and the behavior it describes with point-free function combinators. I get conditionals, advanced composition (parallelism for instance) , instrumentation (debugging), etc... without burdening my DSL with ad-hoc, invasive implementations. More importantly I can reuse these facilities across DSLs.
For python apps (whether we should use python for apps is another question completely) my preferred config language is python.
A little config.py file gets imported by everything in the project. It contains nothing but assignments to config variables. No functions. Nothing dragged in from a file. Just variable assignments.
It's easy to understand, easy to update, and everyone understands this much python.
I’m working on this just now and this article was one of the ones passed around when I was working through the design. I found that article’s framing really useful for several of the discussions.
I’m heavily down the path of composability, it’s all ended up very monadic but I’ve resisted the DSL idea. One thing that I’ve still to solve is some kind of polyglot binding. If I’m saying no dsl and you get to express config in a regular programming language, it’d be nice if I could say your home / preferred language. Every way I’ve come up with for that so far just sucks.
I feel similarly about environment variables. Envvar issues are a pain to debug in cloud VMs and CI pipelines.
Oftentimes, changing the envvar value doesn’t propagate without a container restart anyway.
I wish that instead of all these vaults and similar tools, cloud providers would let me pipe in a flat text file and read config from there.
Anything that requires a more complex setup should live with the code.
In many scenarios, the increased cognitive burden that comes with these hierarchical config files, DSLs, and rule engines is just not worth the yield. Redeploying isn’t hard unless we’re talking about a multi-region, globally distributed system.
I have this optimistic belief that there exists this platonic ideal of a configuration language which isn't a programming language but is still expressible enough.
I think of it as an algebra of configurations and there are at least two existing languages that implement this ideal. One of them is Jsonnet and the other is internal to Google (and might have influenced Jsonnet).
That said, obviously a good language is not enough. You still need good judgement about which stuff goes into configuration.
I actually really don't like moving configuration out to a config file unless it actually is necessary. I also don't like feature flags except where actually necessary.
Yes this gives you more power to change things with config instead of code, but it means that from now on you have to treat those values as abstract quantities rather than as something you can actually reason about.
Prefer to put configuration near where it is used. Prefer to put utility functions near where they are used. A single page of code is your "cache" and accessing information in the same page is way faster than having to look elsewhere, and that's even if you already know where to look.
Obviously you need to make exceptions for things that genuinely need to be configured elsewhere, but if it doesn't need to be configured elsewhere, please just configure it right by where you use it. It makes debugging and understanding the code a lot easier.
Option 1:
sub truncate {
my ($self, $str, %opts) = @_;
my $max_length = $opts{max_length} // $self->max_length // get_optional_config('max_length') // 15;
return substr($str, 0, $max_length);
}
Option 2:
sub truncate {
my ($self, $str) = @_;
my $max_length = 15;
return substr($str, 0, $max_length);
}
In option 1 you have 3 different places to specify max_length (and you just know that $self->max_length is going to look in more than one place as well...). Trying to divine the actual behaviour of truncate() from this code is very difficult, and it gets worse for functions that do more complicated things and are configured by multiple interacting parameters.
In option 2 you know it truncates at 15 characters, no exceptions.
Why not take an existing small language, which have good documentation and tooling? E.g. lua.
It can be integrated very fast and anyone can learn it in a few minutes.
> In the pub after work someone quips, “we’re back where we started four years ago, hard coding everything, except now in a much crappier language.”
For me it's not the same.
Four years ago - you hardcoding values in (probably) compiled language. So, you were need to recompile it each time the value changes.
Now - you writing (probably) in interpretet DSL. So, your compiled app can reload it at runtime.
Going full circle on the clock looks like achieving full inner-platform effect: https://en.wikipedia.org/wiki/Inner-platform_effect. In short - we make our application so configurable that the "configuration" language mimics the platform our application is wrote in, albeit poorly.
“we’re back where we started four years ago, hard coding everything, except now in a much crappier language.”
Not sure if I agree with this. A proper designed DSL has the advantage of being much closer to the domain of the problem it is supposed to solve. Your code written in the DSL now might end up as 'hard coded' part of the application, but it likely conveys much more meaning in much less code because it is tailored to the core functionality of the application.
Design a DSL. But instead of implementing it, implement the same abstractions in the functions (or classes or whatever) of your code. Effectively, you are implementing the DSL without the parser and AST.
When you chain these functions together into business logic they will be just as readable as the DSL would have been. But you still get an IDE with code completion, debugging, etc.
I've had the misfortune of working on "enterprise" software where avoidance of "hard-coding" went so far that the core system did almost nothing other than exist as a way to plug in mutable functionality. All in the name of not having to re-build, or to re-deploy, and being able to tell the customer that no code changes would be required, even though the "configuration" was practically code, and required many of the things that code might require, like qualified configuration developers, test suites, and detailed deployment plans. Truly madness. In the era of software as a service via internet, software is more "soft" than it has ever been. You can change it and deploy it to production any time you please.
I made almost two full trips around this clock over the last decade on a single project.
One of the biggest takeaways for me is that if you choose to do the DSL, you need to think super hard about your target audience and how they think about the world.
For me, the whole point of DSL is to get the developers working on common modules that the business could string together without too much babysitting.
The first DSL we tried was python, interpreted by way of iron python / C#. This did not stick with the business people at all. It was pure ball-and-chain for the development team.
The second DSL we tried is SQL. The verdict is still out on that one, but the amount of traction so far is almost infinite in comparison to the prior attempts. You can get a non-developer to build SQL queries that express BL if you are patient with them and provide some examples. The tooling is also substantially better if you are using something like SQLite and can easily pass the DB around to play with.
If I was going to approach this fresh, I'd set the clock to noon and then remove the battery. The amount of overhead and risk required to support a DSL is substantial. Even if you use SQL and leverage mostly existing tools, you are forcing developers to build things in a very particular way that isn't necessarily ideal in terms of a pure code solution.
I think you can do a purely hard coded solution that is approachable by the business if it is structured well enough and made available in a friendly context like GitHub. Let the business use the web tool to propose PRs over well documented code they can mostly understand. Maybe there's an "internal" folder that only the neckbeards touch. You can draw your battle lines wherever you please.
For the hardcoded only approach wherein the business people are involved, the choice of language is very important, but I don't know how to have that conversation constructively in this forum.
This ("the rule of least power") is a rule I abide by religiously:
https://en.wikipedia.org/wiki/Rule_of_least_power
I build lots of DSLs/configuration languages but Im pretty militant about killing them if requirements dictate a need for anything resembling loops or conditionals. Those are the the klaxon warning bells telling you that you should just be writing code/a library.
What do you think of my approach (sister comment)?
I tend to do a lot of data-oriented programming, including at the meta-programming level, which blends with the problem of configuration. A pattern I found that works well this use case and covers the whole clock is the following:
- DSL as functions T, args* -> T, where T is your configuration type — or, as I like to call it, a plan. Since under function composition it's insensitive to composition order (associativity of the monoid), you can layer DSL functions on top of each other freely.
- Literal values as implicit functions. Once the plan is built and before it is run/compiled/interpreted, I cast any literal value in the datatype to a function returning that value. It's a design principle that allows me to hard-code behavior when a literal value is not enough by just swapping it with a lambda.
- Once this kind of homogeneity is ensured, and given the points above, I can extend my DSL and the behavior it describes with point-free function combinators. I get conditionals, advanced composition (parallelism for instance) , instrumentation (debugging), etc... without burdening my DSL with ad-hoc, invasive implementations. More importantly I can reuse these facilities across DSLs.
For python apps (whether we should use python for apps is another question completely) my preferred config language is python.
A little config.py file gets imported by everything in the project. It contains nothing but assignments to config variables. No functions. Nothing dragged in from a file. Just variable assignments.
It's easy to understand, easy to update, and everyone understands this much python.
I’m working on this just now and this article was one of the ones passed around when I was working through the design. I found that article’s framing really useful for several of the discussions.
I’m heavily down the path of composability, it’s all ended up very monadic but I’ve resisted the DSL idea. One thing that I’ve still to solve is some kind of polyglot binding. If I’m saying no dsl and you get to express config in a regular programming language, it’d be nice if I could say your home / preferred language. Every way I’ve come up with for that so far just sucks.
I feel similarly about environment variables. Envvar issues are a pain to debug in cloud VMs and CI pipelines.
Oftentimes, changing the envvar value doesn’t propagate without a container restart anyway.
I wish that instead of all these vaults and similar tools, cloud providers would let me pipe in a flat text file and read config from there.
Anything that requires a more complex setup should live with the code.
In many scenarios, the increased cognitive burden that comes with these hierarchical config files, DSLs, and rule engines is just not worth the yield. Redeploying isn’t hard unless we’re talking about a multi-region, globally distributed system.
I have this optimistic belief that there exists this platonic ideal of a configuration language which isn't a programming language but is still expressible enough.
I think of it as an algebra of configurations and there are at least two existing languages that implement this ideal. One of them is Jsonnet and the other is internal to Google (and might have influenced Jsonnet).
That said, obviously a good language is not enough. You still need good judgement about which stuff goes into configuration.
I actually really don't like moving configuration out to a config file unless it actually is necessary. I also don't like feature flags except where actually necessary.
Yes this gives you more power to change things with config instead of code, but it means that from now on you have to treat those values as abstract quantities rather than as something you can actually reason about.
Prefer to put configuration near where it is used. Prefer to put utility functions near where they are used. A single page of code is your "cache" and accessing information in the same page is way faster than having to look elsewhere, and that's even if you already know where to look.
Obviously you need to make exceptions for things that genuinely need to be configured elsewhere, but if it doesn't need to be configured elsewhere, please just configure it right by where you use it. It makes debugging and understanding the code a lot easier.
Option 1:
Option 2: In option 1 you have 3 different places to specify max_length (and you just know that $self->max_length is going to look in more than one place as well...). Trying to divine the actual behaviour of truncate() from this code is very difficult, and it gets worse for functions that do more complicated things and are configured by multiple interacting parameters.In option 2 you know it truncates at 15 characters, no exceptions.
Why not take an existing small language, which have good documentation and tooling? E.g. lua. It can be integrated very fast and anyone can learn it in a few minutes.
> In the pub after work someone quips, “we’re back where we started four years ago, hard coding everything, except now in a much crappier language.”
For me it's not the same. Four years ago - you hardcoding values in (probably) compiled language. So, you were need to recompile it each time the value changes. Now - you writing (probably) in interpretet DSL. So, your compiled app can reload it at runtime.
Going full circle on the clock looks like achieving full inner-platform effect: https://en.wikipedia.org/wiki/Inner-platform_effect. In short - we make our application so configurable that the "configuration" language mimics the platform our application is wrote in, albeit poorly.
“we’re back where we started four years ago, hard coding everything, except now in a much crappier language.”
Not sure if I agree with this. A proper designed DSL has the advantage of being much closer to the domain of the problem it is supposed to solve. Your code written in the DSL now might end up as 'hard coded' part of the application, but it likely conveys much more meaning in much less code because it is tailored to the core functionality of the application.
Design a DSL. But instead of implementing it, implement the same abstractions in the functions (or classes or whatever) of your code. Effectively, you are implementing the DSL without the parser and AST.
When you chain these functions together into business logic they will be just as readable as the DSL would have been. But you still get an IDE with code completion, debugging, etc.
I've had the misfortune of working on "enterprise" software where avoidance of "hard-coding" went so far that the core system did almost nothing other than exist as a way to plug in mutable functionality. All in the name of not having to re-build, or to re-deploy, and being able to tell the customer that no code changes would be required, even though the "configuration" was practically code, and required many of the things that code might require, like qualified configuration developers, test suites, and detailed deployment plans. Truly madness. In the era of software as a service via internet, software is more "soft" than it has ever been. You can change it and deploy it to production any time you please.
I made almost two full trips around this clock over the last decade on a single project.
One of the biggest takeaways for me is that if you choose to do the DSL, you need to think super hard about your target audience and how they think about the world.
For me, the whole point of DSL is to get the developers working on common modules that the business could string together without too much babysitting.
The first DSL we tried was python, interpreted by way of iron python / C#. This did not stick with the business people at all. It was pure ball-and-chain for the development team.
The second DSL we tried is SQL. The verdict is still out on that one, but the amount of traction so far is almost infinite in comparison to the prior attempts. You can get a non-developer to build SQL queries that express BL if you are patient with them and provide some examples. The tooling is also substantially better if you are using something like SQLite and can easily pass the DB around to play with.
If I was going to approach this fresh, I'd set the clock to noon and then remove the battery. The amount of overhead and risk required to support a DSL is substantial. Even if you use SQL and leverage mostly existing tools, you are forcing developers to build things in a very particular way that isn't necessarily ideal in terms of a pure code solution.
I think you can do a purely hard coded solution that is approachable by the business if it is structured well enough and made available in a friendly context like GitHub. Let the business use the web tool to propose PRs over well documented code they can mostly understand. Maybe there's an "internal" folder that only the neckbeards touch. You can draw your battle lines wherever you please.
For the hardcoded only approach wherein the business people are involved, the choice of language is very important, but I don't know how to have that conversation constructively in this forum.
I know one application that went full cycle from the get go: Emacs.
[dead]