current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 25 down vote favorite
4

In Java, there are multiple languages that compile to Java bytecode and can run on the JVM -- Clojure, Groovy, and Scala being the main ones I can remember off the top of my head.

However, Python also turns into bytecode (.pyc files) before being run by the Python interpreter. I might just be ignorant, but why aren't there any other programming languages that compile to python bytecode?

Is it just because nobody bothered to, or is there some kind of inherent restriction or barrier in place that makes doing so difficult?

share|improve this question
17  
...because they don't want to deal with the GIL? ;) –  Mason Wheeler May 17 '12 at 0:04
3  
Instincts would tell me that it has a lot to do with just how mature the JVM is, well specified, and the JVM is on virtually all platforms or stupid easy to acquire. –  Rig May 17 '12 at 0:26
3  
I suspect also that most JVMs are much faster than python's interpreters. –  Peter Smith May 17 '12 at 3:32
10  
By targeting Java bytecode, you get all the features of a JVM (security, performance, portability, scalability, and so on). Targeting Python bytecode doesn't get you very much. –  David Schwartz May 17 '12 at 4:00
1  
Python bytecode is not recognised by later versions of the Python interpreter. How can anyone implement a programming language that compiles to Python bytecode? –  Gus Jul 21 '12 at 14:47

4 Answers 4

up vote 44 down vote accepted

Simple - last time I checked, Python had no formal specification, including its bytecode. CPython is the spec, and bytecode portability is IIRC not required. Thus, it's a moving, undocumented target designed for a specific language.

share|improve this answer
12  
In fact, the details of the bytecode format often change between minor versions, and even the 99% compatible PyPy doesn't even try (in fact, they add their own bytecode instructions). –  delnan May 17 '12 at 9:22
up vote 30 down vote

There are multiple JVM languages because there were talented people who wanted to write code that would work with existing Java code, but they didn't want to write Java.

Apparently there are no programmers who want to work with existing Python code, but hate Python enough to port another language to the Python bytecode interpreter.

You can look at this in two ways: there are alternative languages for the JVM because Java is so widespread, or there are no alternative languages for the Python bytecode interpreter because Python doesn't suck.

share|improve this answer
3  
+1 for python having a low coefficient of suck. –  Warren P Jun 14 '12 at 3:37
6  
I hope you are not implying that Java sucks or Java sucks more than Python :-) –  Giorgio Jul 21 '12 at 14:36
3  
@Giorgio: I'm implying that the creators of Groovy, Scala, Clojure, etc. thought there was considerable room for improvement. Are you implying that Python sucks? –  kevin cline Jul 22 '12 at 20:36
5  
After working with python I would say "low suck factor" would be inaccurate. It bucks too much commonly accepted stuff and that whole 'self' thing is extremely counterproductive. In fact dumb. How doesn't a class method know where it belongs? –  Rig Jul 23 '12 at 4:02
2  
Which is not elegant in the least. –  Rig Jul 25 '12 at 11:08
up vote 12 down vote

There are technical deficiencies such as the GIL in CPython, but few perceived language deficiencies, so the runtime isn't the selling point of the Python community. Exactly the opposite, there are more backend runtime options because of the dissatisfaction with the GIL/CPython implementation.

The Java Language is much more maligned than the JVM ( even in the Java community ).

The JVM is pretty well regarded in most circles; thus the desire for different/better language front ends with the benefits of the highly optimized back end JVM.

share|improve this answer
up vote 9 down vote

I say that Mason Wheeler is right. It's mostly an issue with the Global Interpreter Lock which makes concurrency a very thorny issue. Since there are other VMs that do concurrency really really well comparatively it makes sense to develop languages for those. Also Python has had a major language shift recently and many of the libraries have not caught up making compatibility a mild nightmare at times. For instance because I use PIL for vision work, I have to code in Python 2.7 or lower. This is not the case with the JVM or CLI setups which particularly in the latter's case were designed with language interop in mind.

Did some more research and apparently there are actually two GILs not just the one. The other controls Imports.

share|improve this answer
1  
"GIL free" is one of the technical reasons mentioned on "Reasons that CPython programmers might be interested in IronPython" in the Python wiki. –  Yannis Rizos♦ May 17 '12 at 1:26
    
@YannisRizos: Surely access to the .NET framework is not entirely inconsequential. Of course, it's possible that CPython users might be completely uninterested in that. –  Robert Harvey May 17 '12 at 5:27
    
@RobertHarvey Ninja edited that. Although I don't think of "access to fancy new toys" as a technical reason (not that the toys aren't great), the wiki also mentions that IronPython is easier to extend. –  Yannis Rizos♦ May 17 '12 at 5:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.