Regular Coder

2008-01-11T20:44:00.000-08:00

I just found something that I think _finally_ explains something to me that I never quite understood about C++. I wish a saw this years ago. This is gold.

Const Correctness in C++
http://www.possibility.com/Cpp/const.html

There are a few of things like this in C++ that I don't fully understand. A big part of me really dislikes C++ and would rather write in something else, anything else! But as long as we have so many Von Neumann machines around, C++ fills some important needs that no other language can or probably ever will at this point. It's pretty grandfathered in at this point. Sign, oh well.

2007-06-07T07:23:00.000-07:00

Mike Nelson's Mantras on Programming.

Mantra 1: Today's hot new system is tomorrow's legacy system. It will be hard to use, interface with, and support given enough time.

Mantra 2: Never call a routine 'smart', it is not. It doesn't matter how dumb the code was that it is replacing.

Mantra 3: Don't build for the future, it is unknown. Don't build for the past either for it is just as unknown. Building a new system to replace an old one is tantamount to ignoring the lessons of the past.

Mantra 4: Build for the now. Only consider what it should do today. Not what may happen tomorrow or what it could do.

Mantra 5: Mostly the tenants of maintainable code are fallacies. When he says maintainable code he just means code that he would write.

Mantra 6: All code takes effort to understand. No matter how beautiful it is. Beautiful code just makes the puzzle more interesting.

Mantra 7: No code is maintainable. Code is an object. It is only the coder that can take the action to maintain it.

Mantra 8: Is the effort to make code maintainable greater than the effort to maintain it? Why do more of a thing in order to do less of another?

Mantra 9: Do not attempt to do today what you will know how to do tomorrow.

Mantra 10: Just because you are doing work that does not mean you are adding value; you might be removing value.

Mantra 11: Just because I am using newer tools that does not mean that I am smarter.

Mantra 11: Just because I am using better tools that does not mean that I am better.

Mantra 12: A programmer is not defined by his tools.

Mantra 13: Why must I always use the latest swiss army knife when I can use the sturdy blade?

Mantra 14: Just because I write the code that does not mean I am better than the people that maintain the code. They have to deal with what I write.

Mantra 15: Just because I write the code that does not mean I am better than the users. They are the ones that I wrote it for.

Mantra 16: My software is not a gift of my benevolence.

Mantra 17: How would it help for us all use the same tools? We are not all doing the same thing.

Mantra 18: Software is never good enough. Just make sure that it is good.

Mantra 19: Do not say, "I am a C++ programmer," or "I am a Windows programmer." Don't even say, "I am a computer programmer." Instead declare, "I am a programmer."

2007-05-22T06:33:00.000-07:00

I got hit by this MSN messenger spam attack last night. It looked like someone I knew sent this in messenger,

"hi, check this http://whoadmitsyou.com and find out who deleted and blocked you from the Msn"

2007-05-10T13:33:00.000-07:00

Footboard

This is pretty ingenious. Might not be too useful but I can imagine that it could be useful in some settings. Like for voice bindings ut2004 for instance. :)

footboard

2007-05-04T17:37:00.000-07:00

Web 2.0 is the future now!!!

Seriously, what the hell is wrong with us?

2007-03-25T07:43:00.000-07:00

I was poking around at some programming languages again while thinking about concurency in programming and ran into a discussion on this very thing. Someone there mentioned Erlang as a good language to solve these sorts of problems. I'd never heard of it so I started checking it out. It does indeed have great concurrency support. I was going through their white paper and I found this other great feature that it has that has nothing to do with concurrency.

This program sorts a list using the Quicksort algorithm:
     sort([]) -> [];
     sort([Pivot|T]) ->
          sort([X||X <- T, X < Pivot]) ++
          [Pivot] ++
          sort([X||X <- T, X >= Pivot]).

from "Example 4 - Sort" of the whitepaper.

As it says in there ++ is the infix append operator and this example introduces what they call a list comprehension. Like it says in the whitepaper,

The notation [Expr || Qualifier1, Qualifier2, ...] introduces a list comprehension. Here Expression is an arbitrary expression, and each Qualifier is either a generator or a filter.

For example, the list comprehension

[X || X <- [1,2,a,3,4,b,5,6], integer(X), X > 3].

should be read as:

The list of X such that X is taken from the list [1,2,a,3,4,b,5,6] and X is an integer and X is greater than 3.

Here X <- [1,2,a,3,4,b,5,6] is a generator, and integer(X) and X > 3 are filters. This list comprehension evaluates to [4,5,6].

I was very impressed with this, at one time I was trying to come up with a syntax for this type of expression myself. At that point I'd never seen a language with a compact expression of this idea. I thought SQL where clauses are very close but the rest of the SQL statement is a bit to verbose for this type of case.

Then as I read the example program after understanding this I could clearly see the logic of the Quicksort program and for the first time I understood how the Quicksort algorithm works. I'm a little embarrassed to say but I've never fully understood how a Quicksort algorithm worked before reading the Erlang example. I very clearly remember reading my first introduction to this algorithm back in 1986, or something like that, in a Compute!'s Gazette (a magazine for Commodre computers). I never understood how that Basic implementation worked and from then on I've had some sort of block on my understanding how this algorithm worked. I've come across it may times in may different languages but all the implementations have been cryptic to my eyes. All I could clearly remember is the phrase "divide and conquer", which I think was mentioned in that first Computes!'s Gazette article, but never quite understanding how that helps you sort quickly. This phrase haunting my memory whenever I came across the Quicksort.

Well after about 10 minutes into reading Erlang's whitepaper with no exposure to Erlang before this and once I finished reading their "Example 4 - Sort" the program,

This program sorts a list using the Quicksort algorithm:
     sort([]) -> [];
     sort([Pivot|T]) ->
          sort([X||X <- T, X < Pivot]) ++
          [Pivot] ++
          sort([X||X <- T, X >= Pivot]).

simply blew me away. Suddenly all the pieces fell into place in my mind that had been starting to build in my mind since 1986 till now, 2007, and I suddenly for the first time in 20 years actually understood how Quicksort is implemented. It was here staring me in the face, plainly and succinctly written, which lead me directly to reasoning and logic behind it just like how a great equation compactly and cleanly describes the core of an idea. As a bonus I could see that my work on what they call a list comprehension was not only a good idea but is even a more powerful construction than I originally thought it was. It had helped me understand a difficult concept almost effortlessly.

I suspected before that something like a "list comprehension" is a very common abstraction in algorithms that really should be expressed in a language directly. Coding this sort of construction in C or similar languages is difficult and tiring, especially after you write and debug one for the hundredth time. But now I can see the raw power of using this kind of construction in practice. I think it was probably these details of the implementation of the Quicksort that was getting in my way of understanding the core idea behind the Quicksort itself for all these years. I can see that this language construction is a wonderful tool.

2007-02-28T13:40:00.000-08:00

There's a great post at WTF about how bad programmers can continue to write bad code for a long time and think they have been writing great applications that whole time. This probably applies to most people, myself included. Not too surprising when you consider that usually the only real post-mortem is usually what you write up right before it hits production and all the data comes from memory with no hard evidence from production behind it.

What Could Possibly Be Worse Than Failure?

2007-02-27T06:47:00.000-08:00

Here's a dandy in Ruby, that I just wrote up.

Rather than go the direct approach (like "'remove my spaces'.tr(' ','')") this will do the same thing but in the process will,

- Find all the combinations of characters than can be removed.
- Then removes them for each combination.
- Then takes those removed characters from each combination and finds which one removed the most spaces without removing any other character and picks that solution.

Man, it's hard to write code this convoluted, but fun!

# remove_spaces.rb

def do_combos(range, pos, combos)
  if range.last - range.first == 0 then return combos end
  split = range.first + ((range.last - range.first) / 2)
  range.each { |i| combos[i][pos] = i>split }
  combos = do_combos(range.first..split.to_i, pos+1, combos)
  do_combos(split.to_i+1..range.last, pos+1, combos)
end

class String
def remove_spaces
  # make map of possible combinations
  combos = (0..2**length-1).map { [] }
  combos = do_combos(0..2**length-1, 0, combos)

  # make map of possible solutions
  solutions = combos.map do |combo|
    i = -1
    combo.inject(['','']) do |solution, do_it|
      i += 1
      if do_it then
        [solution[0]+self[i..i], solution[1]]
      else
        [solution[0], solution[1]+self[i..i]]
      end
    end
  end

  # find best solution, the one that removed the most spaces without other characters in there
  solutions.inject(['',self]) { |best, sol| (sol[0].match(/^ +$/) and sol[0].length >= best[0].length) ? sol : best }[1]
  end
end

p ARGV.shift.remove_spaces

A typical example,

mike@dedeX ruby $ time ruby remove_spaces.rb "test this string ! "
"testthisstring!"

real 12m3.352s
user 11m27.059s
sys 0m35.102s

But be sure to have a good machine to run this on if you are removing spaces from a string with more than like 20 some odd characters. It quickly gets out of hand and gets killed on my iron.

mike@dedeX ruby $ time ruby remove_spaces.rb "test this string ! "
Killed

real 3m31.015s
user 1m20.429s
sys 0m19.149s

I originally posted this here in WTF?!

Man I hate posting code in blogger, grrr.

Ray-tracing 3D app built over the weekend -- Pics, video & source code!

2007-02-21T18:03:00.001-08:00

This really inspired me to start blogging my progress on my current project.

read more | digg story

2007-02-10T06:45:00.000-08:00

A very good recommended read for all coders. This specifically covers web coding but is applicable to any type of code.

Getting Real: The Book by 37signals
http://gettingreal.37signals.com/

A basic takeaway from this book is to keep it simple. Which is not new (and they say so) but pushes the idea a lot further than traditional thinking on development. The keep is simple approach is usually in practice only applied to the actual coding and architecture part, not to the requirements. Usually people throw in as many features as possible to their apps which always makes them bloated in the long run. This is really a marketing problem. They want more customers so they try to appeal to all possible customers so they put in all possible features, which in the end makes a big lumbering app that arguably becomes less useful to all because it has so many random features that they never will use that gets in the way here and there. Most of the most useful apps are the ones that are super specialized like grep, tail, or ls (a.k.a. dir).

Another great takeaway is an important key to business, which I like to characterize by the phrase, "Never underestimate the power of doing nothing." The idea is not to sit around a do nothing all day but not to jump at things like it's a do or die emergency, sit back and allow the alleged emergencies to settle in. Most things are not as important as you think they are when you first encounter them. Sit back a while and let it digest for you and others involved and see how important it looks in a few days or weeks.

The big benefit to this is that doing this errs on the side of doing less and not on the side of doing more so you have much less of a chance getting into the situation where you are spinning your wheels all day fighting fires and not getting much done in the process. The dangerous cycle of doing more to accomplish less. If something is important to work on it will still be important to work on next week. Also this helps the "getting into the zone" process where it give you more freedom to focus on one thing at a time to do good work rather than doing many things at once.

I used to jump at every little thing like it needed to be done right now. When you do that you increase the amount of work you have to do in an exponential way. You begin to meddle in things that are not so important which tends to make things worse. This requires you to keep fixing things over and over again because you have a perception that it's not good enough when it actually was good enough in the first place and you didn't need to do anything about it. It's not that the work you do is bad when you do this it's just that you're adding value to something that is not important as something else more important. There is a huge opportunity cost that you are paying here. Usually no one really cares all that much when they step back from things anyway. Following a ton of little emergencies takes a huge chunk out of your moral in the long run. You'll start saying to yourself, "nothing I do is ever good enough."

Remember that odds are that most things are not that important relative to all the tasks that show up on your radar. Take comfort in the fact that if it is important that it will be pretty obvious that it is important next week or even in a few weeks. Let things compete for your time rather than you competing with yourself in order to do everything.

Start saying to yourself, "this is emergency is not good enough for my time, it's not worth it."

A way that can help to start to think about it is, only do something if it was obvious last week that you needed to do this today. Like, "okay, I knew that I would have to eat lunch today so I'll go ahead and do that rather than fix this bug that I didn't know about yesterday." There are a lot of other little examples that help in this book that I very much recommend reading if only for this single reason alone. They took this idea to heart and it shows on every page. This important concept makes for better work and a better work environment.

2007-02-06T06:57:00.000-08:00

Ran into this today. Has some interesting thoughts on the whole nasty thing of why is there is much bad etiquette on-line that I haven't considered before.

http://pogue.blogs.nytimes.com/2006/12/14/14pogue-email-2/

Like this one,

"Young people who spend lots of time online are, in essence, replacing in-person social interactions with these online exchanges. With so much less experience conversing in the real world, they haven't picked up on the value of treating people civilly. That is, they haven't yet hit the stage of life when getting things like friends, a spouse and a job depend on what kind of person you are."

What also might be the case is that even if an adult has this type of experience in in-person social interactions they might not even try to apply this to their on-line presence, until they somehow learn that it's a good idea to apply it there.

This one is interesting too,
"Many parents haven't been teaching social skills (or haven't been around to teach them) for years, but Web 2.0 is suddenly making it apparent for the first time. ('Web 2.0' describes sites like Digg and Slashdot, where the audience itself provides material for the Web site.)"

If parents haven't been teaching social skills for a while, this would seem to make sense. There seems to have been a sort of a non-goal oriented approach to parenting in general over the last 30 years or so for most parents. My pseudo-unthought-about-idea is, when I say "non-goal oriented parented", I mean that the parents sort of perceive that the child is already in the end game of their social development so to speak and don't treat them like they need a behavioral adjustment or can even be changed, they sort of are that why and can't be changed. In a sense they treat them like an adult from day one. The parents don't try to hold up a goal for the type behavior of the child, they just work with the one that the child sort of naturally, or accidentally, acquires. They seem to believe that the child will end up acquiring the proper behavior once they come face to face with the reality around them, which I think is sort of true although there is a lot to be said for helping your child become mentally and socially prepared before you come face to face with it all at once when it is do or die, when first going out on their own, and not run into the probably if falling down so hard when you hit that reality. That traumatic experience I think has emotionally scared some people pretty badly to the point where it becomes very hard to get up from.

Also, it's weird that in general you used to hear a lot about the importance of netiquette a little while ago. Now there is not much talk about it anymore at all. I don't even remember the last time I heard the term until I read this article. He's right on when he titled this "Whatever Happened to Online Etiquette". Web 2.0 seems like it would make this even more important in peoples minds.

2006-12-23T06:44:00.000-08:00

This morning I heard that ryzom.org did not make their goal with the Ryzom game.

From their news mailing,

Hello,

I have bad news this time. Our offer to buy Ryzom and release it a Free
Software MMORPG has been declined by the court.

At the end, there were three offers presented, and the other two were
bigger than our's. They are keeping more employees than we do, and
offer more money. We should get the details of the other offers soon,
so we should be able to know more more then. In the meantime, I would
like to personally congratulate the winner, Gameforge, and I wish them
good luck.

However, even if a conventional company is winning the bid here, the
campaign is still a success. It has made a lot of noise on the Net, it
has been covered by mainstream medias, we have found two FOSS
investors, we have got the backing of the FSF, 170 Kâ‚¬ of donation
pledges have been registered, and â€“ perhaps the most important â€“ we
have found we were not alone dreaming having of own our A-Grade MMORPG,
of owning a world.

We are currently discussing how we could still achieve that. If you want
to join us, please come and take a seat in our boards:

http://www.ryzom.org/forums/viewforum.php?f=1

--
Xavier,
On behalf of the Ryzom.org community.

Like Xavier says this has been pretty successful anyway. This could be some first steps in this bold new direction.

More info in their forums.

2006-12-20T07:02:00.000-08:00

http://www.unionvoice.org/campaign/highspeedpolicy/

I think this is important for a few reasons. This is a good campaign that many would agree that it's a good thing plus most would probably agree that it's a very achievable goal. It's a good place for people to start getting active and connected with eachother and unions.

2006-12-16T07:46:00.000-08:00

"The Free Software Foundation has sent out a press release announcing that has pledged $60,000 to the Free Ryzom Campaign. This campaign is seeking to purchase and free the Ryzom multiplayer game, the owner of which is currently in bankruptcy court (LWN covered this campaign last week)."

read more | digg story

I certainly hope that this project takes off. I agree with the FSF that this is a very important project. This could be a major milestone in the development of free software. They are not only trying to GPL the code but they are trying to go another important step. They are attempting to run a democratically run mmorpg, in the sense that users would be considered developers in the decision making process. Running under the GPL for all code and assets is rather important for this goal to work right. It's important to make the enterprise not owned privately for something like this to actually mean anything in practice.

Tale of the Desert claims to be a democracy run by the players in some sense, but the democracy there is limited in power. There is a bit of a political arena in the sense that some game rules can be affected, basically by petition but it appears that Andrew Tepper (the man that runs the MMO) still holds control and probably veto over any decisions that come out of the game run political arena. The political process is really a part of the game in the sense of that game. The fact that it may affect the development process of the game in a very limited and controlled scope does not really give the players control over the game. This is really a feature of the game in my mind rather than true democratic control, whether it's supported by the game code or the development process itself. I don't know if Tepper actually truly claims if the players have any real control over the game or not, but it seems obvious that Tepper holds the control and he is really the one making the final decisions behind the changes wether or not the impetus of those decisions comes from out of the game's political area or from out of his own head. It is an organization like this that Ryzom would need to avoid in order to have any kind of real democratic power within and without the game. There cannot be an entity that "owns" the game and can affect the decisions of the democracy. Possibly there can be someone (or some entity) that does the decision making process for how to carry out the collective decisions of the player public but that person (or entity) cannot have any more power to affect those decisions than one player in the game.

2006-11-03T11:52:00.000-08:00

Great article, Nine Things Developers Want More Than Money

2006-05-18T15:19:00.000-07:00

Unleash the Fury

This is probably the coolest feature of an MMO that I've seen in a long time,

"A gripe heard often in MMOs are the inability of late adopters to play with early adopters of a game as their friends have far outranked them. In Unleash the Fury, higher ranking skills do not replace the lower ranks in your spell book and this allows and encourages more experienced players to play with less experienced ones by selecting matching skills."

MMORPG.com
if put together well with what they say about their hotbar templates and grouping, this could be very cool.

There are also few other realy neat ideas in there too.

2006-03-08T10:48:00.000-08:00

I'm an indie game developer. In that space everyone does C++, and badly. In my day job I do enterprise applications in Java mostly, at least lately. I've done a lot of Visual Basic, ASP, SQL, and COBOL in my day. The Java we do is okay in my day job. But the game engine that we've used in C++ can be horrible OOP. Thinks like non-moving NPC object that knows how to navigate around a maze and has all the data structures for doing it in memory but never ever needing to use it because it extends from the AIPlayer class so we can get its scripting hooks. Huge objects with rotten cores, a.k.a: Undead Hulking Classes.

The game industry is hooked on C++ to a fault. I found myself longing for the days when it was all Assembly; at least people then knew better what their code was doing. Also C++ has always been a pain to write for a number of reasons. C is better but I never quite got the point of .h header files, and they are such a pain to maintain but they are pretty much necessary if you want to write a program longer than a page long. Anytime I have to write out a definition of something twice is annoying. (I know one is a definition and one is a declaration; but common, really. What am I going to declare about that function if not its definition?) Writing the .h header files feels like I'm writing a cross-reference for my code for the compiler, which the compiler is obviously already doing to my code anyway otherwise it wouldn't complain when it finds that my hand written cross-reference doesn't match its cross-reference. Don’t get me started on the unnecessary mess of pointers. Pointers to pointers, oh my!

I got interested in Lerp, Jonathan Blow’s little (still experimental) language for building games. He seemed to be referencing Perl a bit so I checked that out a bit. I was impressed by a good portion of it, until I got to the object support, which made me go, "what?!" It looks like they used the references support all by itself to sort of hold up the whole object system, which sort of put it at distance from the rest of the language (a distance you have to travel to back and forth each time you want to use an object).

At one time I looked quite a bit into Lisp. The language is lovely if not obfuscated. All the nice little parens all lining up. vim even lines up the code for me automatically based on the parens! But when I start writing something that is of small to medium complexity, getting all of those parens to line up was making my eyes spin in their sockets. It’s a beautiful and complete idea that all of the processing of every part of the program is within a cascading tree of parens within parens going up into the sky (a good number of them recursively, and up into the sky with a beautiful tail-end collapse when it’s all done). But other than that beauty the language implementation within that is difficult and confusing, pre-fix mathematical notation, for instance. And while seeing every bit of code as containing other code, while it makes sense algorithmically it is hard to conceptualize because although it makes sense that you can do that algorithmically because it implies an order, it is easier for most people to see it in a just a simple list of instructions. Perhaps I just don’t get Lisp. Every time I thought I was close to getting it there was some weird syntax like even the simple "(+ 2 (* 3 4) (- 2 (* 3 2)))" that would just take too long to read or write and I would start to get fears about trying to maintain that mountain of parens stacked up like a pile of so many needles.

I started making notes of what I would want in a language. I tried to image what I’d like to write to make the program work. I wrote up some notes in vim (for some reason vim is fascinating to me lately, probably because toolbars and drop down menus always seemed like a UI hack to me).

While I was learning Perl I heard about Ruby. I went to Why’s (poignant) guide to Ruby to check it out a bit and to take a break from Perl because I just heard about Perl’s OO hack into the language and was displeased with it for the moment. I’d probably come back to it after seeing what this Ruby is all about. Someone somewhere said it’s got a great OO system. Besides he says that this Why person is some sort of genius. I pursued a bit. First saw a bit of code that didn’t look like OO to me at first but somehow I knew exactly what it did.

5.times { print "Odelay!" }

-- (quoted from the guide.)

Interesting. Then I started reading. Because Why’s guide is somehow poignant. Then a bit later,

['toast', 'cheese', 'wine'].each { |food| print food.capitalize }

Oh my, oh my. Would you look at that? That’s a bit like something that I was wanting, the ability to pass in a group of thing so each of the things are passed into a function or something one at a time. Not the quite way I was thinking, but this seems prettier, much cleaner than the goofy first draft syntax that I was thinking of. Then he’s saying that the 5.times from the first example means that the .times is a method on the object 5. WOW! 5 is an object! 25 is an object, and so is 26, etc. It makes perfect sense. But I never would have thought of that syntax, maybe something more overt like Java? "new Integer(5).times()". But then how to get that { print "Odelay!" }part in there? Hmm, function-pointer? (yucky!). Everything is an object, even the numbers. Later in the book I noticed that the type system that is so overbearing in C and in Java is gone all of the sudden but I never am wanting to define them in such a way because it seems very apparent what everything is already. Odd but comforting.

Then I found out that things like "answer = 5 * 6" is really syntactic sugar for "answer = 5.*(6)", or if you wanted "answer = 5.* 6", stunning, simply beautiful. Even "if ( things == 5 )" is actually "if ( things.==(5) )". Then I find out you can use full introspection on the objects like "p 5.methods" and see all of the methods available. Mind blowing. So this is what people mean by full object-orientedness? Aaaaaand you can modify those methods, or add new ones, even add methods the main class of everything, then there are these mixins (wow!), which looks like it would fix the whole Undead Hulking Class thing that plagues game programming lately. There are modules you can download to allow you to play with cool things. Oh there is one for OpenGL, and even SDL, or you can build your own, nice.

At this point I totally forgot about Perl, but I was reminded when I saw that Ruby has regular expression support as well. The one thing that it might not have that I had in mind was a modified reg-exp for querying against sets of objects rather than strings, but I’m pretty sure if it doesn’t have it I thing I could extend the base objects a bit to do what I’m looking for. Then my head is really spinning; not spinning as in spinning, but spinning as in flying. (I think why has somehow infected me.) I can’t believe this, I could extend the languages base objects a bit, and that is not even intimidating for me, I feel like the language is not treating me as a second class citizen. I’m on equal footing with the language and we are here to help each other.

What? Am I imaging all of this? That’s too good to be true. Usually I’m used to people like Gosling saying "No, no, no, you can’t do that with the language. That just doesn’t make since. Why would you want to do things like that anyway? How does that fit into the My Design Of Java? You need to do it this way, or this way. See how that fits nicely into my language. Oh the beauty of my design! You’ll just need to rearrange your programs logic structure a bit here, here, here, and there a bit, but only a bit." It’s as if Ruby’s Matz is saying, "Hmmm. That could work. I see what you mean. Not what I ever intended, but it could work nicely in your program. Let’s try just adding a few things to my base Object here and here and here a bit. Let me know if that’s helpful."

A language as a partner; that’s what it feels like, and I’m just starting to learn this language.

Then there was another thought that struck me. These days, maybe people only work in languages because its fun for them to work in that language. Truthfully, I don’t think here’s anything wrong with that at all. People usually pick some language for some reason or another but once the project gets to a certain point the language starts to get in the way somehow, or their design gets in the way and they have to do some ugly hack here and there to get it working. People sort of wince when they do it and posture around it; like, "I wouldn’t do it that way normally" or, "there just is no other way to boot strap it here", and accompanied by a large portion of self-flagellating don’t-do-as-I-have-done comments in the code. I think that this is inevitable in any program in any language and it needs to be welcomed rather than scoffed at. I think Gödel may have much to say here that would put those poor programmer’s minds at ease.

Maybe I should just use Ruby because it’s turning out to be fun to play with. Forget about any other goofy parameter like stability, or performance, or maintainability, what have you because all of those things are going to be a problem anyway in any language I choose, no question there. The only parameter that I can think of right now that is hard for me in a language is, will it run on the platforms I want? Ruby has that down (like just about any other language out there anyway). I have confidence that any parameter that comes threatening to stand in our way, Ruby and I will be able to face it. And maybe that is the true reason that people use the languages that they use; confidence in themselves with the language.

People always say use the right tools for the job, meaning use the right language for what you are doing. But for game programming it’s not a even a question, it’s a mandate; use C++. People all say there is really only one language for game programming right now. This always seemed a weird thing to say, since C++ is not geared toward game programming at all, as a language. They never had that in mind when it was developed. "Hey, Stroustrup, can I write games with C++?" "Um, sure I guess so." But for some reason that’s all anyone seems to write games in. I guess that’s why C++ is usually so abused in game programming because it just doesn’t fit quite right for the problem domain. But then again, not too many years ago the answer would usually be, use Assembler or maybe C, or a mix of both. So things will probably be different in the next few years. We’ll all be writing games in Lisp or something.

2006-02-17T20:40:00.000-08:00

The Forge

Wealth is an agent in a gravity. There is a pull which one cannot deny. The pull delineates. The pull confines. Aspects of the terms of coefficients fascinate and horrify. The pull. The action. Groups of people pushed by the cold air and rise to the lighter warmer atmosphere, where the mind takes its own form and the muscles unfurl. Some are the closest to the warmest spots; some are the closest to the coldest spots. Intriguing the patterns. There are times in warmth; there are times in darkness. Attempting to gain an affect, trying to redirect the pull of the agents to a pull from within themselves. Imagining that the warmth that they feel is coming from within and that that this is the source of the power. “The power is not the wealth the power is me.” Facing the sun, declaring that he is the source of the light. But there is no control of the nature that is the market, there is only control of the people absorbing the heat. In order to receive one must deny. Driving the other group away from the heat. Melting their wings with the scorching wealth they are nearer to. They fall against the mantle of society. Nothing falls below the mantle, yet burning with the fire of fortune, positioning themselves on the seat of the natural market they drive the others into the earth into the frozen ground by the art of displacement. No heat will return to the bones of the others; no light will return to their eyes. No sound will exist for them. The snow will layer upon them until they cannot be seen by any light. Their impurity will not dilute the comfort of the chosen ones, put there by happenstance.

2006-02-14T20:55:00.000-08:00

The Art of Code

What is it that I am trying to accomplish? Is it a work of art that I strive for? Is it really an art form this coding and game development that I do? I believe so. I think that any human endeavor is an art form in and of itself. As long as a person does it there is necessarily some thought put into it and some effort to do it. Even though the level of effort and thought my not be comparable to the process involved in some other forms of art the effort and the thought and the dedication is there. This seems to be congruent to the process of building or part-taking in any other non-debatable art form. This can not be explained in detail, but should be thought upon with completeness.

2006-01-24T21:25:00.000-08:00

Cube - Mike Nelson

Again in the cube of another.
Two men peering into the window on the table.
Code flashing, lips mumbling.
I'm near to the one at the keys.

There is a basking in the time,
a hesitation from the grasses jittering outside.
a readiness for the form of the code described
more in the mind than in the transparent form
of the lines that flicker.

The description of form, once gone, once
the flight of the moment passes,
will come to define them on screens to come.
They will go on, to another place.

Suddenly, in an instant they both move,
thusly the code is formed and the loop is complete,
the job is done. That instant will define the
code. As the code will depart, leaving just
the moment to live on.

2005-10-27T07:12:00.000-07:00

Why do so many license games suck?

Seems like there are a lot of games that take a license to use a good property, like a movie (for example: The Matrix or The Lord of the Rings or Dungeons & Dragons), what have you, that suck. But it could be that the projects from licenses don't get canceled as often if they don't meet the bar of non-suckiness. There are a lot of projects that get canceled. There are a lot of games that suck. There would be a lot more games that suck if projects didn't get cancelled probably -- although not all projects get canceled for this reason. Wish I knew how many did for this reason though.

It makes less sense to cancel a project from a well known license just because the game is turning out to be sucky. If you can finish it but it's pretty sucky as a game, you can still make money off of it because people are more likely to buy a game from a well known license. Seems like that could be a main driver of why so many games built off of licenses suck.

Also as an aside, when you do a license title it makes little sense to do something innovative in game design because you might screw the value-add of the license if the innovation is not easily recognizable as a marketable game (like if it's not in a known genre). If it's so innovative it could detract from the marketing of the license to sell the game and if the license isn't the key part of the game, why even have the license at that point (licenses can be costly to get)? Also the license holder is probably not thinking of having some innovative game for their property, they just want a regular game to give a boost the value of their property.

Plus, there is a high risk that the innovative stuff that you invest R&D on will fail to be compelling (you find that you can't build a cool innovative game for whatever reason); that risk is too unnecessarily high to the project have when you have the safety of the sure bet of a license to drive your game sales.

2005-10-21T12:20:00.000-07:00

High Latency = What the hell is this program doing?

2005-09-09T08:15:00.000-07:00

Whatever, as long as it works

There are a lot of layers of complexity in the life of a coder. Most of it is made up. Examples: VB, DMAC, COM, DCOM, ADO, sockets (or Winsock), TCP, UDP. Just like Word is a beefed up version of notepad with more functionality. All these complexities are there to help us. Joe Spolsky said, these are abstractions of some high level functionality mapped to some low level process to make it work.

For example, as coders, we use tools like C++, Java, COBOL, LISP, or etc. to write programs in a higher order language that creates lower level object code (or byte-code, what-have-you). This allows us to think in higher level abstractions, and closer to how we normally would want to think about solving a particular problem. This way we don’t have to mess with or hopefully not even think about the lower level process at all.

Joel says, I believe correctly, that sometimes there are leaks in the abstraction. There are points when the abstraction breaks down because the lower level process is creeping outside of what the abstraction is build or designed for. The makers and advocates of these abstractions usually don’t get around to tell you about the leaks so they usually will catch you off guard the first couple of times you run into them. Oftentimes when I see coders run into this sort of thing the first time they tend to yell out things like, “Well that’s just dumb! Why would it do that?!” (as I have on a number of occasions). An example situations is when someone writes a massive SQL select query that takes 10 seconds longer than you think it should to run but then when he reorders the where clause in a way that you’d think shouldn’t make any difference, all of the sudden it runs in under a second. The coder in this case may only see the top level abstraction and doesn’t know enough about the lower level stuff in how the database handles SQL select to see why re-writing the query a bit can save a bunch of time. As coders we’ve all been in this situation and suddenly we have to go search around to try and find a deeper understanding of what is actually happening. This is a difficult thing to do. This can be were some coders will just “give up” and get a faster machine or update the requirements for their software to twice as much RAM as was originally needed. Hey, whatever works. But not looking closer can loose you an opportunity to gain a greater insight into your toolset, which is something that we can all obviously all benefit from. And this search might be the true art of coding.

An odd thing about these layers of abstraction is that it almost never seems to end. Basically you have the software layer on top of the operating system (OS) layer on top of the hardware. But within those layers especially the OS and software layer there are all sorts of layers that the software engineer has to be aware of. Like in Windows you might have your COM layer going to ADO systems which link to ODBC then to your database via the network layer. You may have OpenGL and/or DirectX, Windows API’s, .NET runtime, Winsock. In Linux you may have OpenGL via SDL with socks, OpenAL. There are so many layers that it seems impossible to actually understand what’s going on in the hardware. Even the memory is abstracted. Each program treats memory like one long block of memory when usually the operating system treats it as a collection of pages of memory scattered all over RAM with memory from other programs intermixed with it that are invisible to other programs. Sometimes these pages are not actually in RAM at any one time, they might be swapped out to the disk waiting for the program to try and access that bit of memory. All of this is complete hidden from the program. Even the hardware sees memory as something different. It doesn’t see it a pages just a long stream of bytes, but it might access it in a total different type of way based on the architecture.

Even then there are abstractions within that. Some pages or bits of memory might be temporarily held in a cache of memory that is quicker for the CPU to access than regular memory. So in these cases it can just grab is from the quick cache rather than main memory.

Even the CPU in most modern architectures can run instructions out of order while it waits for the longer memory fetches and instructions to finish, then it will reassemble the correct result as if it ran the instructions in the right order. This is only an example of such abstractions. There are many, many others of these. It really does seem impossible to understand what is going on here. I believe that it truly is impossible to truly know. Even if you understood every detail of every abstraction and how it really works it is impossible to hold all that information in mind at the same time and know how it’s going to work. The complexity level is just too high. Weird unexpected things can happen all the time. In fact all this complexity is exactly why we have abstractions in the first place. Otherwise we’d be perfectly fine writing to the hardware in straight byte-code or maybe in some even lower from abstraction.

Like loading a level in a game might tie up a bunch of memory for pre-processing of some game data then the memory is released afterwards but the memory is not really released back to the OS because the memory manager in the game is still holding on to the big block of memory because it thinks its going to need it again soon when it’s not. Things like this happen in development all the time. Abstractions, which in this case might be an abstraction that the developer himself created, can act unexpectedly. Or take the case of a developer that created string function that handles Unicode strings but fails on a strange character set because the user is using a language that uses Unicode character 3 bytes long rather than the expected 2 byte maximum.

Each system in a non-trivial program is usually an abstraction of a concept in the same way. Memory managers are one. It abstracts the tedium of carefully managing your memory throughout the application. A rendering system in a game is another, or sound system, or file reading/writing system, or scripting system, or user input system, ui system. All these abstractions help a ton but can easily lead to strange unexpected errors that you might not be ready for when writing some new functionality. Normally these systems are the ones that you really need to look out for. The ones you write yourself. I’m not saying don’t look out for other systems for problems, but the ones you write yourself (or in-house) can be a major problem because they are usually written to cover a limited number of functional points, but as you develop the system you inevitably want to add functionality to it to do something new and you find that you already have a system that can help. So you go and use that system to do something it may not have been designed for, but it sure looks like it was designed to do that, so you use it. It might even work at first then later when you start using it a lot to do that new thing it might tax the system and just crash, or leak memory all over the place, or bog down in its routines processing the new cases, or fill the disk, or so on. Soon you wonder why the system that you wrote last week is not handling what you thought it could handle yesterday.

The more systems you have in the program there seems to be a combinatorial explosion of the number of things that can go wrong in the system. We all know what people say about things that can go wrong. I know a lot of Object-Oriented people will say thing like, you really need to tightly define the interfaces between your systems and you won’t have so many problems. I’m sort of skeptical of this. When latter changing your code to do something new these little OOP constructs are usually the first to go. They don’t really do anything to solve the current problem they are just there for the programmers benefit to help her understand what the hell is going on. But hey, we need all the help we can get so it’s all good.

This is sort of like the idea of adding getters and setters around all private/protected members of a class “because you know someone it going to want to do that in the future”. The odd part of that is that, is it even worth it to design for some future event that may or may not happen and if it does will it even happen remotely like you may think it will? So in the end, you usually just write a set of functions that just set the member variable without doing anything. But then they can say you now have a hook for whenever other people do something in your class you can now have control over it because they have been using your getter/setters. So later you find it convenient to go change it to update the state of your class when someone uses your setter, then it goes and breaks another set of classes that have been calling your class and using the setter. “Not my problem anyway,” the class says, “That other class should not have been doing that in the first place, it should have been doing it the right way in the first place, let the other class change themselves, this design is the right way.”

I seriously don’t think anyone has any clear idea of what the “right” way is when it comes to software design. Whenever someone says “this is the right way” the first thing that should come to mind is, “Now wait a sec, is that really true?” A lot of people have good ideas on the subject but sometimes they stick to it like it’s written in stone or something. “That function has more than 10 lines of code! It is way too long! How is one to understand it? Its time to break it apart into smaller, bite sized portions.” Hmmm. Sometimes its easier to me to have some stuff all together rather than browse over to another function to see what it’s doing with the other half of the parsed string or what-have-you, even if it is 5 pages long. In some cases the order of a ton of operations is more important to keep in mind than readability of the code. Personally I’ve never put much stock in that one. Are we all so afflicted with ADD that we cannot possibly understand 20 function longer than 10 lines? Sometimes we need to tax that part of the mind to correctly understand what is going on. Also, in a real way it’s more complex when you have 3 smaller functions. You have to look all around for the little bits of code and put each piece together in your mind. And if you are always breaking your functions apart just to fit the model, that’s a lot of extra work. Is it really a good idea?

Many people call this a “religious” debate. Usually each side has strong opinions about how it should be and they just yell at each other until one side is louder than another or has more books on the subject or whatever. A common example is the famous Design Patterns book. The book is so high level about OOP class design that it barely touches real examples and only then in a sort of academic fashion. A lot of the design patters make sense in concept but it is so far from concrete examples that it makes me uneasy reading about it. I’m not saying it right or wrong, just that it’s so self referential to the OOP argument that I wonder how much application it deserves to real word problems. Perhaps I’m being unfair. Usually books like this take a particular point of view on design and apply it to real-word software and say things like, well a lot of people use a class to create other kinds of classes, so that must be a design pattern that people use, so lets call it a Factory Pattern. This is actually very useful to take a particular point of view on design and apply it this way. It tests the point of view and stretches it a fits it to real world problems and solutions. People should just realize that it is just a point of view, an abstraction of the real world problem and stop fighting like it completely fits real world problems without exception.

I see the same sort of thing with arguments between tools. Like the vi / emacs debate. It’s not like vi is the only way to edit text files and emacs is just a rough hack to simulate the pure process of vi or vice versa.

vi, like many things in software, is a made up concept. Even memory as software sees it is a made up concept. A lot of things are just arbitrary; it didn’t need to be that way. Oftentimes things are just built that way because of convenience or performance reasons; the same sort of reasons that you use build your own software. Someone thought it would be cool to do something new so they try and build it. Something doesn’t run quite right so they tweak it a bit now it runs well. But now it’s a bit slow so they tweak it a bit more and get it faster. Then they think it would be easy to make it do this other this other useful thing as well so they add that and soon they have BIOS 0.3 or something. We got to realize that in software, we standing on a house of cards. But all is not lost, far from it. The house of cards is very well tested and stands up very well. Sometimes minor things in software breaks or flexes a bit but the rest of the structure can handle it so the whole thing doesn’t come crashing down. But the principles that build them are essentially arbitrary or at best fits a problem that someone was trying to solve at some particular time. The point is that it didn’t have to be built that way at all; each part could have been built differently. It wouldn’t be dumb to try and build it differently. There is no right way to build something.

This is actually pretty cool. If there is no right way to build something you can build it almost any way you want and as long as it works it’s good enough. We’re used to people propping up technologies and idea as being the best in its field. Go to any software vendor and you’ll see things like,

“IntelliJ IDEA is recognized by many Java developers and industry experts as the best Java IDE on the market. With its industry-leading features, IntelliJ IDEA relieves Java programmers of time consuming routine tasks, remarkably boosting their productivity.” – from the IntelliJ website

While I agree that IDEA is a great product, it couldn’t be the best way to do it. There is always another way to do it that someone else might prefer. As they say, there is always another way to skin a cat.

There seems to be many ways to do the same thing. If two software shops build the same app, I think everyone would agree that the two apps will not be written the same way. One might be in Java and one might be in ASP or LISP CGI. But even if they apps act the same way and are written in the same languages with the same tools and on the same platform and even using the same programming methodologies and both teams learned from the same mentor and had built 10 projects together over 5 years, the programs are not going to be identical. They’ll probably be a lot different even then. The funny thing is that they will probably both work. This is not the expected answer if you expect one to be better than the other. One might say something like the code is easier to read or is easier to maintain in one case or the other but that is just a matter of preference as far as I can tell. Some people find it easier to read COBOL over Assembler, but some people find the straightforwardness of Assembler easier to understand than COBOL’s data structure and sentence-like format. Someone might come up with a cool message routing system because he was playing Frisbee the other day and he saw the messages in the code like the Frisbee. Some might say that performace is better in one way or another in the two systems but that is just preference as well. Some people expect certain things to be faster than others while others may expect the opposite, which is also probably why the two teams build it differently in the first place, because each had their own preference of how it should work.

The mantra that is emerging in this writing seems to be, “whatever as long as it works.” I think that there are so many layers of complexity to software that no one really understands what’s going on. Personally, I think that is just great. It just makes for a lot of potential problems to solve. You can re-write the whole bloody OS if you want. Plus you get to solve them any way that you want to. Hell, you could even write a Tic-tac-toe program and turn it into a AP/GL package just because you like Tic-tac-toe programs as applied to accounting packages. It’d probably work just as well, or maybe even better, as starting with a Payroll program.

I think the “whatever, as long as it works” approach might be the only practical approach to building software. You just build it the way that you think it should be and then test the hell out of it. If it works great, if not tweak it or re-write it or whatever until it does work. I feel that this is the only constant out there. The only bar to entry is if it works, there are no bars like OOP (I keep picking on them but there are many other things that do the same thing), or eXtreme Programming, or Water-fall design, or even breaking you code into many source files, just put ‘em all in one monster file and you’ll only need to open one file to edit your code! Ack, not for me, but whatever floats your boat, and it really is your boat, not the OO Consortium’s boat. They don’t have clue one about how you run your ship.

This makes practical because this idea is a bit like the scientific method. Which seems to work pretty well. The scientific method doesn’t care about how you do things or even what conclusions you come to, all that matters is that the experiments back up what you say. How else could physicists come up with something so counterintuitive as quantum electrodynamics, which makes no sense why it works but it actually works and rather well. The scientific method seems to work well because it forces you to think in terms of “well I have no idea how nature actually works, so well just see if this one thing here works the way I expect it to.” This can be applied to any system and seems to work well with nature with is incredibly complex, so why not apply it to computers and the software world which is also very complex, who’s mechanics is also mostly unknown to us as individuals or probably as a communities of coders and computer scientists even though it’s almost completely man made by us.

There are just too many unknowns out there to think you know just how it should be done, whatever it may be. This may be somewhat a self-fulfilling prophecy anyway since you can take most any approach to solve most any software problem and usually get it to work somehow. If you solve a problem a certain way it can give a false sense of confidence and make you think that this is the right way to solve it.

So I don’t care how you solve the problem, just do it the way you want to and test the hell out of it and make sure it works. It’s all good as long as it works.