toxi.in.process

Friday, January 20, 2006

Dissecting the discourse

As a follow up to yesterday's stormy discussions on the Processing discourse, I have to say I've been quite perplexed by the impact of my last post and the intensity of the discussion started. It's true I got things mushed up got carried away with some of my subjective views, yet I think Processing can't be talked about merely as tool. We all know that and I take it the resulting intensity is a sign we all feel Processing has become a very important part of our (at least) creative lives...

The 2 main points of criticism of my raised issues were:

"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"..."


For some reason (Sorry, I can't quite isolate it) this has been interpreted as me preaching elitism or belittling beginners which is absolutely not the case. As I mentioned previously, my entire knowledge of programming is based on years of playful (often seemingly meaningless) experimentation. The above statement was more concerned with some of the emerging ego issues amongst the userbase. I think I also finally realised (not for the 1st time) that my concept of an artist is strangely incompatible with that of most others and my remarks where caused by this.

FWIW I consider an artist to be a seeker of knowledge, understanding, a master of craft and resulting insights into the very nature of what we call the universe. This is a process which doesn't require nor has it place for bullshit. Life's too short for such things and I can't grasp why people do it instead of trying harder and raising their own standards a little. My mummy told me, be quiet if you don't have something useful to say.

Maybe I should have taken this partial advice yesterday, yet I think the gist of my argument is valid somewhat, but should have been expressed differently. Don't be hurt!

"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."


Now this really was a tricky one and definitely should have been expounded by me a bit deeper. What constitutes Java is not just its overblown and almost uncomprehensible standard library, it also is just a language with very nice features. Try to consider them on their own, the statement above was referrig purely to that. The same goes for the other two languages mentioned. I know exactly where most of you were coming from with your criticism of this above statement: Getting simple things done in straight Java can be cumbersome. On the other hand the language has a handful of simple mechanisms to allow us to construct increasingly complex systems of code without having to constantly reinvent the wheel. My question to that was why does "Processing" not make use of those handy features? - and here it's not really the tool I am talking about but the way those things are totally excluded from the processing reference. If people (beginners) are never made aware that things exists how can they learn about it (Google doesn't count here!)? I also think the teachers amongst us should maybe give students a little bit more credit in grasping OOP concepts?

Another weird question, but it would be ++interesting to know: Has it maybe to do with the fact that most of you (teachers) have never been taught OOP/design patterns yourself?

A while ago I decided for myself that everything (code related) I do should be specialized and yet generic enough to be reusable in future projects, but alas I cannot do that fully with Processing in its current form.

Re: JavaScript and other dynamic languages. I think Ben's argument of saying he can't produce his work with JS is a slight paradox. If he would have chosen JS as base language for his project (with an underlying layer in C, e.g. by using SpiderMonkey) - he maybe would be able by now to do so. IMHO it's a little bit misconstrued, but I won't hit on it any further, since as he rightfully pointed out, there're much more important things to be solved at current.

Reason why I mentioned JS (and above all Ruby) as alternative was because those dynamically typed languages allow for very powerful coding idioms which one can only dream of in Java. But of course these again are very advanced topics and as such are only interesting to that part of our community. This was one of the mushed points of my last post.

Keeping on talking about object orientation just a bit longer, I find it very interesting Casey mentioning MAX, PD and VVVV as tools being almost purely targeted at the artist community. All of those tools are not dealing with text based programming, yet are deeply rooted in an object oriented approach. In fact their entire essence is based on an huge number of tiny encapsulated objects, fulfilling very specialized tasks and are loosely coupled. In order to create a "sketch" people choose them like building blocks and connect them via "wires" to create a directed process graph/execution flow.

So I think some take away points from that are:
  • Objects are not alien concepts to programming newbies - I think it's all down to teaching styles. The visual programming metaphor obviously helps beginners on those platforms more since with the textual approach of Processing the connecting wires are initially invisible and have to be mapped out and "stored" in the students mind.

  • Secondly, the highly modular architecture of those systems has contributed to their incredible success (IIRC, MAX has been on the market for +15 years). Also because of their fine grained modules (which have to be written in C++, lo and behold...) beginners can start out writing just tiny atoms of code instead of thinking on library scale. Because those tools enforce by their nature all objects/patches to be encapsulated, every effort spent on writing those extra bits of code is well spent in the knowledge it can be easily reused, potentially in infinite ways. This behaviour is not the case with Processing.


To back up some of the above, here're some search results for the word "object" for the various community websites:

PureData ~35200 results
VVVV ~2400
Processing 442 results

I couldn't find a decent start site for MAX, but there's maxobjects.com which is hosting roughly 2900 MAX/MSP objects of various complexity.

Do you get my drift?!