Python finally succeeds in cross-platform areas where Java has beenfailing...

[Jonathan P.]

....that would be for desktop-based apps, games, 3d graphics,
and multimedia.

....thanks to APIs and bindings like Pygame, PyOpenGL, PyGtk
and PyGtkGLExt.

A summary of a lengthy post on the subject:
http://lists.free.net.ph/pipermail/compsci/2003-October/001510.html

- OpenGL for accelerated graphics.

(that's PyOpenGL)

- SDL for cross-platform sound, device input, etc...

(via Pygame)

- Gtk for excellent themable cross-platform widgets (make your
Gtk apps look just like Win32 apps)

(via PyGtk)

- GtkGLExt for accelerated OpenGL display inside widgets. Yow!

(via PyGtkGLExt)

One caveat is that while with .pyc files, Python has what are
essentially platform independent executables ala Java
class files, because the libraries mentioned are not yet a
part of the standard Python distribution, you have to
install the modules and dlls separately.

But if the Gtk and libSDL dlls were to one day come bundled
with Python (like Tcl/Tk is now), and with Psyco to provide JIT and
Python C extensions (being easier to deal with than JNI especially
with the help of SWIG) in the mix, who needs Java indeed?

 

[Harry George]

But if the Gtk and libSDL dlls were to one day come bundled
with Python (like Tcl/Tk is now), and with Psyco to provide JIT and
Python C extensions (being easier to deal with than JNI especially
with the help of SWIG) in the mix, who needs Java indeed?

In theory I agree. But in practice I (and perhaps others) live in a
Java-dominated world. Corporate direction is very J2EE, with all the
XML complexification IBM nd SUN can throw at Web Services. So I need
Python to play well with Java and vice versa. Jython is not the
answer for us (we need lots of CPython extensions).

JPE is the right idea for us:
http://sourceforge.net/projects/jpe

What's the status? Any chance of a tarball (cvs is not acceptable
here)?

 

[Jerome Alet]

Le Wed, 15 Oct 2003 05:09:25 +0800, Jonathan P. a écrit :

who needs Java indeed?

Sun.

;-)

Jerome

 

[Alex Martelli]

Le Wed, 15 Oct 2003 05:09:25 +0800, Jonathan P. a écrit :


Sun.

But it's not really making any money from it, is it? I saw the issue
hotly debated (more perceptively in the business press than in the
technical one, IMHO) in conjunction with Sun's recent bad results, and
that's the conclusion that seemed most convincing to me -- BEA, Oracle
and IBM seem to be the firms that make big money from Java, not Sun.


Alex

 

[Jarek Zgoda]

In theory I agree. But in practice I (and perhaps others) live in a
Java-dominated world. Corporate direction is very J2EE, with all the
XML complexification IBM nd SUN can throw at Web Services. So I need
Python to play well with Java and vice versa. Jython is not the
answer for us (we need lots of CPython extensions).

I can say the same from my perspective (multinational assurance
company). While our Python adoption in AS/400 area was relatively easy,
the PC area is dominated by Java, mostly due do gazillions of "business
presentations" that we attend each year at Oracle, IBM, BEA and so many
others, that I can not remember their names. They have funds for
marketing that no one can withstand. After a year of heavy using
Python/400 nobody objects that it iss really awesome development
platform, but theres one statement we hear after each such presentation
when we mention Python -- "nobody uses it". Not just really nobody, it
is "reletively nobody". We have some applications in Python in use, but
is pure "partisan work".

Nobody got fired for using Java.

 

[David Rock]

Le Wed, 15 Oct 2003 05:09:25 +0800, Jonathan P. a écrit :




Sun.

;-)

Jerome

Yes, but Java REALLY runs poorly on Sun. Why is that?

 

[Jonathan P.]

I can say the same from my perspective (multinational assurance
company). While our Python adoption in AS/400 area was relatively easy,
the PC area is dominated by Java, mostly due do gazillions of "business
presentations" that we attend each year at Oracle, IBM, BEA and so many
others, that I can not remember their names. They have funds for
marketing that no one can withstand. After a year of heavy using
Python/400 nobody objects that it iss really awesome development
platform, but theres one statement we hear after each such presentation
when we mention Python -- "nobody uses it". Not just really nobody, it
is "reletively nobody". We have some applications in Python in use, but
is pure "partisan work".

Nobody got fired for using Java.

For business/enterprise systems, I would have to agree with
these two gentlemen regarding the status quo.

But for multimedia and games, Java has been straining to
give adequate performance and has yet to succeed, imo. The
libSDL (pygame) and OpenGL (PyOpenGL) bindings give Python
games much higher performance than the J2SE graphics and
sound classes can muster. SDL and OpenGL bindings are
available on Java but, perhaps due to the difficulty of
working with JNI, they seem to be taking forever to mature.

For (non-game/non-multimedia) desktop apps, Swing apps, with
the right Look and Feel, can look gorgeous (see jgoodies.com).
On 1Ghz+ machines they are no longer oppressively slow.
However, memory consumption is still a problem.

Python apps incur an overhead of roughly 4 to 10MB per
app instance (can someone confirm whether this is correct
or whether a chunk of that 4-10MB can be shared across
running instances?)

Java apps consume more than twice that(*) and afaik,
each app runs on its own, unshared instance of a JVM!

(*) ...and far worse in some cases: top reports usage
of 210mb per process(!) *and* /multiple/ processes for a
tiny Swing demo app! While I'm sure memory consumption
is not as bad as top makes it look, it's still a pretty
good bet that it's going to be waaay bigger than with
PyGtk apps (esp. under Linux). The disparity is less
when comparing Swing to PyGtk apps under Windows (~25MB vs.
~10MB minimum per running GUI app).

Deploying desktop Java apps is easier than Python because
the JRE is a one-shot install. Tkinter has not met with
wide acceptance as a GUI for desktop apps, and Pygame,
PyOpenGL, PyGtk and PyGtkGLExt all have to be separately
installed for now. So, in this aspect, Java might have a
leg up.

Now, I'm not sure we would want the equivalent of a JRE for
Python, as freezing Python apps and deploying them as
fully contained installer packages (like other Windows
apps) seems to work fairly well.

But there is something to be said about how neat the JRE
approach is. You can package up your whole non-trivial
java app into a _single_ jar file and all the end-user has
to do is do a 'java -jar xxx.jar'. Python has yet to
standardize on such a delivery method as distutils is
nowhere near as straightforward a system.

Ironically, instead of touting the ease with which jar
packaged Java apps can be run, Sun is overdoing things
by coming up with the obnoxious Web Start and JNLP which
are virtually guaranteed to make a mess of your Java setup.
Many software authors and vendors have even resorted to
deploying purely using Web Start/JNLP and do not provide
jars - ugh!

 

[Cameron Laird]

.
.
.

But it's not really making any money from it, is it? I saw the issue
hotly debated (more perceptively in the business press than in the
technical one, IMHO) in conjunction with Sun's recent bad results, and
that's the conclusion that seemed most convincing to me -- BEA, Oracle
and IBM seem to be the firms that make big money from Java, not Sun.

.
.
.
It buys buzz. Particularly before 2000, Sun's investment was
alleged to pay off just in the way it helped with recruiting.
The company's tried hard, but I don't think it has any more
viable way than that to profit from Java.

 

[Roy Smith]

How much of Python's cross-platform advantage over Java is due to the
single source of the Python interpreter and how much is due to the
language itself?

There's certainly nothing (that I'm aware of, other than time, money,
and skill) to stop me from writing my own Python interpreter, making
some subtle changes in behavior (either intentionally or by accident)
and promoting it in the field. If I could convince enough people to
install it, we'd suddenly have a cross-platform crisis in the Python
world.

This is really all that's happened in the Java world. The above
scenario describes what Microsoft did to Java. The only difference
between me doing my own Python and Microsoft doing their own Java is
that Microsoft has the resources and desire to pull it off.

What would happen if Microsoft saw Python as a threat and decided to
kill it by shipping their own incompatable Python interpreter with
Windows? Would we have any defense?

 

[Harry George]

How much of Python's cross-platform advantage over Java is due to the
single source of the Python interpreter and how much is due to the
language itself?

There's certainly nothing (that I'm aware of, other than time, money,
and skill) to stop me from writing my own Python interpreter, making
some subtle changes in behavior (either intentionally or by accident)
and promoting it in the field. If I could convince enough people to
install it, we'd suddenly have a cross-platform crisis in the Python
world.

This is really all that's happened in the Java world. The above
scenario describes what Microsoft did to Java. The only difference
between me doing my own Python and Microsoft doing their own Java is
that Microsoft has the resources and desire to pull it off.

What would happen if Microsoft saw Python as a threat and decided to
kill it by shipping their own incompatable Python interpreter with
Windows? Would we have any defense?

Sure, the std open source software (OSS) defenses:

1. If the alternative is open source itself, then std OSS rules of
engagement apply. Thus, if the alternative has a few good ideas,
they will be absorbed by the main line. If the whole alternative
is better, the community may shift over en masse (a la gcc a few
years ago). If not, everyone will know it and will avoid the
alternative. Legal use of the Python name is (I think) up to PSF.

2. If the alternative implementation (including all libraries and all
extensions) was completely green-room, then it could perhaps be
kept closed source. In that case it might take a while to realize
it was incompatible. For a bad enough mismatch, the name "Python"
might be withheld, just as SUN fought MS's use of "Java" for
J++. When word got out, very likely there would be a backlash, and
people would avoid it if they could.

3. "avoid it if they could" is the crux of the issue. If MS
orchestrates DRM, Palladium, etc. so that only MS-owned languages
can play on a MS Win** box, then MS might offer something like
python functionality (e.g., that is the sales pitch for C#). Under
these circumstances, it is up to the buyer to beware of lockins.
So long as PSF doesn't authorize MS use of "Python" for that
purpose, there will still not be a split.