Archive for the ‘Computers’ Category

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 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.

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…


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…

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.


December 15, 2006

I tried out Ruby, and it was pretty nice. But I’m excited about something more now; F#.

Beyond the crazy type system, one of the reasons why I gave up OCaml was the lack of libraries, specifically for GUIs. The Graphics module was nice, but small. Since F# is based on the .NET framework, I get OCaml’s beautiful functional-ness, and all the libraries I could ever ask for (I can even use XNA!). I’ll see how it works out.

It’s the weekend now. But I have a 20 page Biology paper to write. Meh…

A Tale of More Than Two Cities

December 10, 2006

I’ve been trying to write something here; really, I have. I have several unfinished drafts saved, staring me in the face. But, since I can’t think of anything worthwhile to say, I figured I’d share a story instead:

As far back as I can remember, I wanted to make video games; I have pictures that I drew in first grade of a stick figure with a pocket protector holding a computer monitor. But it was only recently that I learned these game-making magicians trained and lived in a magical kingdom known as Programmerlot. I decided that if I was ever going to fulfill my life’s goal of becoming a game programmer, I would have to journey to this fabled land. But when I set out, I had no idea what to expect.

My first stop was BASIC Village. It seemed as though a lot of upcoming young magicians were getting their start here, so I settled down. For a while, times were good. I came to know my TI-83 calculator inside and out. I was immensely proud of myself for being able to display messages on the screen; I could even ask the user for a number, and add another number to it! But I soon became disenchanted. There was little I could do except write small math programs with my beloved BASIC. I saw a few of my peers writing games of Pong, but I wanted more. I wanted to create the games people buy in stores, not trivial calculator applications. I decided it was time to move on to something new.

While traveling the countryside of Google, I heard of a new place: Assembly Town. Apparently, Assembly was an extremely awesome language; I wanted to make awesome games, so I rented an apartment for cheap and got to work.

I never successfully completed one Assembly program. From day one, I was completely lost. I was trying to take in strange new concepts like “Assembler”, “Linker”, and “Command Line”, and it was just too much. At this point, I thought it was time to give up; I simply wasn’t cut out to be a magician. But during my studies one day, I came across a reference to a slightly more distant locale: C City. I packed my bags that night, and arrived in C the next morning.

Coming from Assembly, C was a breath of fresh air. I could insert words in my code now; complete words, readable by humans! Still, life was not without hardships; gcc on Windows was a pain to install for a novice like me. However, I quickly conquered the basics, and I then felt I was ready to take on my biggest challenge yet: Pong. Real, live, graphical, Pong. It wasn’t easy. DirectX was difficult to learn, and even more difficult to understand. My first attempt was little more than the modification of some code from a book. But in the end, it compiled. And I was able to move the paddle back and forth, and hit the ball with it. And I was happy. I thought I had the world at my fingertips. But this is not the end of our story.

I continued to work off this code to create a small game where you controlled a space ship, trying to shoot an alien (although it looked more like a Christmas tree, since I can’t draw to save my life). After some problems, it worked. More happiness. But I could sense change in the air. I was constantly reading about a district of C City I had never heard of, called C++ Square. Although many were praising it for its “Object-Oriented Programming”, I saw no reason to move yet again. I was happy with C; I had made two games. But, curiosity eventually got the best of me, and I was off.

At first, I couldn’t see what made C++ so different. It was just C, with these newfangled “Classes” and “Objects”. But when I began to study the language in earnest, I saw what made it different, and I learned the OO Ways. However, I didn’t do anything significant with C++ on my first visit to its home; by chance, I heard of a new, rather out of the way place, called Python Land. I could see it on my map, but it was far off. Still, curiosity once again got the best of me, and I was traveling once more.

I found Python Land to be very quaint. I thought it was the coolest thing in the world that you didn’t have to specify a variable’s type when you created it. For the first time since BASIC Village, I found programming to be fun. With C and C++, I always loved the problem-solving, and I liked the end result, but the process of writing the code itself was not all that enjoyable; in Python, it was. But even after experimenting a little with PyGame, I didn’t think Python would be suitable for “real work”, so I went back to C++.

It was then I made my first complete game, from start to finish, on my own: Tetris. I was pretty proud of the fact that it was in C++. Although it wasn’t really C++; it was just C with the “struct” keyword replaced with “class”. For some reason, I was having trouble applying the OO Ways to my programs. I understood all the concepts well; I knew the difference between a class and an object, and I knew about encapsulation and polymorphism; but I just couldn’t bring it together.

So, I once again began roaming the countryside, in search of someone who could teach me proper OO techniques. Being the fair-minded person I am, I wanted to find out what was wrong with the OO paradigm, in addition to what was good about it. That’s how I stumbled on Paul Graham’s essays [1].

While checking out the links in the Criticism section of Wikipedia’s OOP page, I came to Paul Graham’s website. In case you didn’t know, Paul Graham is a Lisp programmer; he’s also a very good persuasive writer. Before then, I had heard of the magical Lisp Wonderland, but I had never had the impulse to actually learn about it; but after hearing Graham make statements such as “Lisp is the most powerful programming language” and “Java programmers are unlikely to be as smart as Python programmers”, I decided to check it out.

My excursion into Lisp’s territory was fairly short. I thought it had some novel ideas- code is data, blah blah blah- but again, it was nothing to use for “serious work”, especially since it didn’t have a free GUI that didn’t require 50 other libraries. The Dr. Scheme implementation of Scheme actually has a fairly nice GUI, but I never did much with it.

Still, I liked the Lisp language; a lot. I especially liked the parenthesis surrounding every statement (I think I’m alone in that sentiment). But the coolest thing was that it gave the same “fun” feeling as Python. I wondered if Paul Graham was right: that there are these magical “smart languages” (Lisp, Python, Ruby) that are leagues more powerful and interesting than “dumb languages” (C++, C#, Java). I think it was there I began my quest for the One True Language; something fun, easy to use, and powerful; and it needs a GUI (I’m still trying to become a game-making magician, remember?).

I decided the best place to start my search was with Java. If it really wasn’t a “smart language”, I wanted to experience first-hand why it wasn’t. When I got to the Kingdom of Java, I found it to be the largest city in all of Programmerlot. There are people all over the place, from veterans working on enterprise applications, to newbies asking for help on their CS homework.

My experiences with Java were rather good. Within a few days of learning, I was able to create a Pong Applet, and Swing GUIs. I always wondered why the long-standing citizens in the Kingdom professed it was so hard to learn.

I actually did get a minimal “fun” feeling from Java, mainly because it was so easy to quickly put something together. But it wasn’t the same fun I got from Python and Lisp. You see, while programming in Java was easy, it was also boring; extremely so. The language was so simple, I began to look at it as merely an interface to its standard library, rather than something you expressed your own ideas in. Looking for an excuse to try something new, I heard of a new version of Managed DirectX, called XNA, being released in the City of C#.

C# was easy to pick up, since I was fresh from my Java adventures, and XNA was like having a rock removed from my face after all that time working with plain old Win32 and DirectX. In fact, I’m working on a small RPG in C# and XNA right now.

Shortly after that, I stumbled upon Steve Yegge’s blog [2], where I found high praise of a language I had nary heard of before: OCaml. It was functional; which initially turned me off, since I had already had such a bad experience with Haskell; but it could also create Win32 applications, which piqued my interest again.

Entering OCamlot (which had a population of about five people) was the defining moment in my trip through Programmerlot, I think. It was then I finally began to understand the “smart language vs. dumb language” rhetoric I had been blindly spewing out for the past few months. Now, I’m not one of those language snobs who believes their language is better than everyone else’s; there are times when I would use Java, because it’s well suited for some problems. But I can see how some languages are much more well designed than others. Coding in OCaml was fun; truly fun through the whole process. My code was three times more concise than it was in Java, and it was more clever, too. I thought I had found the One True Language; but alas, I had not.

OCaml’s static type system drove me up the wall after a while. Seriously, where else do you get error messages like “This expression has type Point but here is used with type Point”? Maybe I just didn’t learn enough of it to get past that stage of frustration. I’d still rank it among my favorite languages, if not my most favorite, but I couldn’t imagine doing a huge project in it. Thus, my quest for peace continues.

So, what’s next? After my C# RPG is done, I’d love to get into 3D graphics with C++ and DirectX. But if I just stick with those languages, I’ll stop learning; and when you stop learning, you end up working on a business application written in Java. Thus, I have to keep moving on over the horizon, searching for the One True Language; but what does that horizon hold?

Much of the Great Northern Functional territory remains uncharted; exotic languages like Erlang, Maple, and Dylan await. To the west lie web languages and other oddities: SQL, ASP, and maybe a bit of Prolog can be found there. There is a tropical island in the deep south where people speak Smalltalk. I have also heard of a prosperous country not too far from Python Land where the Rubyists make their home; I believe that will be my next stop. But I have little hope that any of these languages will solve my problem. I am not an expert with any of the languages I have come across, but I know enough to know that they are not perfect. Maybe no language is.

All I wanted to do was be a magician; I had no idea it would be so complicated. Overall, the future looks bleak; but if there’s one thing I’ve learned in my travels through Programmerlot, it’s that the future holds many surprises, and things are never as bad as they seem.

[1]: Paul Graham’s website can be found at
[2]: The archives of Steve’s blog can be found here, while his latest works are stored here