Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Sun Hires Two Key Python Developers

Posted by kdawson on Tue Mar 04, 2008 08:02 AM
from the money-where-their-mouth-is dept.
Sun Microsystems Programming IT Technology
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."
+ -
story

Related Stories

Submission: Sun hires two key Python developers by Anonymous Coward
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Sun Hires Two Key Python Developers 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • 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.

    • 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.
    • 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.
          • 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.
      • 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

    • 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.

    • 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: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.

  • 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) * 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.)

        • 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
          • 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?

    • 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.

  • 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.
  • 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) Homepage 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.
    • 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.

    • Mod parent up (Score:4, Insightful)

      by Viol8 (599362) on Tuesday March 04 2008, @08:32AM (#22634606)
      Indeed. The craze for virtualising runtime code has got way out of hand. Its fine if you want binaries to run unmodified cross platform , but it makes no sense whatsoever for anything else. These days people use Java because of the language and the libraries itself, not the JVM. In fact most java developers I know would be quite happy never to see the JVM again and just use a standard compiler , never mind JIT. I certainly don't understand the reason for using a runtime VM to run executables when a standard binary would suffice , which means I simply don't see the point of .NET either.
      • Running under a VM is really nice for debugging purposes. Changing the code in mid-run, and continuing on executing the code saves a lot of time. Also, you can actually rewind from an exception in .Net, fix the problem, and continue on debugging. Running thing's in .Net lets you get a whole lot more information about where your memory is being used, or where the performance bottlenecks are. Some of this stuff is probably possible without a VM, but having a VM adds a lot of features that you simply can p

      • Re:Mod parent up (Score:5, Insightful)

        by A beautiful mind (821714) on Tuesday March 04 2008, @09:44AM (#22635306)
        Your post is missing the point.

        What you refer to as standard binary is just code that can be made to run on the computer directly, because the CPU understands the commands, etc. A VM is the next evolutionary step in the process, because you determine what's the best assembly/native code on runtime, on the fly, instead of static source code inspection.

        This means not only more portable code, but overall faster than compiled execution speeds for programs. So far the VMs have been under performing, but they are improving and at a faster rate than gcc and friends.

        So yeah, there is more to it than just platform independence.
        • This means not only more portable code, but overall faster than compiled execution speeds for programs. So far the VMs have been under performing, but they are improving and at a faster rate than gcc and friends.

          I think the VMs are improving towards the speed of static compliation. Sure there are benefits such that we could potentially see faster VM code - but there's also layers and layers of cruft that comes about because of VM abstractions. I think projects like LLVM will eventually produce code faste

          • Re:Mod parent up (Score:5, Insightful)

            by AKAImBatman (238306) <akaimbatman.gmail@com> on Tuesday March 04 2008, @11:38AM (#22636856) Homepage Journal

            But if its on a static machine architecture why bother?
            Because there's no such thing? The performance paths of a PIV, Core Duo, Xeon, and AMD64 are all different. Should we continue compiling code for the lowest common denominator and just accept that our code isn't performing as well as it could?

            And what of runtime optimizations? If the VM detects that this collection only contains objects of type X, it can do away with the casting checks on that collection. Yet if it detects an object of type Y added to the collection, it can undo the optimization on the fly. Statically compiled code can't do that. At best it can provide alternate code paths under certain conditions. Of course, additional code paths massively bloat the executables.

            The JVM does these sorts of optimizations today, and thus has unparalleled performance when working with OOP code. That's why all these benchmarks show the JVM kicking ass and taking names later:

            http://www.kano.net/javabench/ [kano.net]

            A C compiler can still outperform a JVM under ideal conditions, but ideal conditions are becoming more scarce for C compilers. In real-world terms, the JVM is going to be able to run your average Java code far faster than your average C/C++ code.

            This idea that native code is always faster than virtualized code is a myth, and an old one at that. You need to get with the times or you'll find yourself a dinosaur. (And you don't really want to be brushing up on your "Get off my lawn!" speech yet, do you? ;-))

        • The only way to compile such code statically would be to link against a Python compiler that can create the new opcodes from newly-generated source on the fly.

          And that's what lisp was doing about 25 years ago.

          • Re: (Score:3, Insightful)

            by Just Some Guy (3352)

            And that's what lisp was doing about 25 years ago.

            Yep. But are there arguments for or against other than "Lisp did it"?

      • Re: (Score:3, Informative)

        by Viol8 (599362)
        Eh? What OS you using , DOS 3.2? Thats easily implemented using file permissions and access control. Well , on unix anyway, can't vouch for Windows. If you don't believe me try and strace a running process you don't have permissions for.

        • Re: (Score:3, Informative)

          by CastrTroy (595695)
          It allows you to specify per-application permissions, without creating a new user for each application. So you can run something as yourself, from your browser, but give it no access to the file system. You could give an application access to the file system, but no access to the network. Running under a VM lets you have a lot more fine-tuned control over what the application can and can't do. It also does it in a way that's completely platform independant. So even if you are using DOS 3.2 (assuming th

    • Re:too little too late (Score:5, Informative)

      by Headius (5562) on Tuesday March 04 2008, @09:16AM (#22635008) Homepage Journal
      You're probably half right. I think it stems from a realization that Java doesn't have to be the only tool on the JVM. And to that end, we're working hard to improve the ecosystem for language development in a number of ways. Heck, some of the most interesting parts of JRuby aren't even written in Java anymore...they're generated programmatically. Java is just one way to create JVM bytecode. We need both better tools for creating bytecode for many languages, and a better way to make the JVM's dynamic underpinnings serve many languages. We're working on both.

        • Re: (Score:3, Insightful)

          by Headius (5562)
          With two devs, perhaps not. But there's far more than two devs working on Jython, and they've made great progress this past year. Plus I'm going to do what I can to help them reuse work we've done on JRuby, so they can focus more on compatibility and Python features they're missing.

          The reason Sun hiring Frank is important is because it provides a full-time developer to help anchor the OSS work that's already happening on Jython. And that's the right way to do things, since it's the community members that ma

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.