Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Sun Microsystems Programming IT Technology

Sun Hires Two Key Python Developers 173

Posted by kdawson from the money-where-their-mouth-is dept.
sspringer writes to let us know about Sun's continuing push to support scripting languages other than Java on its Java virtual machine. Sun just hired two key Python developers: Ted Leung, a long-time Python developer at the Open Source Applications Foundation, and Frank Wierzbicki, who is lead implementer of the Jython project. They will both work on Jython, which enables Python to run on the JVM. Last month Sun's CEO said the company wants to "take the J off the JVM and just make it a VM."
This discussion has been archived. No new comments can be posted.

Sun Hires Two Key Python Developers More

Sun Hires Two Key Python Developers

Comments Filter:

  • Python Developers? (Score:5, Funny)

    by techpawn ( 969834 ) on Tuesday March 04, 2008 @08:08AM (#22634440) Journal
    Got my hopes up! I thought you meant John Cleese and Terry Gilliam had new work at Sun...

    • Re:Python Developers? (Score:5, Funny)

      by stoofa ( 524247 ) on Tuesday March 04, 2008 @08:16AM (#22634488)
      Sun statement: We have hired a key Python developer, Ted Leung Frank Wierzbicki... We have hired TWO key Python developers - I'll start again. Amongst our Python developers are such key people as..."
      • When I first came here, this was all statically typed. Everyone said I was daft to build a dynamic language on the JVM, but I built in all the same, just to show them.

        ...It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Lad, the strongest castle in all of England.

    • Re:Python Developers? (Score:5, Funny)

      by ricebowl ( 999467 ) on Tuesday March 04, 2008 @08:19AM (#22634512)

      Got my hopes up! I thought you meant John Cleese and Terry Gilliam had new work at Sun...

      Have you followed Gilliam's career? Almost everything the guy works on is cursed, usually with multiply-redundant curses in case one of them fails...unless you want Sun to die you don't want him working there. The poor fella.

      On the other hand it would be nice to see the giant foot falling from the sky to crush any run-time errors.

    • salesman: 'ow about o'r java desktop running a java virtual machine wi' jython accessin' from a java portal server, that's not got much java in it.

      woman: I don't want *any* java!

      chorus: jav jav jav jav jav jav jav jav, crufty java, bloated java!

    • Re:Python Developers? (Score:4, Funny)

      by Hythlodaeus ( 411441 ) on Tuesday March 04, 2008 @12:23PM (#22637658)
      No, they're clearly working on the Parrot VM (which is just resting.)

  • What happened to Tcl? (Score:5, Interesting)

    by Ed Avis ( 5917 ) <ed@membled.com> on Tuesday March 04, 2008 @08:08AM (#22634442) Homepage
    John Ousterhout used to work for Sun and they had a golden opportunity to push Tcl a bit more and integrate it with Java... but they never did much with Tcl and he eventually left. It's a shame, because I rather liked Tcl with its absurdly minimal syntax.

    • I'm glad he didn't (Score:3, Informative)

      by Viol8 ( 599362 )
      Tcl with its confused mixture of command line style shell script and C syntax made for a horrid language to both read and code in. IMO the only reason it was ever popular was because Tk was a very advanced GUI toolkit for its day but this isn't 1993 anymore, things have moved on and there are many better solutions

      • Re: (Score:2, Insightful)

        by Ed Avis ( 5917 )
        The syntax is not confused: quite the opposite. It is consistent and very minimal. One command per line, lists separated by spaces, "" quotes with variable interpolation, {} quotes without interpolation, [] to call a function, $ gets the value of a variable, and that's pretty much it.

        • Re: (Score:3, Informative)

          by Viol8 ( 599362 )
          Perhaps confused was the wrong word. Hard to read would be a better way of putting it, of which the seperation by spaces was the prime cause. Also I remember it being extremely fussy about where you put the procedure delimiters though perhaps they changed that in later versions.

          • Re: (Score:2)

            by rockhome ( 97505 )
            How is it harder to read than Python?

            At least Tcl isn't as freaky about indentation. Fortran 90 did away with indent-specific formatting.

        • Re: (Score:2)

          by jgrahn ( 181062 )

          The syntax is not confused: quite the opposite. It is consistent and very minimal.

          That's the problem for me. I prefer a richer (less minimal) language, so that my programs can be minimal.

          I have only hacked a single major Tcl program, and it was not enjoyable. It felt like badly designed C code, only with a more verbose syntax ... and no type checking.

      • Re: (Score:2)

        by glop ( 181086 )
        Actually, Tk is still cool. Python has Tkinter which is just plain natural, easy and pretty. I remember that Tk in Tcl was just what you describe but the Tkinter binding just gives a pythonic feel (i.e. clean syntax, readable etc.).

        I used it the other day for the first time on my EEE PC and it was really easy to write. If I had tried it earlier I would probably have written more GUI code for my scripts in the past 10 years. Hindsight is a wonderful thing...

        Tcl is a bit on an anti LISP. In Lisp everything is

    • Re: (Score:3, Informative)

      by morgan_greywolf ( 835522 )

      John Ousterhout used to work for Sun and they had a golden opportunity to push Tcl a bit more and integrate it with Java... but they never did much with Tcl and he eventually left. It's a shame, because I rather liked Tcl with its absurdly minimal syntax.

      Aside from a few niches (mostly, strangely enough, in the realm of scientific computing), Tcl never quite became very mainstream. Sure, it sits quietly on almost every Linux and BSD distro, and sure there are a few things here and there written Tcl or Tcl/Tk, and almost every seasoned Unix developer knows at least a bit of Tcl, the mainstream audience has been eaten by Python and Perl, for the most part. Probably something to do with that 'absurdly minimal syntax', though I guess that still doesn't expla

      • Re:What happened to Tcl? (Score:4, Informative)

        by Otter ( 3800 ) on Tuesday March 04, 2008 @08:50AM (#22634748) Journal
        There was a time when Tcl/Tk was the least excruciating way of making a simple GUI application on Unix. Once decent toolkits (and, eventually, excellent toolkits) became available, Tcl's main selling point was lost.

        • Re:What happened to Tcl? (Score:5, Informative)

          by korbin_dallas ( 783372 ) on Tuesday March 04, 2008 @09:37AM (#22635252) Journal
          Wrong.

          Tcl biggest selling point now is the packaging and deployement.

          I've written apps in a lot of languages, and deployed them all. Absolutely nothing beats Tcl for cross platform deployments. I got a starkit for ppc405, wrote my app on x86. A simple script packaged it all up in less than 2Mb.
          Another few lines, and I had a win32, linux and ppc405 single file executable(for each) ready to go.

          We also use java, which requires a separate 20Mb JRE install, whether its in your distro or not, you still need it, and the right version. Oh and Java 1.5 and Java 1.6 jar classes are incompatible, HAHA. And how many of you out there have a JRE for ppc405 (not a Mac, but a older series used in embedded systems)? Tcl is deployed on far more architectures.

          The 8.4 and later versions are very fast and lightweight.

          Making a gui in Tk is fine and simple, and well, you're gonna make a gui in Tk if you use Perl, Python, Ruby anyway.

          All those other tools could learn from the Tcl packaging design.

          • wxWindows (the one used by VLC) which actually use native UI as backend (GTK on linux, native on Windows, etc.) is small and easily packaged along the software (unlike Win32 GTK which requires an additional install).
            And has the added benefits to integrate nicely with the OS, unlike Tk which looks like an arse whatever OS you run it on, for lacking a proper theme engine until very recently.

    • Re:What happened to Tcl? (Score:5, Funny)

      by Bogtha ( 906264 ) on Tuesday March 04, 2008 @08:58AM (#22634836)

      What happened to Tcl? Well judging from the look of it, I'd say it was run over by a car, then hit by a train, then had a nasty encounter with stampeding bison, then got a nasty infection from a facehugger, then beaten up by Ripley and was then promptly nuked from orbit. It's for the best, it was in a great deal of pain and nobody wants to live like that.

      Seriously though, that's one ugly language. I always got the impression it's what the inventor of Brainfuck would create if he were actually being serious.

    • Re: (Score:2, Funny)

      by foobarbaz ( 21227 )
      What happened was it starting sucking and never stopped.

    • As I heard the story (n-hand so take with a grain of salt), Sun hired Ousterhout because they wanted a language platform they could control and use against Microsoft. However, Ousterhout insisted that TCL remain with its open license.

      When Gosling and crew showed off Oak (later Java), Sun realized they had what they needed, a completely home grown system they could own and control.

      Java became the favorite child, TCL was ignored (so was SELF, another language Sun was interested in). So Ousterhout left Sun

      • Ousterhout never worked for Sun, they simply provided him with office space and equipment to work on Tcl/Tk away from his regular job as a university professor. I'm pretty sure the original Tcl book makes this clear in the preface, but my copy is in storage at the moment so I can't check.

    • Re:What happened to Tcl? (Score:4, Insightful)

      by MenTaLguY ( 5483 ) on Tuesday March 04, 2008 @02:21PM (#22640088) Homepage
      I was a heavy TCL programmer back in those days, and built some fairly serious software in it (and still maintain one package to this day). Honestly, looking back, I'm glad TCL didn't win. It's a horrible language.

      Absurdly minimal, yes. But it's possible to be too minimal. upvar+uplevel in place of pass-by-reference? Unstructured strings as the fundamental representation for everything? The inability to parse the language without simultaneously interpreting it? I'm sorry, but after a decade of experience I think I can say it's just awful. It's like a Scheme dialect from the planet Htrae.

      • Re: (Score:2, Insightful)

        by Ed Avis ( 5917 )

        Honestly, looking back, I'm glad TCL didn't win. It's a horrible language.

        Why you should not use Tcl [vanderburg.org]

        upvar+uplevel in place of pass-by-reference?

        Indeed, you feel you need a bath after using upvar. But plenty of other languages lack proper references; Python for example (though it can kind of emulate them with the Ref container). (Python programmers at this point will retort that it does have references, indeed every variable is a reference. In which case you move the discussion one level up and the ques

  • Inevitable, and very welcome (Score:5, Insightful)

    by kripkenstein ( 913150 ) on Tuesday March 04, 2008 @08:09AM (#22634450) Homepage
    The only innovation that I credit to Microsoft in all its decades of existence is that of the CLR (.NET) being focused on language-independence, and also on Microsoft pushing hard for projects like IronPython to run well. There is really no reason to have to write language bindings all the time; a library written in one language should be accessible to all others. In the long run, this is going to make whatever platform allows that capability far more competitive. Therefore Sun has no option but to go in this direction, especially given the popularity of dynamic languages in recent years.

    Actually FOSS might have done language-interoperation in other ways: given that the source code is available, we might have had automated tools to generate bindings automatically (actually this is happening now, with GObject-introspection, which is relevant so far to C, Vala and Python). But this hasn't happened in an extremely useful way thus far.

    Note that this is just one reason for having a single VM for all languages. Security, optimization, etc. are others. In summary, kudos to Sun. Better late than never.

    • A niggle re:Inevitable, and very welcome (Score:5, Insightful)

      by davecb ( 6526 ) * <davecb@spamcop.net> on Tuesday March 04, 2008 @08:21AM (#22634534) Homepage Journal

      Note that this is just one reason for having a single VM for all languages. Security, optimization, etc. are others.

      Actually, I'd like to see multiple implementations of a class of (J)VMs, in addition to kripkenstein's point about mutiple languages targeting it/them. This would lead to a rapid shake-out of bugs and disfeatures.

      --dave

      • A VM is just another PLATFORM! (Score:5, Interesting)

        by StCredZero ( 169093 ) on Tuesday March 04, 2008 @09:41AM (#22635274)
        A VM should just be treated as just another Platform! It's a virtual CPU, and instruction set architecture. Taking this further, a language and a set of libraries packaged with a VM should also be considered a Platform just as Windows XP or Ubuntu 7.10 is a Platform. This is precisely why Java version hell exists! You should not update platforms willy-nilly. You should not take a platform and bundle it with an application! If you are smart, you should either make everything supremely backwards compatible (Windows) or supremely upgradeable (Debian based Linux) or make a clean (and well organized) break that provides dramatic benefits (Mac OS X).

        Sun didn't get it. Dot-Net got it because they were able to use hindsight to fill in the gaps where Sun didn't. The truth is, VMs and portable languages don't make operating systems irrelevant. They just (partially) virtualize the OS on top of the native one. The sooner VM language people realize this, and all of the pitfalls, the sooner things will get better! (Many already get things right. Python and Ruby seem to get this.)

        • As StCredZero said, a VM is a platform and a target of development environments.

          However, it doesn't need to have a single implementation, any more than the i86 platform does, so I encourage people to create multiple implementations of a given VM ABI and target different languages toward it.

          This, like building on different hardware, exposes bugs with great enthusiasm, which fairly rapidly yield code quality and stability, visible as a falling bug rate.

          In effect, it's a way to trade more bugs now for f

        • Re:A VM is just another PLATFORM! (Score:5, Interesting)

          by jilles ( 20976 ) on Tuesday March 04, 2008 @01:36PM (#22639178) Homepage
          What Java version hell?! It's perfectly backwards compatible (binary and api, minor API bug fixes and deprecations aside). I've been developing on it since 1995 so I have some idea what I'm talking about. I think Java is probably one of the cleanest evolving platforms around (given the massive changes to it since 1995). Compare this to linux where binary compatibility is routinely broken for minor compiler version increments or libc updates. Compare this to C++ which didn't even have a widely endorsed spec until this millennium and continues to have many incompatible compilers (never mind the APIs, I'm just talking about the language semantics here). Arguably, C++ is still a mess.

          I think you are also wrong about virtualization. The whole point of virtualization is to abstract away OS specifics to the point where it literally is nothing more than a commodity needed to run the vm. Who cares if it is mac, windows or linux running your php/Java/ruby server? If you are doing LAMP development, virtualization is what allows you to scale your new hot web application using Amazon provided service on demand stuff. Stuff like JRuby shows that virtualization can actually be fast and scalable too (it's basically kicking regular ruby's ass). Jython is basically going the same way.

          Microsoft certainly had the right ideas with .Net. Their execution is less than perfect, however. Basically an old Java 1.4 hotspot VM still kicks the CLR's ass easily. In terms of scalability and performance there is really no contest between the two. Nevermind, later versions. However, the CLR design is interesting in some respects and some of the stuff MS has done on top of it is quite innovative. But the truth is that the Java platform is still a fine piece of engineering. Many controversial design decisions taken by Sun in the early nineties around this platform are now slowly being picked up elsewhere too. Basically modern compiler architectures like llvm bring stuff that Sun has been doing for years with Java to mainstream. The whole notion of garbage collection has basically displaced the notion of manually allocating memory (except in the most conservative environments). People do web development in environments that are much slower, crappier and less secure than Java (cough php cough) because development speed is so nice to have. In short pretty much everything Java is doing on the server side has been validated through others imitating with varying degrees of success.

          • Re: (Score:3, Interesting)

            by rabtech ( 223758 )
            What, you don't deal with classpaths, libs/JARs, and other associated bits? You've never installed an app that changed the classpath, pointing to new (and subtly incompatible) versions of a JAR, thus breaking things in an odd and impossible to diagnose way? Never had someone or something drop new files into Tomcat's shared lib directory that overrode you? Have you never had to dig through 14 layers of config files (vomited all over the filesystem in some sort of byzantine maze) to find out why something won

            • Re: (Score:2)

              by jilles ( 20976 )
              I actually know what I am doing when messing with Java and it also helps that I actually understand (and even appreciate) how the classloader works (another quite brilliant design decision from SUN), so no this has never been an issue for me. I'm quite handy with tomcat and yes, I've worked on real and I might say pretty obscure systems.

              Basically all it takes is having a clue and setting up your build and deploy environment properly. Clueless idiots manually copying libraries to what they think is the right
          • Java Version Hell happens because different VMs and libraries can collide within the OS substrate. Having CLASSPATH as an environment variable encourages this. I am not sure what else contributes to this, but I have had more trouble (as a USER, not a programmer) with the installation of one JRE trashing a different Java application than anything else. Perl utilities I use aren't bothered by this. Nothing in Python I've used is. Why is this?

            • Re: (Score:2)

              by jilles ( 20976 )
              That's why you shouldn't have set your classpath as an environment variable but using the commandline; via declared dependencies in the jar file or using something like OSGI.

              As far as I understand, python 2.2 and 2.5 are quite far apart and 3.0 will break language and platform compatibility. It kind of matters which python you have. Good luck with the version from 1995. I happen to run into this a lot because pys60 is based on 2.2 which means that most third party stuff doesn't work there. Thanks to dynamic
          • Almost all of the good stuff in Java and the JVM (from garbage collection through hotspot compiling) was developed first for Smalltalk, sometimes decades earlier.

            • Re: (Score:2)

              by jilles ( 20976 )
              Yep, smalltalk definitely deserves credit here. It still has some nice characteristics over Java.

              Arguably the main contribution of Java has been bringing all the smalltalk goodies to mainstream (finally). Some compromises were made along the way but the overall result is still pretty nice.

    • Also, I think many people would love to be able to develop small apps for mobile phones using Python. This opens a whole new market for this language! Very welcome change, indeed!

      • Re: (Score:3, Interesting)

        by Bogtha ( 906264 )

        Actually, Python has been appearing on phones for quite a while, notably Nokia Series 60. I'm not sure, but it might also be possible to use Jython with J2ME devices.

    • Re:Inevitable, and very welcome (Score:5, Informative)

      by benjymouse ( 756774 ) on Tuesday March 04, 2008 @08:48AM (#22634710)

      Yes, and Microsofts strong focus on multiple languages from the onset also gives the CLR/DLR some clear advantages over the JVM.

      The CLR was built around a the notion of a Common Type System (CTS) which means that different languages can share actual objects without having to wrap them. Wrapping cost performance (wrapping and unwrapping when passing between languages). But wrapping is also inherently language-pair oriented, i.e. between 2 pairs of languages such as Java and Jython. Other dynamic language cannot inherently use Jython objects but must also wrap the "canonical" java objects. It is not that it is impossible to achieve on the JVM platform, it's just that Microsoft has a much more mature VM and type system for this kind of job.

      Take Java generics. The JVM type system have no notion of "template" or "generics", hence the generics in Java are implemented through the dreaded type erasure. But that means that no other language (e.g. Scala) can share generic types with Java. Contrast that with the CLR where generics are 1st class type citizens, both in their generic form and when all type parameters has been fully bound.

      Interestingly, the CLR/CTS seems to have been developed seperately from (but coordinated with) C#. The CLR type system can actually represent types which you cannot describe using C# or VB.NET. The CTS is "bigger" and more generalized if you will. The Java VM was always just aimed at serving the Java bytecode. This is something that is going to haunt the JVM now when they are going all multi-language and dynamic.

      • Re:Inevitable, and very welcome (Score:5, Informative)

        by Headius ( 5562 ) on Tuesday March 04, 2008 @09:11AM (#22634970) Homepage Journal
        Generics are basically no help at all to dynamic languages, so I think that's a red herring. And in fact, it makes implementing interop with dynamic languages much more difficult, since it's an additional class of types you have to be able to deal with and recognize. Ask the IronPython and IronRuby guys about the syntax they've had to come up with to support manipulating generics from within Python or Ruby.

        The only problem the JVM has, as far as I can see, is that it's got this whole "Java" thing wrapped around it. The JVM itself is much better suited to all sorts of languages, if only we can punch a hole through the Java exterior. And that's exactly what we're going to do, by adding dynamic invocation support in (hopefully) JDK7 and a host of other features like tail calls, tuples, value objects, continuations, and so on in OpenJDK subprojects like the Multi-Language VM.

        If anything, the CLR is a much more difficult platform to develop dynamic languages for due to its strict static-typed nature. You have to do some really unpleasant tricks to get the CLR to run a dynamic language fast, and that costs a lot of development time and hassle. DLR hopes to make some of that happen across all languages, but at the end of the day the CLR is just not as advanced a VM as the JVM.

        At any rate, it's going to be an interesting couple of years.

    • Re: (Score:2)

      by jhines ( 82154 )
      VAX/VMS had this in their libraries, with a clear API, and calling conventions from all languages. One could mix and match languages as needed.

    • Re: (Score:2, Informative)

      by wuzzeb ( 216420 )

      Actually FOSS might have done language-interoperation in other ways: given that the source code is available, we might have had automated tools to generate bindings automatically

      Actually, you should check out SWIG [swig.org]. It has been around since 1995... open source has had automated tools to generate bindings for a long time now. The main problem with this approach is that C does not give enough information. The biggest problem is memory management. most scripting languages are garbage collected, but ther

      • I'm familiar with SWIG; it's a nice tool. But it isn't as immediate as things can be in a language-independent VM. So while SWIG makes things far easier, it doesn't make things trivial.
    • Actually the JVM was multi-language before Microsoft ever released the CLR. The fact that the CLR had multi-language flexibility as a selling point doesn't change this fact.

  • 2008 - the year of the VM shootout (Score:3, Funny)

    by A beautiful mind ( 821714 ) on Tuesday March 04, 2008 @08:17AM (#22634508)
    I guess we'll see which is better, Python's native, (J)VM or Parrot.
    • You forgot the .NET CLR (IronPython)

      • DLR (Score:2)

        by drewness ( 85694 )
        IronPython runs on the .NET DLR (Dynamic Language Runtime), which is on top of the CLR. The DLR does dynamic types and dynamic dispatch, unlike the CLR. Apparently the DLR code lives in the IronPython tree for the moment, but when IronPython 2.0 is ready they're going to integrate and release the DLR into .NET along with a couple other dynamic languages.

    • Re: (Score:2)

      by TheLink ( 130905 )
      But parrot is dead! ;)
  • In 1995~1996 I was working at a medical imaging company and we were exploring the idea of using Java and its about to be announced graphics interface to be the basis of our new computerized viewers. This was in the time frame of the DEC Shark, a strong ARM based thin client, and Sun's HotJava browser.

    Anyway, Sun has been harping about how the "JVM" could support multiple languages. They talked about Basic and fortran, I guess with M$ pushing C# and C++ on the JVM. Java can finally justify the multi-language

    • Re:Nothing New... 12 years later (Score:5, Informative)

      by TheRaven64 ( 641858 ) on Tuesday March 04, 2008 @08:50AM (#22634742) Journal
      As someone who tried to get a Smalltalk compiler to target the JVM, I can say from experience that it is a really horrible design (and .NET copied all of the worst design decisions). The VM imposes so many constraints that it's really hard to implement anything that isn't semantically almost identical to Java on it without seriously compromising the speed. A far better approach is LLVM, which allows you to layer things like garbage collection and object models on top of a common VM.

      • Re:Nothing New... 12 years later (Score:5, Insightful)

        by Headius ( 5562 ) on Tuesday March 04, 2008 @09:06AM (#22634910) Homepage Journal
        It's difficult, but it's certainly not impossible. And we're working to make it easier by exposing the JVM's underpinnings. You see, the JVM is already a dynamic language VM; it just has this cumbersome static-typing wrapped around it.

        • Re: (Score:3, Informative)

          by TheRaven64 ( 641858 )
          Exactly my point. Unless your type system and dispatch semantics closely match Java, you need trampoline objects which make everything horribly slow. The dynamic call primitives in the latest proposal go a long way towards this, but there is still not enough runtime type introspection for a lot of neat language features.

  • wow; parrot has had an impact. (Score:3, Interesting)

    by WindBourne ( 631190 ) on Tuesday March 04, 2008 @08:28AM (#22634572) Journal
    The only reason why Sun would hire them, now, is if they were concerned about parrot splitting the market.

    • Re:wow; parrot has had an impact. (Score:5, Funny)

      by techpawn ( 969834 ) on Tuesday March 04, 2008 @08:32AM (#22634610) Journal

      is if they were concerned about parrot splitting the market.
      They're pythons! The parrot's dead... 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies!'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisibile!! 'E f-in' stuffed it!

    • Re: (Score:2, Informative)

      by handmedowns ( 628517 )
      Actually the reason Sun hired them is they've made a commitment to get Glassfish http://glassfish.dev.java.net/ [java.net] running other higher level languages besides Ruby. So now they've got some jruby developers and jython developers. They're really trying to push their appserver platform, and with the acquisition of MySQL, they have a complete stack under their roof (SunOneWeb, Glassfish, MySQL) not to mention, OpenDS, OpenSSO, Metro, among other things.

      Sun is going after the ruby and python developers because

    • Re:wow; parrot has had an impact. (Score:5, Informative)

      by Otter ( 3800 ) on Tuesday March 04, 2008 @09:30AM (#22635166) Journal
      Basically, Leung lost his job, posted [sauria.com] on his blog that he was looking, someone at Sun read it and they made him an offer. I don't think this whole thing is nearly as elaborately crafted a strategy as people are making out.

    • Re: (Score:3, Funny)

      by fahrbot-bot ( 874524 )
      The only reason why Sun would hire them, now, ...

      Actually it's because, with the current economic decline, Sun can no longer afford to hire Perl programmers... :-)

  • Um, not just Jython (Score:5, Informative)

    by tbray ( 95102 ) on Tuesday March 04, 2008 @08:47AM (#22634702) Homepage Journal
    Well, no, if you check Ted's blog [sauria.com], you'll see that he's going to be working on Python-in-general, not just Jython.
  • This must be some new java of which I am unaware.
  • This seems to overlap/compete with Parrot [parrotcode.org]. Of course Sun are expected to promote their own JVM. I don't see Perl going JVM though.

Slashdot Top Deals

C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341]

Close