Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!render
From: render@m.cs.uiuc.edu
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Message-ID: <39400046@m.cs.uiuc.edu>
Date: 23 Jul 89 22:13:00 GMT
References: <5225@mtgzz.att.com>
Lines: 86
Nf-ID: #R:mtgzz.att.com:5225:m.cs.uiuc.edu:39400046:000:4755
Nf-From: m.cs.uiuc.edu!render    Jul 23 17:13:00 1989


I wasn't going to get into this discussion, but I saw a lack of support
for some good things Mr. Grandi had to say, in combination with less than
reasonable attacks on his position.  

Written  8:30 am  Jul  7, 1989 by davis@mtgzz.att.com:
>In article <1052@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>>Conversely, at least in principle, it would be much more interesting to use
>>a true DBMS, e.g. Ingres, as a substitute for a file system, rather than
>>viceversa (e.g.  to store all the mass of unruly info currently contained in
>>UNIX ad hoc "databases" like /etc/passwd, /usr/lib/sendmail.cf, etc...), or
>>even for pathname resolution.
>
>Oh it would, would it ? And to forever have such information bound up
>in as part of some highly complex, obscure, binary-oriented system,
>in which there is very little access to the information unless you go
>in through the specified channels ?

(Based on Mr. Davis' address, I'll assume that UNIX is his OS of choice.)

What do you think UNIX is if not a binary-oriented system with very limited
access channels?  There's no support for record-oriented I/O (something that
operating systems had twenty-five years ago) and a primitive notion of 
different types of file.  The fact that the only thing which distinguishes
a C source file from an object file is the suffix attached to its name
indicates its level of sophistication.  With all the advancement in programming
language technology you'd expect some of it to filter down to command languages
and programming environments, but you see almost none of it in UNIX.  A lot 
of time and effort have gone into making DBMS that support a higher-level 
view of the data and operations.  This work applied to file systems could 
provide developers with a lot nicer working environment than UNIX and [tkc]sh.

>Give us a break - the proliferation of ridiculous systems like Ingres,
>Dbase and Oracle is one of the most worrying on the computing horizon.
>Extending their reach into SW engineering and system admin could turn
>into the worst nightmare ever. 

This statement demonstrates little knowledge of the current trends in 
software engineering.  Most development environments that I'm familiar 
have some sort of DBMS built into them, primarily because most file 
systems don't provide the facilities you need (transaction mgmt., data 
structuring, UI development tools, etc.).  I really don't see why you
consider the DBMS systems you cite ridiculous, unless it is because you
never felt comfortable using them.  You have to admit they allow you to
do several things you can't in UNIX without a lot of effort and hacking
around.  I'm not saying you can't emulate a DBMS using various UNIX tools,
but you are almost assuredly going to lack several facilities and suffer
a severe performance loss over a well-constructed DBMS. 

>If we have to have RDMS on Unix, lets stick to those that adhere to
>the philosophy of the whole system (such as /rdb) and forget
>cryto-DB's. (By which I mean ASCII files in simple filterable format).

"Crypto-DB"?  That's a novel term.  If by this you mean a DB which stores
it's data in a form other than one which is human-readable, then you'd better
stay away from any application which has more than a few thousand data items
to manage.  Storing things in human-readable form is fine when you've got
a few thousand pieces of data to look through, but when you've got a hundred
thousand or more than you had better use a storage format (such as B-trees)
that isn't going to be a time-hog for look-ups.  ASCII files are fine for
storing your list of personal phone numbers, but not for a cross-reference
of all the defined functions and global variables in a 3 million line software 
system.  For things like that you need a DBMS.  Of course you'll need special 
access routines, but what do you think function libraries are for?  If read 
and write routines were sufficient, we wouldn't have bothered with scanf and 
printf.  The same is true for other types of data store.

>>	* 4GL interfaces
>
>From "Relational Databases under Unix" (or some such book by the
>author of /rdb)...
>
>	* the Unix shell (s) - the best 4GL yet invented

Right.  And some people still say, "COBOL -- the best programming language
yet invented."  You'd better learn to take such statements with a grain
of salt if you hope to ever progress beyond the current state of the art.

>Remember: build a system a fool could use, and only a fool will want to.

Good quote, but if I read you right, you'd still love for us to be programming
in machine code and on cards.  Hey, punch cards were fun when I was back in 
college, but I'd rather not be forced to still use them, if it's okay with you.

Hal Render
render@cs.uiuc.edu