I remember reading something recently by one of the Processing higher-ups, saying that eventually Processing would most likely leave Java behind and switch over to Python as its primary language. Presumably this would mean Java would be relegated to being an add-on mode in the IDE.
I didn’t see another topic about this, so I figured I’d create one, basically a general conversation thread about the subject. Things like:
What do you guys think about this eventual switch? Pros and cons? For it or against it?
Any estimates on when this switch would happen? I remember hearing that the Processing project is kinda low on developers lately, so this probably wouldn’t happen for a long while.
Should people learning Processing these days focus on the Processing.py mode, or it’s still too early to tell how this is all going to shake out?
I can’t see that change ever happening, personally. Python mode currently is based on Python running on the JVM anyway, and stuck with legacy Python 2 still AFAIK. To move to native Python you’d have to rewrite everything, including every library, demolish the ecosystem, and end up with a slower system. Not to mention one written in a godawful programming language!
Now, Processing modes using Graal for polyglot (multi-language) support might be more interesting, but that’s not moving away from Java.
“… move to JDK 11 and support for new Java language features. The changes should be transparent to most users …”
Python Mode will still work fine in Processing 4 (Jython supports Java 11). But there are proposals to add Python 3 support using a Jython alternative. I suggest you use Python Mode if your prefer Python syntax.
Yup, I saw that Processing 4 section on P’s Github right after posting this topic.
Re: preferring Python: it’s not a question of that, it’s that I’d seen someone from Processing saying the project would probably be switched over to Python for v4. Don’t remember where that was, I wish I did.
I would personally love to see a full Python version of Processing. Truth be told, I even happen to secretly hope to win the lottery just to spend all the money on developing such a project.
Why ? Because I think Python beautifully matches the ethos of Processing: accessible and easy to learn, flexible and versatile, educational-oriented and prototyping-friendly. It seems to me that the two are conceptually closely tied to one another.
From my daily coding experience in Python mode I would say that this is also true on a practical level:
the high-level nature of both worlds makes that you end-up with an exceptionally “performative” language (it says what it does): draw(), circle(), add()… in Processing; sort(), enumerate(), sum()… in Python. One echoing the other almost naturally.
this performative aspect coupled with Python minimalist syntax can allow for a higher degree of clarity, both visually and intellectually speaking. As rightfully put by WakeMeAtThree in this other thread, clear and shorter code makes it very often easy to keep track of the logical process being built while enabling to focus on the higher level aspects of a visual idea.
these characteristics are of paramount importance for the Processing community because it means that most people would be given the opportunity to sketch and prototype much faster. Not only speed is a characteristic of the very definition of “sketching” (Processing is referred to as a software “sketchbook” after all) but it is also a crucial feature in any creative process: more iterations can lead to new ideas, faster results help having a more fluid and seamless experience (keeping the “flow”), quicker trial and error, easier transitioning between projects…etc.
It is also my opinion that Python would not only improve the sketching process but also broaden the spectrum of possibilities in terms of creation.
sure it would break compatibility with current Java-based libraries but users would then get access to the huge ecosystem of Python libraries instead. Top grade modules in any field of choice: computer-vision, vector math, computational geometry, combinatorics…you name it.
Python has undoubtedly the best AI-related frameworks. Given the recent impact of deep learning techniques on creative methodologies I can only imagine how beneficial this would be for creative coders, computational artists, designers/architects…etc
That said, I have too much respect for the work of Casey Reas and Ben Fry as well as for the whole community of users and developers, who for the vast majority (90%+) has been relying on original Java Processing for almost two decades, to call for a “switch”. It would be too radical.
That is why the most reasonable initiatives that have been made so far do not intent to replace Java but to concurrently provide a “true” Python alternative. The most promising in my opinion: Python 3 Processing on JVM through JEP (would support both eco-systems). But it will probably be a long time before it is released and fully operational.
It’s utter FUD though! I don’t know anyone who worked at Sun on Java things who even knew what Processing was. The vast majority of Java people I speak to have never heard of Processing. The number of users Processing brings in is minimal in comparison to the wider Java ecosystem. And as much as I dislike a lot about Oracle, the changes brought in over the last couple of years and the commitment to open-sourcing everything have been a major positive.
TL;DR - I long ago (2006) took to ignoring what the original Processing devs have to say about Java, it’s usually nonsense, and they still haven’t moved away from it 14 years later!
I’d love to switch over to native python processing. Python mode is too restrictive. Lure of the Python for me comes from libraries like numpy or keras and they don’t run in Python mode. But only few days ago I learned about p5 (https://p5.readthedocs.io/en/latest/ or https://pypi.org/project/p5/). A native Python port of processing API. I’m looking forward to trying it out.
I meant @solub’s post was good reading, not the P devs’ Github post.
Thinking about it more, there’s definitely something to the idea that a more easy-to-learn and easy-to-use language is more conducive to rapid prototyping in Processing. I know basic Python and basic JS, and I know a little bit of Java. In my experience, armed with the above, it’s way easier to make complex stuff in Processing using either basic Python or JS, because the languages are easier to riff with. Compare that to Java, where you have to know a lot more of the underpinnings and inner workings of the language to be able to improvise.
Example: I ran into a situation yesterday where I was porting some Processing.py code to Processing Java. I had Function A, whose params could be either single numbers or arrays, depending on what was passed to it. Inside Function A was a nested definition for Function B, which was passed as an argument to Function C. Those were all trivial to implement in basic Python or JS, but when I tried to translate to Java, and I Googled how to handle each thing, the answers weren’t straightforward at all, and I realized I basically need to find a big fat Java book and dig into learning much more of the language and philosophy etc. Which I’m now debating whether to bother with at all, vs just sticking with Python and JS.
There’s nothing inherently wrong with a language being more complex than another one. But in the case of the default language for a tool that’s meant to make art vs coding pacemakers…
Personally I find ruby to be an easy to use and easy to learn language (but I might be biased). Being based on JRuby (cf jython) it is relatively up to date with ruby (currently ruby 2.5 soon to be ruby 2.6 compatible). I have tried processing.py but for me unless numpy is available there is no compelling reason to prefer python. I also tried pyprocessing but that was somewhat under-performant albeit numpy was available. Processing in ruby on the RaspberryPI is available as PiCrate for most others there’s a choice between JRubyArt and propane.
Well, as someone who spends lots of time riffing in Java in front of people, I’m not sure I agree with you! Actually, being serious, I don’t think the choice of language is that important - definitely not compared to simple APIs and hiding boilerplate. Certainly from teaching beginners I’ve found that language is almost irrelevant in comparison.
Processing made a great job there, building a beginner friendly API, and hiding all the complex stuff of the wrapping class, imports, etc. Where they went wrong in my opinion was changing the syntax of the language. That has made things far too complex, and kept Processing from keeping up-to-date with Java’s evolution - your example would be much easier in idiomatic Java 8+ or 11+.
My own reason for working with Java is a desire to work with a more unified tech stack - no fast native / slow scripting distinction. Now Graal might change that! The future choice for Processing and Python is probably GitHub - oracle/graalpython: A Python 3 implementation built on GraalVM
Not sure I agree with much of that if you expand away from Processing’s libraries and consider the wider Java ecosystem, but the key thing with Graal would be, why choose? Let’s have it all!
Python Mode is fulla hacks in order to integrate w/ Processing’s Java library and its global mode style.
I dunno much of the details but the whole PApplet instance is available both on Python’s global namespace and as a variable named this.
And when using Nashorn I was able to make the whole PApplet instance transparently available on JS’ global namespace as well using an exclusive method called Object.bindProperties().
So I believe PythonGraal should have a similar hack trick too.
I’m a big proponent of having the sketchbook API available in several mainstream languages.
One of the high school courses I teach, AP CS A, is exclusively Java. My students last year learned JavaScript in AP CSP, so we started off with a few lessons in p5.js before switching to Processing.
The transition went pretty smoothly and they had fun with Processing all year, so I intend to take a similar approach starting next week. The only hitch is that this year’s crew learned Python in AP CSP and we’re starting virtual. All work needs to be web-based, so I have pyp5js and Processing.js running on repl.it. It’s a bit of a hack but I’m rolling with it.
Graal python is probably a long way further back than ruby (aka truffle-ruby), and in real world situations may well under-perform (like does exceptionally well in performance tests, but less so in real world). Then there’s the lag time (or warm up time). Charles Nutter co-developer of JRuby for years (originally at Sun) probably knows as much as anyone about JVM optimizations collaborated with truffle-ruby team.
Afaik Processing.py was always intended as a teaching tool; its isolation from the Python ecosystem ensured that. But I think it’s a great one for people who know Java and want to learn Python, or at least that’s how it worked for me! (Wouldn’t a pure Processing Python mode need to come up with its own OpenGL implementation comparable to current Processing Java’s–which is really quite performant these days for GPU-bound stuff?)
That said I think bringing the Processing design philosophy to more places, without necessarily porting the entire environment, is a great idea. Just recently I made a small wrapper class to “Processing-ize” the Python Pillow 2D graphics library:
@n1ckfg You can read the creators (Jonathan Feinberg) own words here. It seems like Ben Fry and Casey Reas were both keen from the outset. Although I rather think he created it because he could like Jeremy Ashkenas who created ruby-processing.
Yes, although I’m not sure how much it’s “performant”! There are certainly better performing drawing / rendering libraries built on top of JOGL and LWJGL on the JVM - there could potentially be a performance benefit to building a Processing API compatible wrapper on top of one of them. Likewise, for a pure Python mode I would assume something similar to your wrapper there - working with a higher level existing library rather than the raw Python OpenGL bindings.
Yes, maybe, but there’s a whole load of expertise already in the Graal team too, including a number of ex-Sun people. And I wouldn’t discount the expertise of Chris Seaton, who started the Truffle Ruby project, either. I guess Ruby is somewhat ahead because of being used to drive this element of the development. An interesting thing is that Truffle is also used to run LLVM bit code - with Graal Python, the native libraries can (or will?) be running on the JVM, with fairly minimal overhead.
I must confess I have a bit of a bias since Python is my fav language ever but god… I would love for this to happen. Python’s Data Science ecosystem is really active and interesting, and with Processing there, there would be a great back and forth for:
creative+interactive data visualizations and sonorizations
data-related creative projects
almost every web service has a python api so this would open a whole new world of exploration and gui design with Processing (which is really needed in python in my opinion)
It would also integrate so easily with all the multiple backend frameworks and libraries available, allowing processing sketches to go beyond and become more complex applications.
just
…imagine using nltk and spacy to make text art with processing
…imagine using processing for real time dall-e (image generation model) collage making
Actually, being serious, I don’t think the choice of language is that important - definitely not compared to simple APIs and hiding boilerplate. Certainly from teaching beginners I’ve found that language is almost irrelevant in comparison.
