Newsgroups: comp.client-server,comp.lang.smalltalk,comp.lang.cobol,comp.lang.clipper,comp.lang.basic.visual.database,comp.databases.xbase.misc,comp.databases.xbase.fox,comp.databases.theory,comp.databases.sybase,comp.databases.rdb,comp.databases.progress,comp.databases.pick,comp.databases.paradox,comp.databases.oracle,comp.databases.olap,comp.databases.object,comp.databases.ms-access,comp.databases.ingres,comp.databases.informix,comp.databases.gupta,comp.databases
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!dbmoore
From: dbmoore@netcom.com (Dennis Moore)
Subject: Re: 1995 Developers Competition Update - 42 Teams,Japan,Languages Used
Message-ID: <dbmooreDDB02K.62G@netcom.com>
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <40dl7p$iis@redstone.interpath.net> <40k1f4$7rc@natasha.rmii.com>
Date: Mon, 14 Aug 1995 13:56:43 GMT
Lines: 70
Sender: dbmoore@netcom8.netcom.com
Xref: glinda.oz.cs.cmu.edu comp.client-server:12260 comp.lang.smalltalk:27133 comp.lang.cobol:4741 comp.lang.clipper:3717 comp.lang.basic.visual.database:8450 comp.databases.xbase.misc:5071 comp.databases.xbase.fox:25508 comp.databases.theory:5168 comp.databases.sybase:23083 comp.databases.rdb:3169 comp.databases.progress:1735 comp.databases.pick:8263 comp.databases.paradox:24963 comp.databases.oracle:43265 comp.databases.olap:1962 comp.databases.object:6910 comp.databases.ms-access:41384
s.ingres:15367 comp.databases.informix:22398 comp.databases.gupta:1061 comp.databases:48742

You make many interesting points and I would hardly claim that any benchmark,
specification, or competition is perfect.  Nonetheless, it is not unusual for
programmers to have to work from a specification developed by others on a
database schema already in existence or built by an analyst (possibly one not
as educated in object orientation as the programmer would like ;-) prior to
the beginning of coding.  If the objective of object orientation is reuse,
presumably we can reuse someone else's analysis and design.

-- Dennis Moore, Oracle Corp.
dbmoore@oracle.com	<- Office (preferred for e-mail)
dbmoore@netcom.com	<- Home (preferred for living ;-)

In article <40k1f4$7rc@natasha.rmii.com> cjames@cec-services.com writes:
>tom@dcs.pdial.interpath.net wrote with possible deletions:
>
>|   Total cash prizes of $10,000 will
>| be awarded the top 3 teams.  Gold medals will be awarded the best MultiMedia,
>| Object Oriented, Rapid Application Development and Client Server application.
>
>The specifications for the 1994 competition in fact prohibit _any_
>object-oriented approach.  This is because the fields or columns are
>blocked, the rows which go into which tables are specified, etc.
>Hence it can be _proved_ that a gold medal for Object Oriented
>application is a gold medal for something not object oriented.  Maybe
>this explains why no Ada or Eiffel participants are interested, and
>why there is only one team using SmallTalk.
>
>For an application to be object oriented, the analysis and design
>phases would have to be done without being given a canned database
>design to implement.  In other words, for the application to be object
>oriented the analysis phase must determine the problem domain, and the
>design phase must determine the solution domain.  But the 1994 specs
>are just that and prohibit oo analysis or design.  Hence the result
>would be a SQL solution written in Ada or Eiffel or BASIC or FORTRAN.
>If I were a judge, given the 1994 specifications any SmallTalk entry
>would be immediately failed because the analysis and design phases are
>crucial to oo technology.  Furthermore, for a team to demonstrate
>proficiency in oo technology would require that they produce a class
>library of reusable components with which total strangers must
>successfully implement the given specifications.  That's not possible.
>
>The assumptions in the 1994 specifications are also legion.  For
>example, areas of improvement include normalizing the database
>further.  But this assumes that the optimum approach is to use a
>relational database, rather than anything else.  
>
>A number of the details of the 1993 specification are amateurish.  For
>example, table names such as TableName (notice the caps) are not used
>in any standards.  This particular important point is not a matter of
>style, but rather of readability established by many disparate
>projects, namely, TableName should be table_name.
>
>I believe the 42 teams are wasting their time on the 1995 competition.
>
>
>
>
>~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
>Colin James III, Principal Scientist  cjames@cec-services.com
>CEC Services, 2080 Kipling St, Lakewood, CO  80215-1502   USA
>Voice: 303.231.9437; Facs: .231.9438; ISDN: .462.1107 & .1448
>~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
>
>


-- 
-- Dennis Moore, Oracle Corp.
dbmoore@oracle.com	<- Office (preferred for e-mail)
dbmoore@netcom.com	<- Home (preferred for living ;-)
