These are called trapeziums in my homeland. As a result I shall call them that, Lewitt be damned. Also, I’ve included my solution so that the annotations on the drawing make some more  sense:

The drawing is an interesting concept in itself, and the idea of man as machine is very clearly presented here. I am most interested in one particular element of the instructions. It’s a comma:

“…the upper right corner to the center of the square, the left side is drawn to a point halfway between…”

Lewitt is bending the doctrine of our language as far as he can, but all of his bending is permissible except for this. This comma, by all rules of the English language, should be a full stop. He clearly decided he wanted the instructions to be one sentence, but in doing this he makes his instructions totally insensible, and breaks the principle of ‘program’ instructions.

The real question is wether this ‘bug’ was intentional, because it alone differentiates the human from the computer by forcing us to interpret creatively. Either way, it brings something completely new to the instructions, and I think the piece is better for it.

 

 

 

This was probably the most confusing experience I have ever had.  I was not sure what they meant by the top side so I assumed that it was the top side of the square because it was impossible to find the midpoint of a non existent topside.  I had to circle and label the transition words such as “and” and “to” in order to determine exactly how, many lines were being drawn and to where they were connecting.  In all honesty, I probably failed this whole test but it was really nice setting a time out of my day to focus on one task.  I would say this is a type of code because it has a hyper specific set of instructions that arrive to a specific conclusion and if done properly, will always arrive to the same conclusion. In my experience sat the executor, it was left up to my interpretation of language that determined the end result. But then again, I am illiterate so I might have just idiotically messed this up.

Here is my Lewitt “Wall Drawing”:

It is not really the code we talk about today because this was made by a human. It was code as origami or crocheting instructions are code (although Lewitt had no intention to clarify for the person on the receiving end). I saw a lot of similarities between the wall drawing and code. It was a structured whole piece that needed to be de-constructed layer by layer. Not as straightforward as it sounds, because no piece could not be fudged or ignored without resulting in an odd drawing. I found that I worked on this the same way I would work on a processing problem.

I got through it by looking at past wall drawings and seeing his style of wording, and then applying that to our trapezoid. Our trapezoid was not as bad as some other horrid wall drawings.

 

Here is my interpretation of Sol Lewitt’s “Wall Drawing,” 1974:

If the goal was to confuse and confound artists and mathematicians alike, then Lewitt succeeds very, very well. If the goal was to inscribe a shape into a set of readable and easily transferable instructions, then Lewitt fails miserably. If Lewitt really wanted to transfer a drawing into text, a much simpler solution would have been something along the lines of:

1. Draw a square with side lengths 6.5 in.
2. Draw a trapezoid with the coordinates of its vertices (1,1), (2,5), (5,5), (6,1).

Perhaps Lewitt follows some very strict and obscure form of logic in the way he writes his instructions, but certain ambiguities may arise from over-complexity, allowing the creation of many valid shapes from the same set of instructions. If we can call Lewitt’s work “code” akin to that of computer programming, then I would have to say it is very poorly written code. Code for computers is not written for computers to understand, but for humans to understand; if the coder fails in this respect, then the coder is either working alone or is simply really bad at the art of coding. Good code should aim for either one or both readability and efficiency; Lewitt’s “Wall Drawing” goes for neither. This is not to say confounding myself in Lewitt’s transcription was not entertaining – at the very least, it was an interesting experience attempting to draw Lewitt’s logical spaghetti.

I have extremely limited knowledge of code, but I’m going to go ahead and classify Sol Lewitt’s Wall Drawings as such. I enjoyed this rather frustrating task even though I’m still a tad confused and pretty sure it’s not right. As executor, I translated his instructions into a language I could decipher and draw from. I struggled with different ways of interpreting the text and figuring out which ways of translating worked best for me. In the end I tried to highlight the word “to” and map out the connections by labeling each point with a letter, ending up with instructions like A is half way between B and C and is drawn to D etc.

I realize that the paper was supposed to be oriented in portrait rather than landscape. Whoops.

The syntax of Sol Lewitt’s “Wall Drawings” is halfway between the language of men and halfway between the language of machines. As a result, it is nearly incomprehensible to both. As one may be able to tell by my (somewhat illegible) handwriting, I was befuddled by Lewitt’s instructions, and attempted to create the shape from what little I understood.

I am thankful that our current computing machines cannot grasp the concept of tedium, nor that of frustration. I am also thankful that the typical exchange between a given person and a given machine is somewhat straightforward (and the reason we have user interfaces).