"The Cons:"
"Smaller pool of Python developers compared to other languages, such as Java"
Some commercial tool vendors, who have thousands of developers, still have bugs in their products that are many years, and product versions, old. It is not the size of your developer base that is important, it is how you use it.
"Absence of a commercial support point, even for an Open Source project (though this situation is changing)"
Perl, Apache? Lack of a singluar commercial support entity does not seem to have hurt them. With most popular open source tools, support of a variety of types can be found. The thing with Python (and Perl, etc.) is that you do not have to pay for support, unless you really want to.
Funny thing is, the support thing seems to get brought up so often, that I believe that it's importance is somewhat inflated. In my experience, support for a language is not nearly as critical is it may be for a commercial database system, for example. If my code does not work, I can re-write it in a way that it will work, to work around a language implementation flaw. In over a decade of developing software, I can recall a single instance where _commercial_ programming language support was needed - and it was not foran open source language. Anyone care to guess who the vendor of the language product was?
"Software performance (though benchmarks repeatedly demonstrate Python is comparable to Java in most applications)"
Then why is this a problem? Java isvery obvious in Enterprise level envrionments. Thus if in "most" situations, if Python performance is comparable to Java, and Java's performance is accepted, should not Python's?
There will always be a segment of the market who will choose their tools based on how many other people use them (sheep), and not be concerned on how suited to the task or efficient the tools are. Some of us prefer to be the wolves.
Discussion on:
View:
Show:
First, you have to realize, of course, that my
assignment from the editors here was to write
a balanced piece. I'm a bit of a Python fan
myself, so I had to be sure I covered all of the
objections I had heard from enterprise folks I
interviewed for the piece and didn't spend the
article defending Python. Balance was key.
Second, the point about the size of the
programmer pool is important, I think.
The problem is the overall availability of
Python coders. IT shops are reluctant to
support languages if their perception (in this
case rightly) is that they will have trouble
recruiting trained coders down the road. This
is somewhat offset by the shallow learning
curve for Python, but IT shops don't generally
see things through that lens.
assignment from the editors here was to write
a balanced piece. I'm a bit of a Python fan
myself, so I had to be sure I covered all of the
objections I had heard from enterprise folks I
interviewed for the piece and didn't spend the
article defending Python. Balance was key.
Second, the point about the size of the
programmer pool is important, I think.
The problem is the overall availability of
Python coders. IT shops are reluctant to
support languages if their perception (in this
case rightly) is that they will have trouble
recruiting trained coders down the road. This
is somewhat offset by the shallow learning
curve for Python, but IT shops don't generally
see things through that lens.
Just my two cents...
I am dev manager in a small development shop. When I started they were switching from Delphi to Java, I had been using python for about 6 months. There's only one other developer other than me and he took to python very quickly, he likes to learn lots of different languages.
Of course it'll be harder when we advertise, but I have a plan. We'll hire graduate Java programmers who don't mind learning a new language. I think that's it's pretty easy to switch from Java to Python. In fact I think that they'll apreciate the
jump, because Python's so much easier.
Also, about the documentation. ActiveState's python comes with a nice CHM file for window's developers, that includes excellent documentation on the python library and the win32 extensions. Unfortunately, third party extension's documentation doesn't "transparently integrate" into python's documentation because there's no standard IDE or help system.
But still there's plenty of help from google searches and the #python IRC channel and Open Projects Network.
And finally GUI support. One of the unique(?) features about python is that it doesn't have a standard GUI library, Delphi has VCL and CLX, Java has JFC and swing. Python's standard has been Tkinter, but there are still lots of other GUI toolkits for python (wxPython, PyGtk, AnyGui, DynWin, FxPy, PyAmulet, PyFLTK, etc....). The graphics toolkit is seperate from the language.
Anyway, this is good because it lets the language be moreportable, but it's bad for the VB developer guy who wants to try out python. This guy wants a single standard library for everything, that everyone knows, a full IDE with drag and drop form design and CVS support, and glossy magazine's with third party add-ons in them and all that good old commercialism added value.
I am dev manager in a small development shop. When I started they were switching from Delphi to Java, I had been using python for about 6 months. There's only one other developer other than me and he took to python very quickly, he likes to learn lots of different languages.
Of course it'll be harder when we advertise, but I have a plan. We'll hire graduate Java programmers who don't mind learning a new language. I think that's it's pretty easy to switch from Java to Python. In fact I think that they'll apreciate the
jump, because Python's so much easier.
Also, about the documentation. ActiveState's python comes with a nice CHM file for window's developers, that includes excellent documentation on the python library and the win32 extensions. Unfortunately, third party extension's documentation doesn't "transparently integrate" into python's documentation because there's no standard IDE or help system.
But still there's plenty of help from google searches and the #python IRC channel and Open Projects Network.
And finally GUI support. One of the unique(?) features about python is that it doesn't have a standard GUI library, Delphi has VCL and CLX, Java has JFC and swing. Python's standard has been Tkinter, but there are still lots of other GUI toolkits for python (wxPython, PyGtk, AnyGui, DynWin, FxPy, PyAmulet, PyFLTK, etc....). The graphics toolkit is seperate from the language.
Anyway, this is good because it lets the language be moreportable, but it's bad for the VB developer guy who wants to try out python. This guy wants a single standard library for everything, that everyone knows, a full IDE with drag and drop form design and CVS support, and glossy magazine's with third party add-ons in them and all that good old commercialism added value.
The statements about GUI support is missing the wxPython and PyQt interfaces.
We are building industrial applications based on PyQt (GUI editor is the Qt Designer ..) and
the embedded SQL data bases 'gadfly' and SQLite
(PyQSLite). It works very well!!
Befor you make statements ... please dig a little bit deaper
I think this is a small miscommunication.
What I intended to say was that there
was a shortage of good GUI tools, not a
complete absence of them. I have found PyQt
to be marginally usable and the underlying Qt
library not to be a very strong cross-platform
entrant.
By SQL support, I was taking the IT
perspective here, and Gadfly (which I
personally find to be approaching usability in
its latest incarnation) and PySQLite don't
measure up to industrial-strength apps, I don't
believe. More to the point, IT shops don't
believe!
What I intended to say was that there
was a shortage of good GUI tools, not a
complete absence of them. I have found PyQt
to be marginally usable and the underlying Qt
library not to be a very strong cross-platform
entrant.
By SQL support, I was taking the IT
perspective here, and Gadfly (which I
personally find to be approaching usability in
its latest incarnation) and PySQLite don't
measure up to industrial-strength apps, I don't
believe. More to the point, IT shops don't
believe!
"Creating graphical user interfaces on Python
applications is unnecessarily complex."
This argument is wrong (as Mr. Steinhoff has
already pointed out). If you use the PyQt
binding you can layout your widgets with
Trolltech's official "Qt Designer" and get your
Python code automatically generated. Qt is a
very complex but easy to use GUI framework (and
provides the foundation of KDE). PyQt is a
nearly complete binding of Qt.
On a side note ... I consider the absence of
(optional) static typing to be a showstopper,
since it is most useful especially in huge (read
enterprise) systems.
Regards,
C&E
applications is unnecessarily complex."
This argument is wrong (as Mr. Steinhoff has
already pointed out). If you use the PyQt
binding you can layout your widgets with
Trolltech's official "Qt Designer" and get your
Python code automatically generated. Qt is a
very complex but easy to use GUI framework (and
provides the foundation of KDE). PyQt is a
nearly complete binding of Qt.
On a side note ... I consider the absence of
(optional) static typing to be a showstopper,
since it is most useful especially in huge (read
enterprise) systems.
Regards,
C&E
I think the issue of static typing is one of those
religious wars nobody ever ends up winning.
And I suspect like most such wars, it is more
about style than substance. There are, I am
sure, situations in which static typing is a
must; in those situations, Python may not be
the right language to choose. But I also
suspect (in fact, I iknow of a few) there are
some situations where static typing is one of
those knee-jerk checkboxes IT shops put on
lists just to make their jobof selecting a
language or tool easier, rather than out of any
real necessity.
I've seen some very large enterprise apps
build in things like Smalltalk and the lack of
static typing doesn't seem to become a major
issue. It does impose agreater obligation for
programming discipline, particularly in team-
oriented situations, but I don't think that's a
real deal breaker in most situations.
religious wars nobody ever ends up winning.
And I suspect like most such wars, it is more
about style than substance. There are, I am
sure, situations in which static typing is a
must; in those situations, Python may not be
the right language to choose. But I also
suspect (in fact, I iknow of a few) there are
some situations where static typing is one of
those knee-jerk checkboxes IT shops put on
lists just to make their jobof selecting a
language or tool easier, rather than out of any
real necessity.
I've seen some very large enterprise apps
build in things like Smalltalk and the lack of
static typing doesn't seem to become a major
issue. It does impose agreater obligation for
programming discipline, particularly in team-
oriented situations, but I don't think that's a
real deal breaker in most situations.
Interesting article, I agree with most of the points - however - I do not see how anyone could classify Python as Object Oriented. It has absolutely no provisions for data hiding - a key OO characteristic. I think this may also contribute to its lack of acceptance.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
