Re: INFO-ADA Digest V92 #299

[munnari.oz.au!goanna!ok@uunet.uu.net (Richard A. O'Keefe)]

In article <1992Oct2.104250.21814@lth.se>, dag@control.lth.se (Dag Bruck) write
s:
> In <comp.lang.ada> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >Let's keep a sense of perspective here:
> >	Ada is smaller than COBOL.
	...
> >	Ada is larger than Scheme.

> Excellent advice.  How do you measure size?

Effort required to read the defining document.  The COBOL-85 standard is
physically larger than the Ada-83 LRM and I found it harder to read.  It
also appears to define more concepts.  The Scheme standard is ~50 pages,
very much in the style of the Algol 60 report, and that includes a
formal semantics which I (ahem) skipped.

> >....  If it comes to that, I am continually surprised by how
> >little C many of the C programmers I speak to know, and it's not large.
> 
> Do you mean that C is a good language (in some sense) because it is
> small to start with and you don't even have to know much of that to
> get useful work done?

I didn't mean to say anthing at all about good/bad.  I will say that very
little of ANSI C is "bloat".  However, there _are_ rough edges to watch
out for.  I have in mind things like which arguments of what built in
functions are size_t rather than int, and why; what exactly are the
differences between pointers and arrays; why it's a bad idea to put
function declarations (not definitions, that's not legal) inside blocks
even though it's legal; what NULL is and exactly when it needs a cast;
when p[-1] is legal; how to do arithmetic on times; when you need ptrdiff_t;
I could go on and on.  I've never written down a full list, but most of
the rough edges don't exist in Ada.  (How many Ada programmers would think
of multidimensional dynamically allocated arrays as _hard_?)