“But that’s where the complexity kicks in: Oh! MSVC only works on Windows! Test X requires 8G of memory and the box Y only has 4G available. Shared libraries have .so extension on Linux, .dll extension on Windows and .dylib extension on OSX. I need to switch on valgrind for test X an box Y temporarily to debug a problem. Support for SPARC in our preferred version of LLVM doesn’t quite work yet. We need to use older version of LLVM on SPARC plarforms. And so on and so on.”
This is exactly why logic programming was used in early expert systems for configuring things. It’s easy to express such things with declarative programming with programmer feeding in environmental data and correct configuration coming out the other end. Similarly, one project in academia was rewriting “make” in Prolog for much cleaner operation. Biggest, commercial LISP’s always embed Prolog in them for such things so you write most of your app in preferred language then drop into declarative programming where it makes sense.
Best tool and default for most such jobs. That said, Cartesian is interesting work. The examples look clean like with other declarative programming. Plus it’s unusual for me to see cartesian solution to problems like this. I wonder what the inspiration was to try that.
Good observation. I would be a fan of doing this kind of work in Prolog myself, but lets’ be frank: Prolog is a hard sell to real-world developers.
As for the motivation, it’s twofold.
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.)