Bernhard, Simon: I like the idea of reducing the pool of available
methods. The test for arity is nice too, which could be done at the
start or as the pool is reduced, but I like my software to my work for
me sometimes and for the sake of clarity even if at the sake of
efficiency, hence rescue rather than testing first. Although, it is
good to know why something has ‘gone wrong’ or to explicitly prevent
Joel: I had similar ideas for the purpose of constructing intelligent
autonomous networks of code… Assume you have (untrained) monkeys at
keyboards at one end and hope to have something sensible at other given
enough decent filters, er DuckWeed? (A little enviro joke for all you
ecologists and environmental engineers out there… Any?)
Expect to see something like this in wacky (but good, useful—no really
this time… Hint, it’ll do something other than p.) stuff soonish…
The more pressing need (or just simply what I referred to at the bottom
of that post) is for code to randomly ‘rewrite’ methods to point to
other methods. Then one’s code doesn’t need to explicitly refer to
random_method and Test::Unit is automatically confused as soon as
include RandomMethodOrSimilar is dropped in.
It would be good to combine the reducing pool of methods into
DuckDebugging. Another idea for DD is to change the number of
parameters, randomly or sequentially.
Oh and yeah, I didn’t need that methods = self.methods line: I was
trying to make things obvious, but ended up being awfully redundant.
P.S. Excuse the lack of quoting below as ruby-talk > /dev/null due to
volume… I just read it off the web presently.
Why stop there?
On the theory that if something goes wrong, you should just
try something else until you find something that works.
def method_missing(meth, *args, &block)
m = methods
meth2 = m[rand(m.size)]
result = send(meth2, *args, &block)
rescue => ex
p [self, meth2, args, ex] if $DEBUG
p [self, meth2, args] if $DEBUG
result = (now your program can be any batch of garbage
just enter words at random and you will get something)