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!"
The Jython language is still (essentially) an older version of Python. Just because it runs in a Java VM and can integrate with Java classes doesn't moot the point about doing enterprise work by "coding in a language that isn't painful."
A man without a God is like a fish without a bicycle.
I don't know whether to be happy or afraid.
I agree -- Python is fantastic for quickly building small apps, or even much larger ones.
The problem arises in Python's web programming support. The documentation is pretty much non-existent and you can soon get module-overload when you are importing more and more modules to do fairly simple stuff in web apps.
Sometimes I just think while Python is most certainly a far better designed language, PHP/ASP.NET (C#) seems much more 'pratical', and it's definitely much easier to quickly build web apps in.
Is there much effort to improve Python's web support? A manual with similar completion of php.net would help it go a lot lot further.
IntechHosting - Free domain, 2GB, PHP, £4.95/$8.95
The first dozen replies are all trolls, so I'll add my experiences for posterity's sake.
I've been using python for pretty much anything in my company that isn't web based, and things couldn't be better. There's talk about python being slower, which it is, but most libraries that do important things are just C wrappers anyway, so the speed decrease is negligible as python is just holding the logic. Tk is nice enough, I guess, but I tend to use wxPython. Either way, it gives you cross platform GUIs, which is always a nice thing. Using pyexe allows you to even 'compile' scripts into exe files with win32 machines.
To be absolutely honest though, I can't think of an easier language to learn (I even teach >40 yo women now and then!) or a quicker language to code in. Once you're accustomed to it, the code just flows out, and I've seldom been disappointed by the results. The formatting requirement helps to ensure that your code isn't a disgusting mess that no one can figure out, YMMV.
The Computer Language Shootout is pretty useless - often there is a reference implementation in C and the task is to code the *same* algorithm in other language. This ignores the fact that there might be better ways to solve the problem in the other languages. Or in almost all languages. Just take a look at the fibonacci test - it a stupid useage of recursion, if your compiler doesnt optimize out all the duplication. Ok, that would be a nice feature, but it just shows "This language/compiler is good at optimizing bad written code".
..)
Also you can make the shootout say almost anything, for example if you also calculate the code lines in and weight pidigits with a 4 multiplier, Python comes up as the best of the "serverside languages" (Perl, Python, Java, PHP
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?
And all of this isn't to say that one can't leverage both technologies where appropriate, even in commercial products...
While I agree wholeheartedly that python is a wonderful language to code in, I think that it lacks a sting GUI system. Yes wxPython is cross-platform, but without getting overly detailed here, it definately lacks the detail and robustness of SWT or even Swing. Until wxPython can stand up to those, I think the movement to it for more broad based use with be a bit slow. As far as apeed goes, who cares? We are not programming for 286 machines anymore!
My
I think that Python is supposed to be better in benchmarks not listed on that page, such as "mean time to correctly add a feature to unfamiliar code, written by someone who has since left the company".
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
Had you done the same test 8 years ago but searched for Java versus C/C++, you'd probably have seen the exact same results.
I've never had any problems with Python's speed. It's fast enough for web applications. It's fast enough to use GUI toolkits. It's even fast enough for simple OpenGL demos (a shameless plug, I know, but it seemed relevant).
If you come across a situation where Python is too slow for what you want to do, then Python can work happily enough with libraries programmed in C. If that's still not fast enough, then use a different language. But I suspect that for 95% of all programming tasks, Python is fast enough.
1) The twenty minute problem
Many programmers, including top ones like Eric Raymond http://www.linuxjournal.com/article/3882, are so put off by Python's use of whitespace as a block delimiter that they swear never to touch the language. In my case, this lasted for two years. You need to spend twenty minutes learning the language, after which the whitespace stops being a problem and starts looking like one of the many great ideas in the language. The challenge is getting people past their initial disgust enough to try it.
2) Misperceptions about typing
Many people think agile languages like Python and Ruby are not strongly typed and therefore present scalability problems and can't be used reliably by large teams. But Python and Ruby are strongly typed (unlike Perl)- you don't get type conversions you don't ask for. The real distinction is that the agile languages are dynamically typed rather than statically typed like Java/C++. To truly grasp the notions of "duck-typing" and lazy evaluation of types is as much a stretch as it was to "get" objects for those of us who were around 15 years ago- it's a basic change in how you think. You'll know when you're there, because you'll see in a flash that Java's static type declarations are not only redundant and painful, but they are also in themselves a key source of brittleness in large programs over time.
3) The youngsters' problem
This is probably the biggest barrier: university CS departments have become nothing but Java training courses. In trying to better prepare grads for actual careers, they have added a lot of basic business teaching, which is good. But they no longer bother to give students a real understanding of actual computer science, sticking instead to a cookbook approach using Java. So young people arrive in enterprise IT shops knowing nothing but Java and thinking they know everything, so they are not open to anything requiring a different intellectual approach.
I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it.
Soon as the qt windows free version starts shipping I think we will see alot of renewed development of gui stuff in python. Currently wxwindows exists but it is a little funky to program in if you ask me. A good industrial strength redily available qt is going to move alot of things.
It is a great language we use it for everything, web services, linux / win integration, nt services, automation etc.
Got Code?
For good measure, let's look at the documentation from a J2EE vendor here.
While PEAK sounds intriguing, I'm not sure that major projects started by Fortune 100 globals will leverage a technology that lacks the level of documentation quality you can find in other products in that space.
I bring this up because documentation is often an indicator of the level of quality you can expect in terms of support. This is not to say PEAK is bad or poorly written, just that the supporting documentation and resources don't match those available for J2EE implementations.
Remember -- it isn't the best technology that wins, but the technology that is most accessible. In the case of enterprise APIs, even though PEAK may be easier and more scalable (and this is an excerpt from their page): But PEAK is different from J2EE: it's a single, free implementation of simpler API's based on an easier-to-use language that can nonetheless scale with better performance than J2EE. ...it will need some time and some nurturing in order to compete for mindshare with developers and non-technical decision makers.
The old K&R style of doing:versus:this is NASTY in the debates it causes and wars people fight over which is 'right' or 'easier'. For those who don't know, Python doesn't use braces, it uses any consistent indent, as in:Very simple. Reduces line count by 1 or 2 and completely removes the religious debate about brace location. I really like this. There's enough problems debating what the code header/copyright/IDENTIFICATION DIVISION (grin) section's going to look like. "I like #####!" "No, I like #-------!!!", "You Suck!" "No, You Suck!" etc.
Don't knock the lack of braces until you try it. it really does make the code look cleaner.
--Kevin
Unitarian Church: Freethinkers Congregate!
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. I guess it could be argued that at least it's not a bad thing, in which case it boils down to a matter of personal taste, but everyone seems to be saying it makes reading unfamiliar Python code so much easier.
Well, with any other language, if I get a piece of unfamiliar code and have problems reading it due to weird indentation, I just run it through Emacs' indent-region. Can anyone explain to me why this is not just as viable as mandating the indentation policy by embedding it in the language's syntax?
-- If no truths are spoken then no lies can hide --
What's the point in spending several times the develeopment effort on making it work properly instead of adding polish or just doing new stuff?
What's the point of making it work properly?!?!? Surely you have mis-spoken here.
Let's play a game. Let's suppose a bunch of little apps for which speed is not a critical factor for any one of them. As a forinstance, look at all those apps presently running in the system tray. Let's suppose that those apps are written badly or are written in inefficient languages. That shouldn't be too much of a stretch.
Now, let's try to do something. Whether you are trying to run a realtime application like desktop video conferencing or create a document in a word processor, it doesn't really matter. What ever it is that you try will be a struggle because the system's resources (CPU cycles, memory, swap space) are consumed by all those "noncritical" apps and their inefficiencies. A 1Ghz processor with 1 gig of RAM is no longer adequate? That's ridiculous! And yet, that is where we are at today.
Everyone seems to feel that their "Ultimate MP3 player" is the only app in the world or at least the only one that will ever be run on a machine. They don't think that speed and size are important. After all, they have a very powerful machine at their disposal with oodles of available resources, right?. They fail to realize that their program, no matter how wonderful, is only one of countless others that are all running at the same time and are required to share the resources. They fail to realize that their app may not be too slow when run by itself but, it becomes too slow when run with everything else.
Today, the preferred system is 3Ghz, 64bit, with at least 2 gigs of RAM. Why? What's the point of such a powerful system? Speed! That's the point. Speed is important. Code efficiency is important. But, as programmers continue to deny this and produce poorly written and bloated/slow apps or use inefficient languages, the time will come when a 6Ghz processor is not enough. Doesn't that sound stupid?
Well, my point is that more knowledge isn't necessarily a good thing, if it isn't coupled with judgment -- wisdom if you will.
I think the level of knowledge among Java programmers is impressive, but by in large I've found they aren't necessarily better programmers because of it. I've learned this the hard way, by hiring people with incredibly impressive knowledge of Java APIs, and then watching them struggle with overengineered designs that attempt to drag as much of that knowledge in as they can manage. I'm not going to make sweeping generalizations here, only to state that I've had bad experiences Java guys who prefer to wander lost in the wonderfully rich world of Java APIs and frameworks than focusing on a customer's problem.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Whitespace-delimited blocks are not the reason to use Python. Dynamic typing is.
Ruby will give you dynamic typing without all of the whitespace issues. Given that the two languages compete in (mostly) the same space, why should I go with Python if I don't like it's whitespace issues?
I've seen many cases where thirty minutes of practice gets rid of the problems people have with the whitespace.
But why do I have to adapt to the tool as opposed to the other way around?
Your reaction is just as the OP predicted.
The truth is that whitepace-delimited blocks can be a source of difficult-to-find bugs. It also makes it quite difficult to easily copy n paste code from one place to another. Add to this that it makes Python a very poor language for templating (embedding in HTML for example) and you start to understand why Ruby on Rails is doing so well.
""Processors are cheap." and "Disk space is cheap." are horrendous excuses for bad programming. If you have used these expressions to justify your application, you are a bad programmer!"
Okay, I'm going to refute this is two stages because you're wrong in two ways.
First, it's not a matter of "processors are cheap". It's "processors are cheap compared to programmers, sometimes". If they're paying for months of your time, most of the time it's way cheaper for them to get a faster computer than have you write the thing in a language that will take longer. That is of course dependant on the number of computers it will run on and the performance requirements of the project.
Second, Java and Python are not necessarily slow. In the case of Java, it's usually a matter of keeping heap allocations to a minimum. In the case of Python, it's usually a matter of spending as much time as possible in a C library (even if that means you have to write the C library).
Doing that will usually get you within a factor of two of the performance of C.
I rarely criticize things I don't care about.
Its the package name for the class File. Similar to c++ namespaces. Its a CS thing dude.
That said, the grandparent poster was a bit disingenous. The File class is roughly equivalent to the stat function/structure in C. You can't read the file without creating an inputstream/reader.
So yes. You are correct. It is more verbose when doing simple operations. But I like to think that more complex operations fall together more easily.
Many programmers like to whip something out now. A quick "one off". Instead, often, with a little more time and more ground work, they can make something that is reusable.
In terms of the IO being verbose. Well its pretty flexible. 2 Interfaces (InputStream/OutputStream) are used for many different opertations. Read/write a file. Read/write to/from a socket. Read/write from a string or byte array. Read/write serialized object s to/from a file/socket/etc.... Its not just File IO. Its ALL IO. Long story short, that is why.
Today, the preferred system is 3Ghz, 64bit, with at least 2 gigs of RAM. Why? What's the point of such a powerful system? Speed! That's the point. Speed is important. Code efficiency is important. But, as programmers continue to deny this and produce poorly written and bloated/slow apps or use inefficient languages, the time will come when a 6Ghz processor is not enough. Doesn't that sound stupid?
If there was money to be made by making that WeatherThing or UltimateMP3 player fast and efficient - companies would do that. There's plenty of programmers out there capable of writing in or learning more low level languages - of optimizing each loop or branch. The problem is that people are not willing to pay all of the extra associated with the development and testing of software written with risky optimizations (optimizations tend to complicate and obfuscate code, reduce abstraction, etc) in unsafe languages.
The truth is the consumer would rather spend an extra $100 to get enough RAM then spend $10 per program on their PC (that adds up faster) for the programmers to program it "correctly." It's not economically efficient, at least not in the eyes of the consumers.
Why do you think so many kitchen appliances last only a year or two nowaways? Or current VCRs which almost qualify as "disposable." People are rarely willing to pay extra when they think the low cost option is "good enough." In some ways this is what killed the Mac - it was better according to many metrics, but PCs were "good enough" for the average consumer, and the price difference wasn't justifyable.
A computer is a tool to get work done, nothing more. If people valued security, reliability, and efficiency enough, most software would be secure, reliable and efficeint. But people value features and low price, so that's what the market gives them.
Look on the bright side - at least compilers are getting better.
Ok, the test description says that its task is to show the performance of recursion. But then they have to find a task where recursion is an merit - not a flaw.
Can you establish that more fully? How is testing say, a recursive-descent parser, going to be a more valid test of recursion than a recursive solution for fibonacci numbers?
Fibonacci is convenient because you get lots of recursive calls while only hitting the stack, and no integer overflow. If you were to use a recursive parser and python ended up slower than the others, you could easily blame it on the non-recursive work you were doing. The fibonacci example allows you to accurately describe the recursive performance without all that other stuff getting in the way.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
How about encryption and security, SOAP, ORB, web services, directory services, messaging services? You know, all those things that distinguish large enterprise applications from normal business applications.
I do suppose if your definition of a good enterprise language is one with all such libraries included, then Python isn't a very good enterprise language. Of course, one could argue that the benefits of Python outweigh the disadvantages at having to download extra packages to handle SOAP, ORB etc.
The difference between Java and Python is similar to the difference between C# and Visual Basic.
I'm a little confused. Are you saying that Python is inferior to Java because Java comes with library X included, whilst with Python library X has to be downloaded separately?
Python is slower than Java and higher level than Java, but beyond that I can't say that there's too much separating Java and Python as languages. Personally, I find programming in Python more efficient, despite having more years experience with Java, but that may be just me.
The profusion of library modules with overlapping functionality is a real concern. The confusion over a standard window system (wxPython, Tk, ...) is actually just another example of that.
The sys/os split, logical as it may seem to the experienced Python programmer, also confuses Python newbies, as does the fact that string needs to be imported and that re is yet another separate module.
I think Python would do well with a major library cleanup, removing rarely used and duplicated functionality, and improving the quality of the library code that is there.
Furthermore, I think it would help for common string, I/O, OS, and regular expression functionality to be importable either via a single import statement (without name conflicts), or to be simply present in the default namespace.
If I read another comment talking about the fucking lack of braces I'm going to punch the monitor... Why are people giving that so much weight instead of discussing the features of the languages instead?
And who cares about the programmers discussing brace placing styles? They'll surely find other things to discuss about with Python...
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
Another poster already made a clarification on this. I didn't "mis-speak" I was just a bit obscure with my meaning. Point being, if you code in C/C++ you'll spend a lot of time making the program work correctly. If you write in eg Java or Python you can get the program working correctly in a fraction of the time. This means you can add polish or move on to new stuff.
Point being, you are more productive in other languages as you don't have to mess with the details so much.
First off, I'm willing to bet that virtually none of the little apps you currently have running are written in Java/Python whatnot. A sloppy coder can leak memeory in any language. (In fact I'd say it's a lot easier to leak memory in a language without a GC.) So moving to C/C++ doesn't really fix the memory issue.
That they consume enourmous amounts of CPU is also not really true. Those processes I have running on my machine all go in at 0% CPU time. If you add them together they might reach a few percent. Not really something which will stop you from typing in Word.
The fix for this "problem" is to get an OS with a descent scheduler so you can prioritise processes properly. That way your real-time applications won't suffer because your little application wants to check for new mail.
No, bragging to your friends that you can get 180 FPS in Doom3 is important. Very few people actually need a 3GHz 64-bit CPU with 2GB memory, I have one and I sure as hell don't need it.
And while code has become more bloated and unoptimised by the years a lot of that is because today a computer can do quite a hell of a lot more than say 10 years ago. Is all of that necessary stuff? Hell no! Is it more fun? Hell yes!
Finally there is one specific area of consumer software that actually demands better computers. That is games. Interestingly enough that area also have many of the best coders.
Clearly everyone missed my point, so I'll clarify.
I was using an example from the real world to point out why 3 seconds matters. In any significant application there will be some processes that are sufficiently complicated that the choice of algorithm or choice of language will lead to a 3 second delta one way or another. There will also be places where adding a UI shortcut will save 3 seconds.
The real world example talks about UI shortcuts that can save those 3 seconds, and Python makes it easier (according to the common wisdom) to add features. Other languages are more performance centric, and make it easy to save those 3 seconds in operation intensive sections of the code.
I wasn't arguing that Python is bad because it's not as performant. I was saying that both CPU performance and UI friendliness are important, so choosing between Python, Ruby, C#, Java, C++, C or any other language on the spectrum is a question of weighing values.
Ferfucksake people, stop trying to be argumentative and start trying to understand what people are saying. We all claim to be so smart, is our only ability with our intelligence to pick nits? Or can we use our intelligence to seek mutual understanding?
I mean, I can see why the media is turning into a bunch of ranting extremists - they're just a mirror reflecting our own horrible image.
Feh.
Stop-Prism.org: Opt Out of Surveillance
- Older
- More mature: used by a wider variety of people for a wider variety of tasks, community process more developed
- Unicode
- Syntactically simpler; less punctuation
- There Should Only Be One (Best) Way To Do It (not always succeding -- but at least we try)
- Less opportunity to globally effect the language/process -- e.g., you can't change the behavior of strings throughout the system
- Larger community
- More libraries and software
- Better OS support -- standard on most Linuxes, Mac OS X
- Some corporate support (e.g., IronPython); EU funding
- Distributing Python apps fairly easy. Large-scale distributions have been successful (e.g., BitTorrent, iPodder)
- OS-level threading (I don't believe Ruby has this, though I think they are trying to add it)
Well, those are the ones I can think of now.