Is P5.js supposed to be the successor of Java-based Processing ?

carcaju

On his Twitter feed, Daniel Shiffman talks about adapting all his code for P5.js and about how ITP Tish will now teach P5.js in the intro course. In this article from Motherboard (http://motherboard.vice.com/read/meet-processing-the), it is said that P5.js is a reboot of Processing from today's perspective.

Is P5.js the official heir?... the next Processing? Will (should?) it eventually replace Java-based Processing as the official flagship?

From the Motherboard article :

"The programming language world is a whole lot different [since 2001] and there are any number of ways to do cool stuff on the web or otherwise. Would Reas and Fry have done it differently had Processing been released in 2015? Maybe. "We asked [artist and programmer] Lauren McCarthy to explore this question in one of the first [Processing] Foundation fellowships," Reas explains. "How could the initial goals of Processing be achieved in 2014 outside of the technical decisions we made and have been making since 2001? The answer was to apply the ethos of Processing to JavaScript and the web. The p5.js project is the result and she is doing an amazing job as the leader of that project. I think 2015 will be a big year for p5.js."

GoToLoop

• Short answer is the web! And p5.js is the best option among Processing ecosystem for the future.
• However there are some shortcomings... Debugging in JS is much harder than in Java.
• Also, OOP in JS ECMA 5 is more complicated. Although it got much easier w/ ECMA 6.
• And keep in mind that p5.js is still in beta and it's yet to start support for WebGL canvas.

blindfish

It's an interesting question. From a teaching perspective I suspect Java-based Processing would be easier to teach: it's more rigid which makes it easier to debug, as common errors get picked up at compile time, and it's harder to create errors through sloppy type handling (e.g. forget to set a type declaration on a variable in Java and it won't run. Do that in JS and you just made your variable global!). JS also has a number of other quirks you have to get used to (e.g. variable hoisting in functions)...

Conversely the satisfaction students gain from putting their work online is likely to be part of the move; even if in terms of performance p5.js is well behind Java processing.

@GoToLoop said:

Also, OOP in JS ECMA 5 is more complicated.

I disagree! What could be simpler than:

var myObject = {
   someProp : "foo",
   someOtherProp : 123,
   someMethod : function(bar) {
     return (bar *2);
   }
}

'OOP' is only more complex in JS if you're trying to implement classical (pun intended) Class-based code with inheritance and so on. It's actually far easier to define an object in JS (as the above code demonstrates). In fact it's almost too easy: so JS does need a different mindset; and it really is harder to debug. This difference also means it may not be a great choice if you want to move on to more 'serious' programming languages like full-blown Java; but since the web is everywhere these days JS is a great language to learn!

edit: changed 'MyObject' to 'myObject' - sorry: the capital would have been interpreted as a class definition; which it isn't...

GoToLoop

I disagree! What could be simpler than:

Those properties from MyObject are static! That is, the way you've set them now won't get any instance of them! [-X

GoToLoop

This is the corresponding code in Java of your "class-object": #-o

static class MyObject {
  static String someProp = "foo";
  static int someOtherProp = 123;
  static int someMethod(int bar) {
    return bar*2;
  }
}

blindfish

Nope: it's an instance of an object; not an object constructor:

  var myObjects = [];
  for (var i=0; i<10; 1++) {
      myObjects[i] = {
       someProp : "foo" + i,
       someOtherProp : i,
       someMethod : function(input) {
         return (input * i);
       }
    }
  }

And that's one of the handy shortcuts in JS: you don't need to formally define a Class or constructor for a one-off object; or even multiple object instances.

In terms of teaching and learning though I think this is a negative: it means you don't have to carefully consider the members of your object and this can lead to ill-conceived code...

GoToLoop

... you don't need to formally define a Class or constructor for a one-off object...

That is about flexibility and nothing to do w/ being easy to do it!
IMO, Java has the easiest & cleanest way of doing OOP! JS will get closer to it w/ ECMA 6 Harmony!

GoToLoop

@blindfish, there's a very nasty bug in your "class" loop! :-\"
And it's related to 1 of the most complicated things to grasp: "closure"! :-SS

All of those Object instances share the same closure, related to the iterator variable i.
Closures by nature are static. They don't instantiate automatically by themselves!

It means that when we call someMethod(), the value of i is always 10,
no matter which instance is used for it! Check it out:

var NUM = 10,
    myObjects = Array(NUM);

for (var i = 0; i != NUM; ++i)  myObjects[i] = {
  someProp: 'num: #' + i,
  someOtherProp: i,
  someMethod: function (input) {
    return input * i;
  }
};

// Displays: 80 80
console.log(myObjects);
console.log(myObjects[3].someMethod(8), myObjects[7].someMethod(8));

In order to fix someMethod(), we replace i closure w/ this.someOtherProp:

var NUM = 10,
    myObjects = Array(NUM);

for (var i = 0; i != NUM; ++i)  myObjects[i] = {
  someProp: 'num: #' + i,
  someOtherProp: i,
  someMethod: function (input) {
    return input * this.someOtherProp;
  }
};

// Displays: 24 56
console.log(myObjects);
console.log(myObjects[3].someMethod(8), myObjects[7].someMethod(8));

blindfish

IMO, Java has the easiest & cleanest way of doing OOP!

I highlighted the key point in the above statement. In terms of classical OOP, with inheritance and all the trimmings - which I think is the perspective you're coming from - then I'd agree that Java is a better option. But that's not the definition of OOP; it's just one very popular implementation. For once I'm being the pedant :P

In the context of JS there are people who are arguing against using classical structures and relying on inheritance.

So; whether Java or JS based Processing is the most appropriate teaching tool depends on what your students hope to move on to. In terms of those using Processing for art, visualisation etc. then Java Processing is likely to be a better option in terms of raw performance; but if you want to put stuff online then p5.js will eventually - i.e. once it's matured and supports webGL) be a better option.

blindfish

@GoToLoop: good catch. That'll teach me for writing demo code in too much of a hurry and not actually testing it :/

GoToLoop

There's another problem in your approach, @blindfish!
But this time is structural and it's the same issue affecting "Revealing Module Pattern" too:

For each myObjects instance, both the property someMethod and its function are unnecessarily created! b-(

Methods are not state in a class instance. Therefore only 1 copy of it is actually necessary!
So they need to go to the static part of the class. And in JS that place is called: prototype.

However, the way your loop "constructor" works, it's awkward to include a prototype there.
Closer cleanest solution we can get is to create "method" someMethod() outside of that loop.

We still get an unneeded someMethod individual property for each instance.
But at least, they all point to the same shared someMethod() function: :ar!

var NUM = 10,
    myObjects = Array(NUM);

function someMethod(input) {
  return input * this.someOtherProp;
}

for (var i = 0; i != NUM; ++i)  myObjects[i] = {
  someProp: 'num: #' + i,
  someOtherProp: i,
  someMethod: someMethod
};

console.log(myObjects);
console.log(myObjects[3].someMethod(8), myObjects[7].someMethod(8));

_vk

I'm very interested in this.

I think being easy to online deploy is a BIG feature, that java's Processing kind of lost together with Applet's restrictions.

This is why I'm exploring the javaScript world, and using p5.js.

For me - I'm a self learner, started in programming with Processing (I made some attempts on Java, but always trough Processing) - it's being hard to make the move to js. Specially regarding objects and closures. My feeling is that I should think different instead of trying to "translate" Java structure to js. But I don't know how I'm supposed to think...

There are several articles about several different ways of dealing with OOP in js. Module, Revealing Module, Singleton, Literal, Constructors, prototype inheritance... There are so many options, that my first problem is decide which one should I start with. I noticed the greater flexibility in js but I don't know if I liked it :) probably because my lack of formal programming knowledge. But functions as first class citizens are amazing in js. Very powerful. I liked that.

My first attempt is to create a Image object with bound position data and a lifetime. This is supposed to be instantiated and "kill" itself (or set a flag dead) after some time. How would you guys do that?

this is an untested kind of pseudo code for such an object in java:

class AImage{
    PVector pos;
    int bornTime;
    int lifeTime = 5000;
    PImage img;
    boolean live;

    AImage(PImage _img){
        img = _img;
        bornTime = millis();
        live = true;
        }

    void display(){
        update();
        if(live){
            image(img, pos.x, pos.x);
            }
         }
    void update(){
        if(millis() - bornTme > lifeTime){
            live = false;
            }
        }
    }

GoToLoop

Here are 3 styles for OOP. Compare them and decide which 1 has better chances for the audience target of Processing. That is, artists and non-programmers in general:

A) Raw object instantiation in a loop:

var NUM = 10,
    myObjects = Array(NUM);

function someMethod(input) {
  return input * this.someOtherProp;
}

for (var i = 0; i != NUM; ++i)  myObjects[i] = {
  someProp: 'num: #' + i,
  someOtherProp: i,
  someMethod: someMethod
};

console.log(myObjects);
console.log(myObjects[3].someMethod(8), myObjects[7].someMethod(8));

B) Most popular & memory efficient prototype pattern:

function MyObject(i) {
  this.someProp = "num: #" + i;
  this.someOtherProp = i;
}

MyObject.prototype.someMethod = function (input) {
  return input * this.someOtherProp;
};

var NUM = 10,
    myObjects = Array(NUM);

for (var i = 0; i != NUM; ++i)  myObjects[i] = new MyObject(i);
console.log(myObjects[3].someMethod(8), myObjects[7].someMethod(8));

C) And Java/JS cross-mode w/ more expressive classic class OOP:

static class MyObject {
  String someProp;
  int someOtherProp;

  MyObject(int i) {
    someProp = "num: #" + i;
    someOtherProp = i;
  }

  int someMethod(int input) {
    return input * someOtherProp;
  }
}

static final int NUM = 10;
final MyObject[] myObjects = new MyObject[NUM];

void setup() {
  for (int i = 0; i != NUM; ++i)  myObjects[i] = new MyObject(i);
  println(myObjects[3].someMethod(8), myObjects[7].someMethod(8));
  exit();
}

GoToLoop

My feeling is that I should think different instead of trying to "translate" Java structure to JS.

Good news for ya: W/ ECMA 6, JS is almost Java. We can keep using our Java knowledge in JS! <:-P
Don't believe me? See for yourself: https://developer.Mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes

Of course support is generally lacking. It's gonna take some more time for all main browsers to get full ECMA 6 parity. Nonetheless, we can use other JS transpilers for Java-style classes in JS right now.

For Processing, there's CoffeeScript Mode which got class support.
We can play w/ CS syntax below. Click at "Try CoffeeScript":
http://CoffeeScript.org/

But my most favorite is TypeScript. We can play w/ it here:
http://www.TypeScriptLang.org/Playground

In order to write in TS I'm using Atom IDE w/ Atom-TypeScript package:
https://Atom.io/packages/atom-typescript

But there are many more IDEs for TS. Including MS' Visual Studio as well:
https://en.Wikipedia.org/wiki/Microsoft_Visual_Studio

GoToLoop

There are several articles about several different ways of dealing with OOP in JS...
There are so many options, that my first problem is decide which one should I start with.

For general use, we can't go wrong about sticking w/ prototype pattern only!
AFAIK, all JS transpilers rely on prototype pattern for code emit.
Even the new JS class keyword structure is sugar syntax for prototype pattern too! :-bd

_vk

Hey @GoToLoop. Thanks! That's exactly the kind of info I was looking for. I'll dig into this ASAP. cheers

blindfish

@GoToLoop: you've taken my example a little too literally. It was just meant as an example of the flexibility of JS objects rather than as an example of good practice ;)

Would love to carry on this discussion but I'm off on holiday!

_vk

Well... when you came back we will be glad to hear your thoughts

carcaju

Thanks everyone for the input! This answered my question. I'll learn javascript. P5.js looks very promising and javascript is more directly useful in my field (graphic design), because of the web (obviously) but also because of the automation of Adobe's softwares. Thanks again for the input.

KevinWorkman

All of the discussions about whether JavaScript or Java are better for beginners is a bit irrelevant, imho.

The nice thing about core Processing is that it doesn't restrict you to any particular deployment. If you don't use any Java libraries, you can deploy as JavaScript, as an executable, or even as an Android application.

That makes Processing perfect for beginners, because then when you're ready to "graduate", you can choose anything: you can transition into "pure Java" or "pure Processing" or Android, and the syntax you've learned will apply to any of them.

So while web deployment is certainly the way to go for client-side applications, people who eventually want to get into server-side programming can also start in core Processing, then "graudate" to Java and then into server-side programming. People who want to get into web development can start in core Processing and then "graduate" to p5.js and then into html/css and other JavaScript libraries.

Saying that p5.js is the replacement of Processing is missing the point a bit, I think. It's not the replacement, it's just one "avenue of graduation" that people who learn core Processing can take.

Chrisir

processing (and openprocessing) has to cope with the death of PApplet

I wonder about the libraries though. Can't they be cross-compiled or rewritten to work with p5.js?

It's a huge loss otherwise.

Or can the source of the libs be embedded?

I think the lib issue really has to be adressed.

GoToLoop

• Processing devs killed Processing's flexible deployment by giving up & removing "JavaScript Mode" and its Processing.js (pjs) framework from the "official" mode list! >:P
• We can't write code w/ "Java Mode" and deploy it as JS for the web anymore! b-(
• To make matters worse, they've also removed writing pure JS syntax w/ pjs since v1.4.9! X(
• Now they expect us to learn JavaScript in order to use p5.js framework.
• However, Processing's main target audience's gonna have more difficulty in learning OOP for JS; since JS ECMA 5 classes aren't as encapsulated nor expressive as Java's! :-\"
• I really wished that we'd get cross-mode libs for Java & JS modes though. Alas... 8-|

KevinWorkman

I wonder about the libraries though. Can't they be cross-compiled or rewritten to work with p5.js?

Some can. Libraries that just use things like collections and whatnot are probably pretty easy to port over. See also: GWT.

But some can't. Libraries that require access to the hard drive, for example, simply cannot be implemented in JavaScript.

Or can the source of the libs be embedded?

This doesn't really make sense, since you aren't running any Java code when you deploy as JavaScript. The library would either have to be rewritten for JavaScript or possibly "transpiled" using an approach like GWT.

Processing devs killed Processing's flexible deployment by giving up & removing "JavaScript Mode" and its Processing.js (pjs) framework from the "official" mode list!

When did they do this? I still see a JavaScript mode in my IDE.

We can't write code w/ "Java Mode" and deploy it as JS for the web anymore!

I can?

Now they expect us to learn JavaScript in order to use p5.js framework.

p5.js was always designed as a JavaScript-first implementation. It gives you more control over the web page in which you reside, etc. I think it's a reasonable "graduation option" from plain-ol' Processing.

However, Processing's main target audience's gonna have more difficulty in learning OOP for JS; since JS ECMA 5 classes aren't as encapsulated nor expressive as Java's!

I think that's at best subjective, but mostly a moot point: if you don't like JavaScript syntax, stick with Processing syntax. No need to choose either Java or JavaScript until you better understand the difference.