Re: OOP and memory management

From: Robert STRANDH (strandh_at_labri.fr)
Date: 07/04/04 

Date: 04 Jul 2004 07:05:51 +0200

qed@pobox.com (Paul Hsieh) writes:

> "Thomas G. Marshall" wrote:
> > Not talking about run time efficiency, I'm talking about the amount of time
> > it takes to create a project, and maintain it.
>
> Well on this very narrow point, what I am saying is that a compiler error that
> tells the programmer about an error before the program runs is better than a
> program that doesn't tell you about the error until it runs some specific
> scenario and there isn't necessarily a developer around to fix it.

While this might seem like an obvious statement, things are not quite
that simple. Obviously, if everything else stays the same, then it is
better to have errors caught at compile time than at runtime.
However, if the ability to catch errors at runtime influences other
aspects of the development process negatively, things are not
necessarily just positive.

As Thomas hinted, if the ability to catch some errors at compile time
influences the time it takes to create the project, you might be faced
with a situation of catching errors at compile time in a project that
will not finish on time, or that will be canceled from running out of
funding, whereas if you give up on that ability, you might finish the
project.

> Remember this is a narrow point -- and you can't weasle or talk your way
> around it. Run time dynamic type mismatches are for real in dynamically typed
> languages; they are very annoying and they don't exist in strongly typed
> languages.

Of course they exist, even in statically ("strongly") typed languages.
The fact that you cannot declare a variable of type "positive even
integer", and the existence of divide-by-zero runtime errors is proof
of the presence of type mismatches. In order for a type system to be
decidable, some approximations have to be made. The claim is that, in
order to be decidable, such approximations necessarily have a negative
impact on development time and, more generally, on the kind of correct
programs that can be expressed.

> You can be objective and realize this as the primary fundamental
> trade off or you can be blinded by typical language adherence fanatacism.

Of course it is a fundamental trade off, but the trade off is not
between catching all type errors at compile time, or not catching
them. The trade of is between on the one hand catching some type
errors at compile time at a the cost of not being able to express some
correct programs and of making development time longer, and on the
other hand of not catching some of those errors (that may not exist
anyway) in an expressive language that allows very rapid development. 

-- 
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Relevant Pages

  • Re: OOP and memory management
    ... if the ability to catch some errors at compile time ... >> trade off or you can be blinded by typical language adherence fanatacism. ... > between catching all type errors at compile time, ...
    (comp.programming)
  • Re: Multi Dimensional Array Reallocation ?
    ... I've never said that everything can be done at compile time. ... >> g) would make Delphi programs run slower, ... would require a symbol table lookup and then a type check. ... specific interest in formal languages and compiler construction. ...
    (alt.comp.lang.borland-delphi)
  • Re: evaluating a string as an expression
    ... to evaluate a string as an expression and I ... The problem here is the difference between compile time and runtime. ... interpreter (which most scripting languages such as ColdFusion, PHP, Perl ... give you access to fields on objects and not local variables. ...
    (microsoft.public.vsnet.general)
  • Re: Using a string as a variable name
    ... construction only works in an interpreted language ... ... resolution should be compile time ... ... Only interpreted languages would be able to do this, ... global object only works for global variables, ...
    (microsoft.public.scripting.jscript)
  • Re: How can my software know when a LX200 has finished slewing?
    ... But strongly typed languages are much better when lives are at stake or for mission critical systems. ... Far better to have programmers typos and common errors detected at compile time than turn it into code that is guaranteed to crash in obscure ways later. ... Ultra high reliability software now has to use a cunning subset of the Ada language. ...
    (sci.astro.amateur)