URLs Matter Wisconsin Voting Machines
Jan 06

Microsoft shows they are serious about dynamic languages….. again!

Tech Add comments

Please listen Sun. Please do something about this, rather than adding one opcode as Ted put it ;)

Mr IronPython (and former AspectJ lead, and Jython, …) Jim Hugunin posted:

We

6 Responses to “Microsoft shows they are serious about dynamic languages….. again!”

  1. Mikael Gueck Says:

    Please Sun, do about Python and Ruby exactly what you did about VB – concentrate on building actually useful tools. Pandering to bored programmers is not a viable long term strategy, it’s not like the current fad will last any longer than any of the previous ones.

  2. Dion Says:

    Mikael:

    This isn’t about bored programmers. This is about building a platform that caters to people from many backgrounds, and allows you to choose the right solution for the job.

    Java is a plaform, not just a language. Sun needs to start thinking of it in that way else it will lose.

    Cheers,

    Dion

  3. Rob Says:

    Mikael: calling the rise or ruby/groovy/js a fad is a bit disingenuous, don’t you think?

  4. Sascha M. Says:

    PHP + Java is the way to go. IBM, Oracle, SAP and Intel are business-partners of Zend, PHP’s mother-company. Eclipse has an offical PHP-project now. Caucho already has PHP running on top of the JVM. Same will be done by other Java-companies. PHP has 40% market-share in webapplications.

    No need to be afraid, Dion. I guess the major Java-companies are aware of dynamic (web-)languages and they aware of the most import: PHP!

  5. Dalibor Topic Says:

    10 years ago, sure, the Java world embracing the world outside it would have been an interesting strategy. Unfortunately, the direction taken was a different one, to encourage/force people to rewrite everything in Java so that it could run on top of a JVM. The Java language world stayed a neat little pool of its own, largely.

    The same has happened with the JVM: it is extremly limited in how it can be used to interact with code written in other programming languages, unless those languages are ported over / cross-compiled to run on top of the JVM.

    That’s by design, because it was written to run Java in the first place, and not to be an arbitrary ‘CPU’. Due to backward compatiblity constraints, it’s not likely to change very much in the future.

    Sorry :(

    The problem with cross-compiling to Java bytecode, or interpreting the language on the JVM, is that for a lot of things, the JVM is far from the optimal enviroment to port to. Think of simulating C pointers, C++’s deterministic deconstructors, on a JVM: it’s not easily done very efficiently. The bytecode format itself is a pretty hard limit one bumps into, as it has not been designed as an ELF substitute. Etc, etc.

    cheers,
    dalibor topic

  6. Charles Nutter Says:

    Hiya Dion!

    What a great idea! Then the 30 hours I spend every week working to redesign JRuby’s internals would be paid time :)

    Seriously though…as much fun as I’m having with this thing, I’d be the first to say that an actual job would be a huge help. Both Tom and I (the most active developers on the JRuby team right now) have day jobs, so our available time to spend on JRuby is minimal at best. I’ve actually gone so far as to take a week off from work to do JRuby.

    My redesign plans are ambitious, and I’m hoping to present a version of JRuby at JavaOne that will fully support Ruby’s thread scheduling, continuations, and hopefully, Rails. I’ve spent something like 25-30 hours this week on JRuby, and I’ll be working through the weekend.

    The concerns some others have had about dynamic languages on the JVM are well-founded, but in my redesign I’m taking an approach I think will work well. JRuby is transitioning toward a partial “JRuby VM” that runs on top of the JVM. Essentially this means that calls into Ruby land are run through an separate set of VM-like services that mimic the runtime environment Ruby must have to work correctly. This means iterative interpretation, heap-allocated stack frames, green threads (scheduled m:n with native threads), continuation support, and some level of AOT or JIT compilation. As various changes are made to the JVM allowing us similar services, we can transition those subsystems to native versions.

    I hope to have this redesign completed and working by JavaOne. Tom hopes to have a number of functional goals completed. Corporate support for our work would help speed things along…but we’ll get there eventually (though I’d sure like to work on this all day, every day).

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'ajax'