Re: dynamic vs. static: the age-old debate

On Thu, Aug 17, 2006 at 09:24:50PM +1000, cr88192 wrote:

"Curtis W" <cwarren89@xxxxxxxxx> wrote in message
news:1155783268.644882.250860@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Dynamically typed languages postpone everything until absolutely
necessary, including type checking, method lookup, etc. Compile time
errors or "possible errors" are strictly forbidden, barring what is
necessary to compile a program, e.g. syntax errors are ok.


they don't always postpone everything as much as possible.
often, some level of type inference will be used, when reasonable, in basic
attempts to optimize the performance of compiled code.


Drawing from this, it should be obvious that code written in one
version will not work if the language is changed to use a different
kind of type system.


yes, within limits.


The second issue in your post is that discussing dynamic/static typing
brings the rest of the type system into the argument. For this to be
true, the other concepts in the type system would have to be
inseparably related to either dynamic or static typing, which certainly
is not the case. OCaml is a great example simply because of the large
amount of different concepts it has in its type system. Type inference
is possibly the most popular, but this isn't related to static typing
at all (indeed, type inference can be used for optimization purposes in
compilers for dynamically typed languages). Union types and structural
subtyping are two others, but these too aren't linked directly with
static typing, especially considering that dynamic typing implies
structural subtyping.


I am not entirely sure there is understanding here.

I am not saying that the features themselves are necissarily either static
or dynamic in nature. what I am saying is that such a distinction does not
exist in a purely fundamental sense, but that it arrises out of the
particular mass combination of features, but mostly as a "path of least
resistance" type feature, rather than any fundamental or golden rule.

I will argue that, with effort, one can make a dynamic implementation for an
otherwise static language, and with similar effort, can write a largely
static implementation of a dynamic language.

cr88192,

I have the feeling you are not separating semantics and implementation;
theory and practice, to the degree that Curtis and I are. While you are
right that dynamically typed languages don't have to postpone absolutely
all type-related work to run time, this is what happens _semantically_,
or _theoretically_. The implementation, the actualy, practical code of
the compiler or interpreter may do things any way it pleases, as long as
it doesn't affect the semantics of your programs (although some effects
on the semantics are often accepted in practice, just to complicate
things). As an example, consider

greeting = "Hello, world!"
print greeting
a = greeting / 12
print a

Now, suppose that the operation of dividing a string by a number is not
defined in this language. If the language is statically typed, this
program will never compile or run, because it contains a type error, and
static typing dictates that such programs be rejected at compile time.
Dynamic typing dictates that the program is allowed to run, alttough, of
course, it will abort with an error as soon as the third line is
reached.

All this says nothing about the compiler being allowed to optimize the
program, e.g. by taking advantage of the knowledge that greeting
contains a string, and thus its value does not have to be converted to a
string before it can be printed. It also does not (at least using my
definition) preclude the compiler from emitting a warning about the
offending third line. So, a lot of work can be done at compile time...as
long as the program does compile and run (until the third line is
reached), because, otherwise, it would not be dynamic typing. The
semantics of the language (if dynamically typed) say that the program
must print "Hello, world!", and then abort, and so, as long as the
implementation ensures this, it is a correct implementation of the
language.

As for how the language designers come to the decission of making the
language statically or dynamically typed (or some hybrid form, or
anything else you can think of), I have no idea and will make no claims
about it. Nevertheless, static typing or dynamic typing are fundamental
features of a language, that can be examined in their own right; just
like other features, for example, if the language has a built-in +
operator or not, and if a language's print function (assuming one
exists) appends a newline or not.

Regards,

Bob

---
The optimist proclaims that we live in the best of all possible worlds,
and the pessimist fears this is true.



.

Relevant Pages

  • Re: GMP vs. straight C arithmetic
    ... ordinary data structures that don't impose an additonal performance ... Side-effects are another crucial part of the language. ... > Take the tree structure example I gave earlier. ... determined at compile time, is this a compile time error? ...
    (comp.programming)
  • Resolved: NOT. --WAS: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming:OO
    ... I certainly want more errors detected at compile time, ... > advocate reaching that goal through beefier type systems. ... in a procedural language, or in an object based language. ... Relativistic mechanics - solves the transaction thing, ...
    (comp.object)
  • Re: dynamic vs. static: the age-old debate
    ... I am not saying that the features themselves are necissarily either ... static implementation of a dynamic language. ... static typing dictates that such programs be rejected at compile time. ...
    (comp.lang.misc)
  • Re: Teach myself C++.
    ... That seems to be an objection to the quality of implementation of ... The language IS the compilers. ... should be possible to compile some code more than once, ... I'd say that string handling is something most other languages get ...
    (sci.crypt)
  • Re: c#.net or vb.net
    ... Both C# and VB.NET compile to the _same_ IL don't they? ... developers using any particular development tool might make the body of code ... for a particular project doesn't make the language itself more "powerful," ... although that situation might make it more popular. ...
    (microsoft.public.cert.exam.mcad)
Loading