Extravagaria Workshop Wiki


PaintingsAsPrograms

In software engineering research, we're often trying to find ways of helping developers "express themselves". And as programmers, we're trying to express ourselves in both a way that "runs", and also in a way that can be understood later: by programmers, and by ourselves. The idea of trying to get something to "run" has dominated the way in which developers can express themselves (though not completely dominated it).

But artists are not constrained by getting something to run. Perhaps we can learn alot from the way artists try to express their ideas, and the way in which they pass them along to both themselves and others. For instance, artists talk about "dynamics" of their pieces, in a way that makes you think that they are actually expressing something poised in time, much the way source code is. The way in which artists build dynamism into their pieces would be an interesting point of study.

Also, I can imagine that if we could somehow take for granted that something would run, that eventually we could get to a point where paintings could actually be programs. Perhaps, their interpretation would even be "in the eye of the beholder".

Okay - that makes no sense - just rambling there...

--ElisaBaniassad


One thing that would be pleasant is to have a better balance of form and function in programs. I'm not just talking about "well factored" code, although that's part of it. I would like to give components shape and make programs colorful maps of themselves. This, I think, is something the standard UML abstractions have failed to achieve.

What I have in mind is more like a network of hypertext documents with visually rich, yet executable content. It would be possible to approach the program from any number of viewpoints. The question of what is code and what is representation would be, to some degree, meaningless. -- ChrisSteinbach (also rambling)


I think most software folks are left with "runs" as their primary measure of success (or perhaps "usually runs"). They are sometimes aware in a secondary way of the elegance of the solution, its maintainability (comment: this is a hack that someone will need to fix one day...), and whether it truly meets users' ethereal needs. A running failure (failed in terms of the secondary criteria) is viewed as better than an elegant solution that doesn't run.

The wonderful thing about painting (IMHO) is that the run requirement is lifted. Anyone can produce a running painting. However, many thinkers (such as MacKenzie) talk about how the question "Who here can paint a picture?" is met with unanimity in Kindergarten and a guarded minority in high school. I believe that this is because people artificially introduce run requirements to painting. Will people think it looks good? Will it look like what I want it to look like?

Midlife artists talk themselves out of that insecurity or justify their desire to paint by taking art classes. Art instruction introduces more similarities to software construction with techniques and tools. To truly be able to transfer what's in your mind's eye to canvas, you need to know how to mix, brush stroke effectively, represent forms and shadows, and so on. Still, knowing all that does not guarantee success by whatever definition.

And so it is with software. The front line troops discuss tricks and tribulations with the tools, techniques and patterns, and curse the users for not being able to express their needs in BNF. Questions like "why don't you implement the elegant maintainable solution that you really want?" are met with complaints about project schedules, pesky regression testers, backwards compatibility issues, insufficient toolsets, user priorities,...

Who here writes beautiful code?

-- DeanMackie


I would have to say I'm not sure whether I write beautiful code, simply because I hardly ever get a sense that I'm "seeing" my code. You can see projections of it using diagram generators, by running it, reading bits of it, etc, but you never really get at a representation the thing itself. Maybe, though, I need to take a "code appreciation class"?

--ElisaBaniassad


I think it would be interesting to get lots of submissions (anyone? anyone?) of code they thought was beautiful (or not) from many different perspectives. For example, at the detail level, we can improve our word power and appreciation for literature by reading the classics (why did they become classics?) such as Knuth (see KnuthArt). Similarly, we could talk about the aesthetic experience that arose from working with (or maintaining) code, or even of using it: what software have you used that just blew your mind? Similarly, we can probably recount negative aesthetic experiences we've had: a seeming insignifigant modification resulted in a cascade failure and had to be rolled back, or completely unusable interfaces, or when you're on the phone getting transferred between departments and each of them asks you again for your account number (why doesn't their software give it to them? You know that it can and should!).

Anyone? Anyone?

--DeanMackie


It's true that a lot of programmers use "runs", or "mostly runs" as their criterion of success, but I don't think that "runs" is quite as objective a criterion as we might think. "Runs" can mean anything from "doesn't crash the computer when I invoke the program" through "mostly behaves the way I expected it to" all the way to "behaves the way the intended user needed it to". This isn't so very different from the many possible measures of the worth of a work of art, from "is pleasant to look at or listen to" through "challenges and interests the audience" to "communicates a fundamental truth to the viewer". And of course there are other dimensions you could categorize criteria of success on for both programs and paintings.

I guess what I'm trying to say is that programs have many purposes and so do paintings; so there have to be many possible measures of success as well.

-- BruceCohen