Linked by Eugenia Loli on Thu 10th Aug 2006 21:56 UTC, submitted by gonzo
General Development With highly expressive syntax that is easy to read, write, and maintain, dynamic programming languages like Python and Ruby are extremely conducive to rapid development. Microsoft and Sun Microsystems have observed growing interest in dynamic programming, and plan to integrate more extensive support for dynamic language features in their respective managed language platforms. Elsewhere, check PHP for .NET.
Thread beginning with comment 151499
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

Had the same idea a while ago...
But I don't really know if compile time would only slightly slow down the whole process.
g++ is not exactly fast at compiling stuff.
At least for some of my small programs (~500 lines) it took about five seconds and the slowdown seemed to grow worse than linear with the number of lines.

Of course you could always choose a faster compiler, say tinyC, that might compile ten times faster at best but then the generated code will be slower.
It would probably approach the speed (or lack thereof) of a JIT-compiler as you increased compile speed further and further...

Reply Parent Score: 2

SamuraiCrow Member since:

Thanks, RandomGuy, for your reply. Your comments made me realize that I had failed to fully indicate the method of compiliation I was describing.

Here's the process I'm suggesting: GCC to compile to a bytecode on the developer's platform, bytecode to compile to native code at install time. GCC is slow becuase it does a lot of macro-optimisation internally using its internal bytecode. The only compilation necessary on the client side would be the final back-end code-generation stage of the compiler.

Reply Parent Score: 1

RandomGuy Member since:

Hmm, I think you explained it quite well.
It's just that I don't know all that much about the compiling process so I didn't know where most of the time was spent.
I often heard guys complain that GCC throws away type information only to recover it incompletely (eg. autovectorisatiion). Do you know at which point exactly this loss of information happens?
In other words: Is all of the type info still available after compilation to bytecode?

Reply Parent Score: 1