What about cartesian programming?

It was used in a 2000 era web app. Neat.

http://cs.nyu.edu/~bacon/phd-thesis/diss/node35.html

You're hired!

That translates fairly well into Python, with its set type and list/set/dict comprehensions.

    def setrange(first, next, last):
        return set(range(first, last+1, next-first))
    
    fizz = setrange(3, 6, 100)
    buzz = setrange(5, 10, 100)
    fizzbuzz = fizz & buzz
    fizz -= fizzbuzz
    buzz -= fizzbuzz
    num = setrange(1, 2, 100) - fizz - buzz - fizzbuzz
    line_map = dict({n: "Fizz" for n in fizz}.items() +
        {n: "Buzz" for n in buzz}.items() +
        {n: "FizzBuzz" for n in fizzbuzz}.items() +
        {n: n for n in num}.items())
    for i in range(1, 100+1):
        print(line_map[i])

Some SETL features Python lacks:

• No ellipsis notation for ranges; must use the "range" function and add one to the maximum value, or define a custom "setrange" function

• Can't concatenate dictionaries; must concatenate their "items" lists and convert back to a dictionary

• No consistent map-lookup notation; collections are indexed with brackets, but functions are called with parentheses

First time I learned about SETL at NYU was when I was learning about Spitbol.

Here is a fizzbuzz in Spitbol. Probably not the best way to do it.

      var a = 0;
      start
      +a = a + 1;
      break
      +lt(a,101) :f(end);
      x01
      +x = (remdr(a,3) + remdr(a,5)); eq(x,0) :s(x06);
      x02
      +y = remdr(a,3); eq(y,0) :s(x04);
      x03
      +z = remdr(a,5); eq(z,0) :s(x05)f(x07);
      x04
      +output = 'fizz' :(start);
      x05
      +output = 'buzz' :(start);
      x06
      +output = 'fizzbuzz' :(start);
      x07
      +output = a :(start);
      end
      

More: http://www.hakank.org/setl/fizzbuzz.setl

He also has pages on APL and k.

Wait, do you mean it in a sense of mathematical sets or sets in SQL?

I think that comment goes in the right direction. It's kind of like relational programming but with focus on generation of data rather than querying it. While writing this kind of thing in SQL would be a headache, maybe a simpler language that would translate to SQL or maybe an extension to SQL would be a good idea.

You're not wrong, if the only verb is `c.expand()`. In Haskell you would write:

    -- omitting the definitions as trivial...
    cmdline (Suite box (Compiler cmd _ out_opt) (Test binary sources))
        = intercalate " " [cmd, sources, out_opt, binary]

     testSuites = [Suite srvr comp test |
         srvr <- [box1, box2, box3, box4],
         comp <- [gcc, clang, msvc],
         test <- [frobnicate, loadtest, end2end],
         not (binary test == "loadtest" && ram srvr < 8)]

(Note that Haskell lets you specify what `==` means so probably the above should say `test == loadtest` more directly...)

If there are other verbs then it might not be 100% equivalent. For example one might want a sort of "Non-uniform random choice monad," let's say a monad of "Choosers", which will quickly generate a random candidate test suite. If you wanted to support both, you'd want to quickly define:

    class Monad m => MChoice m where
        choose :: [x] -> m x
        invalid :: m x
        invalid = choose []
        mfilter :: Bool -> m ()
        mfilter True = return ()
        mfilter False = invalid

    instance MChoice [] where choose = id

Then you can say,

    testSuites :: MChoice m => m TestSuite
    testSuites = do
        srvr <- choose [box1, box2, box3, box4]
        comp <- choose [gcc, clang, msvc]
        test <- choose [frobnicate, loadtest, end2end]
        mfilter . not $ test == loadtest && ram srvr < 8
        return $ Suite srvr comp test

In this respect maybe Cartesian programming represents a generalization of the list monad.

I think someone once proved that all programming languages (or just about) are equivalent in their expressiveness, and given that similar problems arise in all paradigms, it is not surprising that all paradigms have their own names for similar things. Just as monads and continuations are two different ways to express similar computational notions, it would not be surprising if there were others. None of these is more fundamental or "real" than the others. They are simply different ways to formally model an abstract concept.

That's a testament to Turing completeness.

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.

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

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.

I admit I've only started programming around '99/00, but I don't remember learning "weird" languages being very popular even then. Mainstream communities mostly had a mix of C/C++/Java/Perl/PHP.

Yeah, it's sad. It's the Worse is Better effect combined with momentum of legacy systems. You have to reuse things that have momentum to increase odds of your own thing having momentum. Three examples coming to mind were C++ building on C, successors using C-like syntax, and a number of languages integrating Java or .NET libraries. Those clean-slating solid concepts usually didn't go anywhere.

I agree.. when I hear that this doesn't exist then I am wondering if the author has heard of Eve or Elm

Sometimes, I wish I could double downvote a comment.

The author doesn't claim those are the one two paradigms.

The author effectively calls out that there is no existing thing that goes by that name - how could he, when in the first paragraph he says he has never heard of it elsewhere.

He succinctly states what it is before going into more detail.

It's as if we read completely different articles.

All in all, a low effort comment.

> Shows limited knowledge of the author

Visit the website again and check out who the author is, and you'll be embarrassed for the rest of the day :)

Here's what it says on the first line of his home page: "Website of Martin Sústrik, creator of ZeroMQ, nanomsg, libdill, libmill and ribosome."

Even aside from the "limited knowledge" issue, he doesn't say anything you're accusing him of saying. Chill out and be nice man.