Blog  |   Puzzles  |   Books  |   About

Processing as a first language, compared to Flash

I really like Processing, the programming language.

I’ve been using Processing for about a year and a half, and I use it fairly frequently. I use it almost exclusively to do quick and dirty tests of ideas where I want graphical feedback. Because very little of this work has been seen by the general public, I thought it would be a good idea to put up a gallery of some of my processing code, both to illustrate what kinds of things I think Processing is good for, and to provide some free code samples.

Here is my Processing gallery.

When I first started programming, most computers came with a built-in BASIC interpreter, which was a simple way to start learning programming. Sadly, this is no longer the case. I think that most of the languages that are taught to first-time programmers are terrible choices. I don’t think first time programmers should be learning C, nor Java, nor BASIC in its most common incarnation. If you started on those languages, and are still going, then more power to you, but I worry that starting artistic thinking “right-brained” programmers on these languages is a big turn off.

I teach Flash 6 actionscript as a first programming language, to mostly right-brained high school students at an Art School. It works pretty well for that, but I think Processing would be an even better choice. Here’s why:

* It has less baggage.

When I teach Flash, I have to spend about two classes on stuff that has nothing to do with programming, but is idiosyncratic to flash. Timelines, tweens, movieclips and so on. Flash is filled with idiosyncrasies, like the fact that scripts which are attached to movieclips look totally different than scripts which are attached to frames. These idiosyncrasies get in the way of ease-of-learning. With Processing, you can start programming right away, and produce a pretty picture in a line or two of code. It puts you into a programmer’s mindset right away.

* It provides a nice simple environment for programming.

Processing has a built-in sketchbook system for saving and loading and running projects, an idea (perhaps borrowed from Mathematica) which I’d like to see more of. It makes cutting and pasting between projects a snap. It’s not a full blown IDE, which is good, because a full blown IDE has too big of a learning curve for first time programmers. Like flash, the built-in editor isn’t great, but it’s good enough.

* It’s cheap and widely available.

Like Flash, Processing runs on more than one platform (any technology which is primarily targeted at windows machines is of extremely limited value, in my opinion – this is why you will so no C# or .NET on this website). Unlike Flash, Processing is free.

* It has a richer set of graphics commands.

Flash 8 has rectified this to some extent. In prior versions of Flash, there are certain things you simply can’t do, graphically, because everything is vector based. You can’t paint individual pixels (well, you can, but it’s cumbersome), nor read the value of individual pixels. Processing allows for these things, and also provides multiple color modes, 3D, and a host of other cool graphical goodness. This is one of it’s principal strengths.

* It’s significantly faster than Flash.

Once it’s running, that is (see below). Flash is pretty darn slow by comparison.

There are also some things I really dislike about Processing, as compared to Flash:

* Terrible name.

I truly believe that the name, “Processing,” prevents wider adoption of the language. Because it is a noun already in common use in computer jargon (unlike, say, Perl or Python), the name guarantees that web-pages related to the language will be hard to find in search engines. The word’s banality makes it difficult to remember when you first hear it. Nearly everyone I talk to about Processing fails to find it, when they try to remember it a few hours later — either they forget the name, or they fail to find the website, The name Processing is almost as bad as “Language”. Processing used to be called p5, but that name has fallen out of favor with the developers. Personally, I think p5 is a better name, and I still use it when I’m trying to be clear what I’m talking about.

* Java engines suck.

Because Processing is a superset of Java, it relies on current Java technology. On most of the web browsers I use, it takes a long time for the java engine to come up, and then a long time for an applet to start. This means users spend a few seconds looking at a mismatched square, and it’s one of the main reasons I discourage my clients from using Java-based web applets. My flash applications start much more cleanly in web browsers.

I should mention that although I like Processing, I do not particularly like Java (or at least, current implementations of Java). I like to use a lot of different languages, but there are virtually no projects for which I consider Java appropriate — I usually prefer Perl or Python on the high end and C on the low-end. I consider Processing to be a “fixed” version of Java in some ways.

* Buttons are painful.

I find it cumbersome to make user interfaces in Processing, as compared to Flash. It’s not terribly difficult, but it requires some tedious work, and I’m lazy. Therefore I usually have very minimal interfaces in my p5 programs, such as simply moving the mouse up and down or left and right, rather than the draggable objects and sliders that I more commonly use in my Flash movies. It’s not that I don’t know how to make them, I’m just lazy. On the other hand, the kinds of things I use processing for generally don’t require much in the way of interfaces, so it’s usually no big deal.

* No built-in hashes

Actionscript supports hashes as a built-in data type – basically an extension of arrays. This is one of the most elegant things about javascript and actionscript, in my opinion, and I sorely miss it in Java and p5 — in these languages you must use the Hash class, which involves some ugly code, so I usually don’t bother.

5 Responses to “Processing as a first language, compared to Flash”

  1. rgovostes Says:

    Your points are valid, although I will point out that there are several UI libraries under development (and most of them are functional), which should make the buttons easier. You’re free to contribute your own hash code if you’d like, and I’m sure it would be greatly appreciated! I’d also recommend looking into a Java obfuscator, which can significantly compress an applet and make loading nearly instantaneous. Finally, the applet loading display can be customized to show a custom picture with any background color you wish.

    I’ve updated my Processing implementation of your “Alien Blob” (from Pixel Magic, originally ported in 2003) to work in the BETA version. You can see it at … it still mesmerizes me!

  2. jbum Says:

    Hmmm… looks like it’s time time port some of my other old pixelmagic stuff – nice to see it can be animated in real-time on the web!

    When I originally wrote that code I had to generate a QuickTime movie to see the animation…

  3. KrazyDad » Blog Archive » Processing Group at Flickr Says:

    […] As I’ve mentioned before, processing is an excellent first language for budding algorithmic artists. […]

  4. Hola, mundo. » Blog Archive » On ChucK, Terry Riley, Jim Bumgardner and emulating old masters through code Says:

    […] (on a deeper look, I’ve found more gems, such as the article Processing as a first language, as compared to flash, his processing gallery or the JSyd Java Synth) […]

  5. DoctorEternal Says:

    Too true, it is sad that PC’s no longer come with a programming environment. My good ‘ole Vic-20 (which is sitting next to me on my desk) had the first language I ever learned: Basic, when I was 11 (in 1982).

    I agree Processing makes a great first language. Not simply because it it based on Java, which I love, but that it initially hides the gory details of Java while allowing you to pull those details out when you need them.

    I am currently teaching my 10-year old to program using Processing, and he’s taking to it like a fish to water.