For starters, Java and thus by extension processing doesn't allow funargs and is constrained by it's verbosity. For anything other than basic Sketches, this is a huge disadvantage for something that claims to be an educational tool.
First, the nitpick: Processing isn't quite a subset of Java, it actually both supports full Java syntax (if a tab is named .java, it's processed as a plain old Java file) and adds a few syntax preprocessings of its own apart from wrapping everything into a Java class (one example: numbers don't have to have f at the end to be interpreted as floats).
With that out of the way: it's worth noting that someone put together a Scala version of Processing, which addresses the lack of functional goodness in Java while still using the "normal" Processing library (maybe even the environment?): http://technically.us/spde/About
As an educational tool, you could do a lot worse than introducing people to Java, though, since if they ever plan to work, it's probably what they'll be stuck coding.
And for all its limitations power-wise, I've seen far better (and far more) data visualizations come out of Processing than anywhere else (data viz is probably the #1 use case, since graphic/animation work is made very painless), so they're clearly doing something right...
You quickly graduate into writing PApplets in Java. However, even as you do so - the ability to sketch ideas and algorithms in the sketchpad interface is still a huge help.
In practice, Processing is by far the best thing going for creating interactive ad hoc visualizations. Fluency in processing imparts enormous viz power. It is really liberating. I pretty much only write Java when I do Processing (and some Pig stuff), and I don't mind it at all - despite not loving Java.
Using a JVM is a huge advantage because you can embed your applets in web pages and interact with the rest of the page via JS. Jython would be cool.
Nodebox 2 is cross-platform [http://beta.nodebox.net]. Unfortunately, IMHO, they achieved this by going with Java as the base and changing the scripting engine to use Jython.
As one of the people behind NodeBox, I'd love to know why you think this is unfortunate. We have been working hard on an application that runs on Windows, Linux and Mac, and a blanket statement like "unfortunately Java" is a bit frustrating.
As graphic designers we are really sensitive to awkward Java applications that look out of place on Mac or Windows. We are trying to find the right look that works on every platform. We discovered that this has more to do with an attention to detail than the underlying technology. As an example, look at a "Mac-like" application iTunes, iPhoto, iCal or Garageband: none of them use the standard aqua buttons in the main interface, instead opting for custom bitmap buttons.
For us, the choices are really down to Qt or Java. We need a solid graphics layer that provides the same results on every platform. Java's 2d graphics does this, and it has native back-ends (Quartz). Also, by using Java, we can speed up a lot of the Python code without resorting to hunting memory bugs in C++.
Lastly, I discovered at Pycon 2009 that Jython really has become a first-class citizen, officially supported by people like Guido. It also does away with the GIL.
I knew the Java argument would come up eventually: I'm surprised it took so long. However, it doesn't come up with people using the software: our users don't realize/care that we use Jython. Instead they're just happy they can use NodeBox on Windows.
Permutations and combinations.
Taking 3 (visualized as dimensions) from 7 (length of side).
License: Public domain. Attribution requested.
KEY:
Permutation: (order matters).
Repeating (Sequence): All (little cubies). Eg: Passwords.
Non-repeating (Arrangement): All except the reds. (ie transparent + blues). Eg: Number of ways of podium finishes in a race.
Combination: Selection (order doesn't matter).
Repeating: Cubies with white outline. Eg: Number of 3 scoop icecream serving from a set of flavours.
Non-repeating (Subset combination): The blues. Eg: Number of ways to choose 3 member committies from a group.
I wonder what this means for Douglas Crockford's "Good parts" subset and JSLint?
Those were islands of sanity and beauty in the ocean of raw sewage aka the browser environment.
In any case, I don't see this as evolutionary nor revolutionary. The benefits are non-existent, the hassles too many to enumerate. This feels like something a jobless and clueless government would do.
For starters, Java and thus by extension processing doesn't allow funargs and is constrained by it's verbosity. For anything other than basic Sketches, this is a huge disadvantage for something that claims to be an educational tool.