4 ms·
I find writing a library is usually enough for the types of problems I encounter. You can even design it to be language-like using fluent interfaces; take Fluen
by brushfoot 5y ago
I find writing a library is usually enough for the types of problems I encounter. You can even design it to be language-like using fluent interfaces; take FluentAssertions for example: `actual.Should().StartWith(expected);`.
Beyond that, I tend to reach for:
- A config file. Can the problem be solved declaratively through a config file that a program reads and bases its behavior on?
- Templates, generators, and macros. Along the lines of syntax, would templates or generators solve problems with an existing GPPL?
- A domain-specific language. Does the problem lend itself to composable patterns or statements? Could a DSL help organize and simplify them?
- A transpiler. Is the syntax of an existing GPPL the problem? Would syntactic sugar be enough?
Of course, there are plenty of other reasons to write a new GPPL, like for your own learning or just as a hobby. Just know what you're getting yourself into.
- stevekemp 5y agoConfiguration files are such a useful thing to start with - I remember one of my most productive changes was to hack on a local copy of mutt: * If the configuration file had mode 0755 then execute it, and parse the output. * Otherwise read as-is. That was my solution to writing a complex configuration file, which behaved differently upon different hosts - write the thing in perl, and have it "print" blocks and configuration values appropriately.
- krapp 5y agoOk but why not just have separate, simpler configuration files for each host?