RAD vs. performance

Curtis W wrote:
> Dr Jon D Harrop wrote:
> > > I certainly do. It might require slightly more work from the programmer
> > > compared to a baseline, unoptimized version, but it'll still probably
> > > be shorter than the statically typed version or at most equivalent in
> > > size.
> >
> > I'll believe it when I see it.
>
> So, does this amount to your objection with dynamic typing, or do you
> have an actual reason?

The non-existence of a good implementation is a valid reason not to
subscribe to such a belief.

> > > > Dynamic typing is not "higher level". It is a special case of static
> > > > typing.
> > >
> > > Dynamic typing is not a "special case" of static typing--they're both
> > > two different ways to implement a type system. One does more checking
> > > at compile time, the other doesn't.
> >
> > Static typing implies that you do some type checking at compile time.
> > The special case of static typing with no type checks done at compile
> > time can be called dynamic typing.
>
> At which point it's no longer static typing. With that reasoning, a
> semi is a specific type of sports car, because they both have wheels
> but the semi has a trailor.

Your compiler supports n compile-time checks. In the general case of
n>0, you have a statically typed language. In the special case n=0, you
have a dynamically typed language.

Cheers,
Jon.

Curtis W wrote:
> Dr Jon D Harrop wrote:
> > > I certainly do. It might require slightly more work from the programmer
> > > compared to a baseline, unoptimized version, but it'll still probably
> > > be shorter than the statically typed version or at most equivalent in
> > > size.
> >
> > I'll believe it when I see it.
>
> So, does this amount to your objection with dynamic typing, or do you
> have an actual reason?

The non-existence of a good implementation is a valid reason not to
subscribe to such a belief.

> > > > Dynamic typing is not "higher level". It is a special case of static
> > > > typing.
> > >
> > > Dynamic typing is not a "special case" of static typing--they're both
> > > two different ways to implement a type system. One does more checking
> > > at compile time, the other doesn't.
> >
> > Static typing implies that you do some type checking at compile time.
> > The special case of static typing with no type checks done at compile
> > time can be called dynamic typing.
>
> At which point it's no longer static typing. With that reasoning, a
> semi is a specific type of sports car, because they both have wheels
> but the semi has a trailor.

Your compiler supports n compile-time checks. In the general case of
n>0, you have a statically typed language. In the special case n=0, you
have a dynamically typed language.

Cheers,
Jon.

Dr Jon D Harrop wrote:
> Curtis W wrote:
> > Dr Jon D Harrop wrote:
> > > > I certainly do. It might require slightly more work from the programmer
> > > > compared to a baseline, unoptimized version, but it'll still probably
> > > > be shorter than the statically typed version or at most equivalent in
> > > > size.
> > >
> > > I'll believe it when I see it.
> >
> > So, does this amount to your objection with dynamic typing, or do you
> > have an actual reason?
>
> The non-existence of a good implementation is a valid reason not to
> subscribe to such a belief.
Such pessimistic views aren't particularly helpful to advancing
knowledge, however. After all, everything has to exist as a concept
before it is implemented; if everyone thought like you, the industry
would be at a stand-still!

> > > > > Dynamic typing is not "higher level". It is a special case of static
> > > > > typing.
> > > >
> > > > Dynamic typing is not a "special case" of static typing--they're both
> > > > two different ways to implement a type system. One does more checking
> > > > at compile time, the other doesn't.
> > >
> > > Static typing implies that you do some type checking at compile time.
> > > The special case of static typing with no type checks done at compile
> > > time can be called dynamic typing.
> >
> > At which point it's no longer static typing. With that reasoning, a
> > semi is a specific type of sports car, because they both have wheels
> > but the semi has a trailor.
>
> Your compiler supports n compile-time checks. In the general case of
> n>0, you have a statically typed language. In the special case n=0, you
> have a dynamically typed language.
Aside from being an incorrect definition of dynamic typing, it isn't
even right in the general sense. The general variable 'n' refers to a
quality present in all type systems, thus dynamic typing is a special
case of type systems, not static typing. It's also worth pointing out
the fact that a dynamically typed language doesn't preclude the
checking of errors at compile time, so long as it keeps with the
general spirit of dynamic typing.

Dr Jon D Harrop wrote:
> Curtis W wrote:
> > Dr Jon D Harrop wrote:
> > > > I certainly do. It might require slightly more work from the programmer
> > > > compared to a baseline, unoptimized version, but it'll still probably
> > > > be shorter than the statically typed version or at most equivalent in
> > > > size.
> > >
> > > I'll believe it when I see it.
> >
> > So, does this amount to your objection with dynamic typing, or do you
> > have an actual reason?
>
> The non-existence of a good implementation is a valid reason not to
> subscribe to such a belief.
Such pessimistic views aren't particularly helpful to advancing
knowledge, however. After all, everything has to exist as a concept
before it is implemented; if everyone thought like you, the industry
would be at a stand-still!

> > > > > Dynamic typing is not "higher level". It is a special case of static
> > > > > typing.
> > > >
> > > > Dynamic typing is not a "special case" of static typing--they're both
> > > > two different ways to implement a type system. One does more checking
> > > > at compile time, the other doesn't.
> > >
> > > Static typing implies that you do some type checking at compile time.
> > > The special case of static typing with no type checks done at compile
> > > time can be called dynamic typing.
> >
> > At which point it's no longer static typing. With that reasoning, a
> > semi is a specific type of sports car, because they both have wheels
> > but the semi has a trailor.
>
> Your compiler supports n compile-time checks. In the general case of
> n>0, you have a statically typed language. In the special case n=0, you
> have a dynamically typed language.
Aside from being an incorrect definition of dynamic typing, it isn't
even right in the general sense. The general variable 'n' refers to a
quality present in all type systems, thus dynamic typing is a special
case of type systems, not static typing. It's also worth pointing out
the fact that a dynamically typed language doesn't preclude the
checking of errors at compile time, so long as it keeps with the
general spirit of dynamic typing.

Curtis W wrote:
> > If you didn't design for it, you've got quite a bit of work to do.
> > However, the static type system will pick up on all of your type errors
> > while you're developing, so it won't take long to make the alterations.
>
> Ah, but you see, that wouldn't even be necessary if the standard
> library was written correctly in the first place.

How is OCaml's stdlib relevant here and what do you mean by
"correctly"?

> > How do you mean? A lot of the duplication in the stdlib is done for
> > performance reasons, not because it is good abstract design. Indeed,
> > abstracting numbers in OCaml is extremely costly in terms of
> > performance (up to 20x slower).
>
> That's only partly true. Even with a generic standard library, it
> would've been possible to completely negate the cost through proper
> inference in the compiler.

No. The performance cost of abstraction in OCaml has nothing to do with
inference.

> Unfortunately, rather than doing this, the
> compiler writers and language designers simply pushed it off onto the
> programmer to do, manually.

What are you talking about? What does the programmer have to do
manually?

Cheers,
Jon.

Curtis W wrote:
> > If you didn't design for it, you've got quite a bit of work to do.
> > However, the static type system will pick up on all of your type errors
> > while you're developing, so it won't take long to make the alterations.
>
> Ah, but you see, that wouldn't even be necessary if the standard
> library was written correctly in the first place.

How is OCaml's stdlib relevant here and what do you mean by
"correctly"?

> > How do you mean? A lot of the duplication in the stdlib is done for
> > performance reasons, not because it is good abstract design. Indeed,
> > abstracting numbers in OCaml is extremely costly in terms of
> > performance (up to 20x slower).
>
> That's only partly true. Even with a generic standard library, it
> would've been possible to completely negate the cost through proper
> inference in the compiler.

No. The performance cost of abstraction in OCaml has nothing to do with
inference.

> Unfortunately, rather than doing this, the
> compiler writers and language designers simply pushed it off onto the
> programmer to do, manually.

What are you talking about? What does the programmer have to do
manually?

Cheers,
Jon.

Dr Jon D Harrop wrote:
> Curtis W wrote:
> > > If you didn't design for it, you've got quite a bit of work to do.
> > > However, the static type system will pick up on all of your type errors
> > > while you're developing, so it won't take long to make the alterations.
> >
> > Ah, but you see, that wouldn't even be necessary if the standard
> > library was written correctly in the first place.
>
> How is OCaml's stdlib relevant here and what do you mean by
> "correctly"?
This problem would've been solved before even having arised had the
standard library been written in an extensible fashion using objects.

> > > How do you mean? A lot of the duplication in the stdlib is done for
> > > performance reasons, not because it is good abstract design. Indeed,
> > > abstracting numbers in OCaml is extremely costly in terms of
> > > performance (up to 20x slower).
> >
> > That's only partly true. Even with a generic standard library, it
> > would've been possible to completely negate the cost through proper
> > inference in the compiler.
>
> No. The performance cost of abstraction in OCaml has nothing to do with
> inference.
First, yes it does. Second, I mistated that. I meant to say something
along the lines of:

it would've been possible to completely negate the cost most of the
time through proper inference in the compiler. It's completely possible
to infer when variants are and aren't needed most of the time; when
it's not possible, e.g. in circumstances in which complete compilation
would be necessary to find it, the generic case would be used. If it
turns out to be a bottleneck, the language could allow the programmer
to force a specific case, e.g. with a type declaration.

> > Unfortunately, rather than doing this, the
> > compiler writers and language designers simply pushed it off onto the
> > programmer to do, manually.
>
> What are you talking about? What does the programmer have to do
> manually?
Pick the correct function/operator to use.

Dr Jon D Harrop wrote:
> Curtis W wrote:
> > > If you didn't design for it, you've got quite a bit of work to do.
> > > However, the static type system will pick up on all of your type errors
> > > while you're developing, so it won't take long to make the alterations.
> >
> > Ah, but you see, that wouldn't even be necessary if the standard
> > library was written correctly in the first place.
>
> How is OCaml's stdlib relevant here and what do you mean by
> "correctly"?
This problem would've been solved before even having arised had the
standard library been written in an extensible fashion using objects.

> > > How do you mean? A lot of the duplication in the stdlib is done for
> > > performance reasons, not because it is good abstract design. Indeed,
> > > abstracting numbers in OCaml is extremely costly in terms of
> > > performance (up to 20x slower).
> >
> > That's only partly true. Even with a generic standard library, it
> > would've been possible to completely negate the cost through proper
> > inference in the compiler.
>
> No. The performance cost of abstraction in OCaml has nothing to do with
> inference.
First, yes it does. Second, I mistated that. I meant to say something
along the lines of:

it would've been possible to completely negate the cost most of the
time through proper inference in the compiler. It's completely possible
to infer when variants are and aren't needed most of the time; when
it's not possible, e.g. in circumstances in which complete compilation
would be necessary to find it, the generic case would be used. If it
turns out to be a bottleneck, the language could allow the programmer
to force a specific case, e.g. with a type declaration.

> > Unfortunately, rather than doing this, the
> > compiler writers and language designers simply pushed it off onto the
> > programmer to do, manually.
>
> What are you talking about? What does the programmer have to do
> manually?
Pick the correct function/operator to use.

Curtis W wrote:
> Dr Jon D Harrop wrote:
> > The non-existence of a good implementation is a valid reason not to
> > subscribe to such a belief.
>
> Such pessimistic views aren't particularly helpful to advancing
> knowledge, however. After all, everything has to exist as a concept
> before it is implemented; if everyone thought like you, the industry
> would be at a stand-still!

As you've said, lots of people have tried very hard to write good
compilers for dynamically typed languages and, as I have said, none
have been able to compete with statically typed languages. You're
welcome to sit around believing that you could do better if you tried.
I'd rather attack some tractable problems.

> > Your compiler supports n compile-time checks. In the general case of
> > n>0, you have a statically typed language. In the special case n=0, you
> > have a dynamically typed language.
>
> Aside from being an incorrect definition of dynamic typing, it isn't
> even right in the general sense. The general variable 'n' refers to a
> quality present in all type systems, thus dynamic typing is a special
> case of type systems, not static typing. It's also worth pointing out
> the fact that a dynamically typed language doesn't preclude the
> checking of errors at compile time, so long as it keeps with the
> general spirit of dynamic typing.

A "dynamically typed" language which checks errors at compile time can
be regarded as a statically typed language.

Cheers,
Jon.

Curtis W wrote:
> Dr Jon D Harrop wrote:
> > The non-existence of a good implementation is a valid reason not to
> > subscribe to such a belief.
>
> Such pessimistic views aren't particularly helpful to advancing
> knowledge, however. After all, everything has to exist as a concept
> before it is implemented; if everyone thought like you, the industry
> would be at a stand-still!

As you've said, lots of people have tried very hard to write good
compilers for dynamically typed languages and, as I have said, none
have been able to compete with statically typed languages. You're
welcome to sit around believing that you could do better if you tried.
I'd rather attack some tractable problems.

> > Your compiler supports n compile-time checks. In the general case of
> > n>0, you have a statically typed language. In the special case n=0, you
> > have a dynamically typed language.
>
> Aside from being an incorrect definition of dynamic typing, it isn't
> even right in the general sense. The general variable 'n' refers to a
> quality present in all type systems, thus dynamic typing is a special
> case of type systems, not static typing. It's also worth pointing out
> the fact that a dynamically typed language doesn't preclude the
> checking of errors at compile time, so long as it keeps with the
> general spirit of dynamic typing.

A "dynamically typed" language which checks errors at compile time can
be regarded as a statically typed language.

Cheers,
Jon.

Dr Jon D Harrop wrote:
> Curtis W wrote:
> > Dr Jon D Harrop wrote:
> > > The non-existence of a good implementation is a valid reason not to
> > > subscribe to such a belief.
> >
> > Such pessimistic views aren't particularly helpful to advancing
> > knowledge, however. After all, everything has to exist as a concept
> > before it is implemented; if everyone thought like you, the industry
> > would be at a stand-still!
>
> As you've said, lots of people have tried very hard to write good
> compilers for dynamically typed languages and, as I have said, none
> have been able to compete with statically typed languages. You're
> welcome to sit around believing that you could do better if you tried.
> I'd rather attack some tractable problems.
If I try? I'm actually almost done with my interpreter, at which point
I'll start writing the compiler In any event, I still don't see what
you're point is. Circumstantial evidence doesn't prove or disprove the
ability to create such a system; unless you have an actual argument
against what I've said, I'll have to think you're just beating around
the bush.

> > > Your compiler supports n compile-time checks. In the general case of
> > > n>0, you have a statically typed language. In the special case n=0, you
> > > have a dynamically typed language.
> >
> > Aside from being an incorrect definition of dynamic typing, it isn't
> > even right in the general sense. The general variable 'n' refers to a
> > quality present in all type systems, thus dynamic typing is a special
> > case of type systems, not static typing. It's also worth pointing out
> > the fact that a dynamically typed language doesn't preclude the
> > checking of errors at compile time, so long as it keeps with the
> > general spirit of dynamic typing.
>
> A "dynamically typed" language which checks errors at compile time can
> be regarded as a statically typed language.
Not really, no. A statically typed language requires everything to be
checkable at compile time, with explicit casts or waives by the
programmer for when this is not true. Dynamic typing requires nothing
of the sort, even when checks are done at compile time.

Dr Jon D Harrop wrote:
> Curtis W wrote:
> > Dr Jon D Harrop wrote:
> > > The non-existence of a good implementation is a valid reason not to
> > > subscribe to such a belief.
> >
> > Such pessimistic views aren't particularly helpful to advancing
> > knowledge, however. After all, everything has to exist as a concept
> > before it is implemented; if everyone thought like you, the industry
> > would be at a stand-still!
>
> As you've said, lots of people have tried very hard to write good
> compilers for dynamically typed languages and, as I have said, none
> have been able to compete with statically typed languages. You're
> welcome to sit around believing that you could do better if you tried.
> I'd rather attack some tractable problems.
If I try? I'm actually almost done with my interpreter, at which point
I'll start writing the compiler In any event, I still don't see what
you're point is. Circumstantial evidence doesn't prove or disprove the
ability to create such a system; unless you have an actual argument
against what I've said, I'll have to think you're just beating around
the bush.

> > > Your compiler supports n compile-time checks. In the general case of
> > > n>0, you have a statically typed language. In the special case n=0, you
> > > have a dynamically typed language.
> >
> > Aside from being an incorrect definition of dynamic typing, it isn't
> > even right in the general sense. The general variable 'n' refers to a
> > quality present in all type systems, thus dynamic typing is a special
> > case of type systems, not static typing. It's also worth pointing out
> > the fact that a dynamically typed language doesn't preclude the
> > checking of errors at compile time, so long as it keeps with the
> > general spirit of dynamic typing.
>
> A "dynamically typed" language which checks errors at compile time can
> be regarded as a statically typed language.
Not really, no. A statically typed language requires everything to be
checkable at compile time, with explicit casts or waives by the
programmer for when this is not true. Dynamic typing requires nothing
of the sort, even when checks are done at compile time.

Curtis W wrote:
> > You do have to care about the internal representation. That is my
> > point. Trying to brush it under the carpet by providing a consistent
> > interface is asking for trouble.
>
> You only have to care when you interpret the numbers, not when you
> calculate them.

Nonsense. I already gave transitivity as a counter-example.

> > No, it has the advantage that the rest of your program can be
> > statically type checked. If most of your code is not in the dynamically
> > typed interface, then that benefit is worth having, otherwise it is
> > not.
>
> Ok, and what do you gain by having the rest of your program "statically
> type checked"?

Reliability.

> > > > Has anyone ever made a compiler for a dynamically typed language that gets
> > > > performance comparable to that of statically typed languages without having
> > > > massively longer compile times?
> > >
> > > I don't know. I think so. But does it really matter?
> >
> > Of course it matters. I'm not about to ditch statically typed languages
> > with compilers that exist and work because someone thinks that it might
> > be possible to write a compiler for a dynamically typed language that
> > offers the same benefits. Especially when all the evidence indicates
> > that this is wrong.
>
> This is a purely theoretical debate; nobody's trying to force you to
> use dynamic typing, we're merely correcting your misconceptions about
> dynamic typing.

Your theory is so detached from reality that it is worthless.

> > > What's important
> > > isn't if anyone _has_, but if it's _possible_. I think it is,
> >
> > I think it isn't even theoretically possible. Just look at the work
> > Stalin has to do to get decent run-time performance.
>
> I think it is. Of course, we could go on all day like this, so would
> you like to, perhaps, provide a reason why you think so?

Get good run- and compile-time from a dynamically typed language?
Because you need whole-program optimisation for a start.

> I've already
> walked you through a type inference example for my dynamically typed
> language; it's your turn.

>From my point of view, you have stated that you believe you can easily
do something that mankind has been trying and failing to do for 50
years.

> > Any way you cut it, if you "develop" a dynamic type system to provide
> > the benefits of a static type system then you've reinvented the static
> > type system.
>
> What is your reasoning behind this outlandish claim?

The benefits of static typing come at compile time. In order to get
those benefits, you must be doing static checking. That isn't
outlandish, it's obvious.

Cheers,
Jon.

Curtis W wrote:
> > You do have to care about the internal representation. That is my
> > point. Trying to brush it under the carpet by providing a consistent
> > interface is asking for trouble.
>
> You only have to care when you interpret the numbers, not when you
> calculate them.

Nonsense. I already gave transitivity as a counter-example.

> > No, it has the advantage that the rest of your program can be
> > statically type checked. If most of your code is not in the dynamically
> > typed interface, then that benefit is worth having, otherwise it is
> > not.
>
> Ok, and what do you gain by having the rest of your program "statically
> type checked"?

Reliability.

> > > > Has anyone ever made a compiler for a dynamically typed language that gets
> > > > performance comparable to that of statically typed languages without having
> > > > massively longer compile times?
> > >
> > > I don't know. I think so. But does it really matter?
> >
> > Of course it matters. I'm not about to ditch statically typed languages
> > with compilers that exist and work because someone thinks that it might
> > be possible to write a compiler for a dynamically typed language that
> > offers the same benefits. Especially when all the evidence indicates
> > that this is wrong.
>
> This is a purely theoretical debate; nobody's trying to force you to
> use dynamic typing, we're merely correcting your misconceptions about
> dynamic typing.

Your theory is so detached from reality that it is worthless.

> > > What's important
> > > isn't if anyone _has_, but if it's _possible_. I think it is,
> >
> > I think it isn't even theoretically possible. Just look at the work
> > Stalin has to do to get decent run-time performance.
>
> I think it is. Of course, we could go on all day like this, so would
> you like to, perhaps, provide a reason why you think so?

Get good run- and compile-time from a dynamically typed language?
Because you need whole-program optimisation for a start.

> I've already
> walked you through a type inference example for my dynamically typed
> language; it's your turn.

>From my point of view, you have stated that you believe you can easily
do something that mankind has been trying and failing to do for 50
years.

> > Any way you cut it, if you "develop" a dynamic type system to provide
> > the benefits of a static type system then you've reinvented the static
> > type system.
>
> What is your reasoning behind this outlandish claim?

The benefits of static typing come at compile time. In order to get
those benefits, you must be doing static checking. That isn't
outlandish, it's obvious.

Cheers,
Jon.

On Wed, Jun 28, 2006 at 10:29:20AM -0700, Dr Jon D Harrop wrote:
>
> How do you mean? A lot of the duplication in the stdlib is done for
> performance reasons, not because it is good abstract design. Indeed,
> abstracting numbers in OCaml is extremely costly in terms of
> performance (up to 20x slower).

Perhaps it is worth noting that this is about the same factor I measured
in my prime number benchmark for Chicken with vs. without
-fixnum-arithmetic (9 seconds with, 160 seconds without).

Bob