Tao of the Machine

NeoPets CCG

Cool, there's a NeoPets card game now. (It probably has been out for a while, but I am not so sensitive to trends and such...)

I might be a bit too old for it, but it's still cool. Then again, whether a game is worth playing or not is mostly in the rules... all the rest is just sugar.

Here's how to play it. Hmm, in some ways it resembles Nova a little... It's more of a tactical game than a strategical (like Magic or L5R), and luck plays an important and very direct role.

The case for reinventing the wheel

Software reuse is cool, but sometimes it's better to write something from scratch.

I once overheard somebody say that X was the company's best programmer because rather than writing something himself, he would look online for components to reuse, thus saving a lot of work and time. (It wasn't a programmer who said this, by the way.) While this is generally true, especially for application programming, it is not an absolute truth. Of course it's a waste of time to write something yourself if perfectly good code is already available. But there are other cases.

1. Sometimes it's easier/faster to write new code, rather than trying to understand existing code. I encountered this today... for my work, I am writing a module that talks to an FTP server in a certain way. There was already (old) existing code, that we never actually used, and that pretty much did what we wanted. Pretty much. It turned out that trying to understand the old code, and trying to make it work conforming to the new specifications, was more work than I thought. I now think that writing something new would have taken less time.

2. The new code will (or should) do exactly what you want, while the existing code might not. For example: Python first had xmllib, but that didn't stop people from writing a more sophisticated XML framework, because xmllib didn't do what they wanted. And even now that xml.dom and friends exist, people are still rolling their own parsers, because they are not entirely satisfied with the xml package, for various reasons.

3. The existing code may be lacking in certain ways. It might be too simple or too complex. It might be buggy (so you either have to fix it or write your own). Maybe it isn't really meant to do the task you have in mind. Maybe it has licensing issues. It may not perform as well as you think it should. It might use a brain-dead algorithm. And so on.

4. When you write your own version, you learn a lot about the issue at hand. If I write my own XML parser, I necessarily need to know or learn a lot about XML, and probably about parsers, in order to do it right. When I just use an existing parser, often in the form of calling a few methods on an object, then I won't learn much at all.

Granted, sometimes you don't want to learn, because you're not interested in it, or because you don't have the time. But everything else being equal, having the opportunity to learn something is not unimportant.

That said, I often successfully reuse code, especially in Python where it's often easy to find a workaround if existing code has limitations. But I wouldn't go as far as saying that the best programmer is the one who reuses the most. Sometimes reuse is obvious, sometimes it's not possible, and there's a large gray area where the benefits of both options have to be considered, rather than just go for the reuse because "some" code is already available.

Hey, Goodyear didn't go out of business making wheels...

Finally...

Irrefutable proof that I'm evil.

Hum...

Lots of stuff going on before my vacation. Some work... I am designing a website... the site will possibly be maintained with Firedrop, which needs to be improved... another project is the "cloning" of a Delphi app, using Wax... some changes to Antilog are necessary... etc.

Currently reading: Robin Hobb: Assassin's Apprentice
Currently listening to: Haagse Mark, B-52s, Spyder-D
Currently hacking on: Wax, Antilog, Tarantulon

OK, so I don't really know anything to write about. Maybe tomorrow...

Super furry animals

De kritiek van Hans, part 2

(via Jarno Virtanen -> Glyph Lefkowitz) In this Artima interview, Bertrand Meyer mentions the importance of reducing complexity. "I think we build in software some of the most complex artifacts that have ever been envisioned by humankind, and in some cases they just overwhelm us. The only way we can build really big and satisfactory systems is to put a hold on complexity, to maintain a grasp on complexity. Something like Windows XP, which is 45 million lines of code or so, is really beyond any single person's ability to comprehend or even imagine. The only way to keep on top of things, the only way to have any hope for a modicum of reliability, is to get rid of unnecessary complexity and tame the remaining complexity through all means possible."

I prepared a long post, discussing the meaning of simplicity and such, but I wasn't content with the result. So I'll just say this: certain Eiffel features, like requiring getters and setters to access attributes, and static typing, don't reduce complexity... they increase it. The same goes for being anal, reducing flexibility, and preventing programmers from doing what they think is best. Reducing the number of rules makes things less complex, adding rules does the opposite.