mnot’s blog

agreed - i'm coming in from the other angle - a big Perl fan whose been looking for something a little more uniform though finding Java or C# too much of a big step backwards. Other similar options aboud, notably Ruby and Groovy, but the Python family has some serious momentum as well as the promise of being a first class pier on the JVM, CLR and Parrot VMs.

Amen!

I remember the same being said of Perl only 3-5 years ago.

It may be that many people are meaning to get into it but it means nothing in terms of commercial adoption. I see new found traction around Python as well but it is more along the lines of another PERL, not a C# or Java in terms of use in products. For us (SAP) we have no plans and there are no whispers even. What is there is interest from developers and lots of dicsussion on using Python (and PERL) for connecting to our systems I never would have imagined going on out there in the field. To me the fact that Python is used seemingly as much as PERL in this context is a real success. Still, the title of this post is a bit overblown. Sorry buddy but it ain't gonna happen. Now to your point about staticly typed languages, I could see dynamic typing getting more broadly adopted someday, but for large commercial applications the language of choice to provide that will not be Python. It will have to get added someplace else with greater traction in among application providers, like I dunno, ABAP.

I have to disagree with Marc g on his comment:

"but for large commercial applications the language of choice to provide that will not be Python"

I have worked on contracts and have developer friends who have worked on contacts

1) with some of the largest corporations in the world
2) writing very large, distributed enterprise applications, and
3) writing code glue for legacy apps, providing a unified front.

Python is clean and easy to maintain. It's easy to build powerful custom libraries. It's a simple language, and thus very easy to both learn and write quickly. It's a powerful language, and thus "easy" to write powerful applications.

For these reasons, departments in some of the biggest corporations are dictating that python be the language of choice. Obviously, the world will never be 100% python (nor should it be!), but it's becoming the choice for, uh... the next generation... *cough* *lawsuit* *cough*.

And let's face it, the python community is dedicated and fun-loving, thus we pycoders are a beloved addition to any corporate tech zoo ;-)

N.B. — I’ve manually copied some comments over because of a hosting switch; their content is not changed, but the last three comments’ dates are incorrect (they were posted over the last day).

I think d and I actually agree. You and I have a different definition of "comercial". I'm talking about packaged apps. The example you site about corpoarte IT shops using Python is exactly what I was getting at, but those apps almost by definition will never get packaged and sold. PERL has a long history in this type of enviornment as well but neither it or Python are commonly used for packaged applications. I maintain that neither will ever have the adoption levels that languages like C# and Java have that are more commonly used to create packaged comercial applications do.

While packaging Python is a bit harder, it can be done. Python has been used for scripting in a few commercial games. Talking Panda (http://www.talkingpanda.com/) uses Python for a commercial app on the Mac. BitTorrent isn't commercial, but it's packaged and widely used, by people who are never aware of what it's written in. And most of the BitTorrent clones continue to be written in Python -- the distribution issue isn't enough to drive them off the platform. SpamBayes is another application that is quite deployable. Zope and Plone can be fairly easily deployed in a shrink-wrap style.

It's absolutely true that Python isn't used much for shrink-wrapped packages. It's also popular in open source crowds, where people don't write shrink-wrap packages. But it has the potential, as can be shown in these existing packages.

I don't know enough about Perl to know whether it's been used in this way, but I always got the impression it didn't work well on Windows and wasn't great for packaged software.

I work for a VERY large US corporation... a name you all would recognize instantly.

Maintenance on legacy apps is usually performed in the original language, but new applications, and major additions to existing, is another story. Java is our 1st preference ("industrial strength" and all its implications) with Python clearly the 2nd choice. ALL other languages are 3rd, 4th, 5th...

It all depends on what you are doing, but if you walk up and ask, not saying anything more, the answer is Java, but if it is not a good fit, use Python. This wasn't the case a year ago.

Back in 1996 I supported Java, and hoped that people would recognise the need to stop obsessing about CPU performance. Java has been an incredible triumph of marketing over matter, however.

In legacy environments there are established ways of building large-scale back end and batch enginery and where existing software asset values run into $billions.

A better route to new delivery has been found that treats old, heads-down screens as robust middleware - that can still be accessed rapidly with terminal emulators.

New exciting possibilities have opened that will allow cost effective front-ending tech. to be augmented by interactive XUL-type scripting capability. What is the best language to take advantage of this new frontier? (Cue Monty Music)

I really thought for a moment that the link under "the real thing" was going to go to http://www.cliki.net or a similar page -- because compared to Lisp, Python is a Johnny-come-lately, halfway-there language.

Back in *my* day…

*grin*

Mike: Compared to Lisp, almost any language is a Johnny-come-lately, halfway-there language, but if it was completly there it would be Lisp, right?

Like Mike I was hoping that the reference to "dynamically typed languages" was code for Lisp. The GNU folks had this discussion several years ago and settled on Scheme as their preferred extension language: http://www.gnu.org/software/guile/guile.html. SISC, http://sisc.sourceforge.net, is an excellent implementation of Scheme in Java. If you want "the real thing" look no further than Scheme.

Guile never turned out like GNU had hoped. In part, they had an idea that Scheme could be a common runtime (ala CLR), but they weren't really committed to making that happen -- in no small part because the people who became involved in Guild wanted it to be a good Scheme implementation, not as an appropriate target for other languages. Also, the tool and library support just wasn't there. It wasn't a particularly fun environment to develop in (even extension scripts, which need debugging just as much as any other coding does).

So, I wouldn't take the GNU decision all that seriously, to me it feels like an anachronism at this point, an artifact of a debate held ten years ago that everyone forgot about.

Python is far too C oriented in it's syntax to be a language of choice.

The problem is not that the C nomenclature is any better or worse than any other language, it's that C programmers by far are poorer programmers than programmers of other languages.

When a programmer is attracted to the syntax and structure of a language whose roots lie in C, you're asking for trouble.