Slashdot Mirror

Python compiles to bytecode, much like Java does. In fact, Python was doing it several years before Java was ever introduced.

Yes, one can argue that JVM bytecode then sometimes gets JIT-compiled to machine code, but by that point, the Java programming language is gone. What actually gets JIT-compiled is JVM bytecode, and this could have been compiled from any language. Like, say, Python.

Jython is up to 2.7 http://www.jython.org/

Java is moving into archaic irrelevance faster than ever. That is, the language itself.

The JVM, however, is now more useful and relevant than it ever was. It used to be naught but an implementation detail. Now, rather, it's central to an entire ecosystem of languages that will inevitably send Java the way of C: used only when the greatest speed is necessary.

Scala is basically a next-generation Java. Java with functional programming, or really, vice versa. JRuby make Ruby actually scalable, given the presence of native threads and interoperability with existing enterprise libraries that commonly only ship in the form of Java or C# libraries. Clojure enables LISPers of yore and Schemers of new import explore functional programming as it used to be, without having to drop the wealth of Java libraries available. Ceylon, Groovy, Jython, and dozen of others are paving a way to give the JVM much more to do after Java becomes obsolete.

Java will never die - it'll just become like COBOL, Fortran, and C before it: used in enterprise software, operating systems, and outdated educational assessments.

So exactly what do you get with Groovy that you don't get with Jython (Python on the Java VM)? Apart from different syntax of course ...

One of the great things about Python is it runs just about anywhere. There are even embedded versions.

The only real problem with Jython is it doesn't implement Python 3 yet.

Sigh. I am a ten year python guy, and... it really does pain me to admit the truth of your statement.

To be clear -- there /are/ ways a competent architect can work around the GIL. Many of them even catching on in typical design. But the lack of true multi threading is still a real and legitimate concern/problem/flaw.

Given that I have not been able to recommend Java while feeling like a honest professional since the moment Oracle bought Sun... what I'm saying should be taken with...a palmful of salt.

http://www.jython.org/jythonbook/en/1.0/Concurrency.html#no-global-interpreter-lock

Running Python with Java is a way to get the best of both worlds. And it does work just fine as long as you have a developer that is competent to handle the juxtaposition.

But sadly, I can of course not recommend Java to any professional these days without advising a lot of 'due diligence'

I do want to pitch a few things your way though WRT high performance apps.

1) Much like Java, python bytecode is smaller.

For a well structured application, in which you can fit your VM, or a stripped down VM entirely in memory or better yet l3 cache....

The effective 'smaller' JIT can have cache localization benefits that will blow your typical C/C++ performance away (and most Java guys are such fools with memory management I have only once seen an application written in a manner that comparison was fair).

Yeah, we won't be beating Fortran any time soon though.

2) If you're threading your high performance applicaiton, I hope it really is an application that needs threading, and not /just/
  - running on windows
  - need 'lighter' or 'faster to create' processes
- GUI updating
- Some sort of glorified network FIFO

I know there's real reasons to use threads. But in truth, (working in Python or not) -- every single time I've worked with someone who suggested them, they did so for the wrong reason. The only 'right' part of it was that they knew the API pretty well.

3) Most engineers and scientists I have had the intense displeasure of working with are better working in Python than Fortran, Java, whatever. But really, that's the language design -- and I wouldn't advocate COBOL just because it's more readable or writeable. I will advocate a tool for making jobs accessible though.

They are unfortunately utterly incompetent as software engineers and debuggers in either language, but usually they can manipulate a custom API in a subset of python if you give them a template to work from.

But if they get it running well in Python, it's usually pretty portable to a faster language.

Unless they're a genuine stack-overflow-copy-pasta-idiot.

Those... really can't be helped.

I do, however, disagree with Guido's statement that "Python is fast enough". Whether it is or not depends entirely on what you're doing. For my purposes I don't think a 12-core computer optimally programmed in assembler would be "fast enough".

It's faster to write code in Python than in C or C++ or Pascal or Java. But Python isn't "fast enough" unless your program is I/O bound. And it's inability to handle multiple processing uints gracefully is a real problem. (Not that anyone has a decent answer to that except the dataflow people and the pure functional language people.) Multiple core machines are now the rule rather than the exception, so the GIL is no longer acceptable. Even Ruby attempts to address that, though they didn't really follow through after considering their library situation.

You're absolutely correct that whether a language implementation is "fast enough" depends totally on the problem being solved. If the program is I/O bound, as most are, Python and many other languages are fast enough. Even if part of the problem is CPU bound, there is usually a lot of code that is not, which is why hybrid C/Python solutions are so common. For example, NumPy can take advantage of multiple CPUs when doing matrix calculations, allowing one do heavy, fast number crunching without writing a line of C.

If you need to do CPU-bound processing in Python code, threads won't help if you're using CPython, but they might if you're using Jython which is JVM implementation that has no GIL. Alternatively, you can use the multiprocessing module which avoids the GIL and a lot of other potential problems with threads at the cost of having to explicitly communicate between processes rather than share data structures directly.

Google is breaking the Java "contract" with developers: portability.

I'd be much more (read: nonzero) sympathetic to that position if Google didn't explicitly state that their binaries run on Dalvik, and not the JVM:

Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language.

Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool.

The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.

But seeing as how cross-platform compatibility isn't a stated goal or feature of Java The Language on Android, that's all totally irrelevant to the situation at hand. Suppose someone implemented Python on a non-CPython VM. Your logic would imply that the Python Software Foundation should be able to sue them for breaking cross-platform .pyc compatibility. That's ludicrous.

Python, the new Java

That's Jython, not PyPy.

why don't they use jruby
http://www.jruby.org/
or jython ?
http://www.jython.org/
inventing yet another languge when there so many to choose from doesn't seems to be too smart
i can give only one failure go language that is now falling from top 10 if you watch tiobe
http://www.tiobe.com/content/paperinfo/tpci/index.html
also another failure is Groovy used with grails:
"Other interesting moves in the TIOBE index this month can be found outside the top 20. This is due to the fact that the index uses 7 different search engines as of this month. Some promising languages lost many positions. Most striking examples of this are NXT-G (down from 19 to 54) and Groovy (from 25 to 65)."

Python is slower because it's a highly dynamic, interpreted language, and it's interpreter has also gotten a lot less attention than Java's compiler. Java is a compiled, much less dynamic language.

If by "compiled language," you mean that the first step in running a program is transforming source code into some other form, then both Python and Java are compiled languages (as are the vast majority of commonly-used language implementations). Both Java and Python implementations use compilers that transform source code into intermediate forms (byte code). In both cases, very little run-time optimization can be done at that level AFAIK.

The use of compilation is not truly a property of a language, but of an implementation of a language. For example, in addition to the official implementations, there are implementations of both Java and Python that transform source code into native machine code ahead of time, bypassing any byte code.

When talking about compilers, you also have to be careful about which compilers you're talking about. Most implementations of Java use a JIT compiler which transforms Java byte code into native machine language at run time. The official implementation of Python (CPython) does not have a JIT compiler, but there are several projects which add a JIT to CPython, including Unladen Swallow and Psyco.

I want to be extremely clear that I was not comparing the maximum execution speed of equivalent Python and Java programs, since Python will probably never rival Java in that way. I was talking about the suitability of the JVM for executing programs written in languages that are very different from Java, such as Python. Jython is an implementation of Python that does just that, but has only recently caught up to regular CPython's performance, even though it benefits from the JVM's JIT compiler.

As much work is being put into increasing performance of CPython, I think PyPy is much more interesting. Though PyPy is written in Python and a subset of Python called RPython, it can execute Python around three times faster than regular CPython or Jython.

You're right, a regular JVM might not do such a hot job of working through all the code generated by something like Python, but it could be used effectively with a language that is less annoying than Java while still being fairly static.

I doubt Ceylon is going to be a language I'd be much interested in. Python + Cython + C is a pretty potent combination for pretty much everything. It might be good for some things though.

I haven't tried Cython yet, but it sounds very interesting and I'll definitely try it when it seems appropriate. However, if just increasing performance is a goal, simply using PyPy might be just as good as Cython if examples like this are to be believed.

I think a lot of the JRuby effort will be moving to Rubinius (which I think uses LLVM instead of JVM). Jython appears to be abandoned. NetRexx hasn't seen any development activity in several years, but is being transitioned from IBM to a foundation (RexxLA) in the hope of jump-starting it.

I don't think Jython has been abandoned. It has a low volume but still pretty active mailing list and the latest RC was released in October. Jython has traditionally had a slow development/release process as far back as I can remember.

Slow but steady development != abandoned.

Other than that, you're spot on. :)

For a Python/Ruby style scripting language there's Groovy.

You can use Python or Ruby themselves with Jython or JRuby, respectively.

And Java is the only language you can use on the JVM. There are no python, ruby, implementations available for that platform

....except for Jython.
 

So I'm going to trot out a different perspective; enough others will thrash through the personalities under discussion here. In my view, Mono is essentially irrelevant. Some folks will use it to bridge apps around platforms, instead of Qt or a handful of other approaches. Yawn. Internally, Microsoft has done some pretty neat things with their various implementations of the CLR (the VM underlying C#). This is unsurprising, as they're well capable of hiring some pretty bright folks. But I doubt that any of that will ever really inform the broader computing community.

In contrast, the JVM seems to be undergoing a renaissance. There's tons of programming language work on the JVM these days: Scala, JRuby, Clojure, Jython, etc. Each of these are bringing their own communities and problem domains to the JVM, and have already broken new ground in language implementation and design. As for new frameworks, there's scalable computing work going on under the Hadoop project (Google filesystem, Bigtable, and map-reduce for-the-rest-of-us) and the really interesting related framework Cascading. With the JVM as an interoperability platform, these languages and various new frameworks all get to be combined together in fascinating new ways.

Who mentioned programming Java? Only your fouled-mouthed troll.

Cyberax was talking about running languages such as Python, Ruby or Lisp on the Java Virtual Machine. In turns out that many of the runtime techniques within HotSpot to speed Java can also be used to optimise the performance of others. Where not the case, special mechanisms are being added to bytecode to create a truly language independant VM.

Thanks to Red Hat, there's also an LLVM based backend for HotSpot in development, Shark.

The JVM seems to have advanced to the point where other languages besides Java are targeting it as well. Two of the more popular seem to be Clojure and Jython. I suspect more will start appearing if JRE 7 adds better built-in support for compiling dynamic languages, as has been long discussed.

I know you're trying to be funny but... If you're talking plain Java vs Python, Java looks to be quite a bit faster. You don't have to look hard to find benchmarks that show java is faster.

Jython seems to be about 2-3 times faster than CPython according to those test.

This could give CPython the performance edge over Jython, but it still has a way to go to catch up to Java.

Perl, Python, Ruby? Sure, all will work, but have fun rewriting the interpreters themselves in Java!

This has been done for Python and Ruby. I believe there was an abortive attempt to do the same for Perl a few years back.

Guess you haven't heard of Jython?

Jython: "A compiler to compile Python source code down to Java bytecode which can run directly on a JVM".

When you have a language like Python, which is defined by a single (very slow) implementation

Which of C Python, PyPy, Jython, or IronPython is the only implementation?

Well, you could always use a Java applet.

Or implement another language - say, Python - in a Java applet.

But few seem to have had a burning desire to do so. Javascript, bless it's heart, actually works pretty well now.

If the python version wraps C code, you would probably have to use the Java version from Jython, which apparently isn't a big deal:

http://www.jython.org/docs/usejava.html

Once you've gotten past the whitespace thing in Python you'll slap your forehead and say why didn't I use this language before? I do my development in Django and I am far more productive in it than in other web development applications. If you need to work in Java there's Jython. If you need to work in .NET there's IronPython.

There are a lot of other cool Python web technologies out there as well:TurboGears, WSGI, Plone, Zope, Twisted.

What major company hired Guido van Rossum, BDFL? What major company rolled out GoogleAppEngine (based on Django)? Ruby's pretty hot right now but so is Python.

Though Java-centric in nature, the JVM provides a secure sandboxed environment to host numerous languages including Ruby, Python, Lisp and even JavaScript. Throw in Groovy and Scala for home-grown alternatives.

Thanks to the efforts of IcedTea (principally funded by RedHat) and others, Java 6 will be fully GPL by the end of the year.

The question was which programming language programmers should learn, and Python is one of the few reasonable answers I've seen in the comments.

If you program in Ruby, learn Python because it has been there before you, and you can often translate Python solutions into Ruby ones. Yes, I have personally translated Python code into Ruby back when Python 1.52 was the state of the art. Then Python improved so greatly that I dropped Ruby and canme back, mainly because of the wide variety of modules available for Python. After 7 years with Python, http://del.icio.us/tag/python continues to throw up surprisingly useful stuff.

If you program in Java, learn Python because you can begin to use it today http://www.jython.org/Project/index.html to reduce the number of lines of code that you have to write. The Jython code can access all of your Java classes so there is no need to learn a new set of libraries. And Jython has solid support behind it from SUN.

If you program in C# or VB, learn Python because you can get that same advantage, leveraging all your existing libraries and classes while reducing the lines of code that you have to write. And IronPython http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython has solid support behind it from Microsoft.

If you need to write code for yourself, from simple scripts up to cross-platform applications, then learn Python and use one of the distros of the standard CPython such as ActiveState or Enthought. Or roll your own by downloading from http://www.python.org/ and adding the libraries that you need. Want to build wxWindows apps crossplatform? wxPython does it. Want GTK apps cross-platform? The pyGTK is the library for you. Need to distribute Windows binaries? Use Py2exe. Or for OS/X use Py2app and on UNIX use freeze.

Python has 10 years of widespread use behind it with people building everything from multi-thousand lines-of-code apps to system admin scripts. If you want to learn how to write threaded apps, Python lets you focus on the essentials. Or if you want to avoid threading and build asynchronous servers or true parallel apps, Python has modules for that as well.

If you are already a master of three or more current programming languages (not COBOL) then maybe you won't gain anything by learning Python, but every other programmer really should make it part of their toolbox. If nothing else, use it to build quick prototypes, then when it's write, redo it in C++ or Java for the final delivery. The boss will not complain if it reduces the turnaround time for your projects.

Wouldn't it be possible, at the corporate level, to do quite a bit of customization, more than possible for mere humans on MS Office.

I'm not all corporations, but I've been around a few decades. Here's my 2 cents worth.

All of the OOo code is licensed under the LGPL, and can be freely downloaded, built and customized. So yes, it's possible. The sky's the limit; it's just software. :-) Several factors make it less likely that a corporation would take this approach, however.

One is that such a customization would very likely be deemed a "derivative work" by Legal, in which case if it were distributed (e.g., to suppliers for a given project, or even arguably to contractors working for the corporation), then the source must be made available as well. Non-software corporations tend to be allergic to releasing their source code, in my experience, because their lawyers tend to be very conservative. Some manager somewhere will likely have to bet his career by accepting legal liability for the corporation. Will the risk to his career if Something Bad Happens justify the benefit he perceives?

The issue of support will also likely be raised. What if the customized version breaks - who will "support" it? Yes, yes, we all know the internal team of developers will - assuming they weren't laid off in the last "shareholder value" improvement exercise (a constant risk in corporate America). But IT directors tend to go the other direction, from what I've seen - they want to outsource support (and legal indemnification) for open source software, so it can be treated as if it were proprietary. Proprietary means comfort; a target at which the finger can point if Something Bad Happens. This tendency is likely the foundation of IBM's business case for Symphony, by the way.

Finally, if a support team were to be established in a corporation to produce a custom version of OOo, they would need to have some type of development environment. As much fun as bashing Microsoft may be, Visual Studio and .NET are not technically inferior products. So a corporation is unlikely to consider that an inferior option to, say, Eclipse technology. Sure, it costs a lot more - but it's a small number of licenses. They probably wouldn't hesitate.

But in the end, I suspect a lot of corporations just want to write scripts and such without mucking around in the source code proper. The issues most likely to resonate are: (1) How do you efficiently distribute the customizations? (2) How hard are they to develop and maintain? and (3) Can we use them on all of our platforms as is, or do we have to port or (ack!) redevelop for each platform? The third is where Microsoft's "Windows Everywhere" bias may hurt them with this decision to abandon VBA. (Gee, now I'm sure glad we chose to use Python as the scripting language in our internal applications! :-)

Why choose, you can have both! :)

Sun has new language for client-side scripts.. Just-so-coincidentally, Sun has had a variation of this new "language" available in your browser for a decade! It's called applets and the JRE.

Python, Ruby, JavaScript, Groovy. Whatever. Sun has a Java runtime in the browser, a sandboxed one that can only access the DOM and browser. But you still get all the Java benefits, like multithreading and bytecode compilation. And all the Java benefits, like it's implemented for IE AND Firefox on Mac, Windows, Linux and Solaris. Further, it is available under the GPL, so you can port it to any other platform.

See this web page for details of Sun's leaner faster in-browser JVM.

It can host a variety of scripting languages such as Python, Ruby and, surprise, even JavaScript, as well as a couple home-grown languages such as Groovy and the purpose built JavaFX Script

Now before you shriek in horror at the thought of a JVM running in a web browser, Sun have made a renewed commitment to the browser via the soon to be released Consumer JRE, which aims to relieve some of the bloat and provide an improved experience.

Still no official 64 bit browser plugin but the IcedTea folks are working on a substitute.

When I think about it, I don't even know one scripting language which has proper kernel threads support.

JRuby is one of many languages that can be run on the JVM. It has been around since 2001 (IronRuby was announced in 2007). Jython, a Python implementation on Java, was started even earlier, in 1997. There is also Groovy and JACL and many others.

Last i heard, it would only create some sort of bastardized python code that was no longer cross platform.

That's not correct; IronPython runs on Mono or .NET, so it will run on any Mono supported OS as well as Windows.

You may mean that IronPython scripts are not 100% compatible with a CPython implementation. Well, duh! Even different versions of CPython aren't 100% compatible! Jython isn't 100% compatible with CPython. IronPython is fairly compatible with CPython 2.4.4; the list of differences is available here, so you can avoid them if you ever want to run your code on different Python systems.

The big advantage IronPython has is the integration with .NET. It's trivial to access .NET libraries from IronPython, while CPython doesn't make it easy. I'd expect migration mostly from cPython to IronPython (the biggest issue I had was regex related). If you don't want .NET integration, stay with cPython.

Bummer. At least it looked nice on paper... not that i'd like to have anything to do with .NET :) Or Java, for that matter.

And how do you propose to run them and their JIT compiler without another VM?

Modern interpreters compile the language and then run the bytecode. Early interpreters work the way you describe because memory was at a premium.

See Parrot, the VM for Perl

Tamarin, Mozilla's JavaScript VM.

Oh yeah, almost forgot!
The Jython Project

I don't think you can aquire an open source project. Your comment is a bit misleading. Rather what happened was that the sole developer Jim Hugunin wanted to join Microsoft after meeting with the .NET CLR (Common Language Runtime) team while discussing with them the technical issues he encountered. Jim joined up, and with a team at MS, brought IronPython to it's 1.0 release in September 2006.

There's some history on Jim Hugunin's blog here http://blogs.msdn.com/hugunin/archive/2006/09/05/7 41605.aspx

There's other Python projects for you purists to get your teeth stuck into, but this one isn't one of them, as it is with a lot of .NET stuff. Here, try Jim Hugunin's JVM based Python called Jython http://www.jython.org/

You mean, things like Ruby, Python or PHP running on an open-source JVM ?

So exactly what other languages other than Java can I write in and have it compile into Java byte code? Last I checked it was just one.

How about Jython or JRuby

oops, got the jython link wrong. also, if you're into (CPU) performance, it might be useful to take a quick look at a relevant benchmark over at the great language shootout.

Having a scripting language (like PHP) that people can run on the same VM as Java would be a great boon to both people who use the scripting language as well as to Java's popularity in general.

As the two ACs who have been modded out of view said, that particular drug already exists - Jython - and is already supported in Java IDEs like NetBeans (via Coyote) and Eclipse. It's been interesting to see all the old urban myths about the Java platform being slow, bloated, single language and so on doing the rounds again though, I'd almost forgotten about them...

http://www.jython.org/
http://en.wikipedia.org/wiki/Jython

As for why you'd want to mix Python and Java... I'm really not sure. Perhaps someone else can describe a situation where it would be warranted.

Groovy does offer things they don't, primarily the ability to compile to class files so that Groovy classes can be used from Java classes and vice versa.

Jython has this feature.

Below are two bullet points from the linked page:

• Dynamic compilation to Java bytecodes - leads to highest possible performance without sacrificing interactivity.
• Optional static compilation - allows creation of applets, servlets, beans, ...

Especially when you have languages like Jython available, standardizing on Java and Python makes sense.

Indeed, python has a lot of nice features. I actually use Jython a lot for DB scripting because it gives me the flexibility of Python with JDBC (among other Java libs).

Derek

If you want to learn what "serious developers" think of Python just read articles at Python Success Stories.

While you are at it see Jython for Python interpreter for JVM. It has a very long track record already today.
Or take a look at IronPython from Microsoft: implementation of Python on .NET.

Actually Jython runs very nicely on JVM. I know there is JRuby in the works, plus several others.

On the other hand, Java runs on Unix and Windows. Is there a working version of .NET for Solaris?

Java also supports Ruby and Python and Tcl and Eiffel and...

Is that all you're waiting for? We've had that for years.