From: Patrick McCuller (firstname.lastname@example.org)
Date: Sat Apr 14 2001 - 10:41:40 MDT
> Of course execution speed has to be balanced with development
> speed. Since developing a seed AI is far from being a well-worn
> path, I would suggest you concentrate effort on the development
> issues (like flexibility) rather than speed issues. After you've
> nailed down exactly what various components will be doing, you can
> rewrite them later (or they can themselves). But just watch your
> memory consumption (e.g. no Java).
> Dale Johnstone.
OK, stop the Java bashing. I've programmed in more languages than you've
likely heard of, and Java is my favorite for many, many technical reasons.
Memory consumption is NOT a big issue for Java. Speed is NOT a big issue for
Java. But this is irrelevant.
You could write an AI in B for all I care - interpretation speed and memory
usage will have ZERO impace on an AI that DOESN'T WORK. Just make it work, and
you'll do fine.
Scenario A. You have a really fast, really slick program that has few
hardware requirements. Unfortunately, this program is not a functioning AI -
it can't reprogram itself. You've got two, three years of more slick
programming to do before it's got a chance to do that on its own.
Scenario B. You have a slow, clunky assembly of programs that suck processor
time and gobble up memory in ways that make particle collision analysis
systems look tame. Just to run it you've got to spend crazy cash leasing
supercomputers. But, IT WORKS. The damn thing improves itself without much, if
Which situation would you rather be in?
This archive was generated by hypermail 2.1.5 : Fri May 24 2013 - 04:00:19 MDT