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!"
TOS or TNG?
Aren't some of them using Jython, which is really just Python on top of Java anyway.
gay nigger association of america's prefered enterprise development language is python. http://www.internet-terrori.st/
....Oh you mean Trek?
Enterprise NOT The Enterprise
Im not a coder my self, altough I hahe programmed in Java and in python, but I fail to see Python's advantages comparing to Java in an enterprise environment.
Besides... wasn't Star Trek cancelled?
Why don't you go have more sex with Roland Piquepaille?
Maybe it'll eat Archer's stupid little dog.
$6.21 is the number of the beast before sales tax. Meh.
"Will we finally be able to code for living in a language that's not painful?"
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.
Python is a nice language, but it's excruciatingly slow. It's below Tcl on The Computer Language Shootout, which is telling.
I don't know whether to be happy or afraid.
...Monty Python was merging with Enterprise? Now there's a show I'd like to see... :)
I had a mental image of a new member of starfleet with an odd name..
. ,it is easy to learn and has a massive collection of librarys for many difrent things , infact i am suprised it has not happend sooner .
However seeing python moving into the enterprise market would be grand
Python has really come on in strides in the past few years
The only things certain in war are Propaganda and Death. You can never be sure which is which though
and Cameron Laird is an unabashed Python booster who's been writing the same booster prose for years. You're actually arguing Python is ready for the enterprise because Cameron Laird went to a Python conference full of Python boosters and saw they were just like him?
Timothy, you may want to check out the definition of "echo chamber."
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!
Sorry guys; April Fools' was two days ago.
Donald Ferrone, Ph.D
Professor of computer science
http://www.geocities.com/donald_ferrone/
Star date 3042005 , we have recently encounter a strange spacial disturbance , The computers logs seem alterd and for some odd reason the Starfleet logo on the lcars monitors is replaced by a cartoon snake . Voice commands have been replaced with typing #! /usr/bin/env python
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.
no matter what cool features it has nothing is going to make me want to code in a language where you have to bung the self reference into the signature of class methods.
php is annoying enough with $this-> accesses to everything
can't somebody spend a bit more time on the basics?
Python has a reputation for being quick to program in. If you just speak basic python, you can program the same stuff you could in qbasic. It is very comparable to Visual Basic at that level. I find it very good for quick-and-dirty stuff.
The difference from the simpler languages is that it can do very difficult things. Once you get used to some of its unique features (I remember how thrilled I was to discover dictionaries) you can put serious applications together a lot faster than with other languages.
The bottom line is that you can do serious applications a lot faster than you can with other languages. In a business environment, that translates to profit.
p.s. "Integrated development environments (IDEs) are also more numerous than polished." Yep, I use emacs.
Marketing and support , Python is in dire need of some big name support , This is one of the primary reason Java became such a large player in the enterprise market .
The only things certain in war are Propaganda and Death. You can never be sure which is which though
I know that Java is used to push realtime market/financial data to a possible countless number of hosts. One only has to visit http://www.refcofx.com/FinanceChart.html?symbol=EU R/USD to see java in action, (assuming the java runtime is installed). Can one use Python to do the same? Where would it play its role? The backend or on client machines?
for Python jobs. It returned 312 jobs. Java returned 9196. I don't think Python will ever dent Java's dominance in the enterprise. Do you really expect Python to do what .NET has failed to do? Not a chance. It is a cute scripting language. No more and no less. Python competes with Perl and Ruby.
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
It seems Google is using Python for a good deal of stuff... And I thought google was enteprise
Assembling etherkillers for fun an profit
Happy. It's open, and could be a sign that MS is actually "getting it".
I wonder if anyone said that when they introduced IE.
Who in the 90's writes a language where whitespace has meaning???
11*43+456^2
...then why is it found in nearly every Linux distribution? ...and why is there ActivePython? BTW, I've used this with "classic ASP" and, not unlike JScript, it makes it almost a tolerable environment to use it in.
List comprehensions rule.
Il n'y a pas de Planet B.
Not that I think Java is the ideal example of a modern programming language (far from it), but this trend towards 'lean' scripting languages where almost every bit of rubbish you can write is executable, and every bit of code you look back at (even your own code two days later) looks like rubbish is really troubling.
Is it just because there are more and more people writing code who've never had to work on maintaing large-scale software?
in the hallway... Well past 50... unliked, unloved, unsettling. A huge pain in the ass to everyone he's ever met. Right now all his considerable talent and strength is totally focused on seducing a tiny dog into the elevator door he holds open.
MELVIN UDALL
Come here, sweetheart... come on.
ON DOG
Sniffing at a particular spot on the hall carpeting. Melvin lets the elevator door close and advances on the mutt who has ignores him.
MELVIN UDALL
Wanna go for a ride? Okay,sweetie?
The dog lifts his leg at the precise moment Melvin lunges and picks him up with a decisive heft -- so that dog urine squirts the hall wall for a second or two. The DOG sensing a kindred spirit starts to GROWL and BARK.
MELVIN UDALL (a malevolent tone)
You've pissed your last floor, you dog-eared monkey.
The dog takes a snap at Melvin, but the man is much meaner and quicker than the dog -- he holds his snout shut with his hand and reaches for the door of the garbage chute.
MELVIN UDALL
I'll bet you wish you were some sort of real dog now, huh? Don't worry... this is New York. If you can make it here, you can make it anywhere, you know? You ugly, smelly fuck.
And with that, he stuffs him in the garbage chute and lets go. We hear a FADING SERIES of PLEADING "ANOOOOS" from the DOG fade to nothingness..
had you used something other than a 6sided die your results would be different.
Besides Python is evil, why would i use that which poisoned eden.
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.
it's still slower than molasses flowing uphill on a cold day.
.NET/MONO, Perl is the fastest. But, it's still slow when compared to a compiled language like C or C++.
Let's face facts. I don't care who you are, what you think or what emotional attachment you have to Java, all interpreted or VM based languages are SLOW!!!!
I would say that out of all of them, including
Now don't get me wrong, these "scripting" languages do have their place. Rapid Application Development(RAD) is one of their biggest advantages. But, RAD should be for prototyping and testing. It shouldn't be used for the final product. Use Python or Java or whatever you prefer to develop the prototype but, once you've fleshed out all the ideas, for God's sake, rewrite the application in a real language.
"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!
I'm glad to hear it. Python is amazing, and I'd like to see it get the credit it deserves. Whenever I do a big project in it, I'd say I spend about %3 of the time I spend with other languages debugging. About half of that is time spent telling people about how much I love python, because I'm always blown away when every drastically complex feature I implement works perfectly on the first shot. Regarding speed, I've never checked them out, but I'm told there are several ways to dramatically optimize normal python code. Psyco, for instance.
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?
Is it possible to use Python with Mac OS X's developer tools and build GUI applications?
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.
C is faster then Python?
Lets see a performance of data-entry GUI apps for a PostgreSQL database, and in addition you need to export queries over a VPN to a MySQL database used in the backend on a clients website.
Oh, and it has to be cross platform.
Person A gets to use C or C++
Person B gets to use Python
They both are equaly experianced programmers.
Lets see who gets it done faster and who is more likely to have bugs and other issues!
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.
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 --
I remember when I first heard of Python back in grad school. I wondered what would become of it, but didn't have time to deal with it at the time, after all FORTRAN was teh cool, right? Lately, since I started using Zope, which is written in Python, and more recently Plone, which is built on Zope, I've really gained a great appreciation for Python because it really has made building sophisticated logic for web apps a lot easier than some alternatives. Now admittedly, I did not choose any of these because I heard they were easy or even cool, I stumbled into Zope because of an app, OIO, that I thought I could build on for another project. Later I heard about Plone and decided that I could build an easier to use portal for clinical investigators using that rather than PHP based solutions like PHP-Nuke. Python was just the icing on the cake as I discovered how much I could do with it.
To the making of books there is no end, so let's get started
Call me when Python has CPAN's 7848 modules. Then we can talk about "productivity".
-- Given enough time and money, Microsoft will eventualy invent UNIX.
Set phasers for stun.
The toad can't burp - and for some reason can't fart either, so it swells up and eventually explodes. --Anonymous Coward
I mean "J2EE" is a good name, but the Python equivilent "PEE", is missing something.
For some strange reason, I, suddenly, have to use the bathroom...
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
Obligatory PC Weenies webcomic about one Python developer's personal struggle...
:-)
(found many places online...)
(I write this under assumption that Fibonacci numbers can be more easily calculated without recursion, although I am not sure if I am right.)
No sig today.
Typical Example Mr. Golfplayer. Found a great little OSS application, needs compiling, uses Perl, running make, opps need to use CPAN, "Oh crap, company firewall blocks FTP", "No problem, I'll download the packages one at a time.", followed by individual downloads, packages added only to find out a package requires another package!
Bzzzt! Wrong!
Interdependencies of packages on CPAN are a clusterfuck. Are you smoking crack Kevin? You might be a coder but all the hack work is paid for by us compilers.
You tell me to make a backup of CPAN or what? You can't call these packages easily, it's crap work you have to make a offline mirror of CPAN. No. No. No. CPAN is the plague. You customize your Perl env and build and start using non-standard hack libs just because you can and you quote CPAN!
Python might not have so many libraries OR a so-called package repository but the standard libraries accomplish as much as the fancy CPAN calling Perl code.
The example could be written in Java as:
public class Hello
{
public String myName="Monty";
public static void main(String[] args)
{
System.out.println("Hello " + myName);
}
}
Which is just as short, if not shorter (depending on how you measure length) as the Python example.
The joke, to my mind, is not on Java, but on Java developers' tendency to overengineer everything in sight. Once you move these people over to Python, you'll be seeing the same joke with Python on the right side and Ruby or Groovy on the left.
People in the "scripting" lanuage camp by contrast have more of a "just make it work" attitude. To my mind, neither of these attitudes is perfect. Getting this right involves experience and judgement -- you have to look at the big picture. The kind of person who can be consistently successful using scripting (or "dynamically typed" ) technology is likely to be quite capable of having the same success with Java, and vice versa.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Typical Example Mr. Golfplayer. Found a great little OSS application, needs compiling, uses Perl, running make, opps need to use CPAN, "Oh crap, company firewall blocks FTP", "No problem, I'll download the packages one at a time.", followed by individual downloads, packages added only to find out a package requires another package!
Bzzzt! Wrong!
Interdependencies of packages on CPAN are a clusterfuck. All the hack work is paid for by us compilers.
You tell me to make a backup of CPAN or what? You can't call these packages easily, it's crap work you have to make a offline mirror of CPAN. No. No. No. CPAN is the plague. You customize your Perl env and build and start using non-standard hack libs just because you can and you quote CPAN!
Python might not have so many libraries OR a so-called package repository but the standard libraries accomplish as much as the fancy CPAN calling Perl code.
As you say, Java's type system is often worse than managing the typing for yourself (dynamic typing), but that's hardly a reason to move to a dynamically-typed language - a good type system can manage your types better than you can, so if you're going to switch languages over typing, you need to future-proof your investment by moving to something that does it well.
Surely you don't still believe that garbage collection is inferior to the DIY approach, just because the first mainstream implementations had drawbacks in comparison to C's DIY approach to memory management? So don't make the same mistake with type management.
Would anyone recommend Python in an embedded environment, like say embedded Linux on a Virtex 4 with dual hard-core PPC processors running at 350MHz? Would anything but C/C++ be fast enough for this kind of environment?
I'm inclined to think that the embedded world is still very much dependent on the old workhorses C and C++, but I could be wrong.
Ever hear of the Crimson Permanent Assurance?
"I just run it through Emacs' indent-region."
Why would you want to reformat code every time you check it out? And what about checking it back in? That only work if you're completely taking over a project, or mandating a particular style. Keep in mind that the fact that you're familiar with this issue indicates that there is a problem in your language. Someone who only ever learned python would not be familiar with this "different style" issue at all - it doesn't exist in python.
"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?"
It's not just a policy. It's an enforced policy - meaning code doesn't work correctly if it's not formatted correctly. That may sound like big restraints to a programmer, but haven't you ever tried to follow someone elses coding style? It's not the end of the world. The biggest arguements I've seen in C are when one guy puts { on a new line and someone else puts it at the end of a conditional or for(){. Or when someone indents 2 spaces for { and then another 2 spaces for the code (I hate that). In python these worst case differences of opinion can not happen because they are arguements over the placement of extra characters that don't exist in python syntax. We all indent the code anyway - in fact python doesn't care how far you indent, just that you do. Therefore, Pythons enfoced indentation style is not IMO objectionable, and you don't need to type the extra characters (and {} each require the shift key). That may seem lazy, but so is an unwillingness to use a defined indentation style.
Just commit to doing some of the tutorials and writting a simple application with it (or any language) before you pass judgement. That's all I can really say. If you still don't like it after actually using it, at least you'll have a proper feel for what it's like and why people may like it.
You're not talking about python there. Python is the most readable language I've ever used. I suspect you have't used it.
So, instead of Java we could use perl, pyton, php (remember that?) .net and I am sure someone will come up with many more.
They all are simple, fast, exciting, new, wonderful... etc.
I am beginning to think that this is a plot of Microsoft to dilute the only alternative to .net (.net is a clone of java, but of course -SARCASM- much better, faster, newer, more portable etc. -/SARCASM- )
It was Caesar that used the method to conquer an empire, and it did work.
"Mind your own business, Mr. Spock. Your mother was a hamster and your father smelt of elderberries!"
"You don't frighten us, Starfleet pig-dogs!"
There are two kinds of people: 1) those who start arrays with one and 1) those who start them with zero.
As someone who used to code for a living in python for enterprise, this can only be a good thing. This is one of the easiest languages you can learn, I picked it up in just a week and was more or less productive from that point onward.
The company I worked for used it for CAD/CAM software, which let code written in one language, python run on five platforms (windows, and a bunch of UNIX platforms). The ability of Python to call C libraries when speed was a must made it the perfect language for our uses. Given you really want speed in the CAD world, python still did the job admirably!
You still needed the C interfaces, but you could do all the logic and front ends in Python, which really reduced the amount of re-work when porting to new platforms without really sacrificing much speed at all. I'm glad more companies are seeing the use for Python and hopefully many will learn, like my last employer, that Python is good for more than just replacing Perl and shell scripts.
--Won't that be grand? Computers and the programs will start thinking and the people will stop. - Dr. Walter Gibbs
When some zealot starts pushing Python that's the first thing that they'll also defend. Much like when some zealot starts pushing Macs and the one button mouse is the first thing they'll defend.
It doesn't matter if it's "right" or "wrong". Some people just don't like it. There are no absolute truths when it comes to people's preferences.
It reminds me of a joke I once heard regaing a guy who, after getting hard contact lenses fitted said, "It feels like a toenail is stuck in my eye", to which the optometrist responds, "Don't worry, you'll get used to it." He replied, "If I've got a toenail stuck in my eye I want it out, I don't want to get used to it."
All I can say is there already are a lot of block delimters already in use in Python, e.g.:That defines an associate array with a regular array as the value and a string as the key.
Python's statement's like if still require weird syntaxtic sugar (presumably for parsing):What's with the colons?
Instead of alienating people by spouting dogma and telling them their opinion is invalid and incorrect when critiquing Python's choice of how to handle statement block delcarations perhaps just once reflect on why so many people feel this way and just maybe ponder the possibility and wonder to yourself "Why can't there be block delimters or the use of whitespace? Wouldn't that make everyone happy and the world a better place to live?"
At least in Apple's favour, it may have taken them 20+ years to come around but at least they finally did. Perhaps there's some hope for Python too but maybe we'll have to wait until 2010.
large, monolithic, and inelegant.
:)
Zope is a reason there are so many python web frameworks today: people try Zope, think, "there has GOT to be a better way" and create a new framework.
What's Python like for coding GUI's in?
And are there any nice IDEs available for it?
My Journal
John Cleese? Eric Idle? Michael Palin? Terry Jones in drag? Or have they decided to drop the 3D CGI and replace all special effects with Gilliam's cutouts?
Java is dying!
Sorry, I just couldn't resist.
On a more serious note - good riddens. Java needs to die a quick and painless death. Unfortunately it'll be a slow and painful (especially for those that are forced to use it) death. Java is the one programming language I've used that I have truly *hated* working with. It's slow, bloated, and has no redeeming qualities to make up for it. It even failed at its goal of "write once, run anywhere" - I don't know how many Windows-only Java applications I've seen, and J2ME is a joke - look at any mobile gaming site and their J2ME games have a different file size for nearly every phone they support.
Unbelievably, despite Python being a scripting language (admittedly one that can be bytecode-compiled) and Java being bytecode-interpreted, my experience has been that every Python app I've used has been far more responsive and memory efficient than anything written in Java I've used. (Java AIM client and its 256M of memory usage anyone?) Add psyco (JIT compilation for Python, x86-only for now) and it's REALLY fast.
It's also pretty easy to interface native code to Python when you need the speed, even easier than using SWIG with Perl
retrorocket.o not found, launch anyway?
Does exist in Python. Guido, last I heard, believed firmly that tabs stops should always be 8 characters apart. Almost every other programmer likes 4 or 3, but some like 2 or even 1. Some have their editors set to use and save tabs, some have their editors set to get rid of all the worthless tab characters. You've got to enforce some kind of standard on a shop of multiple python programmers to make this work at all.
I've had very positive experiences with Python, and I'm glad that it is making its way into lots of large, serious projects. Problem is, though, that as these projects get very large, there HAS to be an option to disable implicit variables, e.g., variables that can be used without first being declared. Try working with an old Fortran 77 code that is full of implicit variable usage, and you'll understand!
Please, Python dev-team, hear our pleas!
Was that an intentional pun?
Excerpt from http://www.forum.nokia.com/main/0,,034-821,00.html
Python for Series 60 allows developers to execute Python commands and run Python scripts and applications in devices based on Series 60 Platform.
Python for Series 60 is capable of running applications that use native resources of Series 60 Platform and Symbian OS. It is well suited to the development of prototypes or for building proof of concept applications with a simple and consistent language. Python for Series 60 is an idea choice for starting to create application for devices based on Series 60 Platform.
Why don't you read this post: http://it.slashdot.org/comments.pl?sid=144795&cid= 12126400
Read the subject line....
Think Deeply.
I've done work simultaneously in Java and C# in the last 2 years, and there so similar as to not have any meaningful difference, as far as day to day coding goes. Every coder worth his salt is looking for the next good thing to learn, and for a lot of guys, it boils down to: C#, or something different? Anecdotally, 'something different', i.e. Python, seems to be more attractive. So what I've seen at two large employers in the Bay Area is that people spend a couple days playing with C# , conclude that it's enough like Java that there's no need to invest time in mastering it, and then after playing with Python, they decide Python is the new toy worth spending many evenings and weekends mastering. So I think we'll find in a few years there will be a lot of programmers who have deep Java expertise, and secondarily pretty good Python expertise.
Builded with the Default build of Python there IS a IDE but kinda ugly...
As corporate and enterprise-able products and that have support:
The Kompany makes one called Black Adder...(Never seen it.)
http://www.thekompany.com/products/blackadder/
ActiveState makes one called Komodo(pay) which can/is bundled with ActiveState Python(free). It is very nice and a free trial download!
http://www.activestate.com/Products/Komodo/?_x=1
"Will we finally be able to code for living in a language that's not painful? Exciting times!"" Yeah...I have been doing ti for years...I believe it is called C++. No language is painful once you master it....well except FORTRAN.
Spaces are for spacing, tabs are for indenting: 1 tab per level of indentation
Sorry for shouting, but the number of spaces *you* use to represent an indent in *your* editor SHOULD BE IRRELEVANT TO ME! The only reason it ever becomes an issue is when people who don't understand this decide to use spaces to indent their code. And if ever there was a language where this mattered, it's python.
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.
"If I've got a toenail stuck in my eye I want it out, I don't want to get used to it."
Uncontestably true, but it says nothing about having a hard contact in your eye, so it misses the point.
Whitespace-delimited blocks are not the reason to use Python. Dynamic typing is.
But even having said that, I've seen many cases where thirty minutes of practice gets rid of the problems people have with the whitespace. The problem is prejudice, not toenails.
Anyone else read the headline and think of that, hiding in the ship, eating the entire crew one by one?
Python isn't painful?
python is said to be strongly dynamicly typed. Sort of the worst of both really. The inconvenience of strong typing with the inabilty to syntax check caused by dynamic typing. this means run time errors out the wazoo.
Intentional typing is what perl does. The prefixes tell the compiler/interpreter what kind of thing to expect but not the type. @ means its an array but never mind the type of the content. $ means its a scalar primitive or scalar reference.
the result is the compiler can find syntax errors easily and its hard to so something you did not mean. For example, in python both of the follwoing compile:
A = d.lstrip()
A = d.lstrip
in the latter cas A becomes a function reference and in the former it becomes a string with the spaces removed from d.
Gaa! that's a syntax error waiting to bite, but python cant detect it since both are legal syntax.
Some drink at the fountain of knowledge. Others just gargle.
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. And for many tasks, CPython is still effectively single-threaded due to its global interpreter lock. 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 on CPython's memory management. The author is developing some patches to let CPython return unused memory to the OS 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 it looks like these patches haven't yet been accepted.
I once spent six months of my life trying to write a production-quality compiler for SML/NJ. I concluded that it couldn't be done. And sure enough, functional languages have not had a mainstream impact on enterprise computing.
I would contend that the static typing embedded in Java/C++ imposes an exogenous constraint on programming methodology that does not directly contribute to quality (defined as correctness + maintainability + large-team support).
I suspect that the same is true for type-inference engines. "Duck-typing," on the other hand, relies on the shocking intuition that proper typing is in fact almost automatic in a properly thought-out program.
In other words, the fact that the compiler/interpreter checks your types doesn't actually make your programs any better. This is the non-obvious insight that explains why Python and Ruby seem to be "magically" better to their proponents.
There's a much better example of the use of python in a GIS: OpenEV - its open-source, cross-platform, and has an open python API for writing extensions, including, using PyGTK, graphical dialogs and menus.
Its not as 'enterprise' as anything from ESRI is, but as an open platform for building custom solutions onto basic GIS functionality, I've not found anything better.
It will be a true pretty for many good programmer to overlook Python just because they the feel turn off by the whitespace syntax.
To appreciate the power of Python one should look beyond this trivial issue. How do you feel if your 50 lines Java program can be implemented in 10 lines Python code? What about the productivity gain you can archieve by using such agile and dynamic language? Once you used Python's high level data structure like list and map, Java's collection feel like a drag.
Whitespace is such a trivial issue, it never enter my consciousness after I used the language for 5 minutes. Turn your focus on truely significant aspect of a language, not this minor syntactic issue. Python has many more unconventional design that may shock you when you look deeper into it. And these unconventional ideas are what make Python a break through rather than yet another language. (Think XP)
Without goto a language is crippled. It is fairly easy to translate a Knuth algorithm into a language that has goto (C, BASIC, Perl, Common Lisp, Scheme (tail calls)). Translating into a language without goto sometimes requires enough changes that it isn't obviously the same algorithm.
If you are deciding between Python and Java, you obviously don't understand the question.
I read the headline and thought that is the one thing they needed to get Enterprise past season five, the Monty Python boys reprising the roles of the various enterprise crew. Nobody expects a federation inquisition!
I love python. It's by far my prefered language for development, but it has one major impediment that makes it very hard to take seriously in many rolls in an enterprise: the GIL (global interpreter lock).
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.
Re-read my post, I was unclear about Eric. He initially resisted Python because of distaste for the white-space handling. However, he tried the language and got past the issue, and now is a Python devotee. My point is that everyone who "hates Python" because of the whitespace issue should spend the time needed to give it a fair trial. Thanks to michael00_98 for taking me to task over this.
You are right: there is no way that you can use python for any task that requires even the slightest amount of performance. Realistically a zope / plone server can support 10 concurrent users (with write access). With PHP I aim at supporting 100+ concurrent users per server, and with java 1000. For me these technologies are for totally different uses, and I use the 3 of them:
python/zope/plone - intranets
php/perl - "medium" commercial apps
java - "Enterprise" stuff (3+ developers)
For each project the right technology: I like all of them!
You don't have to fix those problems if you stop being incompetant.
Ruby does everything Python can do, only better.
I should not respond to your post because I happen to be a Rubyist rather than a Python-ist! However, the key point is that dynamic typing is the benefit which enterprise practitioners need to focus on, and this is true for both Python and Ruby.
Python is a somewhat older language than Ruby (~15 years vs ~12 years) and is a little creakier syntactically. But that is a pure matter of taste. Both Guido and Matz have said as much on many occasions.
The whitespace issue is one of those religious things that give zealots something to fight about. But it's important to mention in a discussion about "Python in the Enterprise" because it's a (perceived) barrier to adoption.
Ruby has different barriers to adoption (at least in America and Europe), such as the lack of comprehensive documentation, a defect that is being rapidly addressed through the efforts of Gavin Sinclair and many others.
Ignore this terrible advice. Zope is so horribly slow that it is simply not worth trying to use. You absolutely must run a caching proxy in front of zope to make it usable, and that only helps with pages that are the same for each visitor.
Zope's documentation is terrible, and trying to do anything above and beyond "ordinary" things becomes a nightmare. You will be more productive using apache + PHP than you will with zope, and that's just sad. If you want to use python, go for it, there's web frameworks for python out there. But stay the hell away from zope.
I really like Python. It's an incredibly powerful language -- what other languages give you the power to redefine what "is" means? For example, you can override the '.' operator (and getattr) and create whole sets of virtual objects that don't really exist. Things like object proxies for RPC or external resources like Zope become possible.
:), the third-party libraries certainly made this project a breeze.
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 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
>>> Very bad, it really increases developing times since an error which could simply be signalled at compiling time is, instead, found only when executing the wrong line.
>>> The value of strictly typed languages is in compile time type checking. It's good to have languages that are not type checked, and it's good to have languages that are.
These two statements encapsulate the received wisdom on the static-vs-dynamic issue. It will take several years to decide the issue. Compile-time checking is indeed valuable in its own way. However, it just may be that the problems solved by compile-time checking are not actually the problems that make programming-in-the-large difficult to do. Please re-read that sentence a couple of times. This is the subtle and far-from-obvious intuition which must be tested and proved or disproved over the next several years.
Thee Python jobs can be found here...
which is precisely the idea, barring your utterly fallacious argument that the modules are "crap" (which ones? how so?).
I don't want my devkit to be a 90MB download, I would rather call packages upon request to my system as I need them, outside of the sensible core perl ships.
# Speakers told of experiments and used anecdotes to explain that programmers
# who use Python finish jobs in no more than half the time required by those
# coding in more conventional languages
The "more conventional languages" it's talking about are C# or Java, mainly.
(It also mentions XML and SQL, but you don't use Python instead of those.)
I'm trying to figure out how doing anything in a VHLL such as Python could take anywhere *near* half as long as in C# or Java. As a Perl programmer, I know that if I can't complete, test, debug, and deploy in an eight-hour shift what would take a C# programmer a month, then there's something wrong with my understanding of the problem. I would not expect Python development to be quite as fast as Perl, since it's a bit stricter about certain things, but nevertheless, I would have thought it would be a lot closer to Perl than to Java or C#. It *is* a VHLL, after all, right?
Are they just being really conservative with this claim, or is Python develpment really that slow?
Cut that out, or I will ship you to Norilsk in a box.
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.
It will take several years to decide the issue.
This issue hasn't been decided for half a century, what makes you think it will be "decided" within another several years?
However, it just may be that the problems solved by compile-time checking are not actually the problems that make programming-in-the-large difficult to do
Who said they were? Static type checking fulfills an important function in large programming projects. That function is not necessarily what you would understand as "programming in the large", it may well be "programming in the small". But when building large systems, you need to do both a little bit of "programming in the large" and a lot of "programming in the small".
If there is anything like an answer emerging at all, it is that the Java and C# approach seems pretty good: those languages use static type checking by default, but they also give you dynamic type checking, reflection, and code generation when you explicitly ask for them. The existence of such a compromise won't shut up the people who are religiously in the static or dynamic camp, but it helps the rest of us get our work done faster and more safely.
Use pike. Its a statically typed, object oriented scripting language with a curly brace syntax. So your example would be found at "compile time". If you have A declared as a string, then your second line of code will be a compile time error (bad type in assignment, expected string got function).
...or a replacement for VB6? What little I've heard is Visual Basic (which I know from experience has got to be the most successful garbage programming language in a long while) and Python are often used in the same sentence, with disparaging remarks reserved for the former. Given that a few programmers out there are peeved that VB6 is being phased out in favor of VB.NET (how successful has that been?) and Java is controlled by another single company for the most part, this leaves Python.
He was "thrilled" to "discover" hashes. Every decent high level language has this data type, wether its called a hash, a mapping, a dictionary or an associative array, its not new and its not thrilling.
Eric Raymond is not a top programmer. He is barely a programmer at all. He has contributed nothing but self obsessed posturing, no worthwhile code has ever come from him.
Second, spending 20 minutes with python will not cure the whitespace problem. It is 100%, without a doubt a mistake. I have a 12000 line 3 man project in python, and the whitespace issue is a very big problem. We are looking for a proper language to migrate to partly because of this.
And typing is a real problem. variable = obj.function and variable = obj.function() are both legal, and both compile. They are not equivilent and a language with proper typing would catch such errors.
I should NEVER have to debug whitespace, EVER!
I've used whitespace-blocked programming languages (MUMPS, anyone?) and they blow. They blow so hard, they suck.
Someone (I think it may have been Stroustrap) said (and I paraphrase), "The restrictions of the language translate to restrictions in the programming solution." I find white-space blocking restrictive and somewhat... arbitrary.
I understand these are my opinions, and others feel differently. Python looks like it might have been a good language for me if it wasn't for the pain of whitespace blocking. But you know what? It doesn't matter, because Python is there for those that like rules and restrictions, and Perl is there for those that thrive in chaos, and Forth is there for those who like to invent their language to fit the solution every time.
Lisp is there for those that like lots of tiny little chunks of things. C is there for those who aren't man enough for assembler. C++ is there for those who like pain (those are called masochists, right?). Objective-C is there for those who can't *quite* commit to Smalltalk. COBOL is there for the clearly insane obsessive-compulsive.
Java is there for those who used to listen to marketing hype. C# is there for those who grew disillusioned with the old marketing hype, and who listened to the *new* marketing hype.
That's the great thing, even about sucky languages like Python. Everyone has their place.
Mine is INTERCAL.
Microsoft is to software what Budweiser is to beer.
Just because you can't think of a reason for it doesn't mean it should be a syntax error.
There are perfectly good reasons why you'd want to store method references (x = obj.method) that way. The fact that you can then use the reference x() instead of obj.method() means the assignment is not a "dead-end".
If you're in the habit of forgetting parenthesis in function calls, perhaps that's something you should work on instead.
There are a lot of things wrong with what you are saying. It looks like while you learned the language, you have a lot of trouble adapting to some of the "paradigms".
Asking for functions to return None instead of raising exceptions on errors ruins a fundamental concept of "focus on what the program should do" which makes exceptions useful. A significant percentage of C code is "if - else" statements dealing with such return codes.
In C or Perl, writing a file is a painful operation, along these lines:
open file for writing()
if open failed {
handle error
} else {
while not finished {
retvalue = write content to file
if retvalue not good {
handle error
}
}
close file
if close failed {
handle error
}
}
Note how inline error checking not only makes the bulk of the code, but also makes it less obvious what the code does. In Python, you'd do something along these lines:
try:
open file for writing
while not finished:
write to file
close file
except open failed or write failed or close failed:
handle error
That is even assuming we want to handle the error and not let it propagate up, which is made possible by the exception mechanism, and would be made difficult if all those functions would return on error.
Have you ever tried Python? It's far more readable than Java, the clean indentation, limited for loop, and general verbosity without anything unnecessary make it much easier to maintain than any other language I've ever worked with. The non-compilation also means it feels easier to debug, there's no separation of compile-time and run-time errors but that's actually a good thing, because it doesn't really matter where the error occurs, you just need to see where it is and fix it, so there's no need for two "cycles" when debugging.
I am trolling
At least no one at /. can complain that MS is hurting open source software by providing a way to compile python to CLR.
The paragraph below is a great example why people usually *want* stuff they really do not *need*, and why not all programmers can be language designers:
It reminds me of a joke I once heard regaing a guy who, after getting hard contact lenses fitted said, "It feels like a toenail is stuck in my eye", to which the optometrist responds, "Don't worry, you'll get used to it." He replied, "If I've got a toenail stuck in my eye I want it out, I don't want to get used to it."
I recall the "old" style as being
if (test)
{
expression
}
But even with that goal it still includes some very irritating and useless constructs.
It's best place is to replace the original BASIC as in introduction to computer programming course... say at the early middle school level.
Last week I realised I needed some way of generating a bunch of stuff on the fly as prep work for a current project.
It had been mentioned in my hearing that Python was acceptable within the constraints for the overall program.
Figuring it was at least worth a look, I spent a day playing with Python basically putting together the things I needed to to do the task. In spite of a couple of disruptions, my code was fully functional and more or less ready for primetime by COB Friday.
I wouldn't use it for the real-time parts of what I'm doing if only because the framework being used is suitable as it stands ( C++/C/FORTRAN ) but for most other things it rocks.
I plan to push for making Python the standard glue language at the office.
Ruby is first of all, incredibly slow. Second, it doesn't have real threads. And third, it doesn't offer anything special. The best argument for ruby anyone has come up with is "look at rails", which could be done in python or perl just as easily, and "the syntax is like natural language", which is both wrong, and not a good thing.
GTK is portable, and you can make a GUI for it in glade. Then save that GUI as an xml file, and use it to quickly and easily create the GUI portion of your app from any number of languages, including C, C++, perl, python, pike, and ruby.
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.
CURLY BRACE PLACEMENT HAS NEVER BEEN AN ISSUE. Man indent you fucking whitespace loving morons. Curly braces are a *feature* that allows you to indent and re-indent any code automatically. Python breaks this, and makes it completely impossible to re-indent people's code, and you don't even know if the code is indented correctly to begin with. (bugs can hide behind space vs tab problems, and you will often totally miss them). We knock the lack of braces BECAUSE we have tried it, because we are experienced programmers who have been coding since before you are born, and realize that the lack of block syntax is a problem, not a feature.
Someone who doesn't understand what semantic structure is, and is stupid enough to not realize that block delimiters allow computer applications to indent and re-indent code automatically, while syntactically significant whitespace makes it impossible to assertain wether or not code is in fact correctly indented, much less reindent it to a standard indent size/type.
Your example is painfully silly and does not even compile. You neglected to create a sayHello method and looks like you criticized someone else for not creating a class which is just silly because while you define one you do not create it.
It doesn't solve all my problems with python, and it doesn't support threads. This is not a show-stopper, but it does lose points.
And there isn't "some" validity to my point, its a real and serious problem. There is no assurance that such an error will be caught when I run my code the first time, only when a certain, possible rare sequence of events causes that particular line of code to execute. That bug could be there for weeks after it was made, without anyone noticing, and then by the time we notice, its a problem that just affected a user, and we've got to debug it now. In a statically typed language it would have been caught immediately, and would save time having to debug a silly mistake.
I'm not sure why you are comparing to java, as there's no way in hell I would write this in java, but we have started re-implimenting the base of it in perl, ruby and pike to see which seems like the best bet. My vote is currently on pike due to this exact static typing issue.
There have been many posts concerning the speed of each and every possible language. Some have gone as far as to link to several studies with nice charts and graphs to conclude that X language is faster or X1 is truly the fastest. You are all wrong.
A laguage, in of itself, cannot be measured by speed. A language is merely a group lexical elements with a particular syntax. That syntax has an associated semantics to it. That is it! It is pointless to compare languages purely on speed.
Now, what we can compare is the implementation of a particular language. For example, we can compare the speed differences between the intel compiler and gcc for the same piece of C code. We might find that in most cases, gcc is slower that the intel compiler. Does this mean that C is slow? No! Now, take the same algorithm and port it to Java. Lets imagine that the Java version was 10x faster. Does this mean Java is inherently faster langauge? NO! It means that the compiler, JIT, and HotSpot implementations are better at tranlating Java source code down to the machine level.
So, in summary, a language by itself should NOT be measure in speed. It should be measured by the following:
Maintainability
Ease of Use
Learning Curve
Clear Semantics
Support
Documentation
Standard APIs
Most often, when languages are compared, you are merely comparing the differences in constants in a language! Lets say we implement the Quick Sort Algorithm in C++ and Python. We will probably find that the C++ version is slightly faster. What does this mean? It means the the implementation of C++ generates fewer constants that the Python Implementation. So, the Python version may be slower, but it is only in constant O(1) differences and in most cases this does not matter! Eliminating extra constants ( in any language ) is stupid when you have chosen the wrong algorithm in the first place! ( such as an order n^3 when it could have been n*log(n) ).
So, what is the moral of this story? Pick the right langauge for the right job. It you are doing advanced GUI development and prototyping, C++ is probably not the way to go ( since it is harder to write fast and correctly ). However, it you are doing low-level real-time I/O where constants do matter, then C/ASM is probably the way to go. After you have chosen he right language for your task, you must choose the right algorithm! Algorithms are the key! Algorithms are the only true way to measure the efficiency on any program in terms of memory and speed.
It's just something to consider when you are faced with a Perl/python decision. Be a true nerd and go with python.
Transcend Humanity. Please.
-Don
Take a look and feel free: http://www.PieMenu.com
Which is mostly what "enterprise" software is. I've been using Spyce (python server pages) for a few clients and it's a very decent tool. There is however a serious lack of standardization that a true enterprise technology needs. In Java there isn't a 100 different ways to do something right and it helps in commodotizing the Java programmer which in our geek eyes is a Bad Thing but in the view of corporate money it is a Good Thing.
Screw realty just hook me up another monitor!
Well That's certianly not how I would write it. now lets look at how one would do this in a good language that returns default values like Nulls.
That I'm sure you will agree just as readable and maintanable as the try-wrapper. Indeed the above does not preclude having a try-wrapper around it. One of the nice things, any python programmer ought to appreciate, is that the above form is self-documenting. You know where the errors came from rather than having an unexplained branch jump into a non-local piece of code. But the point is that by returning a default value I am free to handle the error or ignore it. I dont have to have the try enclosure if I dont want it. This is especially important when the error is inside of a loop or worse if the error occurs in a nested function.If instead function2 might throw an exception instead of a default return value then I have to wrap the thing inside of a try statement when in many cases if it just returned null or zero I would be perfectly happy. lacking that capability I have to write something like this:Some drink at the fountain of knowledge. Others just gargle.
If a person wants to write spaghetti code, they will manage it, even in Python. If a person wants to write intelligible code, they will manage it.
The most important part of any program is the algorithm. That's what needs to be understood. And Python cannot make a programmer write algorithms.
I don't see the attraction of Python's forcing you to indent in a certain way.
MS SharePoint stores _everything_ in SQL, and it's pretty darn zippy.
So what is the benefit? Is it mainly a productivity thing, where the programmer can type less? Is it that you don't have to cast things? These seem like small benefits when considering you don't have the security of knowing what type your variables are.
What other benefits exist? Where have I made bad assumptions?
Here is an example of what I see as the pernicious "try" crutch. The try syntax is excellent for certain kinds of errors but one should not be forced to deal with an exception when default value would do. it should be optional but its not this leads to the follwoing: see my answerto a simmilar issue for a worked example of what exactly I mean.
Python is easy to learn at a basic level. It is very easy to use for simple tasks.
Python also has the features of modern, powerful, high level languages. I was not saying that Python had features that other languages didn't. Quite the opposite.
At some point it became necessary that I could create cross-platform applications. The reason I selected Python, rather than Java, was a Slashdot article. The article had comments from a developer at Sun saying that Java was a lousy language for developing in their environment. One of the languages that he proposed as an alternative was Python.
ett ne
I can't believe some idiot would mod my reply down while modding the other responses up, even though I was being just as honest in my opinion as they were. Obviously the guy is a Python zealot who doesn't want to hear an opinion he doesn't like.
Python is a great language, so much better than Perl, but it isn't as great as python zealots keep preaching. It simply fails when compared to other tools in areas such as enterprise development, web development, etc.
Just like Java before it, Python is the latest "answer to all our problems" in software development. I'm betting that we'll see another replacement within three years.
But the real problem is that it seems the majority of developers will use any justification to use Python, no matter how thin. Once acheived, they begin their campaign of rewriting entire projects from whatever crappy, unmaintainable language we last used to whatever soon-to-be-crappy-and-unmaintainable new language they want to play with.
This ongoing effort to move from old language to new seems to be driven by little else than a developer's desire to work with cool new stuff. It robs our businesses of tremendous productivity and makes it that much harder to succeed. I've seen bugs put off for years because they were in the old-language code and the developers didn't want to touch it until the major rewrite scheduled real-soon-now. I've seen perfectly good code bases thrown away with no justification given or some flimsy speculation that new language will be better/faster/more.
It is this campaign to use new languages that robs businesses of huge amounts of productivity. Not merely the effort to rewrite stable code with new code in new languages, but the effort to test it, the effort to find and fix bugs. The effort to achieve the previous code's stability with multiple cycles going from 0.0 to 3.0+ over the course of years.
So if you're looking at Python or some new language as an interesting way to do your type of software development work, please consider how much further your business could advance if you just train your current development staff and new hires in whatever language you are already using.
These opinions guaranteed or your money back.
Q: My program wont run!
A: Reconfigure your editor!
Meme of the day: I browse "Disable Sigs: Checked". So should you.
Nobody mentions that the person who wrote the article is hyping python. He is a python lover.
In mature coding shops, all code is automatically run through a lint engine before it is compiled. It doesn't matter what the religious arguments one might have about where the brackets go, how many spaces between parens, etc., because when you hit the "compile" button, it all gets replaced by the corporate standard.
The net bonus is that one can concentrate on making the program work, rather than worrying about tabbing/spacing/bracketing in the right place. In fact, whenever I've worked in a non-mature shop, it is always a pain, because I have to remember to do all that stuff. Using a LINTer is so much easier.
Since you appear to be unaware of formating your code with lint, please at least tell me that you use source control.
Yeah, right.
If you really hate the whitespace thing, then use Ruby. You haven't argued against the basic dynamic-language proposition, just against one of the (arguably minor) features of Python.
Python is no easier to learn at a basic level than comparable languages like perl, pike and ruby. All of which are just as cross platform, just as easy, and more feature complete compared to python. Just because you are used to VB, doesn't mean python is good. It just means VB is bad.
When I first read it I thought maybe Jonathan Archer got a new pet.
Then I wondered, did he get rid of the dog or did the new snake just eat him?
Bet this
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 spanning many problem domains.
A lot of newer languages imitate C++'s approach in terms of design tools, most obviously Java, C# and now Visual basic.Net. However, the beauty is only skin-deep; these languages often lack the solid, underlying framework and reasoned design decisions that have gone into C++, with the result that most of the time they are lucky to be as good, never mind an improvement. The addition of generics to Java several years later is an obvious demonstration of what happens when you go for buzzwords and you meet someone who went for solid design principles.
Many other languages have something valuable to offer developers, but then go and spoil it in some other way, ultimately winding up with something that might fit certain niches, but isn't suitable for major development projects across a wide range of areas. Some common examples come immediately to mind:
Java Pro: emphasises safety, readability, and portability; con: sacrifices low-level control (and with it performance) and only supports a limited number of programming techniques, encouraging over-engineered, component-based designs Perl Pro: quick, flexible, useful for rapid development of useful tools; con: terrible scalability and unfriendly (to both programmers and tools) syntax restrict it almost exclusively to quick-and-dirty projects Haskell Pro: elegant and powerful syntax, serious support for powerful programming tools like higher-order functions; con: overly academic community, and puts purity above pragmatism, making it hard to use in real-world projects where things like UIs are involvedThe list goes on, but the important point is that while each of these has good applications, they all have obvious flaws as well. Java is the closest to a serious general purpose language, but even today most of the serious Java code is restricted to server-side back-ends driving databases or some thinly disguised variant on that theme.
C++, for all its sins, remains a pragmatic, balanced choice for a general purpose language that can be effectively adapted to a diverse range of applications. Is it a perfect language? Of course not. It has gaping flaws in any number of areas. The problem is that no-one has yet produced an alternative that beats it on all of them without significant compensating weaknesses.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You're debating which language is better based on whether a one-liner takes 9 lines or 12 to code?! If it were that easy, we'd all go back to writing in BASIC.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I'm not convinced that Java, as an example, is a worse general choice than C++ (I'd assert that as often, or more often, than C++ is a good choice, Java would be a good choice, but that's obviously not really fairly decidable). You're right that everything has pros and cons, I just feel that C++'s cons began to outweigh its pros a while back, and it just seems more evident today.
I'm also extremely unconvinced that any of the languages you mention have less "reasoned design decisions" than C++. The advantage of these newer languages is that their programming is, in general, more "safe" than predecessors like C++ -- although none of them are a true "general" language (what is?), a competent coder should be able to pick up the one most suited to his or her project and use it, without fear of having to learn a whole load of coding rules to avoid buffer overruns and the like.
Although C++ can be a reasoned choice sometimes, I do not see it as useful for new projects in a lot of areas. For most purposes, there's a better choice. But that's simply my opinion, of course.
Well, you've repeated the same entire expression twice in just one line of code. Moreover, the syntax contains redundant elements even without that. That's hideously verbose compared to, say,
or any number of similarly concise and more readable variations in other languages.
Really, if you're going to support Java, you shouldn't have argued in favour of one of its worst attributes! :-p
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The project is a network server application. What code gets executed depends on what commands the client sends to the server. Conditional execution is very common, they added handy things like "if" and "else" because its so handy in fact. You should try it sometime, it really makes things much easier.
I assume you mean that I should waste time writing tests that verify what the language should be verifying? Things like is my string a string? That's an awfully backwards way of thinking. Rather than spending more time working around a languages limitations, I would prefer a language that doesn't stick me with such limitations in the first place. If you don't mind having to work around limitations like this that's up to you, but not everyone is going to be horny for python and ignore its faults. I don't consider languages like religions, so I am perfectly willing to switch to a language that solves the problems python has.
Saying "ruby doesn't support threads" in response to my statement that "ruby doesn't support threads" seems somewhat disingenious. I know ruby has a broken, pretend threading implimentation within the interpreter. Like I said, its not a show stopper, but I would certainly give more points to languages that impliment threads correctly. We made end up needing to use an SMP machine at some point, and working around ruby's limitations isn't any more appealing than working around python's limitations.
And finally, there's no way I would write this in java because I value my time, and java is not portable. We're using openbsd/amd64 because this is a security sensitive application that has been actively targetted by "hackers", likely being paid by the company we're making angry. There is no java on openbsd/amd64. There is python, ruby, perl and pike though. Python doesn't compete with java for me, java isn't even an option. Python does compete with ruby, perl and pike though, which are all very similar languages that are all similarly productive. We will continue to evaluate those 3 languages, and then move to whichever one solves more of the problems with have with python, while adding the least number of problems of its own.
My question is, why do you have such a strong desire to try to make me believe that python's faults don't exist? Every language has its downsides, I am not going to ignore them and use python just because you can't fathom the benefits of static typing.
We should change the Fundamental Law of Software Development to "premature attempts at reusability are the root of all evil".
If it takes you five lines of code and seven abstractions just to read a value from an input stream, just because you can then share a couple of those abstractions across different types of value, is that really more readable, maintainable or efficient than simply writing one-liner versions to deal with different input types?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Python is excellent for web programming, thanks to a number of frameworks. Zope is the best known, but I much prefer SkunkWeb (http://www.skunkweb.org), which is simple to use and (in my experience, having spent a lot of time trying to get Zope to do things) more flexible. It's also very fast. There is also webware, cherrypy, and others. All these frameworks make it easy to access form fields, manage cookies, build up pages from components, access databases, and use Python to generate dynamic content.
Since Java is unavailable to you because of your platform choice, why not consider C++? (I'm currently supporting a 300,000 line C++ app written on OpenBSD, so I know it works pretty well.)
I'm trying to find out if, in your view, the use of dynamic languages for enterprise applications is a good thing or not. I hold no particular brief for Python (I prefer Ruby).
Because using recursion to calculate Fibonacci in the obvious way is a hideously inefficient algorithm. In languages designed to support recursive programming styles, such as most functional programming languages, this will be dealt with. In low-level languages like C, it won't, but then in C you would never implement the algorithm that way in the first place. It's not a fair test of the ability to implement a real world algorithm efficiently in different programming languages, which is the only useful metric you're going to get out of that sort of test set-up.
Compare this with a divide-and-conquer algorithm like quicksort, or an algorithm over a recursive data structure like an insertion on a binary tree, where the use of recursion to implement the algorithm is natural and need not introduce these arbitrary overheads.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
How many Starfleet Officers does it take to shoot a Python in the Enterprise... Wait wrong article.
I would rather go all the way and use C, I am not a big fan of C++ at all. However, this choice has nothing to do with dynamic vs static languages. Like I said, we are evaluating pike (specifically, I am doing the test rewrite in pike) which is statically typed and catches errors like the one I pointed out, yet its just as high level and fast to develop in as python. It doesn't have to be a choice between low level static and high level dynamic, high level static languages exist too.
You are making a big mistake here in assuming that dynamically typed languages offer a development speed benefit over statically typed languages. I can understand why you would think that if you compare working in java to working in python, but try comparing python and pike, and suddenly you'll see that you can have static typing, and fast development speed.
What I am saying is high level, object oriented, interpreted languages are good, and I don't see any reason they can't be useful in an enterprise environment. But they don't have to be dynamically typed, they can and should be statically typed.
See that "About Us, Products, Services, etc" menu at the top? I moved my mouse to "products," which automatically popped up a menu with "About Zope", "Zope4Intranets", etc. Then I highlighted "About Zope" and right-clicked, assuming my browser would show me a menu that would let me open that page in a tab while keeping the careers page open.
It didn't work.
Because it's not a hyperlink.
That whole top menu is some weird Javascript construction. 2005, and they don't even know how to use hyperlinks on a website yet.
Please, somebody with even modest familiarity with the web, go help these people.
Don't forget that Red Hat has been using Python extensively in its Enterprise Linux releases for years now. Stuff like the system-config tools and... the installer. :)
He's the only believable character on the show!
Then again, shouldn't we all be truly worried for Porthos?
There is nothing wrong with having a variable be a function, and he's not saying that should be a syntax error, or that he can't think of a reason for it. The point is that static typing catches errors that arise when you set a variable you *thought* was a string to be a function. It doesn't stop you from making a variable be a function if you want it to. You just have to want it to, instead of doing it by accident.
// var is the string returned by obj->method() // var is obj->method(), you can now call var()
See, in pike it would go like this:
string var = obj->method();
function var = obj->method;
if you do:
string var = obj->method;
you will get an immediate syntax error, just like if you do:
function var = obj->method();
(assuming obj->method() doesn't return a function of course).
You can submit your faster programs here
As for the 'magic' of in-place or not in-place I dont see that as magic. Indeed this is something that garbage collecting object oriented languages should strive for. For example, java and i'd bet python makes every effort to re-use allocated object space from garbage collected objects rather than creating new ones as they are instantiated. This is essentially no different than the program deciding to do a sort in-place because it can. It's analogous to the lstrip being space efficeint on imuatables.
That is by hiding the implementation you are free to do exactly this sort of magic under the hood. From the user's perspective it would be no hardship if sort() always appeared to return the sort as a value. It could be secretly in-inplace due to the Garbage collection of the original memeber when writing a=a.sort().
So __slots__ is analogous to perl psuedoarrays I gather where keys become enumerables. In some ways I wish you would hide all that from the user so that even more efficient access could be implemented down the road. One could Grant back the low-level under-ther-hood access to object functionality with a forma introspection method rather than allow primitive access to the details to the object itself. (ala java) Afterall how often does one need to fiddle with the objects method list manually? exposing this structure freezes the implementation. This is one place where python could make its greatest perfromance enhancement over perl I would think.
Anyhow thank you for your intelligent comments.
Some drink at the fountain of knowledge. Others just gargle.
I know from experience that syntax I don't like slows me down. I'd rather write more lines in a syntax I'm comfortable with than fewer in a syntax I find painful and annoying to work with.
You're coloured by a particular way of thinking - so whitespace is "trivial" for you. Good for you. It's not for me - or more precisely, the lack of explicit non-whitespace block markers is not trivial for me.
Unconventional semantics doesn't bother me. A syntax I don't like will make me stay far away from a language regarding of semantic properties.
If programming isn't painful then you aren't doing it right. Nothing scares me more than a programmer that still thinks programming is fun. It means they probably either haven't had a customer for their code or they left before their bugs caught up with them.
"Meaningless!, Meaningless!" says the Teacher. "Utterly meaningless!"
It's good to have languages that are not type checked, and it's good to have languages that are. The former is better with smaller groups, smaller programs, or more proficient developers. The latter is better with larger groups working on larger programs with more apprentices on the team. The former allows more flexibility and speed. The latter offers more imposed speed limits (and less car crashes).
Why is dynamic or loose typing allegedly bad for "large" projects? I keep reading this claim from Java fans, but have never seen a clearly described/coded scenario. Can anyone give a specific example?
Table-ized A.I.
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 control are often required), languages like C and C++ are still far ahead of the competition IME. Java is making some inroads into the embedded space, but it's barely a blip in the graph right now.
I think that's a little harsh. If there's one thing you can fairly say about C++, it's that Stroustrup and the standards committee take their time and try to reach good, practical decisions. It takes forever to make changes as a result, but with a few exceptions (the designed-by-committee string functionality, for example) the underlying design decisions of C++ are really very robust. Stroustrup's oft-cited book, The Design and Evolution of C++, provides some fascinating insights into how a serious computer scientist designs a language, and the factors that weigh into that decision. Even where I disagree with a decision that's been made, not that that often happens with this particular programming language, I can at least understand the rationale behind the decision.
Compare this with Java's almost amateur development process, and the design weaknesses that have resulted. For ages, the Powers That Be dictated that generics/templates/whatever weren't useful, and wouldn't be included. Lo and behold, a few years later, they concede that they were wrong and retrofit them (but still in a feeble way that misses half the point and 90% of the power). More seriously, although Java has a vast standard library, much of it is a joke compared to the high-quality, often peer-reviewed work found in things like Boost, CPAN, and so on. For example, AWT was so bad they had to invent Swing, and that's still not a patch on serious GUI libraries like Qt or wxWidgets in their various forms.
In fairness, the less formal processes (a.k.a. benevolent dictatorships in most cases) that underlie many scripting languages (notably Perl and Python in relation to the current discussion) tend to be rather more flexible. Even so, how can a language that doesn't even have a specifcation apart from a compiler that its own author couldn't rewrite from scratch possibly be considered to have an industrial-strength design process? (That would be Perl, and indeed the reason for all the completely rewritten underlying mechanics for Perl 6.)
That is indeed a compelling advantage. C++ has always been written for "good programmers", the craftsmen who take their craft seriously enough to learn the details and avoid the obvious mistakes. Unfortunately most programmers aren't like that, and most companies are going to be employing "most programmers" most of the time. It is therefore a sensible management decision to go with technology that mitigates "most programmer" errors.
The only problem is that sometimes, you actually need finer control (and to accept the attendant risks) in order to get a good result, and if you need to hire some geeks to use that control, so be it. If you have a language that actually won't let them bend or even outright break the rules when they know damn well that it is safe to break them in the particular circumstances they're working under, then that's a serious liability to some kinds of project. If you're going to fall back on linking to C functions, using JNI, or whatever every time you need performance, you might as well write in a language like C++ in the first place, and just hire enough good people to write safe, high-performance wrappers for the low-level code...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I can't see your problem. We just use the normal side-effects to communicate with the outside world, and... Oh, did you say Haskell was lazy? You did? Oh, dear.
Seriously, monads aren't such a difficult concept if you're familiar with the basics of functional programming already. The main argument against them is similar to those often used against "design patterns" for OO languages: they get the job done, but other languages can do it all so much more neatly that they seem like a pointless over-complication to anyone who's used to the languages with native support for the feature. Forcing that level of over-complication to maintain conceptual purity or to permit occasionally elegant techniques like lazy evaluation is fine in academia, but a dead end in the real world.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
What Python requires you to do is basically indent you code neatly. Which is what a good programmer is doing already. If you take a good Java program and remove the curly braces it is what a Python program looks like. So I really don't see why it can be a non-trivial issue.
Do you have any representative example in which Python's syntax cause you grieve?
I know what you are saying that some language's syntax can be annoying. Coming from a C background Pascal's := often got me. VB has lot more idiosyncrasy that often drive me crazy. In anycase it does not stop me from cranking out many lines of code. Python's white space syntax is very minor compares to the above cases as it is what we are practicing everyday. I never find any urging need to format my source code wildly.
according to the parent post, Perl does not even do that: $ is either a variable or a reference, so both would work fine on the left side.
You are saying that indentation is good. Ok, so go ahead and indent. That doesn't explain why curly braces have to be removed. What else people want is the ability to have the clear, consise and useful curly braces that they have come to love. Instead of trying to dismiss the valid concerns about whitespace, how about trying to explain what benefit it provides? Saying "its just like what you are already used to" is a cop-out, that's not a benefit. And "it forces you to indent correctly" isn't even correct, as you can clearly have lines that look identically indented, but aren't actually being interpreted that way by python due to a mix of spaces and tabs. At some point you will have to accept the fact that you cannot convince people to give up something they like and find useful, in exchange for nothing. Provide some valid reasons why significant whitespace is good. If they best you can do is "its not that bad really, you'll get used to it", then its clearly a bad thing, not a feature.
Yes, having to enforce someone elses coding standard that we don't like on ourselves is the entire problem. Languages with syntax allow us all to program as we please, then re-indent to the standard *we* choose for our project. That's the entire point.
Try writing some unit tests? No, try not having to test things that should be dealt with by the language. That's the entire point being made. Statically typed languages find these bugs immediately, and you don't have to waste time testing if your variables are what you think they are, its already guarenteed for you. Just because you don't mind wasting your time, doesn't mean everyone feels the same way. Some people like having computers deal with boring crap for them.
When people say "I don't like language X because it has these 2 problems", you stating those same problems again doesn't counter it and make things all good. If you like python go ahead and use it, but stop expecting everyone to put up with pythons problems just because you don't mind having to deal with them. Python loses points for having these problems, but it doesn't having anything on the other side giving it points that I've seen. I don't find python offers any benefits over perl, ruby or pike, but it definately has a couple downsides. So, we're going to switch to one of those other languages that doesn't go out of its way to try to make things difficult for us.
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 clause almoist QUADRUPLES the time: the first runs in 0.62 seconds and the latter runs in 2.4 seconds!!!
Now here is the is the point I was making in my original post: if you try this without using the get its almost 6 times faster than using the .get format and 24 times faster than doing it with the try statement!!!!!!!
To show this consider the following example: In this special problem we know ahead of time what the keys will be. In general we would probably not know this if we were say parsing a file. But since we know them its cheap to write a loop to initialize them first. then we dont have use the get() statement or the try. then we can see how much speed we are losing to the get() statement.
this runs in 0.11 seconds. Which is about 24 times slower than using the try.your information about how to replace autointialization appears to be seriously mistaken.
Some drink at the fountain of knowledge. Others just gargle.
Re: CPAN -- a bunch of improvements for PyPI (the Python Package Index) were written during PyCon, which should go some length to making something like CPAN. It's hard to really say -- CPAN is actually just a very simplistic FTP site, with lots of tools built on top. So it's a very different design. But with just a little more work, and a lot more evangelism PyPI (a lot of Python programmers don't even know about it) should become very useful.
er..no that's not what I said. in perl if you want the function you have to prefix the name with a slash, otherwise the function is simply called.
If it's really a problem, there are a myriad of solutions -- Numeric and numarray for lots of numbers, psyco for JIT optimizations, Pyrex for a Python-like syntax that compiles to C (and can be as fast as C if you use it correctly), and lots of other new options as well -- IronPython is supposed to be faster than CPython (the standard implementation), there's quite a bit of work on type inference, PyPy is working hard at compiling Python to fast C, Boost can inline C++ code... there's a huge number of options.
I've never encountered someone who had to throw a project away because of performance issues in Python. Sometimes they have to change the design, move some small parts of C, make better use of other people's libraries, and always of course driven by profiling -- but that's the kind of refactoring that always happens in development. And for a very large number of applications it simply is never a problem.
just what most companies need... "new" migration experts pushing widgets that nobody on staff knows how to use.. but hey it must be better, it's new.
Get your torrents...
"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."
Already being discussed in comp.lang.forth The short is that most "higher-level" languages need lots of "scaffolding" to verify the code is correct.
Without a proper steering comittee, made of independent bodies you can't consider a language "enterprise worthy". Take PHP for example - hobsons choice, "The Zend way, or the highway". Same goes for Perl, Python and Ruby - very few people are controlling the direction the language is taking. With Java, at least you have the JCP, JSRs etc - expert groups spend a great deal of time suggesting and revising APIs before they are finally democratically decided upon and implemented.
Java works because of this, and because it has such a large and stable selection of standardised components.
Just my $0.02
Python proponent constantly harp on that one of the advantages of Python is that it gets rid of the {} bracket debate, but completely miss the point that it opens up the more violent "space versus {}" debate or the "you indent 2 spaces? That's unreadable, I use 8 spaces" debate, or that "how the hell do I fix a file that has it's indentation structure broken because has a mix of tabs and spaces -- with braces this mess wouldn't have happened".
Why not be done with it an use the Ruby/Modula style of:
. . if condition:
. . . . stuff
. . end
It's easy to reformat in a good editor to any tab style, and there's only one logical indent struct form.
Just because there's the possibilty of improved performance someday, that doesn't mean you can't compare what exists now. This is what exists, this is what people are trying to claim is so much better than python, this is what gets compared. If ruby increases in performance in the future then that's great, but right now it is a potential issue. Also, pike isn't as old as python either, and has fewer developers and a much smaller community, but its faster than python.
I have tried python. Whitespace didn't prevent me from trying it, it seemed fine at first. Then when I did something larger, I realized what a problem it actually is, and stopped using python.
What I am saying is that removing curly braces does not add any benefit, the language is not any more clear or concise. But there are problems with removing the curly braces. So if you add up the fact that there is no benefit, but there are downsides, that means its a problem. If you don't mind dealing with the problem that's up to you, but trying to pretend its not a problem by claiming "its just like what you should be doing anyways, only kinda a pain in the ass in certain situations" isn't going to solve the problem.
if a > b:
if a > c: # indented with 4 spaces
print "python forces me to use stupid editor settings" # indented with 8 spaces
print "I am less productive in python as a result" # indented by a tab
If your editor's indentation level is 4, then this is how the code looks. But the second print is always executed when the first one is, despite not looking that way. And you can always do bizarre ass indentation where every level is a different width. I realize you shouldn't code this way, and obviously I don't *intentionally* code this way. But there is more to programming than simply writing a piece of code the first time, many other people read it and edit it afterwards, and cause weird errors like this if they don't worship at the alter of python editor settings, or when they try to move a block of code to a different place, where the indentation is different, and have to try to fix it, and can very easily make a mistake. This is completely avoided by simply using curly braces, and any inconsistancies in indentation can quickly be fixed by running indent on the code.
So, clearly removing the curly braces does NOT force the code to be indented clearly, instead it just forces me to use editor settings I dislike, have a hard time working with other people, and makes it a huge pain to move blocks of code since I now have to manually re-indent a whole crapload of code. Even if you don't think these downsides are a big deal, the fact is they are downsides, and there is no upside.
I don't think so. If you develop with Qt, you either have to pay big bucks to Troll Tech up front, or you have irrevocably committed to putting your software under an open source license. Since the latter is usually not acceptable to enterprises (even open-source friendly enterprises), this means paying a lot of money per developer up front.
Keep in mind that there is plenty of software that never gets "distributed". Licensing isn't an issue then, really. If you use Qt under the GPL to develop an in-house tool/application/minderbinder, you're not exactly obligated to go set up a CVS repository at SourceForge.
If other reasons we do lack, we swear no one will die when we attack