I'd bet that most people who have done advanced animation work [with code] can see exactly what Chris means. I certainly can. There is incredible motion design work that is purely accomplished in code. Certain things are faster and far more flexible in that medium. He's not saying "Design can and should only be done with code". I don't understand why anyone would bash the sentiment expressed in Chris' work. I think it's entirely valid and deserves our respect.
Code is a tool, just like a GUI. Most GUIs just abstract away the creation of the code anyway. If a guy like Chris can leverage code as a tool directly and doesn't need a GUI, more power to him. There are plenty of effects I've created with code that would be an absolute nightmare to try to create with a GUI.
> There is incredible motion design work that is purely accomplished in code. Certain things are faster and far more flexible in that medium.
There are, but not that much. Look at the code of this demo. It's not obvious, it was probably hard to tweak to look nice, not to mention doing any debugging.
> There are plenty of effects I've created with code that would be an absolute nightmare to try to create with a GUI.
That's kind of my point. It isn't that code is better-suited to this job - it's that our GUI tools are mostly stuck in the static world and suck for dynamic / interactive visualizations.
Bret Victor put a lot of thought on how to improve this state of affairs; he also brings convincing arguments that such things are still better-suited for direct, visual manipulation - that coding directly is a crutch we use because of lack of better tools.
Different kind of patterns. Design is about visual abstractions; code is more about textual and conceptual abstractions. The design space of a visual medium tends to be much easier to explore... visually.
(Also consider that a typical way of developing a website or application UI involves everything from drawing on paper through painting in Photoshop through building mockups in a graphics-oriented design package.)
I think at times we get too caught up in the visual components. Visuals like sketches and mockups and even code-less prototypes are perhaps best for communicating concepts, which is a part of design. But there's also the part of design that's less about communicating designs and more about applying the concept and designing a way that it can be created and engineered. That's where designing with code is extremely helpful.
So yeah, if I'm exploring or communicating ideas to non-technical people then yeah maybe code is less appropriate, but to say that you shouldn't design with code is ignoring a huge part of the design process.
Some people need those visual metaphors in order to create something. There are people who think differently (from you) and a CAD tool would simply be a hindrance. And if the resulting building is top quality why care how the blueprints were made?
Code is a tool, just like a GUI. Most GUIs just abstract away the creation of the code anyway. If a guy like Chris can leverage code as a tool directly and doesn't need a GUI, more power to him. There are plenty of effects I've created with code that would be an absolute nightmare to try to create with a GUI.