Hacker News Reader

Comment by ihodes | Hacker News Reader

I got so excited for this that I actually began thinking about writing interfaces to the game for other languages. It'd be fun to compete in a Lisp vs Python—maybe one language would lend itself to a certain kind of tribe.

I'll be looking at the source soon, but in the meantime I'm curious to see if other people would be interested in playing this. There could be a repository of genomes/tribes you can download and compete against, or perhaps this would be done server-side so your tribe's genome couldn't be cloned?

As a side note, it seems to me that (unless cells can be aware of their comrades' positions) global position needs to be availible in order to build walls, which is damn cool.

Cheers!

View on HN

I'd certainly be interested in playing this, especially online. I'm envisioning a system where you upload your genome, and the system automatically puts it in battles against a random selection of others. Some sort of ranking algorithm is used to create a leaderboard. You can also choose to watch a battle between any two or more genomes you like. To avoid gaming the scoreboard that would probably need to not count towards their score, or only once a day or something.

>As a side note, it seems to me that (unless cells can be aware of their comrades' positions) global position needs to be availible in order to build walls, which is damn cool.

I don't think so. All global position tells you is "how far away are the boundaries of the map?" Unless there's something I'm missing, you can get everything else just by keeping track of "offset from where I started".

As another side note, restricting messages to integers seems pointless, since arbitrary information can be uniquely encoded as an integer given enough ingenuity. It's a problem that would get solved once and then just irritates people instead of actually constraining solutions. (I assume python integers are only bounded by available memory space.)

Limiting them to n-bit integers, where n = 4 or 8 for example, would be more pointful, but again I think it would probably only make a particular behaviour harder to implement, not significantly limit the set of behaviours that are possible to implement.

A way I thought might be feasible is having the actual games run on servers and then dump the game logs in a simple format, so they can be played back with either the original game or any kind of player people come up with, eg browser-based.

Concerning the integer vs bit, that was what I meant, was still thinking in terms of C ints. An even more extreme version would be to force the agents to store their state in a similar manner, but I think that would be taking it too far.

I'd rather see communication restricted to nearby cells, but possibly a way to leave messages in place (like ants do with pheromones). This would require cells to be a bit more autonomous, and would prevent information from propagating instantaneously. As we can see from real-world ants, this doesn't preclude cooperation, but does make it a bit harder.

Great, I'm glad I'm not the only one that likes the idea! Interoperability to other languages is definitely on my list for the future, and a kind of ladder-server, too, where you submit your tribe and it enters into a perpetual tournament and gets ranked.

I just noticed that your git repo hasn't been updated since late 2009–are their updates to this project that just haven't been posted yet? Perrrrhaps with additional comments that might make it easier if one wanted to contribute?

> ladder-server, too, where you submit your tribe and it > enters into a perpetual tournament and gets ranked

That would be too cool. I'd love to see this happen. I wonder what kind of market there is for something like this.

EDIT: I'm going to be looking through the code more today, though right now I am going through finals at college. I don't want to promise anything, but this is something I could see myself contributing to, if you'd want (though now might not be the time so early in the process). Shoot me an email (in profile), if you'd like to be in touch.

The code I have in github is pretty much identical to what I describe in the article.

Documentation is nonexistent, sorry for that. That was the first thing that came to mind when I saw that this hit the front page, should have thought of that earlier.

I'll go through and comment it though, this resonance has given me a big boost in motivation.

Why stop at a ladder-based tournament system? It would be awesome if we could have all submissions put into a persistant world and go on until they all die out. Kind of like a mmorpg for AI robots.

This is what I thought the article was when reading the title. It totally should be; how hard could it be to hack something together and run it on appengine?

I also think this project is really interesting (which is why I'm following it and some of the forks).

May I recommend Microsoft's TrueSkill algorithm for ranking genomes? There's C#[1] and Java[2] implementations available. Full disclosure, I have no association with Microsoft Research, but I am the author of JSkills.

[1] github.com/moserware/skills [2] github.com/nsp/jskills

EDIT (because for some reason my only option is reply): The other cool thing about TrueSkill is that it can handle multiple players on multiple teams. So, if anyone decides to add the capability for 1v1v1, 1v2, 1v1v2, etc, TrueSkill is ready.

It'd be fun to compete in a Lisp vs Python—maybe one language would lend itself to a certain kind of tribe.

Lisp vs. Python would be most interesting if cells could pass arbitrary information to each other. This would make it easy for Lisp cells to modify their own code. Cells signalling each other and querying each other's information would enable interesting interactions. Some sort of sand boxing would seem to be desirable.

1. Cells can pass arbitrary information to each other.

2. Python cells could modify their own code just as easily (if not easier) than Lisp cells.

> 2. Python cells could modify their own code just as easily (if not easier) than Lisp cells.

I'm not expert on the topic, but what do you mean by easier ? By using eval ? Is it really easier than altering an expression tree stored in a list ?

Show me how you would write self-modifying code in Lisp and I'll be happy to show you the analog. Replacing functions at runtime in Python is just as easy as replacing them at runtime in Lisp.

Ah, you might be setting yourself up for a fall there :) one of Lisp's key elements if the ability to be self modifying (a large amount of Lisp code you will see is self-modifying) to an extraordinary degree.

Python doesn't even begin to match it's abilities in this arena.

(intro: http://www.fact-index.com/s/se/self_modifying_code.html)

> Ah, you might be setting yourself up for a fall there :)

No, I'm not. Give your example.

> Python doesn't even begin to match it's abilities in this arena.

Sure it does. Give your example. To quote your (useless) link: "TODO an example and discussion of 'high-level' self-modifying code such as in LISP."

I am no Lisper - so someone else will have to do that. But it was shown to me on a couple of occasions and Lisp's abilities are stellar!

The problem is:

Replacing functions at runtime in Python is just as easy as replacing them at runtime in Lisp.

Is not the be all and end all of self-modifying code :)

EDIT: this is a pretty good intro to Lisp Macro's http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html The code examples on there are fairly simple though (but it starts you in the right direction).

For example one thing Python is currently unable to do is modify a line in a function to do something completely arbitrary (well, theoretically you could code a specific line to be able to do that, but it wouldn't be trivial to make an entire function that could be trivially modified on the fly).

[we are now at the extent of my Lisp knowledge]

> I am no Lisper - so someone else will have to do that.

So you're making claims without firsthand knowledge? Awesome.

> Is not the be all and end all of self-modifying code :)

It's the vast majority of what people actually do in Lisp, and Python supports it just fine.

> EDIT: this is a pretty good intro to Lisp Macro's http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html

Macros have nothing to do with self-modifying code. You clearly have no idea what you're talking about. Macros are compile-time transformations of code: they have no runtime effect whatsoever.

> The code examples on there are fairly simple though (but it starts you in the right direction).

Dude, I've got PG's ANSI Common Lisp on my bookshelf and I've read On Lisp multiple times. I understand macros. What I don't understand is this Lisp worship evinced by people who actually have no idea what they're talking about with respect to self-modifying code.

> For example one thing Python is currently unable to do is modify a line in a function to do something completely arbitrary (well, theoretically you could code a specific line to be able to do that, but it wouldn't be trivial to make an entire function that could be trivially modified on the fly).

Provide a Lisp example of "modifying a line in a function" that runs in SBCL and I'll show you the same code in Python. Seriously: you're the one making a claim here, you need to be backing it up.

P.S. I remain utterly unimpressed by the anonymous coward downmodding me, upmodding you, but clearly either unwilling or (more likely) unable to defend your claim. More semi-religious Lisp fanaticism <yawn>.

I apologise... the last reply I kinda retract, as you say - it was a bit silly.

I have to admit your posts came across as the old "My Language is As Good As Yours" argument, but it appears your a Lisper too? I have to also admit everything I have seen/heard says Lisp is the original self-modifying language and is damn good at it :) but in retrospect that wasn't the point you were making.

(I was hoping a Lisper would step in with some code... but apparently not...)

Handshake?

> I apologise... the last reply I kinda retract, as you say - it was a bit silly.

Thanks, I appreciate that.

> I have to admit your posts came across as the old "My Language is As Good As Yours" argument, but it appears your a Lisper too?

I'm well-versed in Lisp, but I don't typically choose it for personal or professional tasks for a number of reasons.

> I have to also admit everything I have seen/heard says Lisp is the original self-modifying language and is damn good at it :)

The original self-modifying code was assembly language (or, really, machine code). It's a useful trick when you're working with extremely constrained computers whose memories are measured in single digit kilobytes, but long ago was recognized as really difficult to use in writing quality software. Real self-modifying code, which means code that actually overwrites the instructions the processor will execute, makes it incredibly hard to reason about programs and debug the resulting software. Real self-modifying code was long ago relegated to the likes of Mel (<http://www.cs.utah.edu/~elb/folklore/mel.html>). As I understand it, most Lisp programmers simply mean that their system properly handles the replacement of most (all?) functions/methods/definitions at runtime, which is in large part true of Python as well.

I open to being corrected by a Lisp programmer using a modern Lisp (hence my request for SBCL) to show an example of real self-modifying code, but I really don't expect that any will, because I don't think anyone's seriously written such code since I was out of elementary school.

Reply on news.ycombinator.com