I’ve been playing with Processing for a few weeks now, resulting in new version of the celtic hack. (Click the picture and watch in awe.)
Processing is nice because it’s Java under the hood, so it’s cross platform, object-oriented, it’s got a garbage collector and it’s not too hard to port C code. And on top of Java, Processing offers a very nice graphics API (I haven’t used much of it yet, but the basics are good and the documentation and examples show off nice extras). Especially nice is the fact that in order to write a hack, you can start very simply as you don’t have to be bothered with Java classes and imports:
void setup() {
size(200, 200); // window size
background(0); // background colour: black
stroke(255); // draw in white
}
void draw() {
line(0, 10, width, height);
}
That’s all and it’s a very nice idea, especially for non-expert programmers (for whom Processing is especially designed), or for people like me who look at Java every 5 years and have to relearn how to start every time. The last nice feature is the IDE, which is simple but makes it very easy to develop apps. All this contributes to a very pleasant environment for writing small graphics hacks, running them and exporting them to standalone apps or applets.
However, where things become slightly more confusing is when you want to go beyond small hacks. In this case, celtic has somewhat complex data structures and functions, and it took a long while to understand what was going on when changing gears from a simple setup/draw job to writing complex classes for nodes, edges, graphs and splines and implementing a complex display loop. Here are a few traps I fell in:
- Processing redefines float and int. That simply kills any use of java.lang.Math: functions and even constants. Processing redefines the simplest ones but if you need a more complex one (like log) you’ll have to rewrite it.
- You can’t write one class per file, in good Java fashion. In fact you can, but none of the files (except the main) will be able to access the API, including float and int. So it’s useless.
- It’s a bit tricky how setup() and draw() work, sometimes. For instance, if you happen not to start setup() with size() then it’s called twice.
- You can’t call a function init(). You get an obscure error message if you do, and that’s the kind of thing that takes hours to debug and makes you yell WTF?! when you find out.
- Talk about obscure error messages, if you put all your classes in the main file but forget setup() and draw(), or leave them for later, then you’re told that you can’t do forward references in class definitions. Another few hours of finding out what’s going on followed by another WTF moment
Maybe I shouldn’t have started with a complexish hack, and it would have taken me less time to figure out the above reading more documentation, in particular a clear explanation of how the Processing code is transformed into Java. Most of the problems above would have been cleared up.
Anyway, now that I’ve found the main pitfalls, I’m really enjoying Processing. Java feels a little clunky, compared to more modern programming languages like Python or Ruby (who’s able to write System.out.println(”p=”+x+”, “+y+”.\n”) without messing up at least once?), but removing all those mallocs and free from old C code is still very enjoyable! So I’ll probably be writing or rewriting hacks with it (at least those where SVG fails), until canvas makes Processing redundant and all is to be rewritten again.
And I’ll definitely be playing with Mobile Processing.
Tags: Processing
Hoping dreamhost have fixed security hole
vs. 