André Pang <oz...@algorithm.com.au> writes:
> On 15/01/2009, at 11:28 AM, Daniel Pittman wrote:
>
>> strong vs weak typing is actually more interesting: C is statically
>> typed, but weak: you can transform the data type in memory from one type
>> to another, such as:
>>
>> int a = 12;
>> float *f = (float*)&a;
>> printf("%f\n", *f);
>>
>> A strongly typed language like Perl, though, won't allow that: you can't
>> interpret an integer value as any other type without going through an
>> appropriate conversion routine.
>> [..]
>> Oh, not to mention that most good compilers for dynamically typed
>> languages let you tune various options in the generated code, such as
>> the Common Lisp:
>>
>> (declare (safety 0) (speed 3))
>>
>> That tells the compiler to omit type checking and just assume the values
>> are what they are declared to be: generate code as fast as possible,
>> with as little safety as possible.
>
> Right, I tend to view both static/dynamic the strong/weak comparison as a
> continuous scale these days rather than a black or white definition,
Generally, I think, the strong/weak dichotomy is black and white: either
the language allows you to treat arbitrary bytes of memory as two
different types, or it doesn't — I can't find any exceptions.
static/dynamic is definitely a spectrum, though.
[...]
>> OCaml, which runs somewhere between just below and significantly above C
>> in terms of performance, gains much of this ability from the same
>> feature: the strong typing means that they can do good type inference
>> and generate efficient code without needing type annotations everywhere.
>> [..]
>> So, overall, I don't think I would be brave enough to assert that most
>> compiled languages were statically typed even if I wanted to include
>> only the popular, real world languages.
>
> Re your OCaml quote above, I'd argue that it's static typing, not strong
> typing, that's required for type inference. However, all the statements
> above really depends on your own definition of static typing vs dynamic
> typing and strong vs weak
This is a fair comment, and I certainly agree with you about the
difficulties of terminology. :)
[...]
>> Efficient compilers[2] for dynamic languages can associate type in a
>> range of ways other than the traditional box/unbox representation, with
>> varying efficiency, using tagged pointers, inference from variable
>> storage or region allocation among other techniques.
>
> Sure, I didn't mean to imply that all dynamic languages use boxing/tags.
For what it is worth, I figured that you didn't, but that the rest of
the readers on the list might be, so much of this comment was aimed at
the unheard masses.
> However, it's a ton more effort for dynamic languages to generate
> compiled code that's as efficient as a static language. Writing a JIT
> engine that surpasses the speed of a ahead-of-time compiler is quite a
> large effort[2], and really, not very many language do this.
I think it would be fair to say that writing an efficient compiler for
*any* language is extremely challenging. Heck, strike compiler and
substitute interpreter and the statement remains true.
A good example of this is GCC: popular, but as recent discussion on the
Linux kernel mailing list shows, terrible at stack-slot reuse, resulting
in vastly higher memory use when inlining code than is necessary.
Alternately, ruby is a fine example: a range of interpreters, each with
their own performance, but generally not doing so well. That isn't so
much a language property as a "hard to write efficient ..." property.
> So, I still stand by both my statements that static typing goes
> hand-in-hand with fast performance -- because it's much easier to
> obtain fast performance if you have static typing -- and that most
> compiled languages are statically typed
Mmmm. I have the most trouble accepting the last statement, and in a
couple of years I probably won't at all. OTOH, it doesn't matter that
much yet. :)
The main reason for that is the move to using serious JIT enabled
virtual machines for popular code: JavaScript is increasingly replacing
more traditional code, along with "interpreted" languages moving to
VM-hosting on the CIL, JVM or (occasionally) similar platforms.
> (if you consider my personal definition of static typing, which is
> that types are known at compile-time -- I wrote my original message
> with that definition in mind).
That encompasses a language that uses no type annotation at all, but
performs effective type inference. On that basis I can certainly agree
with you — though I bet many people wouldn't identify a code sample as
being statically typed. ;)
Regards,
Daniel
_______________________________________________
coders mailing list
coders@slug.org.au
http://lists.slug.org.au/listinfo/coders
