Slashdot Mirror
Python Moving into the Enterprise
Qa1 writes "Seems that Python is moving into the enterprise. At the recent PyCon it has become apparent that it's not just Google, GIS, Nokia or even Microsoft anymore. The article points out that Python is increasingly becoming a perfectly viable and even preferred choice for the enterprise. More and more companies are looking at Python as a good alternative to past favorites like Java. Will we finally be able to code for living in a language that's not painful? Exciting times!"
I work at an Application Service Provider startup with 16 employees (5 developers) using Python (30K lines+).
I have 6 years of Perl development plus another 8 in C. So, a newcomer to Python (about 2 months now), I have several reactions shaded by that experience:
* Nice syntax: Not perfect, but very passable overall.
* Love the no-brackets: Indentation as a means of delineating code blocks is great; there's no debate over where to put squiggly braces (the 'if test { statement; } stuff;
* Immature toolsets: there are very few mature toolsets yet. We're using SQLObject, which is in version 0.6, as an object-relational-mapper. It's got some limitations and is admittedly not 'enterprise ready'. it's hard to compare to the Perl DBI because the dbi just is an interface and doesn't do mapping.
* Lack of CPAN: the single most fantastic "tool" I've found in my programming career (15 years) has been CPAN. Got a problem? Someone has probably already seen it and started a solution. I know this is in the works for Python but the tools are not all there yet.
* Syntax (bad): Lack of a requirement to declare vars before use. I really would like the ability to require that all vars are explicitly declared before being assigned to. it would help coding reliability.
Just my 5 cents.
-- Kevin
Unitarian Church: Freethinkers Congregate!
If you haven't already, you want to get hold of a copy of
Foundations of Python Network Programming.
My only experience of web progamming in Python is the client end, for web-scraping scripts, and its great for that. The one problem I have is that once in every few hours urllib2 locks up whilst trying to get a page from a particular site.
The one thing that Java has going for it are "standard" APIs you can bank on. Is there a standard set of enterprise APIs for Python akin to J2EE?
I am not trolling, but isn't the standard Java API painful to program with. Who wants to code 4-5 lines just for opening a file?
In any case, there is PEAK for Python.
- srid
Do yourself a favor and sacrifice 3 months of your life learning Zope & Plone. If you're into web development, it will pay off big at the end.
It's like: why build your own search engine, security engine, your own membership system, html form engine, templating system, cache engine, skin system, content types & custom types, etc, when you can just use zope & plone and get a complete framework with open source products and addons on which thousands already develop at the highest profesional level?
I admit that Plone and zope suffer from some documentation problem, but it's possible to overcome that. There are free books, available online (Zope book and The Definitive Guide to Plone) that can get you through. The documentation on Plone.org is getting very good. There are several code repositories (collective is one of them and some on zope.org) that have example products. Also, read the sources, they're not that hard to understand.
And before any of you jump and shout Booo!! ZODB, let me remind you that you can use just as well a reqular sql server to store your content information.
I'll do the stupid thing first and then you shy people follow...
I don't find Java as a language painful.
It's the output of Java programmers that turns my stomach.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Well, these guys do...
Whitespace
Why is it a good thing? Because in every modern language, the whitespace *already* matters to the programmer. The problem is that in most languages, it doesn't matter to the compiler. So you have to add the braces. Don't believe me? Here are some classic C:
if (condition);
doSomething();
if (condition)
doSomething();
doSomethingElse();
See? To the programmer, it's the whitespace - the level of indentation. In Python, the language parser is simply smart enough to use that as a guide too - no need for the braces.
That being said I am enjoying it. I recently found I was writing a perl program that became unweidly in its comlpexity and impossible to maintain. So I converted to python. My reason for doing so was the existience of a nice matlab packages that allowed me the ability to recycle matlab code and make nice graphs. The syntax in python is cleaner with lets me do more complex array manipulations in the scientific envirnoment.
On the other hand I note that this syntactic sugar is simply a coating. FOr example, python implementes obects via an underlying hash just the same way perl does. But it hides it from view. Thus you get less flexibility in objects than perl and no real ability to optimize their speed since the access method is frozen in the syntax.
other things that trouble me are its seeming incompleteness of many of its metafors. For example, variables do spring into existence upon assignment but they dont auto initialize. Thus simmple things like counting the occurence frequency words in a file becomes a hassle since you have to either explicitly initialize every hashkey value to zero, or use one of the slow accessor methods (like .get()) that introduce huge perofrmance penalties. And the method of doing this is different for arrays, hashes, and scalars. auto-instantiation is somewhat dangerous too since a typo can now become an error without some means of declaring a variable name was meant to exist (e.g. the perl "my" statement).
Related to the lack of auto-initialization is the tendency to rely on the crutch of throwing exception rather than returning default values or signals that allow the progammer to decide if it's worth throwing an exception. I find I end up wrapping too many inner loop clauses in "try" statements. If operations that failed simply returned "None" or zero as appros many things could be simplified without any loss of ability to use exceptions properly.
other incomplete features are a lack of consistency on when an intrinsic operation is done in-place or returns the result. for example .sort() is done in place while .ltrim() is not. While one might wish to argue that space issues can require in-place operations, it woul dbe better to detect when an operation can be done in place from the syntax: a = a.sort() should be done inplace. b = a.sort() should not modify "a".
typcasting also seems to be incomplete as well. Take for example the casting of strings to integers. try this: i= int(45.3); i = int('45') ; i = int('45.3'). The first two casts work. the last one is an error. Why? I note .atoi() also fails in the same way.
My final lament about unfinshed python is the screaming lack of a decent syntax chekcer. Too many of its errors occur at runtime. It's weird that its the low level syntax of python that seems so unbaked. The high level imports are luxurious indeed and are a major attraction of the language. Having a conveinent operation like "shelve" for persistence takes enormous pain out of coding (now if 'shelve' could just use objects rather than olny strings for keys it would be complete).
My hope is that someday python will take advantage of the syntactic sugar to imlpement objects in a faster way under the hood.
all in all I do like python because it's a lot simpler to get the job done than Java or C++. If you know perl then python is useless as a scrpting language (sadly pathetic really) but if you dont know perl then python must seem like a fantastic scripting language if you are coming from C++.
Some drink at the fountain of knowledge. Others just gargle.
One thing I've never been able to grasp is why Python proponents always mention the fact that whitespace is significant as a good thing.
Whitespace (or more specifically, indentation) significance forces you to make the visual structure of your code match its semantic structure.
Having used both, I'd say that Python is quite a bit terser than Java, which is very good in itself. Java is a bit pickier at compile time, which usually is a good thing.
Probably the biggest difference is that there are no checked exceptions in Python. Java has both checked exception and non-checked ("runtime") exceptions, but the normal type of exception used in practice is checked. A checked exception is compulsory for the caller to handle or to pass up.
In theory, a programmer using an API with checked exceptions has to consider all the things that could possibly go wrong. In reality, the idea you can catch every error before you get to testing is a pipe dream. You often don't know what you want to do with it until you have some empirical experience with your basic design. So you do one of two things -- either handle the exception in a half-assed but temporary manner (hoping you'll remember to come back and fix it later), or you pass the buck.
Since the best of these two alternative practices (passing the buck upward) is the better, that means that it is a lot of work to get traction -- you can create a facade layer to orchestrate all kinds of low level stuff, but there is a tendency for that low level stuff to bleed through your facade. Modern Java practice (within the last couple of years) has rediscoverd the runtime exception -- which works exactly like the Python exception. Hibernate 3, for example, uses runtime exceptions. Personally, I'll rip bleeding strips off flesh of one of my guys who does something stupid with an exception -- because it's so easy to just wrap it in a runtime exception (we have a wrapper class for this) and rethrow it. Throwing an exception in a tester's face leads to quicker fault discovery than papering it over.
I think the remaining difference between Python is that it's concept of collections are built-in, whereas the Java language only has generic objects and containers are built using this low level stuff. The resutl is that Python gets a big win when it comes to providing terse, convenient and easy to read syntax for processing all the elements in a collection. In programming terms, this task is about as common as dirt on a farm, and is a major win for Python.
I think Groovy may be more the way to go for Java shops looking for a productivity boost. Python has its own set of gotchas. Which is not to say it isn't quite good, but I'm not a big fan of the idea of combining Java and Python.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Oops:
I meant OpenEV on sourceforge.net
I'm sorry, but the "but it's slow" argument does not hold for most software designed today.
What planet are you from? I do a lot of work at oil companies and utilities, and they have tons of slow software that causes them to hemorrhage man-hours at an insane rate. I'm talking about the big name companies spending tens of millions of dollars per year on bloated applications that take 30-60 seconds just to start up and take just as long to perform many of their routine functions. People often use these various functions throughout the day, running them hundreds of times. This amounts to several hours per day of users twiddling their thumbs waiting for slow software.
Very often, there are only one or two vendors supplying some niche market such as geological interpretation or pipeline facility management. So if you can write an application that takes half as long to perform certain commonly used functions, you've just saved your customer hundreds of thousands of dollars per year in lost productivity, and they will pay you for that.
There are numerous areas where performance does matter. It's not always the most important consideration, but it's certainly not irrelevant.
Most statically typed languages miss out on one or more of these, and all of them have a much more dramatic impact on how quickly I can get anything done in the language than the lack of static typing does -- static typing doesn't get really useful until you have a big interconnected system (and of course the above properties help keep the size of your own program down by eliminating lots of).
I may spend a lot of time cursing at the lack of static typing, but the fact is that the inconvenience of missing the above features is enough to keep me using Python et al. The most annoying thing is that none of them are particularly tied to dynamic typing, except in the sense that it's simpler to implement a dynamically typed language, because there's a lot of theory involved in type systems (especially if you want to do any sort of inference).
Daniel
Hurry up and jump on the individualist bandwagon!
"It's slow" is entirely valid.
Lets be serious -- Java isn't slow so much because of any real technical issues with the language, but because of the mentality surrounding it.
The mentality is to overdesign and overengineer. Everything must be reusable, nothing should be written from scratch if it can at all be avoided. Don't try to understand the problem, get the module that advertises the solution you need and drop it in. Speed? Let the RDBMS/window toolkit/JVM worry about it, programmer time is expensive, you know!
This mentality certainly is not limited to the Java world. This mentality is a facet of "enterprise" scale software development, which you can apply to any language; Java is simply unique in that the Java world goes far out of its way to facilitate this model.
I find that under such a model, the end result is a dreadfully slow, frustrating product which prompts developers to make severe compromises or shove in workarounds at the last minute for speed.
Case #1: Windows NT 4 maintains a SAM database to control access. Pretty clever, keeping it all in a centralized database, but the sucker is massive and takes a long time to load on startup. Waiting for the damn thing to load on some servers was taking 10-15 minutes (I shit you not). The boot process already took 2 or 3 minutes, and to wait 10-15 more minutes on top of that before you can log-in is agonizing, so Microsoft put in a hack to rig it so you could login with the barest bones part of the SAM loaded.
Of course, you logged in, but on the server we found that if we launched anything an administrator would want to use, the management tools would either hang until all of the data got loaded, or crash because it was working on a dataset that was rapidly changing.
Case #2: Large application suites generally take a long time to start because they're organized into numerous modules that all need to initialize and load when the app is started. As the app gets more featureful, load time shoots up. Developers would at first try hard to minimize the impact of their module load times, but as the features kept creeping it, they realized that there was no hope -- the load time was well past the 10 second mark and the user was getting irked. So, they added the splash screen with a status indicator! Once that went in, developers don't try so hard to keep their module load times down, so it stretches into minutes.
It doesn't occur to anyone until after 500,000 lines of code are written and they see the shell of the app running that they should worry about load time. By then it's far too late.
Case #3: the RDBMS is on a giant beast of a server, it's got a terabyte of RAM, 64 processors, -- no worries here: the developers start getting lazy and write O(N^X) performing queries. They don't notice how slow it is on small dataset, and they go with it. Besides! The RDBMS is a monster that can handle anything! But then it goes into production and Y is 100,000,000 and X is 100 and a couple of these queries happen a second. Oops.
http://www.fsf.org/licensing/licenses/license-list .html says you're wrong. It's almost exactly as free and open as Apache.
I am trolling
Pike is statically typed and requires you to declare variables, but is still just as fast and easy. For your example:
int|float twice(int|float x) {
return (x * 2);
}
See, it doesn't have to limit the functionality of the function twice. And you still get all the benefits of static typing finding mistakes for you at compile time.
You appear to be confusing static vs dynamic type checking with strong vs weak type checking.
Static type checking occurs at compile time, whether or not the language is strongly or weakly typed. Dynamic type checking occurs at run time, regardless of whether or not the language is strongly or weakly typed.
Disagreement still exists about what constitutes strong vs weak typing; the extreme definition of strong typing is "type checking that prevents all type errors", while the corresponding definition of weak typing is "type checking that does not prevent all type errors". I call this an extreme definition because it makes strong typing so rare that the term becomes less useful.
I think that the terms strong vs weak typing are best used when comparing two languages, so you'd say e.g. "compared to C, Python has strong typing". This contrasts with static vs dynamic typing, which don't need comparison to be valid: C is statically typed, regardless of what the status of Python is.
One of the benefits is in things like duck typing. Often you don't care what kind of object something is so long as it has some certain method. To put it in a practical way I work with zope which is a python based app server which has an object database as part of it. Often I will run queries and get objects back. Most of the time I don't care if it is a file, picture, dtml document, or any of the many other types in the db all I care is that it has an id and it is willing to draw its url. Those are the conditions I have for working with the object.
So you work with objects by interface rather then by type. The interface also does not have to be a complete interface. You can implement as much of the interface as you need for something. I have some objects that are not lists and can not be used as lists however I have implemented some methods that make it so you can iterate over them like lists and slice them like lists.
This makes many tasks far simpler and encourages more regularity in usage.
How do you check if a substring is in a string, an item in a sequence, a key in dictionary etc? How do you iterate over them? In python it is all the same. if substing in string, if item in seq, if key in dict and the for character in string, for item in seq, for key in dict, for line in file, etc etc etc.
Types are nice but the types the static compilers have are not the types my apps use. The static type systems just end up costing me more time to develop working apps with then the dynamic typing systems and you have to test the product anyways.
Computer modeling for biotech drug manufacturing is HARD!
Apologies in advance if I have misunderstood you, but ...
I think you may be missing an important point here. In older languages, you'll find that the bulk of the work was often thrust on the programmer because the programmer was far cheaper than the computer. One need look no further than the horror of JCL and COBOL to see a high level language that still required inordinate amounts of fiddling by the programmer to get it to play nicely with the computer.
Today, we find that the programmer is far more expensive relative to the computer. Simple economics dictates that shifting much of the load from the programmer to the programming language will save money. However, that's not the end of the story. Some applications need raw speed. Others do not. Choosing Python or Perl for device drivers or ray tracing is probably not a good idea. Choosing C or C++ for processing log files is also probably a bad idea (though not always.) An "always/never" dogmatic approach to language choice means that one cannot choose the best tool for the job, but is instead forced to twist every problem in such a way that your favored language is an appropriate solution (or, perhaps just as common, to simply ignore those areas where your favored language is a bad choice.)
In other words, don't be dogmatic. Dogmatism implies that you won't consider new ideas and that's almost always an error, even if the beliefs that you hold as true are true. Developer performance, processor performance and language performance are all factors that should be considered.
The rate of growth in python exceeds the other major scripting languages.
i ner/java/scriptinglanguagesDejanews.png
http://www.realmeme.com/miner/java.php?startup=/m
Python is the only one that has a clear increase in rate of change.