Re: Perl implementation of an esolang. It's a party, yes?

in reply to Perl implementation of an esolang. It's a party, yes?

Reading the description (I didn't look carefully through the code spec) it kind of reminds me of the old Corewars. Corewars included both self-modifying code, and the possibility (actually near certainty) that your code would be modified by your hostile opponent. Short of trying to execute a DATA statement (the goal was to make the other guy execute DATA statements with all his processes) pretty much everything would execute. It was a simple language-- 10-ish "assembly" instructions and 3 or 4 addressing modes (I'm too lazy to even look through the current site to check). It was fun to have a crude display and watch processes go zipping through the core in unexpected ways.

Comment on Re: Perl implementation of an esolang. It's a party, yes?

Replies are listed 'Best First'.
Re^2: Perl implementation of an esolang. It's a party, yes? by corenth (Monk) on Jul 11, 2012 at 17:31 UTC
I looked up the site & found it really interesting. I didn't get to look at the genetic algorithm part of it, but it makes sense to me how it may work. $state{tired}?sleep(40):eat($food);	[reply]
Re^3: Perl implementation of an esolang. It's a party, yes? by bitingduck (Chaplain) on Jul 18, 2012 at 00:14 UTC
It's not really an explicit part of the game-- it just always seemed like with 64 processes per side running around blasting each other with unpredictable commands you end up with random mods to code and then tests of survival. Hence the genetic algorithm element. I never tried developing programs genetically though. Watching stuff fly through the core it usually started off looking like you expect, and then often switching to really random behavior.	[reply]

In Section Cool Uses for Perl