The importance of simple primitives and efficient composition is that it allows the domain-specific system to be utilized for a wide variety of domain-specific applications. This reinforces the idea that domain-specific systems are not designed to restrict the problems you can solve (ie; the last bullet point), but rather define how you can solve problems in the domain.

So is this slide essentially saying that the simpler the primitives the better? I kinda see the primitives as the basic building blocks of the DSP, so the simpler they are, the more flexible they are.

One factor of good DSP system design is a system that keeps primitives simple and allows the programmer to combine primitives into desired types. Rather than giving highly complex primitives, your primitives should allow the programmer to, as the slide says, compose them together, like structs. This allows the system to be applied in settings the designer would have never intended.

But does the design with very simple primitives leave more work to programmers? i.e. programmers have to write more code to combine and manipulate all the primitives to achieve the goal - not sure if this is a tradeoff here.

@jt I think it’s certainly a tradeoff. An analogy I have to DSP system design is like designing a Swiss Army knife, where a primitive might be one of the knife’s tools. You want the knife to be small, transportable, and with high utility—like you’d want a DSP System to be easily understandable and highly applicable. Too many tools (too many/complex of primitives) means it’s just extra weight on your Swiss Army—the programmer has to memorize/know more about the DSP system. But if your Swiss Army knife helps you in your most important situations, is light and simple, and the tools work together to solve any problem, then bingo, stick with those tools/primitives