Tony Proctor wrote: > 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. > To specify what is unspecified in C would make it bloated and thus no better than any other bloated language. For example, you would have to specify endian-ness and the exact size of integer types. C is specifically designed to be non-bloated. In this it succeeds most magnificently! It is supposed to map directly to hardware. It does this well on the PDP-11, the VAX, and the 80x86 and successors. As you are aware, the 80x86 successors rule the world. You want bloat and full specification, there are languages for you, for instance Ada and Java. Both are near-useless because of exact specification disasters: for instance, Java specifies a specific float formant that is incompatible with the 80x86, a major, major, major problem. So big that strict Java is in fact useless for 99.5% of the computers in the world. Doug McDonald

Doug McDonald wrote: [SNIP] > You want bloat and full specification, there are languages for you, > for instance Ada and Java. Both are near-useless because > of exact specification disasters: for instance, Java specifies > a specific float formant that is incompatible with the 80x86, > a major, major, major problem. So big that strict Java is > in fact useless for 99.5% of the computers in the world. I suspect that we're heading increasingly off-topic, but as someone who programs in both C and Java, I have to disagree with that characterisation of Java. The Java language itself is actually rather elegant and compact. It follows the tradition of C in that respect. You can summarise the essential features of either language on a single sheet of paper. The Java API contains several thousand classes, which can be quite daunting to a novice, but the folks at Sun were wise enough to organise them into a set of packages according to type of functionality: I/O, networking, text manipulation, database connectivity and so forth. Compare that with the API which C programmers need to achieve the same functionality. That too runs into thousands of functions, both under Windows and the various flavours of Unix, and as a programmer, I find that far more of a hassle than Java's API. Java does indeed stipulate the endian-ness both of integers and of floating-point numbers, but the only people who ever need to worry about that are the programmers who are unlucky enough to have to write Java code to read binary data produced by non-Java software. For them, the Java API provides a rich set of conversion functions, so reading and writing 80x86 native-format binary data is actually very easy. Java is widely used on the Intel-based Windows and Linux systems which make up the bulk of the world's computers. Evidently, Java's stipulation of big-endian numbers is not a major problem at all. David Harper Cambridge, England

On 2007-11-16, Doug McDonald <mcdonald@SnPoAM_scs.uiuc.edu> wrote: > > ... > > You want bloat and full specification, there are languages for you, > for instance Ada and Java. Both are near-useless because > of exact specification disasters: for instance, Java specifies > a specific float formant that is incompatible with the 80x86, > a major, major, major problem. So big that strict Java is > in fact useless for 99.5% of the computers in the world. Useless, you say? Hardly! Since about March of 2003, I have been using Java on X86 with Linux, a system type massively more numerous than 0.5% of computers in the world. (Before that, it was Java on Alpha.) It has been quite useful for parsing HTML, producing and parsing XML, archiving data, graphically displaying data, generating time series models from data, and optimizing the parameters for black-box simulation. Oh, and for a tie-in to genealogy, it works just fine with the FamilySearch indexing program. -- Robert Riches spamtrap42@verizon.net (Yes, that is one of my email addresses.)