Idea: Desugared Design Systems

I learned about the concept of desugaring from a lecture on programming languages, and I wonder how that would apply to design systems.

, ,

The other morning I watched the first lecture of Shriram Krishnamurth‘s Introduction to Programming Languages course. In the first ten minutes of the lecture, Shriram makes a great case for discarding traditional programming paradigms (e.g. functional, object oriented) as the canonical way to classify languages and introduces, instead, the concept of reducing languages to core set of features and then classifying those features. In other words, removing the sugar (the syntactic sugar) from the language: de-sugaring (but I will use it without the hyphen, because that’s how it is in the course textbook).

I wonder…what would it look like to desugar a design system? Not the design piece of a design system because that is already a desugared version of the entire design (broken down into features like components, colors, fonts, etc.) but the software implementation of the system. What does it look like to reduce that part, that usually is comprised of three or more languages? This is the design system DSL (domain-specific language). Could we de-sugar this DSL in the same way as other programming languages? Can one desugar a DSL?

And what can we learn from these desugared design system DSLs? Are there consistent differences between mature systems and immature systems, indications that teams are learning expensive lessons over and over? Alternatively, given the human factors involved in designs systems, are design system DSLs necessarily unique?

Maybe, I will report back on some of these questions once I watch more of the course!