Newbie Question
Kent Tegels
I read in the FAQ, vis a vis using the .NET instead of writing your own "The
.NET VM didn't even exist when we started development, or at least we didn't
know about it when we were working on the design. We do now, though it's
still not suitable."
I'm curious as to why its not suitable.
Nothing up my sleave here, just trying learn what the issues are.
Thanks!
Kent Tegels
_________________________________________________________________
Watch LIVE baseball games on your computer with MLB.TV, included with MSN
Premium!
http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/onm00200439ave/direct/01/
Goplat
> Hello, all, and greetings from Omaha.
>
> I read in the FAQ, vis a vis using the .NET instead of writing your own
> "The .NET VM didn't even exist when we started development, or at least we
> didn't know about it when we were working on the design. We do now, though
> it's still not suitable."
>
> I'm curious as to why its not suitable.
>
> Nothing up my sleave here, just trying learn what the issues are.
The paragraph above that says
Those VMs are designed for statically typed languages. That's fine,
since Java, C#, and lots of other languages are statically typed. Perl
isn't. For a variety of reasons, it means that Perl would run more
slowly there than on an interpreter geared towards dynamic languages.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Paolo Molaro
> > I read in the FAQ, vis a vis using the .NET instead of writing your own
> > "The .NET VM didn't even exist when we started development, or at least we
> > didn't know about it when we were working on the design. We do now, though
> > it's still not suitable."
> Those VMs are designed for statically typed languages. That's fine,
> since Java, C#, and lots of other languages are statically typed. Perl
> isn't. For a variety of reasons, it means that Perl would run more
> slowly there than on an interpreter geared towards dynamic languages.
People may want to take a look at this paper:
http://www.python.org/pycon/dc2004/papers/9/IronPython_PyCon2004.html
It suggests a few techniques to implement dynamic languages on the CLR
(some surprisingly similar to the ones I suggested on these lists or in
private emails to people asking: kudos to Jim for actually writing the
code instead of just talking like me:-).
As it has been suggested, python on the CLR runs significantly faster
for some programs and significantly slower for others: now to find out
what case is more prevalent in common code:-) It seems safe to say,
though, that it can run rougthly at the same speed as the current C
implementation, but with all the interoperability advantages that
running on the CLR gives. That sounds good enough for me: I would pay a
50% speed degradation on the dynamic language side when I can easily
implement the time-critical code in C# and have that chunk run 10+
times faster. This new version of IronPython seems to
implement all/most of the semantics of python so it's also likely that
it could be improved to be even faster.
Note also his conclusions, though:
"IronPython can run fast on .NET and presumably on any decent
implementation of the CLR. Python is an extremely dynamic language and
this offers compelling evidence that other dynamic languages should be
able to run well on this platform. However, implementing a dynamic
language for the CLR is not a simple process. The CLR is primarily
designed to support statically typed OO and procedural languages.
Allowing a dynamic language to run well on this platform requires
careful performance tuning and judicious use of the underlying CLR
constructs."
lupus
--
-----------------------------------------------------------------
lu...@debian.org debian/rules
lu...@ximian.com Monkeys do it better
Kent Tegels
kt
________________________________