[EvanMiller]

This is a compelling little essay. I think the author left out a couple of important points, though.

1. Design systems may be "algorithmic," but they're primarily mathematical, and equations remain stubbornly hard to use. Metafont failed to attract designers because no one wanted to cook up high-order polynomials to express their visual ideas. (In contrast, Adobe came up with a good-enough interface for Bezier curves, and now the world uses non-algorithmic fonts.) The new class of designers will need solid grounding in at least high school algebra to get their curves and easing functions right.

2. Any argument about "XXX should learn to code", where XXX is anything other than "aspiring professional software developers," means that there is a significant market opportunity for creating usable software that does not require coding. If people are willing to spend thousands of dollars on bootcamps to learn to code -- when they'd really rather be focusing on their domain problem -- then they're theoretically willing to pay thousands of dollars to not have to learn how to code.

I don't know the state of design software, but if it's anything like other professional desktop tools, it's horrible, creaky software stuck in the early 1990s with very little competition in sight. When I read this essay I can't help but think there's an opening for usable algorithmic design software -- whatever that may look like.

[QuantumRoar]

I agree with your first point. I don't see designers learning to represent ideas as equations. Not even most of the people who studied Computer Science know the difference between a function and the graph of a function. So I don't see how more difficult concepts can be taught to designers who have no foundation in maths whatsoever. And I don't think that high school maths is really enough. You need a solid knowledge of Linear Algebra to understand how to display a 3D object properly.

Expressing a design as a mathematical expression that generates new representations that follow some guidelines means the designer needs to rigorously understand the very essence of what it is he's trying to do. And then he still needs to know the maths to actually formulate it. This is a tough problem if you start from scratch and I doubt that many designers are really capable of pulling it off.

AFAIK creating those layouts for iOS apps has mathematical reasoning. If you design your app, you basically specify rules to anchor each object on the screen. When the app tries to draw its interface, a linear system of equations gets solved and the solution is the best way to put all the objects on the screen, given the rules that were defined. This gives you an extremely powerful design tool to specify your layout for arbitrary screen sizes.

I would very much hope that they do the same for CSS any time soon.

[j2kun]

> Not even most of the people who studied Computer Science know the difference between a function and the graph of a function.

I am surprised by how often I hear this example. Not because people can't define the graph of a function, but because in usual set theoretic terms[1] a function and its graph are the same thing. They are both the set of points (x, f(x)) where x ranges over the domain of f. This is an equivalence that isn't even made by most mathematicians, as they usually denote the graph a function as Γ(f), implying it is different from f itself as a function. Of course they know the equivalence, but prefer to separate the objects notationally for clarity's sake.

[1]: I'm ignoring the notion of a function in category theory, since CS students who are taught math are primarily taught naive set theory, not category theory. Of course, when you aren't working in a category of sets then the graph of a function doesn't make sense, I think.

[QuantumRoar]

> I am surprised by how often I hear this example.

Huh? That surprises me, too. I didn't know it was so common.

Anyway, I agree that there is an equivalence between a function and its graph. Knowing one implies you know the other. But just because it's equivalent, doesn't mean it's the same. A two-dimensional graph is, after all, a set of tupels in R^2. A function, however, is a mapping from one element in one set to another element in another set.

Mathematically they're very different. I can't draw functions, I can only draw sets. I can't apply sets, I can only apply functions. It makes sense to treat them as different things.

Actually, vector graphics are mathematically specified by graphs of functions, not pixel sets. This makes it possible to zoom in without pixelation, since the function in the graph can be defined analytically (like Bezier curves). If you started out with sets instead of functions, you'd get pixel graphics, since it's not possible to save an infinite set. So the equivalence of a function and its graph holds until you try to implement something.

[j2kun]

For whatever reason, I hear it as a "challenge" trying to show someone they don't understand math.

But again, I would argue that you're ignoring the difference between an object and its representation for the purpose of communication. A function is defined to be a set of tuples (a relation) with some extra properties. These tuples are the input-output pairs of the function, which is exactly how you define the graph of a function. They are literally the same object, regardless of whether you choose to represent them as a picture or a mapping. The choice of language suggests they are different things because you want to treat them differently (and this is a good thing), but when you get down to the definitions they're the same.

Your example of vector graphics is not a counterexample to this because the sets that define those functions are uncountably infinite. When you render them on the screen to have to approximate them by a finite pixel set, but that is unrelated to the underlying function's mathematical nature.

These set-theoretic definitions of functions and relations are standard parts of an introductory course on set theory.