Object Obsessed Programming

March 11, 2007

Let’s imagine a perfect programming world. In this world, everyone would always agree on everything. There would be only one language, one API, and one paradigm. No one would ever question this methodology, since it would work perfectly, and would be capable of doing everything imaginable. Language flame wars would disappear. The Right Way To Do Things would be obvious. In short, it would be pretty awesome.

Of course, our imperfect programming world doesn’t work that way, and never will. People have different opinions, and thus we have different ways of doing things, which manifests itself in different languages and paradigms. With so many different opinions, things can get complicated. One of the more popular opinions on how things should be done is Object Oriented Programming, or OOP.

For my latest project (which I mentioned here), I wanted to do things the OOP Way. Because, as we all know, OOP is awesome. How can it not be? Java, which is obviously the best language ever since it is so popular, forces you to do OOP by making you put all your code in classes. Every language on the planet, even functional ones like OCaml, has some sort of object system. So it must be pretty good.

I was pretty excited about learning the right way to do all this OO stuff. I had always struggled with it. When I first moved to C++ from C, I had a hard time integrating objects and classes into my code. Even when I started using them, it didn’t feel like I was using them enough. This project would be my chance to make a real OO application: everything would be in a class, interfaces would be public, data would be private… it all sounded so good.

So, I started coding. In my previous projects, I would usually just start writing the game loop. This would consist of the code to poll the keyboard and mouse, update the screen, and render everything. Pretty simple, but it was sufficient. But it was obvious to me now that that was a horribly un-OO way of doing things. I was going to have to start with the Input class, which would derive from the abstract base class GameComponent. It would have an override of the virtual update() method which would put the state of the keyboard into a public static vector. That sounded pretty OO to me.

The Renderer class would be in charge of drawing the screen, but I would first need to think about how the objects on the screen would be represented. I decided that when the game loads, I could append a MenuComponent to the Game class’s GameComponents list to represent the first menu the player sees. The Renderer could loop through the GameComponent list and use RTTI to see if the component it was looking at was a Menu, and then draw it accordingly.

There was actually much more to the code than what I’ve described. I was up to nearly 400 lines, and the only thing I had to show for it was a window with a black square. It was mostly OOP boilerplate code. 400 lines is incredibly tiny in the grand scheme of things, but for a project of the size I was working on, it was too much. The design was already beginning to break down and become hard to maintain. Various things in the C++ language were also starting to annoy me. I decided that it was time to do a complete rewrite; in Python.

Things are going smoothly now. 30 lines of Python has replaced my 400 lines of C++, and the code does more. I’m also back to my old way of programming, where I just write code that does things rather than worrying about OO design. I can attribute my increased productivity to one or more of a few factors:

  • Object Obssessed Programming is stupid.
  • OOP design is really hard, and I just had a cruddy design.
  • Python is a far better and more productive language than C++.

The third one seems likely. A lot of the best programmers I know despise C++. The second one is probably true too. You can’t slap together OO code and have it be perfectly maintainable, and you can’t become an OO developer overnight. Designing large systems, and designing them well, takes practice. You can probably tell that I haven’t practiced too much.

The first one is the one that I’ve been thinking about lately, and I believe that it’s a true statement. Object Oriented Programming can be a good thing; Object Obsessed Programming cannot.

What’s Object Obsessed Programming, you ask? It’s when people go overboard on OO design; they stress out about getting it Just Right. Which is what I did. I started fussing about what should be public and private, who should inherit from who, and the like. I thought that by getting everything right, I would have a wonderfully written program. I ended up with a horrible one.

Smalltalk (the first OO language) was fairly simple. Member functions were public, variables were private, and classes could singly inherit from each other. Objects were useful data structures; they were there to help you, not hurt you.

Today, OO languages have added all sorts of weird features and terms: public, private, protected, virtual, abstract, the list goes on and on. In their quest to make all ideas enforceable, they severely limited programmer productivity. We have developers who are thinking about whether to have SingletonXMLParser inherit from SingletonTemplate or XMLObject, and they shouldn’t be. They should be writing code that gets things done.

Objects are useful, they really are. If you have an object like thing in your code, like a sprite in a game, make it an object. Give it an internal state, and some public functions for operating on that state. But it’s just silly to write entire programs based on objects. You’ll get lost in the details. That kind of OO design is really hard to get right, and if you get it wrong, you’ll have headaches down the road, or you’ll have to do a complete rewrite. A poorly designed OO program is harder to maintain than a million lines of Basic with GOTO all over the place.

I’m not really sure where I’m going with all this. I thought I was going to expose some sort of grand truth, that I was going to keep people from making the mistakes I did. Instead, I talked about what I’ve done with my project so far, followed by a rant about OOP. Take from it what you will; I guess I was just trying to warn you not to go overboard on OOP. But I’m sure someone much smarter than me figured that out a long time ago.

FizzBuzz, Enterprise Edition

March 4, 2007

Those of you who have been keeping up with the programming blogosphere have probably heard of FizzBuzz by now. Well, in the spirit of this, I decided to create my own overly complicated FizzBuzz: FizzBuzz, Enterprise Edition.

As we all know, Java is the best language for writing enterprise applications, so that’s what I went with. Here’s a quick overview of the code:

  • The FizzBuzz class is where most work is done. This class is a Singleton since we only create one instance of it.
  • The doFizzBuzzApplication() method generates a list of Number objects by reading a file containing all the numbers from 1 to 100.
  • It then creates a new instance of the FizzBuzzOutputManager class, sending it the list of Numbers to be printed.
  • The doOutput() method of the FizzBuzzOutputManager class goes through the Number list, checking if the current object is an instance of numberDivisibleByThree, numberDivisibleByFive, etc. It then prints out the appropriate message on the screen.
  • Like all good enterprise applications, there’s a lot of code in there from past versions that does absolutely nothing. The program also generates a few worthless files when it runs.

You can download the source here.

This shouldn’t be too hard to out-enterprise (especially if you throw in some SOAP web services…). If anyone else has an unnecessarily complicated FizzBuzz, I’d love to see it.

How much Design is Enough?

February 16, 2007

A Quick Comparison

Paul Graham. James Gosling. Whether you like the languages these guys champion or not, I think most people would agree that they’re both pretty good programmers. They also represent two different ends of the programming spectrum. Take the topic of program design, for instance; and by design, I mean spending time thinking about how to write a program before you actually write it. When asked what makes some programmers more productive than others, Gosling responded:

“They think about what they do. They don’t rush in and slap things together. They have a holistic picture of what is to be built.”

Seems like the kind of guy who would be a proponent of designing a program before you start writing it, right? Now, let’s look at what Paul Graham has to say on the subject:

“I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper.”

So, on the one hand, we have the corporate Java programmers who like to work out every detail of a program before they start writing it, and on the other, we have the cowboy Lisp hackers who throw out code and hope for the best. Who’s right?

“We need our design methodologies!”

Allow me to start by saying that I lean more to Gosling’s side. Design is great. I’m wishing I had done more of it sooner.

For example, I’m currently working on a small strategy game. If I hadn’t taken the time to get an idea of how I wanted to write it first, I’d be screwed right around this point. My first problem came in how I wanted to represent the board. Should I just draw sprites in random locations? Should I store the board as a grid of tiles? Ultimately, I went with the tiles. At that point, I had a new problem: in addition to possibly holding a soldier, each tile would also have to have information about its terrain (mountain, forest, etc.).

How would I represent this information? Should I make a list for tiles, have each spot of the list hold an object of Soldier, and have each type of terrain I want derive from Soldier? That’s a bit messy. Should I hard-code terrain information based on the map I load? No, what if terrain changes during battle? If I hadn’t worked out these problems in the beginning, I’d have a mass of broken code.

There’s no need to go overboard on design. Before I started to write my game, I got a good idea of all the features the game would have, what classes and functions I would use in the program, and what all these elements did and how they communicated with each other. That’s all; it was really a very high level overview. But I’m glad I did it; you have to do some design.

Rebuttal from the Lisp Camp

The general sentiment among Lisp programmers who think they don’t need to do design is that the Lisp language gives them this freedom. I don’t really understand the logic behind this, but you can read any of Paul Graham’s essays, or a post on comp.lang.lisp, to find it.

No matter what language you code in, you have to do some amount of design; even in Lisp. When I was writing my RPG language in Lisp, I had trouble in the beginning because I was starting off with a bad design.

My original plan was to read words from a file and look them up in a symbol table to see how the rest of the line would be read. Eventually, I decided to represent rooms in the game as hierarchical data, like XML; I also decided to work backwards, and write the functions to process this data before I worried about constructing it from a file. Seems like a design decision, doesn’t it? If I had thought about my design before I began writing my program, I would have saved myself quite a bit of time.

To Be Continued…

This should probably be called “How much Design is Enough, Part 1”. This game is the first project I’ve ever done any real design on, and I’m very early in the coding process, so I’m going to have to see how it pans out. But so far, this design thing looks like it might be pretty cool. You should do it.

Now, I’ll wait for the angry comments to roll in.

Why it’s so Hard for Imperative Programmers to Learn Functional Languages

February 14, 2007

I’m not currently using any functional languages like Haskell and Lisp, but I’m certainly comfortable with them. I’m certainly no Haskell guru, but I’m good enough to use higher-order functions, ADTs, monads, etc. While I have a good grasp of functional programming concepts now, I had to travel a long, hard road to get to this point.

Picture if you will a programmer with a C-family background discovering Haskell for the first time. He’s heard some smart people talk about how cool it is, and it says right there on haskell.org that it will substantially boost your productivity, so he momentarily puts down his Java Enterprise Web Framework With a Really Long Name and starts reading a Haskell tutorial.

At first, everything goes well. He’s impressed by the fact that you don’t have to constantly compile code to see the effects of your program. But after using the REPL as a calculator for a few minutes, he decides to check out how you write Hello World. This is where things start going downhill.

He notices that the chapter on I/O is tucked away in the Advanced section. Curiously, he flips to it and discovers, not an explanation of console and file I/O, but a disscussion of type classes, monads, and the like. He wonders if everything will make more sense if he just visits the appropriate chapters, but no luck; Haskell looks like one big incomprehensible mess. Our imperative programmer goes back to his Java Enterprise Framework, and that is the end of that.

It’s very difficult for a programmer used to imperative programming to find a good Haskell tutorial, or a good tutorial on any other functional language for that matter. It’s not that they explain Haskell badly; many of them explain it rather well. It’s just that they explain the wrong parts of Haskell. Procedural programmers are more often interested in how to do I/O and create GUIs rather than in how to use Parsec or write monads.

This is one of the major barriers to adoption of the more esoteric languages; lack of learning material for “normal people”. To rectify this, I thought about how I would write a Haskell tutorial.

I figured I would start off with a discussion about how to use the REPL to develop simple functions, and to test programs. From there, we would talk about how functions are side-effect free. We might take a detour into recursion, and then go on to topics such as monads and type classes. It would just be a Really Good Tutorial.

Then I realized something: in this great tutorial of mine, there were no sections on how to do I/O. There wasn’t even a Hello World program. Therein lies the problem.

The only people who can write a Haskell tutorial are the people who know Haskell. Ironically, someone who knows Haskell won’t be able to write a tutorial for the average programmer. They’ll focus too much on the features that make Haskell cool, rather than how to do practical things with it; which is just what the average programmer wants. Haskell gurus have spent so much time in their theoretical wonderlands, they’ve forgotten what it’s like to be an outsider.

We really need a Haskell, or Lisp, or ML tutorial aimed at the rest of the world, not just at functional gurus. Although I’m certainly not going to write it; I’ve got my own projects to worry about.

Trouble in Paradise

January 26, 2007

A long time ago, Reddit (reddit.com) used to be awesome. Not anymore.

A little while ago, someone posted a link to a picture of the old Reddit; the way Reddit used to look before it got popular. Pretty much every link on the Hot page was something tech related, or something else interesting. Sure, everyone one of those links was submitted by Paul Graham, but they were all good links. Even when I joined Reddit a few months ago, there was still an influx of good news stories. Reddit was awesome.

Now, you have to go to programming if you want to see anything mildly stimulating; and those links are only good half the time. Take a look at the Reddit Hot page right now, and it will probably look something like this:

1 ) George Bush is stupid
2 ) Today’s XKCD comic
3 ) Why all the cool kids are converting to atheism
4 ) Bush is still stupid
5 ) BEST PIC EVAR LOLZ
6 ) Lisp programmers have higher IQs than Java programmers
7 ) You should move to Canada!
8 ) Guy talks with a bug [video, funny]
9 ) He’s still stupid

And so on and so forth. That’s not awesome. Not by a long shot.

I can only assume this is the price a social bookmarking site must pay for popularity. Reddit is about what the community likes, not what an individual likes; and now the community consists primarily of 20-year-old ultra-liberal Python programmers.

At least I know I’m not the only one who has a problem with the new Reddit. Unfortunately, meta-links of the “Guys, we need to vote up cooler links” variety are overshadowed by meta-links of the “CONDE NAST IS TAKING OUR FREEDOMS!!!1” variety.

So, consider this a call to all Redditors: vote interesting, fresh links up and boring, repetitive links down. Save your site before it goes even further down the toilet.

I used to think Reddit was better than Digg. It used to have links to articles that were truly interesting; now, we get the same old stories, the same old pictures, day in and day out. I suppose the only solution is to build a news site that has an IQ test its users must complete before they can register:

“Would you rather see a story about Bush making a monkey face, or a story about concurrency in Haskell?” “TEH FIRST 1!” “No, you fail.”

That could work.

Installation is Addictive

January 20, 2007

Well, I haven’t posted here in a while. Not that anyone cares.

I have a great number of language compilers/interpreters installed on my computer; too many for my own good. The current list includes C, C++, C#, Java, Common Lisp, two implementations of Scheme, Python, Assembly, Ocaml, F#, Ruby, Prolog, Haskell, Tcl, and Perl, roughly in the order their program folders appear on the All Programs list. I’ve also worked with languages that I currently don’t have installed, such as J and Visual Basic. You might attribute this polyglotism to curiosity. I attribute it to laziness.

I haven’t done anything major since I finished my Tetris clone last summer; not a thing (of course, Tetris isn’t really a “major” project, what I mean is anything that you might have to actually think about for a little while). I’m much more concerned with using languages for my own amusement, rather than building anything useful with them. Perhaps it’s because the Windows installers feel so magical; there’s a certain indescribable pleasure to watching a program copy a zillion little configuration files, or uninstalling a program I no longer need.

At least there’s hope on the horizon. I’m currently writing an interpreter for a small language for writing text adventures in Common Lisp. The interesting thing about this project is that I’m actually writing code, and this code is actually working, and it’s actually doing something that’s actually interesting. Thanks, Lisp, for getting me out of a slump.

Now, I’ve heard of this new language called Epigram that’s supposed to have a really cool type system…

Erlang

January 2, 2007

I just spent the last half hour or so trying out Erlang; which isn’t enough time at all to seriously evaluate a language, but it’s enough time in my world. I stumbled upon it quite a while ago, but the ugly syntax scared me away. After learning Prolog, the syntax didn’t seem so ugly (Erlang began life as a modified Prolog), but nothing about the language particular jumped out an said “LEARN ME!”. I’m not too interested in writing “real-time distributed systems”.

I’m going to be using this space to rant about all of the new languages I try out. It’s all part of my quest to find the One True Language.  Wish me luck.

I’m Going to Learn Lisp

December 28, 2006

I’m already somewhat comfortable with Lisp programming, but I wouldn’t say I know the language inside and out.  Plus, I haven’t had that “enlightening” experience that users of the language describe.  So I’m going to learn Lisp.  I’m going to use it until it all clicks.  From my perspective, it already clicks, but something is still missing.  I’ll record my travels here.  See you later…

Merry Christmas!

December 25, 2006

I got a Wii and a DS Lite for Christmas; I’ll have a more thorough review tomorrow. Merry Christmas everyone!

Well, um, hmm…

December 20, 2006

Not much to say right now.

I just finnished playing Okami.  Great, if a little sparse in terms of story.  Definitely recommended.

Christmas is only five days away.  I’m hoping to get a Wii.

Prolog is quite possibly the coolest language ever.  I won’t go in to why I like it now, since I’ll probably hate it in a week or so.  But if it works out, I’ll share more.