🚀 go-pugleaf

In article <-M.6315@xds13.ferranti.com> peter@ficc.ferranti.com (Peter
da Silva) writes:

>While I'm generally in the bit-bangers camp, I must agree with Piercarlo here.
>The basic things that people work with are "chunks of data". Lists, trees,
>tries, and so on are methods of implementing these databases in efficient
>ways. There's nothing fundamental about them.

	While I'm generally in PdS's camp, I must agree with David
Gudeman here!

	*Sometimes* one works with "chunks of data".  In that case, yes,
you get to implement your database however you like, and all PierCarlo's
distinctions between data design and implementation design *may* come
into play.  But many, even most, of the real problems I have had to
program come with some structure already built in.

	For example, when analysing a chess position one naturally
builds a tree.  If you like, you can describe that in a relational
database and then observe "Hey, this would look nice as a tree";
I would prefer to skip those steps!  Obviously one should keep an
eye on the data design, in case things start creaking elsewhere,
but as long as things run smoothly, why not stay with the obvious?
Of course, *then* you have to implement this tree, and we get into
the usual paraphernalia that it can run mostly as a stack, but you
also need transposition tables, etc.;  but that doesn't stop the
tree being fundamental.

	Equally, when I wrote my exam-mark analysing program, it was
handed a *list* of marks;  again, you can squeeze it into a database
if you like, but *why*?  Just to discover that you really have a list?
You can implement it as an array or as a list with real pointers, as
you like, but the list was fundamental.  When I look at routes to my
house, I start with a graph;  twist it how you will, the graph is
*there*;  it might get implemented any number of ways, including
database look-up, but you can't wish away the graph.  Nor can you
wish away pointers -- *not* just as implementation details.  You
don't always have to start with pointers, and you don't always have
to implement with them, but they exist, and they are natural, and
convenient.

	As to whether they should be first-class objects -- well,
why not?  Surely, if we have learned anything from the last 20+ years
of structured programming, it should be that relegating objects to
the second class is counterproductive;  it just stops you from using
them in natural ways.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk