Re: RAD vs. performance
- From: "Curtis W" <cwarren89@xxxxxxxxx>
- Date: 28 Jun 2006 12:14:31 -0700
Dr Jon D Harrop wrote:
Curtis W wrote:This problem would've been solved before even having arised had the
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"?
standard library been written in an extensible fashion using objects.
First, yes it does. Second, I mistated that. I meant to say somethingHow 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.
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.
Pick the correct function/operator to use.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?
.
- Follow-Ups:
- Re: RAD vs. performance
- From: Jon Harrop
- Re: RAD vs. performance
- References:
- Re: RAD vs. performance
- From: Robbert Haarman
- Re: RAD vs. performance
- From: Jon Harrop
- Re: RAD vs. performance
- From: Robbert Haarman
- Re: RAD vs. performance
- From: Dr Jon D Harrop
- Re: RAD vs. performance
- From: Curtis W
- Re: RAD vs. performance
- From: Jon Harrop
- Re: RAD vs. performance
- From: Curtis W
- Re: RAD vs. performance
- From: Jon Harrop
- Re: RAD vs. performance
- From: Curtis W
- Re: RAD vs. performance
- From: Jon Harrop
- Re: RAD vs. performance
- From: Curtis W
- Re: RAD vs. performance
- From: Jon Harrop
- Re: RAD vs. performance
- From: Curtis W
- Re: RAD vs. performance
- From: Dr Jon D Harrop
- Re: RAD vs. performance
- From: Curtis W
- Re: RAD vs. performance
- From: Dr Jon D Harrop
- Re: RAD vs. performance
- Prev by Date: Re: RAD vs. performance
- Next by Date: Re: RAD vs. performance
- Previous by thread: Re: RAD vs. performance
- Next by thread: Re: RAD vs. performance
- Index(es):
Relevant Pages
|