3 ms·

It might help to look at the bigger post at Github: https://github.com/sustrik/cartesian https://github.com/sustrik/cartesian Here's what author told me on Lo

It might help to look at the bigger post at Github: https://github.com/sustrik/cartesian https://github.com/sustrik/cartesian Here's what author told me on Lobste.rs about this: "As for the motivation, it’s twofold. Firstly, I have to deal with complex configurations on daily basis and most of what’s out there is pretty ugly. Approach in Cartesian tries to solve the ugliness without resorting to exotic paradigms. It’s (I think) something that your average JavaScript developer would be comfortable with, yet powerful enough to describe really complex systems. Secondly, it’s a methodological experiment. I think it’s fair to say that inheritance has mostly failed us when we tried to model the complexity and irregularity of the real world. Therefore, this is a sketch of an alternative paradigm, one that uses cartesian products instead of inheritance. (But, as mentioned in the README, it can even be combined with classic inheritance.)" I'll message author about the thread to see if he wants to answer any questions.

barrkel 10y ago
In the configuration space there's a certain irreducible complexity. Depending on what angle you come at things, you can try to abstract away details, but you need to mentally evaluate the abstractions anyway to figure out the effective configuration, to see if it makes sense. I've long thought that configuration can be modeled as intersecting N-dimensional subspaces, where N is the number of configuration axes (e.g. production vs test vs dev is one axis, as are datacenter location, machine role, etc). You can say that all test machines enable feature flag X, or everything in datacenter Y should use network setting Y.net - and these are cross-cutting concerns that don't lend themselves to hierarchical composition (and thus inheritance is out). The configuration settings themselves have a scope in the configuration space. But then you need to evaluate it mentally to sanity-check it: are all the spaces covered correctly? Are there any odd overlaps? There's a pairing with table-based exhaustive testing. Perhaps the cartesian product of all the axes results in too many distinct N-cubes to test individually, but predicates might be written that act as sanity checks, and testing for exhaustive coverage of predicates over the configuration space is possible (e.g. "every box has a disk space allocation", "boxes running service D have at least X disk space", etc.). Anyhow, it's rattled away in my head for decades and has leaked out into implemented systems a couple of times, but never in a fully formalized or packaged way.
dlubarov 10y ago
Thanks, that context is helpful, particularly the motivating example of test variants. I worked on a Java library which also tackles the test variants problem: https://github.com/square/burst https://github.com/square/burst With this library you would write something like enum Box { BOX1, BOX2, BOX3, BOX4 } enum Compiler { GCC, CLANG, MSVC } @Test void loadtest(Box box, Compiler compiler) { ... } I'm not sure if there are any big uses for cartesian products outside of test variants though. Probably not enough to justify making it a first-class language feature.

barrkel 10y ago

In the configuration space there's a certain irreducible complexity. Depending on what angle you come at things, you can try to abstract away details, but you need to mentally evaluate the abstractions anyway to figure out the effective configuration, to see if it makes sense. I've long thought that configuration can be modeled as intersecting N-dimensional subspaces, where N is the number of configuration axes (e.g. production vs test vs dev is one axis, as are datacenter location, machine role, etc). You can say that all test machines enable feature flag X, or everything in datacenter Y should use network setting Y.net - and these are cross-cutting concerns that don't lend themselves to hierarchical composition (and thus inheritance is out). The configuration settings themselves have a scope in the configuration space. But then you need to evaluate it mentally to sanity-check it: are all the spaces covered correctly? Are there any odd overlaps? There's a pairing with table-based exhaustive testing. Perhaps the cartesian product of all the axes results in too many distinct N-cubes to test individually, but predicates might be written that act as sanity checks, and testing for exhaustive coverage of predicates over the configuration space is possible (e.g. "every box has a disk space allocation", "boxes running service D have at least X disk space", etc.). Anyhow, it's rattled away in my head for decades and has leaked out into implemented systems a couple of times, but never in a fully formalized or packaged way.

dlubarov 10y ago

Thanks, that context is helpful, particularly the motivating example of test variants. I worked on a Java library which also tackles the test variants problem: https://github.com/square/burst https://github.com/square/burst With this library you would write something like enum Box { BOX1, BOX2, BOX3, BOX4 } enum Compiler { GCC, CLANG, MSVC } @Test void loadtest(Box box, Compiler compiler) { ... } I'm not sure if there are any big uses for cartesian products outside of test variants though. Probably not enough to justify making it a first-class language feature.