Why isn't Python king of the hill?
Mark H
out of Java's sails? Now, don't get me wrong, I love Java, but I have
found I am at least twice as productive in Python than Java, and there
seems to be very little if anything that you cannot do in Python or a
Python extension. Is it because Java has a few big companies behind
it while Python doesn't?
Just wondering.
Sean 'Shaleh' Perry
That plus schools teach Java. Plus companies push Java. Plus book companies
have tons of Java books.
Python simply has not reached the mind share.
Samuel A. Falvo II
For the most part, yes. Sun can afford to pay people to write books on
Java. And the more books on it, the more visibility there is in the minds
of people who peruse the bookshelves in stores. Moreover, I remember Sun
holding all sorts of conferences and symposiums when Java first hit the
streets, illustrating how Java can be used in various markets.
I don't see anything of this sort of organization and magnitude coming from
the Python community today.
Also, consider that Java and Python are designed to serve two different
markets. Python is a host scripting language, while Java is a platform
independent binary representation for software. Therefore, Java hit the
"portable applet" market at the right time with just the right technology to
catch people's fancy. Python didn't address this market, and still doesn't
today (at least, not with the same amount of fervor Java had back then).
--
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA
Bruce Sass
<...>
> Also, consider that Java and Python are designed to serve two different
> markets. Python is a host scripting language, while Java is a platform
> independent binary representation
Like .pyc|o's, ya.
What is a "host scripting language"?
More generally (and directed towards those who would say, "Python is a
scripting language"), why is Python even called a "scripting"
language?
<thinking>
Python is way too verbose to be a scripting language. i.e., Runs
`farther' from the OS than a scripting language should.
Compare:
cat name.pt{1a,2a,3b} > name vs. ???
well, I'd probably do os.system("the-sh-script-line"); and a file with
that, an import, and a #! line in it would be silly, IMO.
</thinking>
- Bruce
Courageous
<begin scathing commentary>
Yes. Sun and IBM have spent millions and millions of dollars _marketing_
Java; furthermore, somewhere, somehow, a huge trove of developers
got it in their head that learning Java would be fun to do and great job
security, convincing themselves with the argument "we're all going this
way, so let's go this way."
The _only_ problem that I ever have with Python is that it is, in some
cases, SLOW. This doesn't matter a great deal of the time, however,
because "slow" merely means slower than the alternative, not actually
perceivably slow or slower than it needs to be. Misfortunately, a little
of the time it is _both_ perceivable slow _and_ slower than it needs to
be, and that's occasionally a problem, particularly if "slower than it
needs to be" means scoring high on some trumped up benchmark
meant to rub your manager's rhubarb exactly the right way.
<end scathing commentary>
C//
Greg Ewing
>
> What is a "host scripting language"?
I think he meant that Python is designed for writing
programs which run directly on the host OS, whereas
most of Java's popularity seems to stem from its
use as a web-server-applet language.
> Compare:
>
> cat name.pt{1a,2a,3b} > name vs. ???
But when the task requires any computation even
slightly less trivial than iterating over a list
of file names, I find it much easier to remember
how to *do* it in Python than to figure out the
necessary sh or csh contortions. So nowadays,
I tend to write any script of more than one
line in Python, even if the Python version is
somewhat longer.
--
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg
Helen Dawson
best of the bunch, and it's a pretty spiffy IDE, but has some serious
debugging weaknesses.
The interactive nature of Python makes a debugger less important,
but a good debugger is still a great thing to have.
The apparent inability to edit variables in PythonWin is my current
gripe, and the odd method of dealing with infinite loops in your
Python scripts is another. Both fixable, but not apparently a priority.
Greg Jorgensen
A lot of companies make money from the Java phenomenon, from book
publishing to bloated frameworks, JVMs to ORBs, training to certification.
On the other hand Python is too open, too easy to learn, too robust and
cross-platform. Where is the profit in it?
--
Greg Jorgensen
PDXperts LLC
Portland, Oregon USA
gr...@pobox.com
Martin von Loewis
> I think debugger weakness is one problem. PythonWin seems to be
> best of the bunch, and it's a pretty spiffy IDE, but has some serious
> debugging weaknesses.
While this is certainly a problem, it cannot explain the attention
that Java gets over Python. When Java was young, debugging support was
terrible also - yet it got attention from companies developing
debuggers.
Regards,
Martin
Pete Shinners
> While this is certainly a problem, it cannot explain the attention
> that Java gets over Python. When Java was young, debugging support was
> terrible also - yet it got attention from companies developing
> debuggers.
i think there was one crucial difference.
a marketing team using sun's deep pockets to get java out there.
Alex
What debugging features is python missing? I use pdb with emacs all the
time, and find it very useful. It seems to have all the features that
gdb has, which is the only other debugger I've used in the past 10
years.
I'm just curious about what I'm missing. :)
Alex.
Darren New
> While this is certainly a problem, it cannot explain the attention
> that Java gets over Python. When Java was young, debugging support was
> terrible also - yet it got attention from companies developing
> debuggers.
But it was available in the usual browsers. It was hyped as a way of
providing a sophisticated UI on every desktop without the need to deploy
any software. It managed that poorly, but better than anything else out
there.
Once that opened the door, that aspect could go by the wayside. If
python wound up being distributed with both IE and Netscape browsers,
you'd have the same effect.
(I'm particularly amused by how Java 1.0 promised that AWT would be safe
to code to and always around, while Java 1.1 deprecates it and Java 1.2
I don't think is even going into new browsers at this point.)
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
This is top-quality raw fish, the Rolls-Rice of Sushi!
Richard P. Muller
In any case, most of the people in this newsgroup (myself very much
included) would agree with you on improved productivity in Python.
That being said, there are some advantages to Java. It's built into
almost every web browser on the net. Hard to overstate the importance of
being everywhere. Jython is getting close to putting Python everywhere
that Java is, but (IMHO) one loses some of the simplicity of Python
along the way. Moreover, Java is strongly typed. Sure, you can staple
strong typing into Python, but having it there all the time occasionally
lets one sleep better. Finally, and probably most importantly, managers
who know nothing about programming have some vague feeling that Java is
a good thing.
Rick
--
Richard P. Muller, Ph.D.
r...@wag.caltech.edu
http://www.wag.caltech.edu/home/rpm
Frank Mitchell
> (I'm particularly amused by how Java 1.0 promised that AWT would be safe
> to code to and always around, while Java 1.1 deprecates it and Java 1.2
> I don't think is even going into new browsers at this point.)
Well, MS is dropping Java entirely, but Netscape 6 uses the Java 2
plugin. Whether anyone will use Netscape 6 is another matter.
Opera also uses the Java 2 Plugin (which is larger than the whole
browser ...)
One of my pet peeves is that Sun lumped a whole bunch of packages into
the "Java standard" before they were field tested. AWT was a mess to
begin with, and now the JDK can't get rid of it. Even Swing depends on
some basic AWT classes. (It's not truly deprecated in any version, but
it's subtly discouraged ...)
Python takes the opposite approach, of bundling libraries enough people
find useful. Good for programmers, but bad for big corporations trying
to impose their product on a reluctant world, I guess.
--
Frank Mitchell (fra...@bayarea.net)
"The trouble with mornings is that they come when you're not awake."
-- from "A Window for Death" by Rex Stout
infobot
> included) would agree with you on improved productivity in Python.
Completely and utterly.
The question facing me at the moment is "how to make a living doing
what I love doing?", which is programming in Python. ie. we know the
many reasons for Java's success, deserved or not. Accept them as water
under the bridge and ask "how now ?"
Almost all serious web/wireless development projects I have the
opportunity of working on are based on one of three alternative
technology platforms :
a) Microsoft tools (.Net in future) running on NT/2000 of course.
b) Java/XML (usually running on Sun boxes, thanks to Sun's attention
to channel sales and partners)
c) Open-source, which 90% of the time means usually PHP/MySQL running
on Linux.
For enterprise projects, which is what most the market comprises of at
the moment where I'm based (HK), I'd say 20% of projects fall into (a)
above (and that's usually due to Microsoft actively pushing it with
key accounts) and the rest is all Java/XML.
Ironically, one of the most prolific exponents of Java is one of
Sun's fiercest competitors in the local market - IBM. Other than the
fact that Java now covers all of their hardware/OS platforms, I'm sure
they prefer Java because it's strongly typed and b/c leads to more
consistent code (less of a "many ways to do one thing" scenario like
Perl and Python); EJB was made for a company like IBM. (Perhaps they
also prefer a less productive language so that their global services
division they can bill more hours too, but that's
another issue completely.)
Meanwhile, I've implemented some projects for clients in Python (and
Zope when it's a web-based project) only to then find the client is
totally reliant on me (something that I don't want any more than the
client does). And if/when I then depart, they usually end up redoing
it all again based on Microsoft tech or Java/XML.
Therefore, I can only imagine myself using Python in the following
circumstances :
1. Where I create a service, software or platform that others
never need to see the internals of, that I manage completely
and distribute APIs to others. eg. an application service
provider model.
Contrast this with a website built on Java/XML or ASP which I
could create and then pass off to a client to manage happily
ever after.
2. Building a product that I can complete by myself. I've tried
hiring and training employees to use Python. They've enjoyed
Python but there just wasn't enough work to keep them employed.
Also, the employees have often feared for their own marketability
in the job market thereafter.
3. Niche R&D type work, where 80% of the work is prototyping.
Unfortunately, I haven't found much of that except when working
on my own startups and ideas.
Despite all this, I manage to get enough Python (and Zope) work to
keep bread on the table (just); but, due to the factors above, it
usually means working alone and doing 3 peoples' work (which,
fortunately, Python allows me to do). It's getting tiring though, and
I find myself now screwing around with EJB (and believe me, this stuff
is nasty compared with Python) for a bit of security.
Anybody else in similar straits ? (Probably people in countries where
there are few Python developers. eg. in China, almost everybody uses
the Microsoft stuff.) Would be interested to hear how it compares in
Korea, Japan and Taiwan too...
Cheers,
chas
ps. I once heard a sysadmin say he'd rather give up his job than work
without his favourite tool (even though it was Perl <g>) ... I
realize now that he wasn't joking.
Mark Brady
it now, python has me!). Just before J2EE was released/hyped around
Dec '99 Java was in big trouble. The hype was beginning to actually
turn against Java when applets couldn't deliver the goods. Servlets
were the turning point and even though alone they couldn't displace MS
ASP they were the only remaining usage of Java that was really
growing. Sun realised where the real market for Java was and developed
J2EE. This was done partly by integration of existing APIs and the
creation of others such as EJB. They moved Java from the browser and
client side to the backend. There is nothing on the server at the
moment to compare to J2EE. It is complete and very scalable.
Sure there is nothing you can't do in Python that you can do in J2EE
but you will end up creating a lot of the functionality that J2EE
developers take for granted yourself. Zope doesn't even compare to a
decent J2EE app server (with JMS, ORB, Servlet/JSP engine, EJB server,
etc.) for this type of stuff. Zope is excellent for what it does but
it can't be all things to all people. A Python J2EE style app server
(*not* content management server) would go a long way to making Python
a viable Java replacement.
Luckily we have Jython and hopefully MS will fix the .NET CLR to
support dynamic scripting languages better so that we can use python
inside both J2EE and .NET.
These views come from my own attempts to introduce Python in the
companies I've worked in and why for them at least, J2EE is king of
the Hill.
Regards,
Mark Brady.
Kemp Randy-W18971
source. Now I have my biases, and we don't live in an ideal world. A case
in point is Perl, which I don't intend to bash, but given choices, I much
rather program in Python over Perl. But Perl was in the right place at the
right time. And I really love EJB, and you don't have to give up open
source to enjoy it. Look at jboss/jetty or jboss/tomcat (www.jboss.org),
and Enhydra enterprise (www.enhydra.org), which are two very strong, open
source, application server projects that use EJB. So for me, if Java is
king, and I love the language, I'm not really suffering. But it would be
nice if more of the world adapted Python.
Sheila King
article <e840346c.01052...@posting.google.com>:
:why for them at least, J2EE is king of
:the Hill.
What is J2EE ?
--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/
D-Man
| On 25 May 2001 05:53:01 -0700, kal...@lycos.com (Mark Brady) wrote in comp.lang.python in
| article <e840346c.01052...@posting.google.com>:
|
| :why for them at least, J2EE is king of
| :the Hill.
|
| What is J2EE ?
Java 2 Enterprise Edition
http://java.sun.com/j2ee/glossary.html#35943
EJB is "Enterprise Java Bean"
http://java.sun.com/j2ee/glossary.html#21914
(Does "Enterprise" actually mean anything besides lots of marketing, and the
ship on Star Trek?)
-D
Kemp Randy-W18971
http://www.jboss.org/business/faq.html
-----Original Message-----
From: D-Man [mailto:dsh...@rit.edu]
Sent: Friday, May 25, 2001 10:02 AM
To: pytho...@python.org
Subject: Re: Why isn't Python king of the hill?
Iman L Crawford
<mailman.990803019...@python.org>:
>the
> ship on Star Trek?)
>
Yes, you can charge exponentially more money for anything with enterprise
in the name. :)
--
Iman
"I was looking handsome,
she was looking like an erotic vulture" The Pixies
Geoffrey Gerrietts
I think that I've seen several places in this thread where kernels of truth
have emerged. Java scales better, Java has better coverage, and Java has
better toolkits for a lot of what's being done. It's not as easy a language
to work in, and not as flexible, but it's faster, and it's more accessible.
At HomeGain, we use Python and Zope. I love developing the Python code, but
its speed has given us a lot of concern. Some of my peers are not so
enraptured with Python, for various and sundry reasons of their own. I don't
think Java would make all of them happier, but it would make some of them
happier.
DTML and Zope are a mixed bag, too. Designers who are used to working in PHP
or ASP find DTML to be a little clunky, and having several designers working
on the same site has exposed a lot of the weaknesses in the
'browser-as-editor' model to us. I should note that we're using an old
version of Zope, but I'm not sure newer versions would solve the biggest
gripes I hear.
We are resolving these problems, and continuing to work in Python and Zope.
I am glad for this, mostly because I like writing Python code. However.
Scaling our python app across fifteen or sixteen boxes has been a challenge.
We have to make a lot of tradeoffs in the way we handle things. We have to
roll our own session management, we have to roll our own
database/persistence toolkit; our RPC mechanisms are add-ons. We have these
things, now, so a revamp in J2EE wouldn't really help us much. A fresh J2EE
developer doesn't really have any questions about this, though -- the J2EE
apps are designed to promote distributed computing, persistence, and lots of
other niftiness straight out of the box. Other technologies (Java Data
Objects, for example) promise to extend this even further. Yeah, it takes
longer to develop your core product in Java, but huge chunks of
infrastructure work are already done for you.
Java's tools have plenty of weaknesses, too. The Java standard library is
so-so, and doesn't even begin to compare with the NeXT libraries. In fact,
Apple's WebObjects has a great set of toolkits, and it's a great app server,
too -- in Objective C or Java. It doesn't scale as well as the J2EE stuff,
though.
I love developing software in Python, because I love the flexibility and
ease of introspection the language offers. It's very easy to do enormously
sophisticated things! On the other hand, if I were starting a fresh web app,
I would hafta recommend a Java solution, with an eye toward J2EE
compatibility. The tools are better suited for long-term growth, the
community is larger, if not as friendly or approachable, and the performance
of the final product is better on a resources-per-transaction basis.
---
Geoff Gerrietts <ge...@homegain.com>
Software Engineer, HomeGain.com
510-655-0800 x4320
> (Does "Enterprise" actually mean anything besides lots of
> marketing, and the
> ship on Star Trek?)
>
> -D
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Martijn Faassen
[snip]
> DTML and Zope are a mixed bag, too. Designers who are used to working in PHP
> or ASP find DTML to be a little clunky, and having several designers working
> on the same site has exposed a lot of the weaknesses in the
> 'browser-as-editor' model to us.
DTML is clunky, and browser-as-editor has problems (but also major
advantages). Better integration with version control systems like CVS
would however be very nice. Note that Digital Creations (including Guido) is
busy developing Zope Page Templates, which should be a lot cleaner than
DTML.
> I should note that we're using an old
> version of Zope, but I'm not sure newer versions would solve the biggest
> gripes I hear.
Newer versions do support through-the-web Python scripts, which makes the
threshold to write a little bit of python glue instead of reams of
dirty DTML a lot lower.
> We are resolving these problems, and continuing to work in Python and Zope.
> I am glad for this, mostly because I like writing Python code. However.
> Scaling our python app across fifteen or sixteen boxes has been a challenge.
> We have to make a lot of tradeoffs in the way we handle things. We have to
> roll our own session management, we have to roll our own
> database/persistence toolkit; our RPC mechanisms are add-ons. We have these
> things, now, so a revamp in J2EE wouldn't really help us much.
How does Zope's ZEO fit in this picture? I would think it'd help scale a Python
app across a lot of boxes, right? Zope of course has a persistence toolkit;
the ZODB. RPC mechanisms exist for Zope as well; for instance XML-RPC.
How were these not satisfactory?
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Martin von Loewis
> Python takes the opposite approach, of bundling libraries enough people
> find useful. Good for programmers, but bad for big corporations trying
> to impose their product on a reluctant world, I guess.
For GUIs, Python's "approach" has changed over time, too. Initially,
Python shipped with stdwin, but that got never any serious attention.
It is actually the openned of the C API that allows you to integrate
different GUIs that defined Python's approach.
Regards,
Martin
Martin von Loewis
> What debugging features is python missing? I use pdb with emacs all the
> time, and find it very useful. It seems to have all the features that
> gdb has, which is the only other debugger I've used in the past 10
> years.
I could never figure out how to use pdb in Emacs. When I invoke M-x
pdb, it asks for the debugger name, suggesting pdb. So I copy pdb.py
to a pdb binary and make it executable. Then, I pass the script name
afterwards, and then the debugger just hangs, without giving me a
prompt.
Regards,
Martin
Bernhard Reiter
Helen Dawson <hel...@accessone.com> writes:
> I think debugger weakness is one problem. PythonWin seems to be
> best of the bunch, and it's a pretty spiffy IDE, but has some serious
> debugging weaknesses.
Have you checked out ddd?
It runs with pdb and should be fairly good.
http://www.gnu.org/software/ddd/
Bernhard
Steven Haryanto
"strong typing" and "weak typing" vs "static typing" and "dynamic
typing"? I've always thought that Python has _strong_ typing,
but it is not static. So it is unlike Perl which has weak and
dynamic typing (although under -w Perl will issue warnings if
you try to mix string and numeric in expressions).
I would say _static_ typing is the one that will make me sleep
better, because once I tell the compiler that my foo variable is
an int, it will stay an int through the course of execution.
Joshua Marshall
> Sorry for bringing back an oldish post, but how does one define
> "strong typing" and "weak typing" vs "static typing" and "dynamic
> typing"? I've always thought that Python has _strong_ typing,
> but it is not static.
Right.
> So it is unlike Perl which has weak and dynamic typing (although
> under -w Perl will issue warnings if you try to mix string and
> numeric in expressions).
I don't know Perl well, but I think I'd say it also has strong typing.
There is some automatic conversion between strings and numbers, but
this doesn't violate strong typing. C, on the other hand, is weakly
typed--you can create an instance of one type then cast it and
interpret the same bits in a totally different way.