http://www.toxi.co.uk/blog/2006/01/note-this-article-is-using.htm

Here's an initial comment:
Processing was never intended as the future of programming or an ideal computational art/design environment. It was built as a foundation from which to build the future. It slightly extends known paradigms. Maybe the future is now. The source is there, it's a great base representing four years of intense work. We put alot of work into getting the code open (over a year of paperwork with MIT) and in building the dev site for easy access. I'd love to see people do something more with it.

some comments:

re: "I also think it encouraged a slightly superficial view of computational design by quickly gaining cult status amongst people never been exposed to programming before. I think it's dangerous and a sign of crisis if every recycled L-System, Neural Network, Wolfram automata or webcam tracking experiment automatically is considered art (by their authors), simply because it's been "(Re)Built with Processing"

if this is true, it's awfully disappointing. the *opposite* of this situation was in fact the intent. the idea being that if we make the "easy" things easy like they should be, then some of the low hanging fruit gets cleared out, and people can be more critical about what it takes to actually make things.

re: "the importance of clean code designs and intelligent data structures or even community interest in further researching and experimenting with those artistically."

i'm not particularly sure whether i agree with this. at this moment, i don't think i agree with it much at all, as i don't think that code being proper *really* has a direct effect on the outcome. if your studio is a mess does that mean what comes out of it isn't proper? or if your brushwork sucks does your painting inherently suck too? the software engineering in some of my best work is really bad, whereas in some of my more boring stuff i got it "right". that's not exclusive, i just don't think there's a correlation.

good, clean code is a virtue and good fundamentals help give you a better foundation for growth. it's something that should be taught so that people know what they're doing, but i think there's a mix here of what p5 users are doing in practice, versus what's in the environment. is it a criticism of processing, or the people using it?

though the part i do agree with is the idea of trying to dig deeper. if the simplicity means that people don't dig deeper, then that's also sad. but i think that's more to do with laziness than an inherent problem in the language. it's like blaming the television for making you lazy. blame anything but the person.

re: "In terms of pure expressiveness of ideas, concepts and thought processes as code, Processing is inferior to straight Java or dynamically typed languages like JavaScript or Ruby. Its ease of use has been gained by sacrifying scalability."

this is a weird straw man.. this is a bit like saying that pseudocode is more expressive than c++. i think expressiveness is also tied to the other factors we're taking into account:
http://processing.org/faq/index.html#whyjava
if i can't develop my own work in javascript or ruby (and i cannot), then that's not really expressive, is it? i guess my point is that i don't think it's particularly relevant to look at syntax in a vacuum. we'd love to use something like python or ruby as the syntax, but since that doesn't balance with the other factors, we're not doing it. i mean really, is javascript gonna address the other issue with regards to proper oo programming? js is *far* worse about encouraging bad coding style.

i also don't understand where we're inferior to straight java. it *is* java, and you can just write java code in the environment "public class blah extends PApplet" and you can go object crazy all you want. or you can use core.jar within eclipse (a PApplet is just a Component, the same as you'd make any other component in java..) but toxi knows these things so i'm not sure what he's getting at.

bottom line, i think i agree with where toxi is going, but i don't think the individual arguments are right, and i don't like how the issues and responsibilities are mushed together.

more fundamentally, i think we can critique processing till we're all blue (doubt not that i can write a much longer rant about it than toxi), but i'd rather that the energy be put into improving things and actually helping out. i think i could write another more complete argument out of what toxi seems to be getting at, but i think you'd rather have me get opengl support working better and bring back P2D. if you have complaints, help us build the thing (and thankfully, toxi has, so this isn't directed to him).

but i think there's something that's missed with the project, where this is a *community* thing.. casey and i put it out there, made all the code available, and our time is completely volunteer. let's get more people off their behinds and helping us improve things rather than stroking our chins about how things aren't being done right or thinking up pet features. sometimes i think people miss the difference between the fact that they downloaded this thing for free rather than paid hundreds of dollars for the privilege to use it. i don't know if that's because of the prevalence of free software (firefox, ie, gmail, etc) on the net, or if the age group for processing doesn't pay for their macrodobe stuff anyway (school-purchased or downloaded via bt), but i think we're really missing out.

i think there are positive developments on the library front (as toxi notes), and that's why we've placed such an emphasis on libraries, but there's still a ways to go.

I pretty much agree with fry's points, and I would have pulled the same quotes out to discuss, especially the stuff about the expressiveness of Java vs Processing.  I'd be interested in some clarification of that issue, because I don't get the difference - I can write Processing in a totally Java way if I want to, but I don't because the Processing way is Java enough with out being too much Java.  IYSWIM

That said, I've talked before about how 'Processing is an approach' (toxi's words, but I've here which is also relevant to toxi's post.  I'd be interested in talking more about that, and why/if it's happened, and what will happen next.

(Oh, and st33d - come to dorkbot!  It's totally an appropriate format for your work.  Sure, you need to be ready to defend things if you truly believe they are art, but then what artist isn't)

Also, we can't have this discussion without talking about the visual programming environments: max, pd, vvvv. They are used as much or more by artists for writing software and creating visual works. It's my belief they are closer in spirit to Processing and its goals than cs derived scripting languages: python, ruby.

ben said>>>>>>>>>>>
quote toxi: "In terms of pure expressiveness of ideas, concepts and thought processes as code, Processing is inferior to straight Java or dynamically typed languages like JavaScript or Ruby. Its ease of use has been gained by sacrifying scalability."

this is a weird straw man.. this is a bit like saying that pseudocode is more expressive than c++. i think expressiveness is also tied to the other factors we're taking into account:
http://processing.org/faq/index.html#whyjava
if i can't develop my own work in javascript or ruby (and i cannot), then that's not really expressive, is it? i guess my point is that i don't think it's particularly relevant to look at syntax in a vacuum.
<<<<<<<<<<<<<<

Okay, point taken and I shall downgrade my critique I guess my point was that since Processing doesn't make big use of OOP (which I'm fully aware of can't be seen that black & white), a dynamically typed language like JS could have been beneficial in other aspects of the syntax and would especially have helped those users coming to Processing from Flash. It also would have helped with other things like the ongoing discussion about live coding etc. Obviously I wasn't seeing those aspects in the full perspective last night and then there's also the performance factor to be considered... so apologies!

But again, please don't grow any grey hair over it. The main intent of my rant was to kick off some discussion about those parts of Processing I think need addressing soon for the greater good and I believe a lot of those semi-issues can be remedied with a solid library collection.

ben said>>>>>>>>>>>
i also don't understand where we're inferior to straight java. it *is* java, and you can just write java code in the environment "public class blah extends PApplet" and you can go object crazy all you want. or you can use core.jar within eclipse (a PApplet is just a Component, the same as you'd make any other component in java..) but toxi knows these things so i'm not sure what he's getting at.
<<<<<<<<<<<<<<<<<<

I was getting at that precise fact that much of Processing's handy functionality is strictly limited to being an applet. For example, I'd love that:

* libraries don't require a PApplet, but just implement an interface (and in turn only require an interface as parent) so they can be reused anywhere

* all the clever IO, colour and matrix stuff would be more modular *internally*

Much of those things are already there and could appear to stay exactly the same to the normal Processing user. Yet this functionality would it be incredibly useful to have on their own for advanced users trying to use the library in other (non-processing) projects. You see what i mean?

ben said>>>>>>>>>>>
bottom line, i think i agree with where toxi is going, but i don't think the individual arguments are right, and i don't like how the issues and responsibilities are mushed together.
<<<<<<<<<<<<<<<<<<

I agree that parts of my original post were slightly muddled together, apologies. I also hope that this follow up clarifies things!

st33d wrote on Jan 19^th, 2006, 5:56pm:

St33d, honest guv, your post made me laugh out loud since I didn't realize someone actually had experimented with *all* of those things I mentioned (L-shaped neural wolfram network tracking automata systems)... rest assured my choice of phrases was compiled within a flash whilst being offline, baby rocking on one arm and without anyone particular in mind or to check up on.

I have no problem with artistic experimentation in any shape of form. I've been spending most of my spare time since being 13 doing exactly that... Sometimes I do take issues with wannabes, claiming expertise or authority without available backup...

Queue Processing Anonymous meeting:

"Hello, my name is toxi, sometimes I take things too seriously..."

Interesting topic. Congratulations to toxi for being brave enough to state his opinions, and the same to Ben and Casey for staying calm and addressing it seriously. I think this debate is a sign of health.

I remember sitting in a cafe in Barcelona two years ago, discussing a very similiar issue with Toxi (sometimes known as Karsten). Karsten was lamenting the fact that Processing syntax does not use OOP. I countered that teaching OOP was hardly the point of Processing. The idea as I saw it was to get people involved with code quickly, before they realize that it's "too difficult" and freeze up. (It's a situation that should be familiar to anyone who has taught a workshop that involved code.)

I like to think of Processing as being a bit like BASIC, or maybe better, Turbo Pascal. On the one hand it's plain, easy procedural programming with plenty of nice features and safeguards to keep you from hitting your head. On the other hand, it has some powerful infrastructure that would take beginners years to figure out on their own.

To be direct: I disagree with Karsten. I don't think it should be the responsibility of the tool to teach good coding practices. Good code does not equal creativity or quality of content. Like Ben said, some of my best work looks awful on the inside. But more importantly, forcing a rigid code structure into the language would scare off most of the people who need Processing the most.

I also disagree with the notion that Processing users should become software designers by necessity. It all depends on what they intend to do with it. If they want to be designers or work in teams producing a maintainable code base, they would definitely need some software design skills. The same is not true if they just want to use Processing as an intuitive tool for sketching in code.

Quote:

While working on Generator.x I wrote lots of marketing speak. I blogged, I wrote press releases and introductory texts full of terms like "computational strategies". I was trying to explain to designers, artists and regular people why generative art and design might be relevant to their experience of the world, and why they should go look at it in a gallery. I might wince at reading some of those texts after the fact, but the inadequacy of the terminology does not mean that the message isn't valid.

The current Processing fad is a nod to the success of the project, combined with some good timing in terms of social trends. The script kids have picked up Processing, that's not such a bad thing. With much more work being created, it stands to reason that much more bad work will be created too. But there will be the occasional gem that makes it all worthwhile.

To create a good work of art or a piece of clever design in Processing is difficult. Not because the tool is in the way, but because creation is always difficult to some extent (even when you get lucky). The Processing exhibition page is proof positive that it's possible to create excellent work in Processing. And some of it was created by people who didn't know code before.

On a practical level

I predict two paths for Processing (actually, I'm probably just describing what is already the case):

1. The continued use of the Processing tool as an environment for beginners. That means continued use of a procedural API, convenience methods and a simplified execution structure. OOP is in the syntax, but not enforced.

2. The growing use of Processing as an infrastructure, a set of libraries to base work around and plug libraries into. Most advanced coders will want to work outside the Processing GUI. That's already possible, but it has some quirks that will hopefully be smoothed out in the future. Essentially, this would require a smooth transition from how the class hierarchies function when used within the GUI and when used as pure Java. If Processing can make that transition, it will prove its usefulness both as a tool for beginners and as a production environment for professional work.

I am very excited by the libraries people have started writing. I think it can become a great source of pre-written code that will allow users to focus on creating applications rather than infrastructure. I only hope that library writers will keep their work Open Source. Maybe it could be a requirement that the source be provided under a GPL license before new libraries are linked from the Processing site.

A suggestion:

I recently emailed Casey to ask if a Processing coder workcamp had been considered, i.e. not a workshop but a DIY camp where people would meet to tinker with the Processing core, write new libraries etc. He replied that such an idea would be excellent once 1.0 is out. I look forward to that. For now, I've downloaded the source, retro-hacked some quirks and keep producing work with Processing.

I hope you will too.

where to start? let's start with the funniest, who is an artist? The definition on wikipedia, if I remember well, says something about an outstanding ability on doing stuff, so related to the tecnique, and I think it is a good definition that avoids to enter in very subjective fields. I really would like to give my personal opinion about it but then a never-ending flame could start.

Although some very subjective thoghts from all, I see clearly some objective issues that should be considered for the good of p5. It's clear that p5 has born to help easy sketching and learning, and I've difficult to think how it could have done better than how it did. P5 has become very popular and recognized all over the world. So many compliments and a lot of respect to Casey & Ben's efforts. But reading Casey and Ben's comments I see that something is missing. Both seem to talk about a lack in the community, in terms of number and effort. Well, if I compare p5 with Flash (that I know much better than MaxMSP and Co., but probably is not the best example) is clear where the difference is. First of all is that there is a huge business behind Flash development, that means people use it for living, a part some artist and teacher, how many can say the same about p5?

Then Ben would like to see more effort from developers on building Libraries, highlighting his effort and the free availability of p5. He is damn right, but I see then some conflicts considering the first aim of p5. Here Toxi is right. I discussed already with him the issue, and he showed me as example the Flash community compared to other more complex technologies, like Java and so on. The typical Flash user is (or maybe was) the one that looks for scripts to re-use and so he doesn't care at all about the community etc, is a kind of leecher. He never had to do some effort, he finds everything ready to use, so he gets unavoidably lazy. Now about Flash the things are changing and there is a respectable opensource community that builds very useful tools that are making Adobe Managers' asses laughing since the platform is becoming a standard for important web applications. This is happening because these very experienced developers are still using the platform in a hardcore way to get by. Toxi worries are right, because if to extending the platform are needed very experienced developers, you should provide them the best tool to continue working on their stuff, and so they will have all the interest on extending it. But if they have to move away for the difficulty on using it in their projects you can't count so much on them, and so it's a big issue.

Although helping beginners was the best move to promote it, probably is better to think how to keep the focus on the seniors. I can't say much about how, but if Toxi's suggestions are right, I think someone should really think about it.