software engineering - Field Guide to Genetic Programming

Message from discussion software engineering
MIME-Version: 1.0
Message-ID: <ce8174d3-d714-4dc6-bc1d-81d0d7d28caf@b5g2000pri.googlegroups.com>
Date: Sat, 12 Apr 2008 08:40:05 -0700 (PDT)
User-Agent: G2/1.0
Subject: software engineering
From: Forrest Bennett <forrest.syntie...@gmail.com>
To: Field Guide to Genetic Programming <field-guide-to-genetic-programming@googlegroups.com>
Content-Type: text/plain; charset=windows-1256
Content-Transfer-Encoding: 7bit

(I had a local group of software engineers read the tutorial that
overlaps with the book.) They were more interested in evolving actual
code than in doing engineering design problems with simulators, or
doing optimization, data modeling, science problems, etc.

We talked a lot about the limits of GP for doing traditional software
engineering: writing end user applications, server applications, large
systems, normal programming languages, etc. I pointed them to what I
could find on applications of GP to software testing, auto
parallelization, evolving oo programs, evolving data structures,
refactoring, estimation, re-engineering, etc. But was hard pressed to
think of the largest, or most complex, most high level language,
example of actually evolving code.

They were very interested in the use of high level languages, higher
level primitives (both in terms of higher level types, and in terms of
higher level functionality), object oriented languages, strong typing,
and that sort of thing.

Since many (most?) programmers write code that has a user interface,
it might be good to have a section dealing with the difficulty of
using GP for that sort of thing.

I wonder if it might be fair to just clearly state that at present, GP
is more of a problem solving technique than a technique of general
automatic programming *in the sense that a software engineer thinks of
programming*? I may be wrong; I haven't kept up much for the past 8
years.

Forrest