//Since CLR/.NET etc… is designed for statically typed
//languages and have penalties like casting involved, will
//using it be a good thing?
Good question - to be honest I am not sure how dynamic typing is can be
done in the way it is presently done in Ruby. I would expect that some
of the reflection API will come into play that can generates types at
runtime. Such code may have slow startup times but could potentially run
as fast as other managed code.
To be honest I don’t know how Jim Hugunin has solved some of these
issues for his IronPython - his notes indicate that IronPython is fast,
faster than traditional C python. Look at this blog entry for relevant
links: http://www.hole.fi/jajvirta/weblog/20031210T0901.html
//Since CLR/.NET etc… is designed for statically typed
//languages and have penalties like casting involved, will
//using it be a good thing?
Good question - to be honest I am not sure how dynamic typing is can be
done in the way it is presently done in Ruby. I would expect that some
of the reflection API will come into play that can generates types at
runtime. Such code may have slow startup times but could potentially run
as fast as other managed code.
Yes, the approach we are taking is to generate most things dynamically.
If you do that it seems the CLR actually can give you a lot of freedom.
To be honest I don’t know how Jim Hugunin has solved some of these
issues for his IronPython - his notes indicate that IronPython is fast,
faster than traditional C python. Look at this blog entry for relevant
links: http://www.hole.fi/jajvirta/weblog/20031210T0901.html
Unfortunately, Jim has talked very little about the technical details so
far.
However, for a majority of Ruby’s dynamism we have spikes that show how
to solve them; for the rest I’m more skeptical. In particular, I don’t
see continuations happening, threads will be different and probably some
other things I forget about now…
stack based languages do computation on stack. They usually identify var as
index and process the stack. variable names vanish. Ruby, I think will need
the variable names at many places to process code.
