Re: OT: Language War (Re: "C" Manual)

[Erik Steffl <steffl@bigfoot.com>]

"Eric G. Miller" wrote:
> 
> On Mon, 31 Dec 2001 13:46:15 -0800, Erik Steffl <steffl@bigfoot.com> wrote:
> 
> > Richard Cobbe wrote:
> > >
> > > Lo, on Sunday, December 30, Dimitri Maziuk did write:
> > >
> > > > * William T Wilson (fluffy@snurgle.org) spake thusly:
> > > > ...
> > > > > So... why *should* the programmer concern himself with individual
> > > > > bytes of memory? (Assuming he is writing an ordinary application and
> > > > > not a hardware driver or something similar).
> > > >
> > > > Because if he does not, his application will segfault and dump core.
> > >
> > > No.  This level of concern is necessary only for non-type-safe
> > > languages.  It is provably impossible for a program written in a
> > > type-safe language to segfault (assuming that the language's run-time
> > > system is implemented correctly, of course).
> >
> >    ???
> >
> >   it's the resource allocation that's important, not types. garbage
> > collectors are generally more robust as far as segfaulting (and similar
> > errors) go (of course, just because the program doesn't segfault it
> > doen't mean it's working correctly). the other important factor is how
> > much runtime check language does (e.g. checking for array boundaries
> > etc.)
> 
> But it's the type safety of the language that prevents the abuse of
> memory, not how it was allocated.  Strong typing eliminates a huge
> number of error cases.  C and C++ both subvert the ability of the
> compiler to do static type checking via casts and void pointers.  Strong
> static type checking also has the possible advantage that the compiler
> can better optimize the generated code.

  consider perl which doesn't have strong types but it's quite
impossible to make it segfault and C++ on the other side which is fairly
dangerous even without casting (I would even go as far as saying that
casting makes no difference (statistally), but I'd have to think about
it).

  most of the segfaults are because of the resource allocation mistakes,
not because of mistaken types... at last that's my impression.

  note that in c++ there's basically no need for casting and using void
pointers (in general, there are special cases). That's of course, if you
are willing to use templates (or, alternatively, multiple inheritance,
in some cases).

  also note that in java you have to cast (when getting items from
containers) but it doesn't make java programs more likely to segfault.

> >   and as far as runtime system goes - only interpreted languages have
> > runtime systems.
> 
> Well, I dare you to remove 'ld' or 'libc.so' and see how many programs
> run ;-)  I think it's fair to characterize required language libraries
> as part of the "run time" system.  Whether or not a program is statically
> compiled is unimportant, as the language library still performs actions
> at runtime that "your" program depends on, and which "your" program
> could not function without.  Among those things, might be checking
> array accesses and raising exceptions for range errors...

  IMO the important distinction is whether the program runs itself
(compiled programs) or whether it is run by other program, which
controls it and takes care of various runtime checks etc.

  you do not necessarily need ld and standard libraries for c or c++
program, however you need vm for java program.

  or, in other words - runtime for compiled program is HW, runtime for
interpreted program is SW (HW usually provides generic, basic &
low-level functionality, SW usually does provide higher level
functionality, specific for given language).

  so IMO the 'runtime' for compiled languages (c, c++ etc.) is a lot
different from what 'runtime' means when talking about interpreted
languages (java, perl, VB)

	erik