peter@ficc.uu.net (Peter da Silva) (03/23/90)
In article <2977@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: > In article <D_D27L1xds13@ficc.uu.net>, peter@ficc (Peter da Silva) writes: > >There are only two languages I know of in which you can take a moderately > >complex program and run it, without modification, on a wide variety of > >platforms. > But, this leaves two issues open: (i) why C has such an idiotic > syntax, arbitrary type-checking, lax compile-time checks and so on, > and (ii) why people think that C's features provide "power" in > general-purpose programming. Point (i) is an accident of history. > Point (ii) still intrigues me. Well, the C syntax is generally pretty nice. It's got a couple of minor boners and one major one (making the shorthand for [0] (i.e. *) a prefix rather than a postfix operator), but all in all it's a pretty language in an art-deco sort of way. As for the latter, well, people find that C provides them with a very broad and powerful base to work from. Other languages that provide similar degrees of power aren't widely enough available, or when they are they're found in too many dialects to be considered a single language. UCSD Pascal, for example, is a useful language. So is Oregon Pascal, and Turbo Pascal. Unfortunately, ISO Pascal hasn't been adequate, so UCSD and Oregon and Turbo and other Pascals aren't compatible with each other. The same holds true, to a lesser degree, for Modula-2. Back to the point... people find a language that does the job, with really no alternative, and they attribute its success to the obvious places where it differs from other, similar, languages. rather than the somewhat subtle issue of the breadth of the standard... > I find that C's adherence to an implementation-defined word size limits > portability anyway; but I don't think that's an avoidable problem. In practice word size is always going to be implementation defined. The biggest problem with C word size is the implicit pointer-integer aliasing in function calls. I expect ANSI function prototyping will fix that. I would hope that ANSI compiler vendors will provide an option whereby it is considered an error to call a routine with no prototype in socpe. > And we mourn its passing. Full PASCAL and screen editor in 56K. Let's not get started on "small is beautiful". -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ 'U` \_.--._/ v
sommar@enea.se (Erland Sommarskog) (03/25/90)
Peter da Silva (peter@ficc.uu.net) writes: >Well, the C syntax is generally pretty nice. It's got a couple of minor >boners and one major one (making the shorthand for [0] (i.e. *) a prefix >rather than a postfix operator), but all in all it's a pretty language in >an art-deco sort of way. To get into the totally irrelvant points, I have been reading this book on Unix system programming (not that I've learnt much, I still think VMS is better) which has exposed me to some excerpts of C code, and I can't say that I am overwhelmed from an esthetical point of view with all these &&, ||, {, }, ?, * etc. And it gets even worse when it comes up on a terminal and letters are used as operators. Possibly art-deco, but that's not my style. Maybe I should redirect followups to rec.atrs.programmming? -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se