3 ms·

This has been independently reinvented countless times, in countless languages. Would be nice to get a somewhat generalized standard in place.

TeMPOraL 5y ago
It's called, "use a Lisp, dammit!". Seriously. There are Lisp languages that could replace whatever language you're using, and, there are also Lisp languages/runtimes that you could embed in whatever language you're using, to avoid rewriting it from scratch like this.
- skybrian 5y ago
  Which lisp though? There are still too many choices. The fact that people say "use a lisp" instead of "use Lisp X like everyone else" should tell you something. It's like the difference between "use SQL" and "use SQLite" or "use Postgres."
  - TeMPOraL 5y ago
    > Which lisp though? Whichever works best for your particular constraints. > It's like the difference between "use SQL" and "use SQLite" or "use Postgres." Precisely! "Use Postgres" is a valid answer to the question, "which database should I use?", or "which relational database should I use?". And "use SQL" is a valid recommendation when you see someone reinventing relational data model and reimplementing a relational database without realizing it. Similarly, "use a Lisp" is a valid recommendation when you see someone reinventing programming using trees from first principles - of which a telltale sign is reinventing s-expressions.
    - skybrian 5y ago
      Which Lisp would you recommend for a config file that has a few business rules in it, when the rest of the system isn’t written in Lisp?
      - mixedCase 5y ago
        Not that poster, but Scheme. Chez Scheme can be embedded with a C API, is Apache licensed, and crazy fast.
bob1029 5y ago
We do something almost like this, but we didn't try to invent any of the hard bits. We serialize our domain instances into JSON documents which also happen to contain the business rules as in-line SQL properties, and then project this JSON document into SQL databases as required for evaluating business logic. Ephemeral, in-memory instances of SQLite can be incredibly powerful tools for building an extensible business logic engine.
- idolaspecus 5y ago
  Could you expand on this idea a bit more? My curiosity has been piqued, but I'm not sure I really understand the system you've described.
  - bob1029 5y ago
    The combining of JSON & SQL is mostly inconsequential here. It is just a convenience for sending things in 1 file vs multiple. The big takeaway is that SQL is a really great tool for exposing any sort of customizable logic over arbitrary datsets. The only major caveat with this - You will typically have to perform some degree of transformation over source data in order to achieve a form of normalization well-suited to the writing of business logic (SQL). Assumptions (i.e. denormalizations beyond 3NF [0]) made in your schema here will inevitably hamper or kill the ability of the business to write flexible queries which can satisfy real-world needs. Today, a customer may have multiple accounts. In a few years, maybe we decide it goes the other way too. If you made an assumption, such as nesting these complex types in any way whatsoever, you are probably stuck with a steaming bag of shit that you now have to refactor and retest top-to-bottom. Using relation types to decouple nested complex types is the core tenant in my mind. Identity is foundation, but you can fudge your way around that a little bit. This one caveat is why a lot of developers look at this idea as a bad one at face-value. It takes a lot of work & iterations with the business stakeholders to get this correct. You can't sit in a silo and expect to completely figure out the abstract nature of business types or learn how they might be related and in what ways. There really is a "correct" and "incorrect" way to go about it if you are being properly academic. Worry about webscale and performance later. Get it correct first. Nothing is too complex for a SQL schema. If you can satisfy the academic gods of normalization and achieve a stable schema, then you are in for a wonderful ride. Between using views to compose higher-order functions, and UDFs [1] to wire into customized SQL functions, you can satisfy literally any degree of complexity required by the business. The only limit is your ability and discipline around modeling the domain types & relations, and willingness to get your hands dirty with some views and functions. You will find your business experts loving the power they gain by being able to write queries in a domain specific language they inherently understand. Giving them higher-order functions (views) and iterating on that side of the fence is yet another gigantic value play that is invisible if you are looking anywhere other than SQL. [0]: https://en.wikipedia.org/wiki/Third_normal_form [1]: https://www.sqlite.org/appfunc.html

TeMPOraL 5y ago

It's called, "use a Lisp, dammit!". Seriously. There are Lisp languages that could replace whatever language you're using, and, there are also Lisp languages/runtimes that you could embed in whatever language you're using, to avoid rewriting it from scratch like this.

skybrian 5y ago
Which lisp though? There are still too many choices. The fact that people say "use a lisp" instead of "use Lisp X like everyone else" should tell you something. It's like the difference between "use SQL" and "use SQLite" or "use Postgres."
- TeMPOraL 5y ago
  > Which lisp though? Whichever works best for your particular constraints. > It's like the difference between "use SQL" and "use SQLite" or "use Postgres." Precisely! "Use Postgres" is a valid answer to the question, "which database should I use?", or "which relational database should I use?". And "use SQL" is a valid recommendation when you see someone reinventing relational data model and reimplementing a relational database without realizing it. Similarly, "use a Lisp" is a valid recommendation when you see someone reinventing programming using trees from first principles - of which a telltale sign is reinventing s-expressions.
  - skybrian 5y ago
    Which Lisp would you recommend for a config file that has a few business rules in it, when the rest of the system isn’t written in Lisp?
    - mixedCase 5y ago
      Not that poster, but Scheme. Chez Scheme can be embedded with a C API, is Apache licensed, and crazy fast.

bob1029 5y ago

We do something almost like this, but we didn't try to invent any of the hard bits. We serialize our domain instances into JSON documents which also happen to contain the business rules as in-line SQL properties, and then project this JSON document into SQL databases as required for evaluating business logic. Ephemeral, in-memory instances of SQLite can be incredibly powerful tools for building an extensible business logic engine.

idolaspecus 5y ago
Could you expand on this idea a bit more? My curiosity has been piqued, but I'm not sure I really understand the system you've described.
- bob1029 5y ago
  The combining of JSON & SQL is mostly inconsequential here. It is just a convenience for sending things in 1 file vs multiple. The big takeaway is that SQL is a really great tool for exposing any sort of customizable logic over arbitrary datsets. The only major caveat with this - You will typically have to perform some degree of transformation over source data in order to achieve a form of normalization well-suited to the writing of business logic (SQL). Assumptions (i.e. denormalizations beyond 3NF [0]) made in your schema here will inevitably hamper or kill the ability of the business to write flexible queries which can satisfy real-world needs. Today, a customer may have multiple accounts. In a few years, maybe we decide it goes the other way too. If you made an assumption, such as nesting these complex types in any way whatsoever, you are probably stuck with a steaming bag of shit that you now have to refactor and retest top-to-bottom. Using relation types to decouple nested complex types is the core tenant in my mind. Identity is foundation, but you can fudge your way around that a little bit. This one caveat is why a lot of developers look at this idea as a bad one at face-value. It takes a lot of work & iterations with the business stakeholders to get this correct. You can't sit in a silo and expect to completely figure out the abstract nature of business types or learn how they might be related and in what ways. There really is a "correct" and "incorrect" way to go about it if you are being properly academic. Worry about webscale and performance later. Get it correct first. Nothing is too complex for a SQL schema. If you can satisfy the academic gods of normalization and achieve a stable schema, then you are in for a wonderful ride. Between using views to compose higher-order functions, and UDFs [1] to wire into customized SQL functions, you can satisfy literally any degree of complexity required by the business. The only limit is your ability and discipline around modeling the domain types & relations, and willingness to get your hands dirty with some views and functions. You will find your business experts loving the power they gain by being able to write queries in a domain specific language they inherently understand. Giving them higher-order functions (views) and iterating on that side of the fence is yet another gigantic value play that is invisible if you are looking anywhere other than SQL. [0]: https://en.wikipedia.org/wiki/Third_normal_form [1]: https://www.sqlite.org/appfunc.html