Re: 1995 Developers Competition Update - 42 Teams,Japan,Languages Used

[Followup-to: massively reduced!] Dennis Moore (dbmoore@netcom.com) wrote: : 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. Absolutely true. And isn't this the very problem that is keeping object-orientation from being the silver bullet that it is often claimed to be? OO is much more than just a coding or implementation method, it's a significantly different way to analyze the problem domain and create a solution. If the analysis and design is already done in a non-OO method, then trying to do an OO implementation is usually an exercise in futility... : If the objective of object orientation is reuse, : presumably we can reuse someone else's analysis and design. Oh, come on. You could just as easily (and just as incorrectly) say that since the objective of using a relational database is flexibility, and you have already done the analysis and design for a COBOL program to solve the problem, presumably the relational database would be flexible enough to allow us to use the record-oriented structure! Of course, it might be doable, but it wouldn't really be relational, now, would it? And wouldn't have many of the advantages that a relational design and implementation would have, either... Reuse is one *result* of properly-done (i.e., properly-analyzed, designed, and implemented) OO. That does not mean that any technique for reuse is OO, or even that any technique for reuse can be used in OO. There are innumberable techniques for reuse, and some of them have no place in OO. Just like relational theory, OO requires a significant change to our view of the whole problem and solution. Ignoring these differences will result in highly pessimized solutions. (Have you ever seen database applications in a relational database that insist on processing one record at a time when set-based processing would do it more simply? How about programs written in an OO language that try to do manually what the language does automatically?) Just my $0.02... : -- 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 ;-) -- -- Noel Maddy noel@mail.msen.com Work: ncm@biostat.hfh.edu "There are no infrastructure heros." - Dan McLaren