Well said David. I'm not sure how much involvement the software vendors had in those early standards like Fortran. However, with languages like C++ I think most of the big vendors are represented on the standards body. These same companies have "language lawyers" though that interpret those standards, and often hide behind 'the letter' rather than embracing 'the word' 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. I think the industry has benefited in the long term, albeit via an evolutionary approach. Programming Languages are better defined now, and more functional, and with less variation between vendor or hardware. I think genealogy could learn a lot from the programming language history. Its biggest problem, though, seems to be its fragmentation - there aren't the same big companies or authoritative bodies around to help kick-start a new standard. Tony Proctor "David Harper" <devnull@obliquity.u-net.com> wrote in message news:aBI_i.40441$T8.22632@newsfe5-win.ntli.net... > Denis Beauregard wrote: > > Hi: > > > > I think what is wrong with GEDCOM as a standard is not the GEDCOM > > itself. Its structure is quite easy to understand and it is easy > > to write a software that will both understand it and generate it. > > > > I would say the problem, as Bob said, is when the standard is > > applied. Any software maker has his/her opinion about that, but > > also, and this is more important, very few softwares can indeed > > support all the features in GEDCOM and many may have more features. > [SNIP] > > This kind of things has always plagued the software industry, alas. > > ANSI or ISO or W3C publishes a standard for some document format or > language specification, and before you know it, there are half a dozen > implementations from different vendors who all add "enhancements" that > are incompatible with the standard and with one another. > > Look at the way Fortran developed after the 1966 and 1977 ANSI > standards, for example. Big companies such as Digital Equipment > Corporation released compilers which allowed all manner of non-standard > extensions, which made portability a huge headache. > > More recently, Microsoft has gained a dubious reputation for its > "embrace and extend" tactic. Ask any web designer about the "standard" > for JavaScript in web browsers, and watch them roll their eyes and groan. > > I work in bioinformatics, using and writing software to analyse, store > and interchange biological information about DNA. There are half a > dozen different "standard" ways to store some kinds of data, and a lot > of software is pretty lax about obeying the standard when writing data > files. > > Like Andrew Tanenbaum said, the great thing about standards is that > there are so many to choose from :-) > > David Harper > Cambridge, England

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. Cheryl

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. 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

You pretty much said it David - thanks! The standards designed/specified by big committees full of big-wig vendors who have vested interests they want to protect, and "edges" over other vendors that they want to enhance, tend to be a disaster as the resulting spec is too vague. My issue with the ANSI C spec, for instance, was that it left so much "undefined" or "unspecified" that you could drive a bus through all the holes. As a consequence, C is not the portable language that it was hoped to be. Smaller, more focused, committees tend to define cleaner standards. However, rather than being an "ivory tower", they would nowadays put out RFIs to gather requirements, and have peer reviews for the drafts. There's a subtle difference is considering lots of valid inputs, and having the specification actually defined by a large number of subjective people. Tony Proctor "David Harper" <devnull@obliquity.u-net.com> wrote in message news:0Oa%i.16594$ib1.15815@newsfe3-win.ntli.net... > 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. > > 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

Tony Proctor wrote: > I'm not sure how much involvement the software vendors had > in those early standards like Fortran. However, with languages like C++ I > think most of the big vendors are represented on the standards body. These > same companies have "language lawyers" though that interpret those > standards, and often hide behind 'the letter' rather than embracing 'the > word' I remember back in the late 1980s when we were waiting for the new Fortran standard to succeed Fortran 66 and Fortran 77. The X3J3 committee had over fifty members, drawn from the big vendors, industry, academia and the U.S. government. The new standard was known informally as Fortran 8X, and as the decade drew to a close, there was much joking that "X" would have to be a hexadecimal digit. So, indeed, it turned out, because Fortran 8X turned into Fortran 90. > 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. Kernighan and Ritchie's "The C Programming Language" remains a masterpiece of brevity and clarity in not only defining a programming language, but providing a tutorial for aspiring programmers. I doubt that any of the "modern" languages could be summarised in so few pages. But then, Dennis Ritchie didn't have to get the approval of a committee, because he created the C programming language. > I think the industry has benefited in the long term, albeit via an > evolutionary approach. Programming Languages are better defined now, and > more functional, and with less variation between vendor or hardware. I think > genealogy could learn a lot from the programming language history. Its > biggest problem, though, seems to be its fragmentation - there aren't the > same big companies or authoritative bodies around to help kick-start a new > standard. The world's first high-level programming language (Fortran, since you ask) appeared in 1956. Wikipedia's list of programming languages runs to more than 500 entries. That's an average of ten new languages every year. I'm not sure that's an example that the genealogy community would want to follow ;-) David Harper Cambridge, England

David Harper wrote: > >> The older ANSI C and ANSI SQL specs are abomininations resulting from a >> design-by-committee approach. > Kernighan and Ritchie's "The C Programming Language" remains a > masterpiece of brevity and clarity in not only defining a programming > language, but providing a tutorial for aspiring programmers. I doubt > that any of the "modern" languages could be summarised in so few pages. > > But then, Dennis Ritchie didn't have to get the approval of a committee, > because he created the C programming language. The original ANSI C is not an abomination. It is just fine, no disasters. It does lack one important thing that should have been added: passing of multi-dimension arrays with filled-in dimensions. This could easily have been done by kludge, with no logical inconsistency, but there was a war between the "just do it " people and the "but we HAVE to use a dope vector" people. Doug McDonald