Python Moving into the Enterprise 818
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!"
Which Enterpise (Score:4, Funny)
Python on the NX-01 (Score:3, Funny)
Jython? (Score:4, Interesting)
Re:Jython? (Score:5, Insightful)
Re:Jython? (Score:5, Informative)
It's the output of Java programmers that turns my stomach.
Re:Jython? (Score:5, Insightful)
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.
Re:Too bad... (Score:5, Insightful)
I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it.
Re:Too bad... (Score:3, Informative)
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 vario
Re:Too bad... (Score:3, Insightful)
When I code for fun I seldom do that in C/C++ anymore. At least not I know that the application won't need "that extra juice". What's the point in spending several times the develeopment effort on making it work properly instead of
Re:Too bad... (Score:5, Insightful)
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?
Re:Too bad... (Score:4, Insightful)
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.
Re:Too bad... (Score:3, Insightful)
The logical extreme of the "all apps must be as fast as possible" argument is to code in ASM. I suggest that anybody who pushes this argument write every app in ASM. See how long it takes before this person gets fired for inefficiency...
Why are some coders hesitant to "use the right tool for the job"? ASM might be necessary if you're optimizing a crypto or compression loop, while C or C++ might be more appropriate for the
Re:Too bad... (Score:5, Insightful)
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.
Re:Too bad... (Score:3, Interesting)
One of the very important featur
Re:Too bad... (Score:3, Insightful)
You are right though that a mix of high level and low level languages tends to give the best result in the lowest amount of time. What has shocked me is that from
Re:Too bad... (Score:3, Insightful)
You meet the demands of the project/customer. I'm not really arguing with you, but this is sort of the point of a thread about Python. It's a tool that helps balance this process for the developer - this in turn should result in benefits to the enduser.
It is nice to have a perfect balance, but efficiency is relative and (developer) resources are finite. Always.
Re:Too bad... (Score:3, Informative)
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
Re:Too bad... (Score:3, Insightful)
I program in C every day and I haven't coded an error of the type you describe in over a year. I would know if I had -- our C memory manager catches all manner of pointer problems, accounts for all memory allocation and freeing, memory over- and under-runs, gives us stats on mem
Finding a good general purpose language is hard! (Score:3, Interesting)
The problem is that actually, it hasn't, although it surely should have been a long, long time ago. Alas, the bulk of the software development industry is so driven by marketing hype and buzzwords that it has collectively failed to develop a new language that is a serious choice as a general purpose programming language spann
Re:Finding a good general purpose language is hard (Score:3, Insightful)
I'm also extremely unconvinced that any of the languages you mention have less "reasoned design decisions" than C++. The advant
Re:Finding a good general purpose language is hard (Score:3, Insightful)
It all depends on your application domain. For applications that are predominantly UI/database driven, as obviously many are, C++ has few advantages over something like Java. However, in anything scientific (where performance is often paramount) or in huge markets like embedded or instrument-control applications (where tight code and/or low-level contr
Re:Too bad... (Score:4, Insightful)
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.
Advantages? (Score:4, Interesting)
Besides... wasn't Star Trek cancelled?
Re:Advantages? (Score:2, Interesting)
Re:Advantages? (Score:3, Insightful)
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 the
Re:Advantages? (Score:4, Informative)
Foundations of Python Network Programming [amazon.com].
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.
Re:Advantages? (Score:3, Interesting)
Yes, it's a little bit of a learning courve, but (and I did all of them for a living) it be beats Java/Tomcat/Struts and PHP hands down in productivity/maintainability once you get a grip on it.
Re:Advantages? (Score:5, Informative)
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.
Re:Advantages? (Score:2, Insightful)
If you take out comments, which one is more easier to read?
I have nothing personal against Python, actually I can say that I am a fan of python, but let's use a right tool for a right job.
Re:Advantages? (Score:5, Insightful)
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 [bea.com] where appropriate, even in commercial products...
How not to win the corporate mind. (Score:4, Insightful)
For good measure, let's look at the documentation from a J2EE vendor here [bea.com].
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.
Re:Advantages? (Score:5, Insightful)
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.
Re:Advantages? (Score:3, Insightful)
What a silly picture.
Re:Advantages? (Score:5, Informative)
Re:Advantages? (Score:4, Insightful)
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.
Re:Advantages? (Score:4, Interesting)
I program a lot. In the course of my job, I have to review a lot of other people's code. I have a particular bracing style I use; and sure enough, I've not only become accustomed to it but also "tuned" to it to the point where it becomes difficult to read someone else's code if (for instance) they use the "K&R" style:
Because at my company, code looks like this:
Those two styles lead to a considerable difference in code density, and so affect readability and my "tuned" response to what I see. And there are so many other C/Java coding styles re bracing and indentation, or lack thereof.
In Python, there is one indentation style. Just one. Not bunches of them. So I get used to the way Python looks, the "tuning" goes into my backbrain or wherever the heck that stuff lives, and I can read anyone's code. This is a distinct benefit for me, and I suspect for others as well.
I would have loved a C compiler that didn't use braces, but used indentation instead. Man, that would have been glorious. Sigh.
Re:Advantages? (Score:5, Informative)
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.
Good: (Score:5, Funny)
No such thing (Score:5, Funny)
Dude, programming for the enterprise without the pain is like the Passion of the Christ without the crucifiction... It's Impossible.
In that case, Perl should fit perfectly.
Re:No such thing (Score:3, Funny)
- The Dread Programmer Roberts.
python performance (Score:4, Interesting)
Re:python performance (Score:5, Insightful)
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
Re:python performance (Score:5, Interesting)
Actually I tweaked around with the code - but the rule of the game are just wrong. Just look at the fibonacci test. It requires you to do the stuff completely recursively - thats one of the rules. So you not only generate a huge return stack, you also calculate all the fibonacci numbers far too often. This is just braindead. A good requirement would say: "Calculate the nth fibonacci number". A simple solution would be to start from the beginning and not recursively calulate every fibonacci number bazillion times.
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. Otherwise you could claim your language is best because it has the best performing idle loops [slashdot.org]
Re:python performance (Score:3, Informative)
But I do understand your point. Different languages have different ways of doing things. The most efficient algorith in C, for instance, may not directly translate to the most efficient algorithm in Python.
Re:python performance (Score:5, Insightful)
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.
Re:python performance (Score:5, Insightful)
Re:python performance (Score:4, Insightful)
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.
Re:python performance (Score:3, Insightful)
People are expensive.
Writing in powerful languages like Python makes your people more effective. And most enterprise apps are not CPU limited anyway.
Re:python performance (Score:3, Interesting)
Say what? You must be living in a very different world than I. If it's an enterprise app, then it has a few thousand internal users. Multiply a few seconds by a few thousand people by a few times an hour by a few dollars per hour. Performance matters. Middle of last year my company pulled two people off their primary project to add a feature that saved our primary users two mouse clicks. Those 4,000 users now save 3 seconds, 10 times an hour, 8 hours a d
Re:python performance (Score:3, Funny)
Did a consultant compute that number? [tripod.com]
Re:python performance (Score:5, Insightful)
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.
Re:python performance (Score:5, Informative)
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++.
Re:python performance (Score:5, Interesting)
If you want a language that's consistently unsurprising and surprisingly efficient, then try ruby. Performance is not a dream, but that's what compiled languages are for. It lacks most of python's inconsistencies and is really quite pleasant to work with. in ruby there are two sort methods, sort and sort!. One does it in place and one returns a new list. (the ! suffix for mutation and ? suffix for predicates is a gem. I'm pretty sure it was stolen from scheme. It really, really helps make your code clearer)
I still find python more practical for large projects, though, because of the large library and potential for rapid development. I generally use python (possibly with C underpinnings) for larger apps and ruby (with its perl heritage) for scripting. Blocks are the greates when you're dealing with ssh sessions, opening and closing files/database connections, etc. As for per,l I've generally avoided after a few bad experiences trying to decipher six month old code. I really don't think it has a place when ruby has most of its features and enough of it's syntax along with the slickest object system around short of smalltalk.
seriously mistaken information. try is 24x slower (Score:3, Interesting)
I benched the two pieces of code: (note the slashdot ecode tag removes the proper indentation, but this should be obvious in context)
and then using your suggestion:
timing these shows the try
Microsoft's involved? (Score:3, Insightful)
Re:Microsoft's involved? (Score:3, Interesting)
Did anyone else think... (Score:4, Funny)
Re:Did anyone else think... (Score:3, Funny)
Re:Did anyone else think... (Score:3, Funny)
"I wish to complain about this tribble what I purchased not half an hour ago from this very boutique." ...
Toolsets (Score:5, Informative)
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
Re:Toolsets (Score:3, Insightful)
Re:Toolsets (Score:5, Informative)
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.
Actually, Guido von Rossum (the Creator of Python) is working on optional declaration of variables for a future version of Python. Although some Pythonistas are annoyed, it may give folks like you, Kevin, the best of both worlds. There is discussion on comp.lang.python about this from time to time, but it certainly appears as though Guido may take action soon;-))).
Ron Stephens
Python Learning Foundation
http://www.awaretek.com/plf.html [awaretek.com]
Re:Purpose of dynamic types? (Score:5, Informative)
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.
sigh... how about a real opinion? (Score:5, Insightful)
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.
A quick check on Dice.com (Score:3, Interesting)
Re:A quick check on Dice.com (Score:5, Insightful)
Re:A quick check on Dice.com (Score:3, Interesting)
You can repeat the same ol' tired mantra, over and over, it doesn't make it true.
And I'll even make the logical case showing how it is a *
Re:A quick check on Dice.com (Score:3, Interesting)
if you had checked for python jobs just 2 years ago i would be amazed if you could find any
(mono is not an option right now).
Python is able to run on all of these syst
Yes, but what about the GUI - speed no problem (Score:5, Insightful)
Re:Yes, but what about the GUI - speed no problem (Score:5, Insightful)
But overall, I completely agree: the std python distro needs to standardize on wx, get rid of Tk and at least incorporate the win32all distribution in the win32 version (it just too nice to leave out).
My biggest peeve as a long-time pythonista (the newsbot in my sig is 25k+ LOC of pure Python) is the standard library: I can live w/o a CPAN-like repository (although that would rock), but for a language that used to boast that it comes "with batteries included" the std lib has gone downhill in the last few versions: too many overlapping or competing modules (why, why do we need httplib, httplib2 and urllib?? or getopt and optparse? and what are the differences between them?) and not enough attention into polishing the library into the fantastic toolkit that was around the 1.5 or early 2.1 series.
Someone, probably the BDFL, needs to stand up and take obsolete modules *out* of the standard library, so that the better ones can be improved even more, instead of having various tweaks and improvements going into overlapping modules. That's the point of having a *standard* library after all...
I'd rather have a good std lib than function decorators and other exotic language constructs...
agreed--cleanup needed (Score:4, Insightful)
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.
Re:Yes, but what about the GUI - speed no problem (Score:3, Insightful)
Three barriers to enterprise Python (Score:5, Insightful)
Many programmers, including top ones like Eric Raymond http://www.linuxjournal.com/article/3882 [linuxjournal.com], 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.
Re:Three barriers to enterprise Python (Score:3, Insightful)
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
Re:Three barriers to enterprise Python (Score:3, Informative)
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 w
Re:Received wisdom (Score:3, Informative)
Re:Whoa, this is all crazyness. (Score:3, Insightful)
Though the error may be clear and obvious, knowing it the first time the code runs can be too late. I've wrote code that can only run a few weeks every year (no
Re:Whoa, this is all crazyness. (Score:3, Insightful)
You'll be able to write the code in Python, and the tests, in less time than most statically typed languages. Many would argue that you can write code and tests in any language faster than writing WORKING code without tests... but that starts down a different avenue of discussion.
We will start to see alot more of it.. (Score:5, Insightful)
It is a great language we use it for everything, web services, linux / win integration, nt services, automation etc.
Only a few tweaks needed (Score:3, Interesting)
Then the newer pythons allow you to import from a zip. That needs polish, there should be a standard way to package a whole app in a zip (just to make it harder to screw up the file distribution. Having a single unit that contains all the needed code is a huge positive; it's just that much harder to screw stuff up.
Then there are people working on compiler speed, really it isn't as bad as you might think from some of the benchmarks. It can use some improvment though and people are working on it.
Why is whitespace significance a good thing? (Score:5, Insightful)
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?
Re:Why is whitespace significance a good thing? (Score:3, Insightful)
As opposed to:
The question is not so much why one should have a language with whitespace significance, but why one should not. Since the vast majority of well-written programs use whitespacing in this manner already, it makes some sense to do away with braces and semi-colons when they're not really needed.
Re:Why is whitespace significance a good thing? (Score:5, Informative)
Whitespace (or more specifically, indentation) significance forces you to make the visual structure of your code match its semantic structure.
Re:Why is whitespace significance a good thing? (Score:3, Insightful)
Java / Python / Ruby (Score:5, Funny)
:-)
(found many places online...)
The trouble with parrots (Score:3, Funny)
Dr. McCoy - - Captain, I wish to register a complaint... Hello? Miss?
Capt. Kirk - - What do you mean, miss?
Dr. McCoy - - Sorry Captain, I have a cold. I wish to make a complaint.
Capt. Kirk - - Not now Bones, we're closing for launch.
Dr. McCoy - - Never mind that, I wish to make a complaint about this tribble that I purchased not half an hour ago from this very bridge.
Capt. Kirk - - Oh yes, the Bajoran Blue. What's wrong with it?
Dr. McCoy - - I'll tell you what's wrong with it. It's dead, Jim, that's what wrong with it.
Python still has severe limits (Score:3, Interesting)
I'm a big fan of Python. I used it almost exclusively before taking my current job. But let's be honest, Python and Java just aren't intended for the same type of applications.
Python's standard library just doesn't have the breadth of Java's. For small apps, the CPython VM is lighter than Sun's JVM, but CPython's VM is lacking several capabilities that I'd consider pretty essential -- chief among them is the ability to return unused memory back to the OS [evanjones.ca]. And for many tasks, CPython is still effectively single-threaded due to its global interpreter lock [python.org]. Java has never suffered from either of these problems. These aren't trivial issues or the result of nitpicking -- they're rather severe limits (which make me seriously question the suitably of Python for enterprise apps, eg. Zope). Of course, once CPython does get decent threading, it's likely that it's GC subsystem will need to be totally rewritten. I apologize if it sounds like I'm beating up on Python. That's not my intent here. I love Python, and I only wish I could stop more people from using Perl :)
In fairness, it does look like the Python community is trying to address some of these problems. I just read a paper presented last week at PyCon 2005 [python.org] on CPython's memory management. The author is developing some patches to let CPython return unused memory to the OS [python.org] for most object types (except for Number, List and Dictionary). The memory manager still can't defragment its heap, so this isn't a perfect solution. As of a few weeks ago [python.org] it looks like these patches haven't yet been accepted.
Re:Python still has severe limits (Score:3, Insightful)
The memory is only available to other programs after the program exits.
As a result of this, most daemons will re-exec themselves to free up memory for the rest of the system.
At least, that's what I've always heard. Maybe newer versions of the linux kernel are much smarter...
Kill the GIL (Global Interpreter Lock) (Score:5, Interesting)
You see Python has quite good support for threads, but there are a number of operations in the interpreter that are hacked into being thread safe by providing a global lock on the whole interpreter. One of them is reference counts on objects. So everytime I do an assignment, I have to queue for the GIL. This effectively means that I only really run one thread at a time, even if I have multiple CPUs in the box (or soon, multiple cores).
As more and more applications start shifting to multicpu (or multicore boxes) this problem becomes a much more noticable issue.
Kill the GIL.
Available libraries (Score:3, Insightful)
Its main two faults in my mind are:
1. Speed (but this is being worked on, see the Parrot JIT compiler)
2. Memory usage. wxPython especially is an excellent toolkit but a memory HOG.
As far as Java goes, I don't particularly like Java all that much, but one area where it has a definite advantage over Python at the moment is libraries. Not just the standard library, but what add-on libraries are available. Python has a lot, but Java has pretty much everything and the kitchen sink.
For example, I recently worked on a project that needed to display and manipulate SVG graphics. The two requirements are that it be cross-platform, and be done quickly (in just a couple weeks). I originally wanted to use Python but was unable to find a cross-platform SVG rendering library for Python. I came across the Apache Batik [apache.org] toolkit for Java and found that it was exactly what I needed.
Batik is pretty sweet -- you get a swing component that you can plop into an app in about 10 lines of code and boom -- you have one of the most compliant SVG renderers that I've seen to date. Plus it even gives you a DOM interface that will update the graphical view in real-time. As much as I dislike Java in general (even more bloated than Python
Re:before RTFA (Score:2)
Support (Score:2)
Re:Python *is* painful (Score:5, Insightful)
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
Re:Python *is* painful (Score:5, Insightful)
And who cares about the programmers discussing brace placing styles? They'll surely find other things to discuss about with Python...
Re:Python *is* painful (Score:3, Informative)
Whitespace [dur.ac.uk]
Re:Toenails (Score:4, Insightful)
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.
Re:Toenails (Score:4, Insightful)
- 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.Re:Better Python-GIS example (Score:3, Informative)
I meant OpenEV on sourceforge.net [sourceforge.net]
Re:Great... but PLEASE allow 'implicit none'! (Score:3, Insightful)
Re:Perl is run by a Christian. (Score:3, Insightful)
why? why does that matter? why should i care whether Alan Turing was gay? why does it matter what religion or faith Larry Wall may or may not follow?