3 ms·
It's a trade. For example, you can split the whole program (think execution of hundreds of business rules) into an interpreter - maintained by developers - and
by noiv 8y ago
It's a trade. For example, you can split the whole program (think execution of hundreds of business rules) into an interpreter - maintained by developers - and the pure rules in an easy to understand text file - maintained by business people.
- taeric 8y agoHas that happened, pretty much ever? It is a great aspirational goal. I've never seen it pan out, though. Not that there isn't a benefit from reducing things to the language you use to reason about the overall problem, and the language used to implement it. In large, whether you create a "DSL" or not, you almost always move to doing things in terms of the API you are using. Effectively making it a language. Taking a little more deliberate control does seem nice. That said, I have found benefit in keeping fewer abstractions around. This is especially true as I am supporting an API. Don't hide that API from anything you do. Too easy to hide warts in it that you might otherwise fix.
- userbinator 8y agoHas that happened, pretty much ever? It is a great aspirational goal. I've never seen it pan out, though. That's pretty much the definition of https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect Almost every story about a "business rules engine" I've heard was that it eventually turned into an odd Turing-complete programming language, and it'd be simpler to just write the same code in the original language.
- noiv 8y agoWell, it depends, if you can keep the rules structured as data and not as code you're fine.