So, at my new job, a bunch of my coworkers are "designer-programmers." Usually these are people who have training in art or design and who teach themselves how to program (often quite well). As one might expect, many of them shifted into C++ and OpenGL after first whetting their appetites with processing.org (which I will simply call "processing" from here on).
Every once in a while I'll run into a quick one-off scripting task whose output (or input!) is an image or a video asset, and my first instinct will be to start looking up scripting language wrappers around things like PIL and ImageMagick. Whenever I express a thought in this vein, invariably, one of the designers will say "Why don't you just use processing?" or "Processing can do that!"
And it turns out that they're right. I have conceded that, even without a strong knowledge of processing, processing is a better tool for quickly programmatically generating images and video than many of the more conventional scripting languages out there (including Ruby and Python). There are two reasons for this. The first of these is that processing gets out of your way, and lets you call visually-related API functionality without having to do a bunch of imports, or the equivalent of "system.out.println instead of printf". The second is slightly more subtle. Processing is structured around the idea that you'll have a setup, a draw, and an event loop, and that the "draw" will draw things, either every frame, or on certain events. It is absolutely amazing how much more natural this is than "print stuff out" for tweaking and debugging programs whose output is (primarily) other visual artifacts.
No comments:
Post a Comment