Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Thursday, May 6, 2010

Putting the "Pro" in Programming

http://images01.tzimg.com/cache/h3w4/500_1185829253_8424.jpg
I think programming is an art. There, I said it. I've come out of my conceited little arrogant and ignorant box. Writing code that works well and is human readable is a form of art. Now before you open your mouth to disagree (or roll your eyes because you don't care), let's agree on a few terms:

art

–noun
1.
the quality, production, expression, or realm, according to aesthetic principles, of what is beautiful, appealing, or of more than ordinary significance.
2.
the class of objects subject to aesthetic criteria; works of art collectively, as paintings, sculptures, or drawings: a museum of art; an art collection.
9.
skill in conducting any human activity: a master at the art of conversation.
(Dictionary.com)
Now I do have to admit, that definition is rather inclusive. Under this line of thinking, almost anything can be an art. What I want to emphasize about programming, however, is its shared characteristics with other accepted forms of art such as paintings and music.

In paintings and music, the artist has some theme, some concept in their head that they want to convey to the audience. They want the audience to feel it and in some abstract way, interact with it. They start from scratch and work their way up, step by step, until they have their final product. Painters may brush a large background color onto the canvas, stroke a few outlines for a face, fill it with a natural color, and ultimately converge on a Mona Lisa. Musicians may lay down a rhythmic beat, record a guitar, and overlay that with vocals - all the while refining their melodies and little tweaks such as fades and mutes.

Programming is very similar. The artist here (yes) wants to write software to fill a particular need in his or someone else's life. He knows what he wants the end product to be but hasn't filled in all of the gaps yet. He must first carefully plan the approach he wants to take to solve his problems. He starts by perhaps writing a main method that contains some variables and executes some debug code. He may then create some classes and divert the program flow into a state machine or constantly run a loop that checks what it should be doing at any given time. Eventually, he will have all the necessary functions, switches, and flow controls to call his program complete. Like a work of art, it must be aesthetically pleasing. While it's definitely true that many programs are just plain ugly, I can think of quite a few examples of fluid and natural interfaces that make using that program ten times more enjoyable.

And while speaking on the topic of aesthetics, let's not forget the code itself. There are varying degrees of ugly and I'm sure I've seen a lot of them. But I've also seen good designs through creativity and good language features that turn vomit-on-sights to sparkling, wonderful breaths of fresh air. Let me give a very simple example. In C, you might have to do something like this to check the contents of a list:


Now that's just nasty. It took eight lines of code that all look like they just rolled out of bed - mussed hair, bad breath and all. It looks like garbage, and you probably wrote at least one mistake in it carelessly that you'll either notice before you compile or notice later when your outputs aren't what you expect. Conversely, you can use languages like C# that allow you to use predicates and lambda functions on wrappered lists to do operations much more quickly and easily without sacrificing readability:


 In the same way that some art is more compelling than others, so too is some software more usable and better looking than others. We can't all hit home runs every time, but we shouldn't be afraid of stepping up to the plate. We should be open to new ideas that may save us some time or complexity or frustration. We shouldn't be afraid of rewriting bad code, changing a note at the end of the second verse, or slightly changing the color of the sky to match the palette we chose. It might be painful to correct mistakes, but it's often worth it in the end.

Art or not, writing better code is important because someday, someone will have to look at the code you write and it's always a pain having to clean the monitor screen after someone's head explodes.

Wednesday, January 20, 2010

Game Design

Team Members:
  • Justin Kern - Viz/Art
  • Drew Reagan - Programmer
  • John Laky - Programmer
  • Brett Hlavinka - Scope Creep
For our first project in the class, we are thinking of doing a reverse modification of Tower Defense. The idea is to have the computer control the placement and type of defenses and the user will draw the path and summon the creeps to hopefully make it to the goal state. The challenging task will be to make it so that there's never one perfect path through the state, but that some will be better than others. Think this or this, only with more defenses and more path options.

I think that once we have a concrete idea as to how this will work, it's going to turn out great. The biggest problem could end up being a lack of interactivity, so we may want to make it so that you can change the current path on-the-fly.