David Harper <devnull@obliquity.u-net.com> writes: > singhals wrote: > > Tony Proctor wrote: > > [snip] > > > >> The older ANSI C and ANSI SQL specs are abomininations resulting from a > >> design-by-committee approach. You can understand the approach taken with > >> Java whereby it was designed and evolved as a proprietary standard before > >> being considered for an international standard. > > > > > > Remind me again please -- what makes _their_ design-by-committee results > > worse than what _your_ project committee could come up with? > > > > If standards in the genealogical software community need to be > > agreed-upon rather than forced-upon, you're going to get > > designed-by-committee standards. > > > > If it's bad when I (or Bob V) do it, then it's bad when you do it. > > Ancient adage roughly translated as sauce for the gander. > > I guess what Tony is trying to say is that large committees tend to have > a wide range of conflicting (and often irreconcilable) goals. In the > context of committees whose remit is to design some kind of standard, > the result is a standard that is bloated, confusing and often impossible > to implement effectively. More often, controversial items are left as implementation-defined. ANSI rules, for instance, say that a standard has to be derived by consensus. If consensus can't be reached on a point, it can't be in the standard. > The best standards seem to come from very small committees, or better > still, two or three very talented and highly-focussed individuals. Look > at the standards which underpin the Internet -- IP, TCP, SMTP, HTTP -- > which each originated as the work of one or two people. Likewise, > languages such as C and Fortran, which were created by one person and a > team of half a dozen, respectively. (And John Backus's Fortran team not > only specified the language, but implemented the world's first > optimizing compiler on a computer which had less memory than your > cellphone!) > > David Harper > Cambridge, England