In recent years, some enterprises have grown more comfortable using scripting languages for tasks traditionally reserved for languages such as C++ or Java. As Python matures, it is becoming one of the choices open to developers for writing enterprise applications in. In a recent CIO.com article, You Used Python to Write WHAT?, Martin Aspeli discusses the pros and cons of using Python in the enterprise:
When choosing a language for a particular purpose, it is often more important to look at how a language is designed, what it makes particularly easy, and what it makes more difficult. If features or performance do not detract, intangibles such as "feel," "elegance" and a sense of programmer productivity should be given serious weight... Python has a strong role in business computing, particularly in Web and enterprise development.
Indeed, Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is an oft-preferred language at organizations including Google, NASA and Industrial Light and Magic...
Python's single best feature [is that] things generally work the way you expect [them]. This obviousness in syntax makes the language relatively easy to learn for new programmers and easy to remember for occasional ones. However, the fact that it differs substantially from most other languages can be a barrier.
As with many modern scripting languages, Aspeli finds that current Python implementations generally scale sufficiently to handle enterprise tasks, and to allow developers to extend an initial prototype into a functional application:
Python is the default choice of scripting language for many developers... It is rare to start a project with Python and discover that it was an entirely inappropriate choice as [the project] grows, because Python scales both in project size and performance. That said, the degree of freedom that the language grants developers means they sometimes have to be a little more disciplined in how they structure their code.
On the negatives side of using Python in the enterprise, Aspeli points out that finding qualified developers may be the biggest obstacle:
The power and expressivity that Python offers means that it may require more skilled developers. Java or C# are more restrictive by design, forcing programmers to adhere to stricter rules around type safety and interface compliance. For some, that hinders productivity. For others, it reduces mistakes or accidents of design...
What do you think of Aspeli's comments on using Python in the enterprise? Do you think Python is ready to tackle complex enterprise computing tasks?
I might be nitpicking but I don't think that Martin suggests that one should "extend an initial prototype into a functional application". Maybe it's a tracer bullet that grows to a bigger application, but not a prototype (I hope).
My biggest disagreement with Martin is his reluctance to recommend Python for desktop applications but he is clearly in the Microsoft Windows world. On a GNOME desktop for example, I wouldn't suggest writing desktop applications in a compiled language unless there were some performance issues involved.
> I might be nitpicking but I don't think that Martin > suggests that one should "extend an initial > prototype into a functional application". Maybe > it's a tracer bullet that grows to a bigger application, > but not a prototype (I hope). >
At this point I think you are talking semantics. Besides, if you are in the agile camp, the prototype usually becomes the application. I think the difference between 'prototype' and 'tracer bullet' is probably a line in the sand anyway. What's the difference?
> My biggest disagreement with Martin is his reluctance to > recommend Python for desktop applications but he is > clearly in the Microsoft Windows world. On a GNOME desktop > for example, I wouldn't suggest writing desktop > applications in a compiled language unless there were some > performance issues involved.
I didn't find his comments on the desktop to be anything more than the conventional wisdom. I know of very few desktop apps that are mainly written in python (bittorrent is the only widely distributed one that comes to mind), so I certainly don't think his comments are anything more than observations.
And it is hard to disagree with the assertion at the end that python might not be appropriate if you:
"Build primarily desktop applications, especially for Windows. Platforms like .Net usually offer more sophisticated tools and easier distribution of the final software."
It's a simple statement of fact on Windows. If you want to roll out a python app on Windows, you either need to package it up with something like py2exe or get python installed on the target machine, along with any supporting libraries. Not having written desktop apps for any other platform I can't speak to those environments. I've only done web, server side and command line apps for other environments with the exception of one small really useful python script that just uses the included Tkinter for the UI.
I would be shocked if somebody that "contributes vocally and prolifically to the Plone open-source CMS" was clearly in the Windows world. I can't imagine putting him there for making a brilliant statement of the obvious.
> Aspeli points out that finding qualified > developers may be the biggest obstacle:</p>
I've found that few, if any, language features or language suitability or anything other technical criteria have any real influence over the choice of language in most commercial projects.
In practice, most people go with the language that they know and that their colleages know and that the ongoing maintenance team are willing to take on. After that, new languages creep in as a result of experimentation by language hobbyists on small independent and disposable projects. If the language popularity grows then bigger projects become possible, not because of the language has somehow gained new features but because it is possible to put a team together with individuals who have a useful depth of experience of the language.
In this respect, language "wars" are no different to the cassette/8-track, VHS/Betamax, Blu-ray/HD-DVD "wars". It's the users that make or break the product, not the product.
> > Aspeli points out that finding qualified > > developers may be the biggest obstacle:</p> > > I've found that few, if any, language features or language > suitability or anything other technical criteria have any > real influence over the choice of language in most > commercial projects.
The real problem with this argument is the implication that you can get dumber developers if you are writing Java. Maybe dumb developers won't be able to make quite as big of a mess in Java but employing unskilled developers is a bad strategy regardless of the language. Any skilled developer will be able to pick up Python without too much trouble.
> The real problem with this argument is the implication > that you can get dumber developers if you are writing > Java.
No. That's a wrong interpretation. I don't believe that the average Python/Ruby/blah/blah developer is any different to the average Java/C#/blah/blah developer in the enterprise environment.
I'm saying that the relative qualities of different languages and the relative capabilities of the language users (if any) are not the most important factor in deciding upon a project development language. The deciding factor is the ability to put together a team now and in the future that can work in that language.
This gives a natural bias towards existing established languages which is only overcome when there is a sufficient pool of people who are familiar with a newer language. Thus, the rise of a new language is dependent upon language hobbyists and small independent projects that eventually achieve a critical mass that can challenge the enterprise status quo.
> > The real problem with this argument is the implication > > that you can get dumber developers if you are writing > > Java. > > No. That's a wrong interpretation. I don't believe that > the average Python/Ruby/blah/blah developer is any > different to the average Java/C#/blah/blah developer in > the enterprise environment.
I apologize, I was unclear. The problem I have is with Aspeli's statement that you quoted. I wasn't disagreeing with you per se.
> I'm saying that the relative qualities of different > languages and the relative capabilities of the language > users (if any) are not the most important factor in > deciding upon a project development language. The > deciding factor is the ability to put together a team now > and in the future that can work in that language. > > This gives a natural bias towards existing established > languages which is only overcome when there is a > sufficient pool of people who are familiar with a newer > language. Thus, the rise of a new language is dependent > upon language hobbyists and small independent projects > that eventually achieve a critical mass that can challenge > the enterprise status quo.
Well stated. I know that in my own case, my attempts to insert Python into the conversation have met with blank stares. The 'nobody gets fired for buying IBM (or MS)' is a more dominant factor than how well a tool will fit.
Previous Topic
