Installation art serves as a kind of performance space where the specators become participants. You are right: it is not great art, awe inspiring art, or even memorable art. Such art does, however, provide interesting experiences and interesting ideas. If you approach it with a relaxed attitude, it can be an interesting experience.

But your are right when you refrain from slamming the whole "epater le bourgeois" attitude. That is pretty much exhausted. But John Cage or Bill Viola and others aren't really interested in the exhausted Dadaist gesture of confronting the spectator. Their art is meditative, phenomenological -- it's something you tarry with. So no, don't extend to the Danish bad boy the kind of respect you give to someone who has completed a novel or made a sculpture by gathering marble chips off of the streets of Cleveland for 20 years.

But painters of minatures, polaroid artists, and the people who design quality sporks are artists too.

Well put! Despite planting the needle on the curmudgeon-o-meter with this posting, I am normally really interested in installation/performance art, when it's done well. One of my fave recent areas in installation art is installation soundscape -- i.e. placing geographically intriguing sounds inside unusual places. I'm trying to remember the name of that artist from Toronto (Hamilton?) who produced this incredibly cool soundscapes that were intended to intermix with your actual environment -- for example, she mixed a bunch of snippets of conversation and woodland/water sounds that you'd listen to while walking around Toronto's industrial waterfront areas. Crazily cool stuff.

Yeah, it's more the knee-jerk pose of rebellion that makes me want to reach for a supersoaker.

TYPOS!!!!

I mean you ARE right when you slam the epater the bourgeois attitude.

The bourgeois watch hustler on sattlelite. I can order Danish beast porn on the interntet. What f**** taboos are there left to break?!

So yes to installation art no to infantile tactics like vomiting on paintings that you do not like or crushing mice with hammers.

Crushing a mouse with a hammer -- wasn't that the "Sniffy the Rat" art project from 1989?

Nice site. thx.

Being able to understand that basic idea opens up a vast amount of power that can be used and abused, and we're going to look at a few of the better ways to deal with it in this article.

That gives us a pretty good starting point to understand a lot more about variables, and that's what we'll be examining next lesson. Those new variable types I promised last lesson will finally make an appearance, and we'll examine a few concepts that we'll use to organize our data into more meaningful structures, a sort of precursor to the objects that Cocoa works with. And we'll delve a little bit more into the fun things we can do by looking at those ever-present bits in a few new ways.

When Batman went home at the end of a night spent fighting crime, he put on a suit and tie and became Bruce Wayne. When Clark Kent saw a news story getting too hot, a phone booth hid his change into Superman. When you're programming, all the variables you juggle around are doing similar tricks as they present one face to you and a totally different one to the machine.

This variable is then used in various lines of code, holding values given it by variable assignments along the way. In the course of its life, a variable can hold any number of variables and be used in any number of different ways. This flexibility is built on the precept we just learned: a variable is really just a block of bits, and those bits can hold whatever data the program needs to remember. They can hold enough data to remember an integer from as low as -2,147,483,647 up to 2,147,483,647 (one less than plus or minus 2^31). They can remember one character of writing. They can keep a decimal number with a huge amount of precision and a giant range. They can hold a time accurate to the second in a range of centuries. A few bits is not to be scoffed at.

This back and forth is an important concept to understand in C programming, especially on the Mac's RISC architecture. Almost every variable you work with can be represented in 32 bits of memory: thirty-two 1s and 0s define the data that a simple variable can hold. There are exceptions, like on the new 64-bit G5s and in the 128-bit world of AltiVec

Each Stack Frame represents a function. The bottom frame is always the main function, and the frames above it are the other functions that main calls. At any given time, the stack can show you the path your code has taken to get to where it is. The top frame represents the function the code is currently executing, and the frame below it is the function that called the current function, and the frame below that represents the function that called the function that called the current function, and so on all the way down to main, which is the starting point of any C program.

Let's take a moment to reexamine that. What we've done here is create two variables. The first variable is in the Heap, and we're storing data in it. That's the obvious one. But the second variable is a pointer to the first one, and it exists on the Stack. This variable is the one that's really called favoriteNumber, and it's the one we're working with. It is important to remember that there are now two parts to our simple variable, one of which exists in each world. This kind of division is common is C, but omnipresent in Cocoa. When you start making objects, Cocoa makes them all in the Heap because the Stack isn't big enough to hold them. In Cocoa, you deal with objects through pointers everywhere and are actually forbidden from dealing with them directly.

When compared to the Stack, the Heap is a simple thing to understand. All the memory that's left over is "in the Heap" (excepting some special cases and some reserve). There is little structure, but in return for this freedom of movement you must create and destroy any boundaries you need. And it is always possible that the heap might simply not have enough space for you.

Our next line looks familiar, except it starts with an asterisk. Again, we're using the star operator, and noting that this variable we're working with is a pointer. If we didn't, the computer would try to put the results of the right hand side of this statement (which evaluates to 6) into the pointer, overriding the value we need in the pointer, which is an address. This way, the computer knows to put the data not in the pointer, but into the place the pointer points to, which is in the Heap. So after this line, our int is living happily in the Heap, storing a value of 6, and our pointer tells us where that data is living.

To address this issue, we turn to the second place to put variables, which is called the Heap. If you think of the Stack as a high-rise apartment building somewhere, variables as tenets and each level building atop the one before it, then the Heap is the suburban sprawl, every citizen finding a space for herself, each lot a different size and locations that can't be readily predictable. For all the simplicity offered by the Stack, the Heap seems positively chaotic, but the reality is that each just obeys its own rules.