Home

Misc News

I'm back... Going through my RSS feeds, two items caught my attention:

Tim Bray: Charles Nutter and Thomas Enebo, better known as “The JRuby Guys”, are joining Sun this month.

Jon Udell: Why argue about dynamic versus static languages when you can use both? Which discusses, among other things, why the first three versions of the IronPython compiler were written in Python, but today it's written in C#.

By Ehud Lamm at 2006-09-09 08:48 | Cross language runtimes | General | Ruby | other blogs | 8237 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Bottom-up or Top-down?

Many dynamic languages are mostly compiled and typed functions etc. The application is likely to be a smaller amount of "glue code". Compiling further is a matter of defining which parts of the application are to be regarded as static and which dynamic. Typically one function to identify the program and to read data might be dynamic and the rest could be static. We might then partial evaluate this down to a C file and compile that. I am not aware of this being done but it is technically quite feasible. One version of MuLisp might qualify, Prolog is either compiled or interpreted but the VM isn't partial evaluated down, etc.

By Hank Thediek at Sat, 2006-09-09 12:49 | login or register to post comments

After Sun lets go the Self team

As mentioned here with a preliminary release of Klein, the Self-hosted (sic) implementation.

By Brian T Rice at Sat, 2006-09-09 19:42 | login or register to post comments

Slate

Hey Brian, any chance that Klein could be retrofitted for Slate?

By Dave Lopez at Sun, 2006-09-10 09:25 | login or register to post comments

Not worth it

Slate is sufficiently different, having closures instead of LIFO-only blocks, no literal object syntax, and the architecture is actually simpler. We just need to finish the compiler we actually have or write a much simpler portable one.

By Brian T Rice at Sun, 2006-09-10 20:55 | login or register to post comments

Python compiler rewrite in C#

It's not the approach I would use, but I think his reasoning was sound for the rewrite of the Python compiler in C#. He was able to find the solution with a more exploratory Python approach, and then once he had it solved it, write it in a faster C# and also open it up to more people at Microsoft. Nothing new about that really.

Oh, and I think there might be problems with IronPython being a first class consumable .NET language, but I could be wrong there. If that is the case though, it would be another reason to write it in C#.

But I'm more interested in hearing others opinion on JRuby and hot code swap that will presumably be making it into JVM 7. I read that with the changes that will be made to the JVM, it'll be be easier to do hotswap with dynamic languages than the Java language. If that's the case would it be better to write a Smalltalk-like environment completely in JRuby, than a Netbeans plugin?

By Dave Lopez at Sun, 2006-09-10 12:04 | login or register to post comments

Specifics?

Oh, and I think there might be problems with IronPython being a first class consumable .NET language, but I could be wrong there. If that is the case though, it would be another reason to write it in C#.

What did you have in mind? IronPython is surprisingly "consumable" by the rest of the .NET world, probably its chief strength. It just-in-time generates statically typed adapters in a very wide range of cases. For example, you can make a Python subclass of a .NET subclass, and this subclass and instances thereof will be fully run-time dynamic in the Python world yet consumable via its superclass's interface by the .NET world. The level of seamless interoperability pretty much blew me away.

By Per Vognsen at Sun, 2006-09-10 13:01 | login or register to post comments

Thanks for the heads up

I wasn't too sure if it was CLS compliant or not.

By Dave Lopez at Sun, 2006-09-10 21:02 | login or register to post comments