I would not use C++ on firmware though. Usually memory/space requirements are far more important than OOP lang features. And good software can be developed without them.
C++, especially modern standards of the language, offer far more than OOP features.
/If/ you know the language and tools well, there is no reason that C++ won't be as efficient in space and time as the equivalent C code. C++ offers real gains to be had over C for embedded software, with rich (if a bit cryptic) zero-overhead abstractions, and higher level constructs that can eliminate entire classes of errors.
Nothing guarantees that it is zero-overhead, it all depends on the efforts, quality and mood of the C++ compiler. Whereas in C you can at least rely on the fact that even without any complex optimisation it will at worst produce machine code that looks 99% like the C code, because it maps 1 -> 0.99. Good luck telling what is the complexity hidden behind a C++ operator.
Right, that was my point. You have to use time/effort on understanding the compiler workings, time that could be used to focus on your actual problem and features implementation. For firmware I wouldn't.
I'm genuinely surprised the kind of reaction this comment is getting. There wouldn't be a design if it wasn't for actual programming.
The vector graphics you see are mathematical models which are 'coded' in a script or a programming language and animated with the help of... again... programming.
I understand the concept of less code and more stuff, but the fact that people are saying programming is not for designing is just simply absurd. The tools on top of which you design convert everything into code.
I'm in no way saying people should stop using these tools or design should only be done through code. But knowing how to visualize things in your mind and materializing that concept through code/programming is beautiful and (in my personal) opinion makes you a better designer.
I'm fairly shocked too. I appreciate that lots of people don't understand this way of creating stuff but to suggest that programming and design are two separate entities is to deny an exciting approach to design in general.
We clearly see design differently then. These lines of code are curved shapes that the bezier line will morph to.
Remember, just because you 'don't see how this kind of code is helpful for design' it doesn't mean that other people share your view. We all see things differently - a good thing to remember especially in these times.
I understand that, and as a developer, I'm used to working with stuff like this.
However, without some sort of interactive IDE, this just feels like magic numbers. The code itself, as written, is not enough to help you visualize what you are producing.
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?