I recently chaired a panel discussion on enterprise open-source, attended by representatives from several dozen Fortune 500 companies, and we turned the discussion back on them at one point. Turns out that: 1) all had made a "commitment" to open-source products; 2) almost none had done anything strategic up to that point (they all had a little Linux and a little Apache/MySQL floating around here and there, of course) 3) NONE were interested in the cost-reductions available with F/OSS 4) ALL were interested in the advanced technology which they felt was probably more available from F/OSS then from incumbent vendors 5) ALL were holding back waiting for better support options. There was a lot of discussion about the latter point, including some really fascinating suggestions that belong in another discussion. But for here and now, the key thing is that you don't necessarily look for support for OSS DBMSs from the developers. Something like the Pervasive model is interesting, as long as they continue to maintain close ties with the developer communities. But OSS support is a service business, with linear cost-scaling characteristics, so we will need a lot of vendors to pitch in. I think it's a nascent large opportunity.
Static type-management as in Java is the DIY option. Dynamic languages give you the "automatic" type management. That's what's backwards. Maybe you meant to say that just because Python's automatic type management is so primitive, that's still not a reason to prefer specifying your own types all over your code, as in Java;-). Ignorance of topic: I've been writing compilers for a living for 15 years now. I wrote my first Java-to-x86 compiler two months after the language was first released. Now tell me what language you prefer for enterprise applications.
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).
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.
There's something I don't get. Why are you writing lines of code that don't immediately get executed and tested? Especially in such a small project?
Part of the "best practices" for dynamic languages is comprehensive unit testing. Ruby makes this trivial to do, since all the required class support is built into the language.
Ruby does have threads. They're akin to the old Java "green threads" but they are there.
No way in hell: why wouldn't you re-write this in Java? That's a serious question, I want to know why not. I suspect that your answer will shed some light on the OP, which was "Python moves into the Enterprise." On this ground, Python and Ruby compete against Java, not each other.
So conceivably some successor to Java could have all the nice features you currently look to Python for. In that case, would you ditch Python to get the static typing?
In my heart of hearts I'm undecided whether large systems (10 million+ lines of code, hundreds of programmers, decades of lifecycle) are possible in Python/Ruby, because of the lack of implied interface contracts that comes with dynamic typing.
But I like your insight that dynamic programs may not ever need to get that big because the expressiveness of the languages makes it unecessary!
If you really hate the whitespace thing, then try Ruby.
var = obj.function var = obj.function()
There's some validity to your point here. In this case, static typing signals you at compile time that you made a "stupid" mistake (ie, a mistake not caused by an improper understanding of the program requirements). But a dynamic language would signal the error just as quickly, because you'll get a clear, obvious error the first time your code runs.
A 12000 python program probably translates to 20-40 thousand lines of Java. Either way, it's a small program. Do the conversion and tell us what you find.
>>> 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.
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.
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.
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.
ESR LOVES Python: That's why I quoted the article. Eric initially avoided Python because of whitespace. After twenty minutes of practice he realized it was a good thing rather than a bad thing. I'm saying that the same would be true for a lot of other people, if only they would put in the twenty minutes.
"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.
Your argument is backwards. You say that first-generation garbage collection was not as good as DIY, therefore first generation DIY-typing is probably not as good as automatic type management.
Apart from the rhetorical flaw, you're missing the basic point about dynamic typing. "Type-management" is only required by statically-typed languages. In a dynamic language, there's no need to check types at all, because the basic program logic requires proper usage.
Many traditional programmers like yourself are comforted by the compiler's ability to lexically cross-check your type declarations. Losing that ability is the biggest leap when moving to the dynamic style.
When you make a type error in a Python program, it shows up as a runtime exception rather than a compile-time error. Most Java programmers have two expectations about this: 1) It will happen about as often as compile-time errors happen in static programs, viz. constantly; 2) The runtime type-system errors are annoying and painful to debug. However, it turns out that expectation 1 is completely false. This is counterintuitive and surprising, but I have the experience to back it up. Runtime type errors are few and far between. In fact they are generally regressions resulting from changes in program semantics. As for debugging them, they are almost immediately obvious. This is also counterintuitive and surprising but I have the experience to back it up.
Bottom line: you will not be convinced that dynamic languages are better until after your first few large projects.
Whitespace as a block-delimiter makes code easier to read. It's an obvious visual improvement over curly braces. But that's a statement of personal taste.
Python (and Ruby) are valuable primarily because of dynamic typing. If Python had used curlies rather than whitespace, it would now be a (slightly) worse language but used by far more people.
By far the number-one reason people avoid learning Python is because they disagree with the whitespace usage on principle.
Your point about whitespace is well-taken and interesting, but the thrust of the original post was "Python in the Enterprise." And here the problem is just prejudice, not any specific technical issue. I have talked to so many otherwise bright and open-minded people who just won't touch Python because of how it uses whitespace (as I said, I was one of them!) In regard to "nondeclarative variables": these are a feature in Python, not a "problem." This may strike you as fanciful, but no amount of automated tools like pychecker and the Java compiler will help you to actually understand and communicate how a program is supposed to work. But it's just as fanciful to suppose that static typing and interface "contracts" promote understanding across large teams! This is the core objection that the more perceptive people have against Python and Ruby, but it will be disproved over time.
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.
Brown finds it "intriguing" that many open-source contributors work for large IT companies. "Every day, an untold amount (sic) of employees beholden to strict employee/invention/intellectual property agreements, in their spare time (and even during work-hours) freely give away ideas, code, and products to open source projects," he writes. This opens up questions around the legal ownership of contributions... There's no conflict with people contributing to open-source projects while employed by business firms. When you agree to assign IP to your employer as a condition of working for him, the employer becomes the legal owner of what you create. (Why is that so hard for everyone to understand?) The best companies have no problem contributing their code to the community because it benefits them in the end. Most big companies are wary of using open-source technology because they can't afford to be without support. The smartest ones know that they can anchor their own communities, especially around the more specialized and vertical software applications. The stupid companies are the ones asking "How am I going to protect my investment if I don't keep this stuff secret?"
Anyone remember reading the Jobs bio a while back that mentioned how in the early Apple days (on Bandley Drive) Steve used to walk around barefoot? And how he used to give himself foot massages in the toilet?
The biggest problem that the Chinese authorities have with electronic communications is their need to know who is talking. The essential part of this story is the bit about "real identities," and it's also why these courageous sysadmins, at great risk to their own lives, drew the line at that point. China has two different societies: the urbanized incipient middle class, and the unwashed rural masses. The former group is a bit smaller than the population of the US, while the latter group numbers about a billion or so. The goal in respect to the countryside is to simply to starve the people while preventing a repeat of the Maoist Revolution. These people are controlled through corrupt, brutal (and somewhat unruly) local officials who make sure that nothing like modern communications technology ever becomes widely available. In essence, the rural population never really finds out what they are missing. The people in the larger cities, however, are being fed on the dream of accession to a middle-class lifestyle, complete with cars and electronic gadgets. If all goes according to plan, this group will rapidly become a source of final demand about as big as the US currently is. And the key is to keep them from realizing that they could do far better still with some real freedom of speech. That's why nothing matters more to the authorities than being able to neutralize that small sliver of independent-thinking, dangerous people. And you can't make them disappear in the middle of the night unless you can positively identify them.
Slashdot Mirror
I recently chaired a panel discussion on enterprise open-source, attended by representatives from several dozen Fortune 500 companies, and we turned the discussion back on them at one point. Turns out that:
1) all had made a "commitment" to open-source products;
2) almost none had done anything strategic up to that point (they all had a little Linux and a little Apache/MySQL floating around here and there, of course)
3) NONE were interested in the cost-reductions available with F/OSS
4) ALL were interested in the advanced technology which they felt was probably more available from F/OSS then from incumbent vendors
5) ALL were holding back waiting for better support options.
There was a lot of discussion about the latter point, including some really fascinating suggestions that belong in another discussion. But for here and now, the key thing is that you don't necessarily look for support for OSS DBMSs from the developers. Something like the Pervasive model is interesting, as long as they continue to maintain close ties with the developer communities. But OSS support is a service business, with linear cost-scaling characteristics, so we will need a lot of vendors to pitch in. I think it's a nascent large opportunity.
Static type-management as in Java is the DIY option. Dynamic languages give you the "automatic" type management. That's what's backwards. ;-).
Maybe you meant to say that just because Python's automatic type management is so primitive, that's still not a reason to prefer specifying your own types all over your code, as in Java
Ignorance of topic: I've been writing compilers for a living for 15 years now. I wrote my first Java-to-x86 compiler two months after the language was first released. Now tell me what language you prefer for enterprise applications.
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).
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.
There's something I don't get. Why are you writing lines of code that don't immediately get executed and tested? Especially in such a small project?
Part of the "best practices" for dynamic languages is comprehensive unit testing. Ruby makes this trivial to do, since all the required class support is built into the language.
Ruby does have threads. They're akin to the old Java "green threads" but they are there.
No way in hell: why wouldn't you re-write this in Java? That's a serious question, I want to know why not. I suspect that your answer will shed some light on the OP, which was "Python moves into the Enterprise." On this ground, Python and Ruby compete against Java, not each other.
So conceivably some successor to Java could have all the nice features you currently look to Python for. In that case, would you ditch Python to get the static typing?
In my heart of hearts I'm undecided whether large systems (10 million+ lines of code, hundreds of programmers, decades of lifecycle) are possible in Python/Ruby, because of the lack of implied interface contracts that comes with dynamic typing.
But I like your insight that dynamic programs may not ever need to get that big because the expressiveness of the languages makes it unecessary!
This would be a nice question to do a thesis on.
If you really hate the whitespace thing, then try Ruby.
var = obj.function
var = obj.function()
There's some validity to your point here. In this case, static typing signals you at compile time that you made a "stupid" mistake (ie, a mistake not caused by an improper understanding of the program requirements). But a dynamic language would signal the error just as quickly, because you'll get a clear, obvious error the first time your code runs.
A 12000 python program probably translates to 20-40 thousand lines of Java. Either way, it's a small program. Do the conversion and tell us what you find.
I sure have. ;-)
But remember the OP: "Python moves into the Enterprise."
After 43 years, Lisp still isn't close
Well roared, Lion!
>>> 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.
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.
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.
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.
ESR LOVES Python: That's why I quoted the article.
Eric initially avoided Python because of whitespace. After twenty minutes of practice he realized it was a good thing rather than a bad thing. I'm saying that the same would be true for a lot of other people, if only they would put in the twenty minutes.
"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.
Was that an intentional pun?
Is that you, Eric? ;-)
Your argument is backwards. You say that first-generation garbage collection was not as good as DIY, therefore first generation DIY-typing is probably not as good as automatic type management.
Apart from the rhetorical flaw, you're missing the basic point about dynamic typing. "Type-management" is only required by statically-typed languages. In a dynamic language, there's no need to check types at all, because the basic program logic requires proper usage.
Many traditional programmers like yourself are comforted by the compiler's ability to lexically cross-check your type declarations. Losing that ability is the biggest leap when moving to the dynamic style.
When you make a type error in a Python program, it shows up as a runtime exception rather than a compile-time error. Most Java programmers have two expectations about this:
1) It will happen about as often as compile-time errors happen in static programs, viz. constantly;
2) The runtime type-system errors are annoying and painful to debug.
However, it turns out that expectation 1 is completely false. This is counterintuitive and surprising, but I have the experience to back it up. Runtime type errors are few and far between. In fact they are generally regressions resulting from changes in program semantics. As for debugging them, they are almost immediately obvious. This is also counterintuitive and surprising but I have the experience to back it up.
Bottom line: you will not be convinced that dynamic languages are better until after your first few large projects.
Whitespace as a block-delimiter makes code easier to read. It's an obvious visual improvement over curly braces. But that's a statement of personal taste.
Python (and Ruby) are valuable primarily because of dynamic typing. If Python had used curlies rather than whitespace, it would now be a (slightly) worse language but used by far more people.
By far the number-one reason people avoid learning Python is because they disagree with the whitespace usage on principle.
Your point about whitespace is well-taken and interesting, but the thrust of the original post was "Python in the Enterprise." And here the problem is just prejudice, not any specific technical issue. I have talked to so many otherwise bright and open-minded people who just won't touch Python because of how it uses whitespace (as I said, I was one of them!)
In regard to "nondeclarative variables": these are a feature in Python, not a "problem." This may strike you as fanciful, but no amount of automated tools like pychecker and the Java compiler will help you to actually understand and communicate how a program is supposed to work. But it's just as fanciful to suppose that static typing and interface "contracts" promote understanding across large teams! This is the core objection that the more perceptive people have against Python and Ruby, but it will be disproved over time.
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.
Brown finds it "intriguing" that many open-source contributors work for large IT companies. "Every day, an untold amount (sic) of employees beholden to strict employee/invention/intellectual property agreements, in their spare time (and even during work-hours) freely give away ideas, code, and products to open source projects," he writes. This opens up questions around the legal ownership of contributions...
There's no conflict with people contributing to open-source projects while employed by business firms. When you agree to assign IP to your employer as a condition of working for him, the employer becomes the legal owner of what you create. (Why is that so hard for everyone to understand?) The best companies have no problem contributing their code to the community because it benefits them in the end. Most big companies are wary of using open-source technology because they can't afford to be without support. The smartest ones know that they can anchor their own communities, especially around the more specialized and vertical software applications. The stupid companies are the ones asking "How am I going to protect my investment if I don't keep this stuff secret?"
Anyone remember reading the Jobs bio a while back that mentioned how in the early Apple days (on Bandley Drive) Steve used to walk around barefoot? And how he used to give himself foot massages in the toilet?
No one has trouble with "CAO," that's just some innocent young people having fun.
Now how about "FALUN GONG"? That would be a little different.
The biggest problem that the Chinese authorities have with electronic communications is their need to know who is talking. The essential part of this story is the bit about "real identities," and it's also why these courageous sysadmins, at great risk to their own lives, drew the line at that point.
China has two different societies: the urbanized incipient middle class, and the unwashed rural masses. The former group is a bit smaller than the population of the US, while the latter group numbers about a billion or so.
The goal in respect to the countryside is to simply to starve the people while preventing a repeat of the Maoist Revolution. These people are controlled through corrupt, brutal (and somewhat unruly) local officials who make sure that nothing like modern communications technology ever becomes widely available. In essence, the rural population never really finds out what they are missing.
The people in the larger cities, however, are being fed on the dream of accession to a middle-class lifestyle, complete with cars and electronic gadgets. If all goes according to plan, this group will rapidly become a source of final demand about as big as the US currently is. And the key is to keep them from realizing that they could do far better still with some real freedom of speech. That's why nothing matters more to the authorities than being able to neutralize that small sliver of independent-thinking, dangerous people. And you can't make them disappear in the middle of the night unless you can positively identify them.