Processing is a wonderful little language. It's designed to be easy to pick up by artists who want to learn some programming, etc. However, it's a real programming language. If you haven't played with Processing, I'd recommend you go do that right now. They have a great series of tutorials, and of course the entire SDK is free.

This post is for people like me - programmers who want to take advantage of Processing's short iteration cycle, clear syntax, and simple API to use it as a prototyping environment.

First, here is what I think Processing excels at:

Interactivity - It's dead easy to get and use mouse and keyboard input and define event handlers.
Graphics - "Hello world" in Processing is drawing a circle. It has a simple but powerful graphics API. 2D is really simple, and it has powerful features that can be used without any boilerplate such as 3D rendering and a matrix stack.
Engineering flow - like I said above, the short iteration cycle, clear syntax, and simple API make it a breeze to get up and running quickly and iterating.
Fun - Because of all of that, it's a lot of fun to write stuff in Processing, especially for smaller projects where you are just messing around.
Multiplatform - Out of the box, Processing 1.5 can build native applications for Windows, Mac, and Linux, native Android applications, and web applets (yuck.) Via Proccessing.js you can also supposedly get your sketches to run natively in web browsers.

Here is what I think Processing is weak at:

Large, complex programs (they tend to get a bit unwieldy since it's impossible to organize your classes inside a folder structure.)
Programmer assistance (No out-of-the-box debugger. The preprocessor's errors are often frustratingly non-specific, and can leave you blindly hunting for syntax errors across multiple files.)
Audio ~~(there is no out-of-the-box support, but there are libraries available)~~ Processing now includes the excellent Minim library, but you have to explicitly import it. Audio still appears to be an afterthought in the documentation and tutorials.

I have been prototyping games and visualizers (including the one above) in Processing for several months now, and have learned some incredibly useful things that I think any programmer looking into it should know. Here they are:

Processing is Java.

This took me a really long time to realize. I mean, it really is just Java, with a slightly simpler syntax. When you hit "Run," processing runs your .pde files through a preprocessor that converts them into one giant Java class. Your classes are all inner classes of your main class, which extends PApplet. This is how all of your custom objects can access "global" variables and functions defined in your main class, as well as all the Processing API methods. No magic.

What this means is that out-of-the-box, you can use tons of classes from the Java standard library. My absolute favorites here are Java's generic collections... HashMap and ArrayList. In the Processing documentation, they have lots of examples using the non-generic versions of ArrayList and HashMap. This means that you have to manually unbox (cast) items coming out of those collections. What a pain. Don't bother, just use generics!

You can also use Java's for-each syntax to iterate through these collections rather than manually using the iterator as they describe in their documentation. For example, the following is perfectly valid in Processing, you don't even need to import java.util (that's part of the default Processing imports behind the scenes):

HashMap hm = new HashMap();
hm.put("somekey","foo");
for(String item : hm.values() ){
     println(item);
}

A trivial example, but generic collections are extremely useful, since you can lean on the compiler to keep track of the types you're using. It's a bit more verbose to create these objects, but it's much less verbose to use them.

Processing is not Java.

Processing is based on Java, but because program elements in Processing are fairly simple, you can learn to use it even if you don't know any Java. If you're familiar with Java, it's best to forget that Processing has anything to do with Java for a while, until you get the hang of how the API works. - Ben Fry

It really is a good idea to try to discard your preconceptions about Java when first learning Processing. You don't need to be quite as verbose as in Java, and there's less technical overhead.

So, I'd recommend that you forget that Processing is Java when you are first learning it. But, if you are able, keep it in the back of your mind, so you can avoid some of the simplistic kludges put forward in the Processing documentation (the main thing that comes to mind for me is using generic collections and for-each loops.) Once you are familiar with Processing idioms, then it's great to know what's going on under the hood so you can leverage the more powerful Java stuff.

This also leads into the next most important thing on my list:

You can use a real debugger.

I have had many headaches trying to debug runtime errors in my sketches without the assistance of a modern interactive debugger. I had started getting used to print debugging to figure out what was going on, but in something as complicated as a game engine, I was really hurting for a real debugger. Then I discovered an awesome trick.

If you are only developing for desktop OSes, you might want to try out writing Processing inside of an IDE. Here's an article on Processing in Eclipse. However, as of Processing 1.5, it would be non-trivial to do this and take advantage of the low-friction Android support as well. I need my prototype to run on Android, so I choose to keep my sources in .pde files, which I can use to build for desktop OSes and Android from essentially the same code base. I figured out how to do that AND use a real debugger.

The first step is to export the Java version of your sketch:

Run and then quit your sketch to ensure your build products are up to date. Click on File -> Export Application. Check only your development platform. Click export.

If you navigate to the export folder, you will find a .java file that's named after your main class. This is the .java file that Processing creates from your .pde files and passes to the Java compiler. This is great news, because you can load this into a real Java debugger and hunt down nasty runtime bugs in style. And those incomprehensible line numbers in runtime exceptions will now map to actual locations in your code!

Here's how I set up NetBeans as my Processing debugger (Eclipse probably works just as well but I have not set that up.) This is a one-time deal for each sketch, afterwards all I need to do is re-export the sketch in order to update the code I'm debugging against.

Install NetBeans for Java SE if you don't have it already
File -> New Project -> Java -> Java Project with Existing Sources, click Next
Name your project something meaningful and click Next
On the right of the list for "Source Package Folders", click "Add Folder..."
Select the export folder inside your sketch folder that contains the .java file (application.YOUR-PLATFORM/source), click Next
Under includes, delete the text there, enter "*.java", click Finish
File -> Project Properties -> Run, click "Browse" next to the "Working Directory" field. Select the main folder of your sketch and click "Open."
Locate core.jar as described in step 3 of "Processing in Eclipse." If you're on a Mac, you're better off copying core.jar to some other location since the file picker is lame and won't let you go inside an app bundle.
File -> Project Properties -> Libraries -> Add JAR/Folder. Locate and select core.jar.
If you are using any Processing libraries, you should also locate their jar files and add them to the classpath.

Phew! At least we only need to do that once. And now it should be all set up for your debugging pleasure.

Since the project is set up to load external sources, just re-run your sketch and re-export the sources from within the Processing Development Environment (PDE) to make them update instantly inside NetBeans. It's awesome.

The Java source is similar enough to the Processing source that I always know what line to fix after I hunt down the bug. I then make the fix in the .pde version - the .java file will be overwritten by the Processing export the next time I need to debug.

Another neat thing I like is using the navigator to peruse my inner classes. Holding the Option/Alt key and clicking the top-level arrow, and then normal clicking it again gives a compact overview of all my inner classes that I can then selectively expand and click to jump to the appropriate field or method. This is helpful for locating places to set breakpoints and watches.

You can use a real text editor.

In the PDE, select Preferences -> Use external editor. If you are like me and believe that mastering a powerful text editor is a worthwhile investment of your time, you are free to use your favorite editor when making Processing sketches. The built-in editor in the PDE is okay, but very basic. I am using Vim with this ftplugin for Processing. It supports syntax highlighting, indentation, and documentation lookup via shift+K. It is wonderful. I keep the PDE open in the margin of my screen to do the build and provide a place to display output, it still can be helpful sometimes in locating the line of a NullPointerException, etc.

Apparently there is also a way to call the Processing build without using the PDE but I'm sure it's not as well tested as that little Run button, so I decided not to muck around with it.

Git is your friend.

If you are comfortable using Git, this is a no brainer. Just "git init" your sketch folder, add your code, and commit. Git is really a helpful tool when working with Processing, especially because the preprocessor is so finicky and unhelpful. I like to stash or stage good versions of my code as I develop, so I always have a version to roll back to if I'm getting syntax errors from an unknown location and the code is clearly FUBAR. Making commits during logical stopping points on features is great, and much cleaner than making a bunch of copies of a sketch. Plus, it makes backing up your sketches stupid easy if you have a remote git repo such as GitHub. I recently have used git's best debugging tool, git bisect, to hunt down a nasty bug. Git helped me do a binary search through my revision history and track down the commit that introduced the bug, which was a different commit than I had expected. I was able to immediately hunt down and fix the bug since bisect revealed that it was data-side (all I had committed was data,) so I knew where to look.

I also use Git to painlessly manage a master development branch, and an Android branch (since Java doesn't have #ifdefs...) More on that later.

If you don't know Git, why not start now? Next to my text editor, it's my favorite programming tool. I'd recommend reading the first few chapters of Hg Init and Pro Git, which are freely available online.

Android development is frictionless.

You do need to have the Android SDK installed and set up first - one-time setup instructions and more details are on the Processing wiki. That can be a bit of an adventure if you've never done it before. Follow the SDK install docs carefully along with the instructions on the Processing wiki and you should be okay.

After that is set up, if you're not using any special libraries, it may be as easy as selecting "Android" from that drop-down menu in the PDE and clicking "Run."

I was using the proxml library in my sketch that I wanted to convert to Android, so I had to comment out all of the deserialization code that used proxml. Not a big deal, as that was just for saving levels, I was using processing.xml for loading levels, so loading still works.

I did this on a separate git branch, so all the Android-specific project files live on the Android branch only, along with Android-specific input code and a handful of display code (locking screen orientation, and not specifying an explicit window size.)

After getting everything set up as described above, I have achieved pretty much frictionless multi-platform development, using Git to manage my workflow. This is going really well so far... I do my development on master, and then merge master into my Android branch. Many times the merge is automatic. Occasionally there is a minor conflict that is easy to resolve. I close the sketch in the PDE before switching branches which doesn't take too long and ensures that it loads my Android settings.

There are a few differences when developing for Android, but overall the development experience is pretty much frictionless, and the Processing APIs are nearly identical. Again, check out the Processing wiki for more details.

Processing helps you learn Arduino.

Another fun benefit of learning Processing is that it's very similar to the Arduino programming language. If you have ever wanted to mess around with writing software for a microcontroller that can be hooked up to all sorts of crazy electronic doodads and do really cool stuff, this is a great entry point into that whole world! It's probably the friendliest microcontroller on the market right now and it's pretty affordable too, well worth checking out if you have a bit of a tinkering instinct.

That's all, for now

I hope you enjoyed this overview of advanced topics in Processing. I will continue to use Processing to prototype ideas - I like it even more now that I can use it like a modern programming language, and being able to iterate quickly on a game prototype that works on both PCs and smartphones is a boon. If I learn more, I'll update this article or write a new one.

If you haven't used Processing, I'm amazed you made it to the end of this article! Go check it out, learn it, and maybe come back and read this again in a few weeks when you will be more able to absorb it. Thanks, and let me know if you have any questions or comments! :)