You get paid to contribute to closed source software. You can buy cook things with the money you make. You can quit if you like. You could have written the same software by yourself at home if you wanted. This is in no way, shape or form similar to slavery. I'd suggest you educate yourself on slavery a bit. Closed source software is "akin to slavery" like a stubbed toe is "akin to cancer."
Try walking down the row of cubes at work with the following offer - if you accept a layoff we'll add to your 401k as if you had an extra 1% of growth for 30 years in the company stock.
This makes no sense. You don't ask the employee "are you willing to be layed off?" You ask: "are you willing to let a very small percentage of your uncompetitive coworkers be layed off?" The unemployment rate bounces around between 4 and 8 percent. So if we make the likely false presumption that 4 is the "natural" rate of unemployment and 8 is where we'll end up due to outsourcing, we're talking about 4% of workers being layed off. If the rest see benefits in their mutual funds, it could well be a good deal overall.
Another thing Schwartz doesn't get: the possibility of forking is precisely what makes "Open source" open. The CIO does not want open source code because he wants his internal IT team to make a fork. He wants open source code because he wants the assurance that if Sun drops the ball technically or goes out of business (both possibilities) IBM or Red Hat or some mythical "Solaris Support Inc.) could pick up the Solaris ball and keep running with it. As long as it is proprietary to Sun, it gets bought by whoever buys Sun and it may be in their best interest to kill it. Mitchell Baker said it best: Open Source is about the freedom to choose leadership. Solaris users should be able to follow Sun's variant of Solaris as long as Sun continues to innovate and lead. But they should be able to follow someone else's variant if Sun starts to falter.
This is all true for Java as well of course.
I read your highly moderated post twice and still don't understand it. Linux has a bug that Solaris does not. Already we're on shaky ground extrapolating from that to "Linux is more buggy than Solaris." But let's suspend disbelief and make that extrapolation. What does this have to do with GPLing Solaris? Are you saying that if Sun changed the license on Solaris to GPL it would somehow magically become more buggy?
You say: I expect more of such problems could be solved when those companies specialized in enterprise bringing back good stuffs to Linux, and GPL. Isn't that exactly what Sun would do if they GPLed Solaris? Bring good enterprise stuff to the open source space?
Then I learned Perl. Now I do websites. I've forgotten most of BASIC. I have been told this is a good thing. But sometimes (actually, lately, more and more) I have to deal with VBScript and I see "LEFT" and "MID" and I think "what the hell is this crap?"
Don't you think that when you look at your Perl code?
Fine, but you're doing no favour to your friends or neighbours if you still encourage them to learn BASIC when they could learn (e.g.) Python instead. Why shouldn't they use a language easier to use than Basic and also much more powerful and scalable with much better libraries.
If Miguel thinks that Longhorn is such a threat because it will incorporate the.NET framework, will he come out an admit the truth: that spending all that time and effort on Mono was a mistake and a waste? Trying to reinvent.NET for Unix/Linux never made any sense to me, since the components in.NET that people really want aren't available on anything but Windows.
Mono is not a "port apps from Windows" play. Mono is a "Microsoft has some good ideas, let's steal them" play.
What makes you think that sticking with Mono will work when MS might well modify the.NET framework by the time Longhorn comes out so as to make it unusable by anything but Windows?
Being compatible with Windows was never the primary goal.
Applications live on a spectrum of portability to platform-specificity. This is totally right and appropriate. Sometimes you care about portability and sometimes you do not. Java (the library, the books, the community, the copyright owner) are totally skewed towards the portability side of the spectrum. In addition, you have Sun criticizing people if they use graphical toolkits other than Swing. This closed-world mentalitiy makes Java unpopular for people building single-platform applications or even just applications that need to run fast and feel native on each platform they are ported to. Languages like C# and Python and Tcl make it easier for the developer to choose when to dip down into something non-portable (e.g. PyGTK) or something highly efficient (C via Pyrex or managed C). Java will succeed when Sun gets its head out of its ass and recognizes that they don't always need to dictate the GUI, the language, the server framework etc. Sometimes you need to use a language just as a language and make your own decisions about the rest. Sun makes this hard (e.g. compare JNI to Pyrex as a C binding mechanism).
I'm sick of people who act as if jobs move in-toto. America still has millions of manufacturing jobs. America still has millions of farmers. There are people in America who sew clothes and weave rugs. When foreigners have more money to spend they will want to buy more American stuff: both the obvious, like Hollywood movies, Gangsta rap and cigarretes but also the subtle, like high-tech sewing machines and old-fashioned tractors. People against free trade have been predicting the middle class apocalypse for decades now. Now it is your job on the line. That doesn't mean that the myth changes to reality. It is still hokum as has been proved historically over and over again.
I can't tell you what the next big American industry would be any more than a person in the 60s could have predicted Silicon Valley or even the Californian wine industry. The rising income tide in the third world will boost demand for products from every country of the world including America.
BTWE, here is the Scheme program that is equivalent to the Python program in the very original referenced URL:
(set! L ()) (define (func) (begin (set! L (cons L () ) ) (func) ) ) (func)
The process grows without bound, just like in every other language...just as in the original URL. Sorry to keep on about it but it annoys me when I am stomping a troll and somebody pops up with a non sequiter that confuses the issue.
Okay, this is my last post in the thread. You are using the term memory leak in a manner different than I do. If we use your definition then Python, Scheme, Java, C#, Modula-3, Eiffel, Sather, Lisp, Dylan and hundreds of other languages do not leak memory. I don't know why you picked Scheme out of the list and remarked on it specially. I also don't know why you didn't look to see the definition of memory leak being used on the page I linked to:
l = [];
def leak(self, item):
l.append(item)
If Scheme IS immune to this kind of leak then that is news to me. If it ISN'T immune to this kind of leak, then your post is off-topic. If you want to claim that this ISN'T a leak, then you could have said that in the original post rather than bringing Scheme up at all.
Leak has a very specific meaning. A memory leak is memory that is no longer referenced by the program, but is not freed within an indefinite period of program runtime.
If this is your definition of "leak" then Python cannot leak either. In my mind, if you are running a server application and over days, months or years the process grows for no outwardly observable reason, that application is "leaking".
I think FOLDOC agrees with me: A leak in a program's dynamic store allocation logic that causes it to fail to reclaim memory in the heap after it has finished using it, eventually causing the program to fail due to lack of memory
Please moderators: this post is over-rated. Weak references are NOT the right way to deal with circular references. There is NO NEED to deal with circular references because Python has had NO PROBLEM with them for years.
An out-of-memory error is the end result of a long-term leak. You'll get the same out-of-memory error in Java, Python, C (reported as a malloc failure), etc. What do you mean by leak? Physical sims slipping out of the machine and onto the ground?
Argh...the garbage collector does handle circular references automatically and has done so for at least two years. Weak references are something totally different and are used e.g. for caches.
You do not need weak references to work nicely with circular data. Python has a cyclic garbage collector that works the same way that garbgage collectors in Java etc. do. Weak references are for referencing things without keeping them alive. e.g. for caches
It is clear you do not know anything about Python. You are not a long-time Python developer but rather a troll. The first hint is that you misspell Guido Van Rossum's name.
The second hint is that you cite a page from 1999. A Python developer would know that that was before Python had cyclic garbage collection. Here is an article from 2001 that describes how the issue was fixed.
The third hint is that you point to a page that describes how to avoid creating a memory leak by appending an infinite number of items to a list. Guess what: appending an infinite number of items to a list causes a memory leak in Java, C++, C, assembly, Scheme, sh, Perl and every other programming language in the world. If you ask the computer to store a continually growing list of items, it will do so...in any language.
If you think that Python can leak memory in circumstances where other languages would not, post an example program and we'll all test it out.
Most of the replies to this article seem to miss the key point: The 40 some-odd programmers, quality-assurance engineers and customer support staffers who work in CollabNet's two-floor outpost in Chennai are mostly in their mid-20s. By mid-2004, the managers here hope to recruit about 15 more of them. The market for their skills has become so heated in Chennai that headhunters brazenly call them up in their cubicles to solicit their services, dangling pay hikes of 30 percent
This suggests that the massive shift to India is nearing its completion. Of course new generations of Indians will arise but universities have only so much bandwidth. There are other countries of the world to consider but there are few with a highly educated English-speaking workforce and one by one they are being pushed up the price curve. Ireland was the cheap place to be five years ago. Then it was totally saturated. Now it is India. It will be saturated soon also. At no point will any country come online fast enough to wipe out the American software industry.
XEmacs has no trouble detecting the start of a block (as far as I can see). The only ambiguity is at the end of a block, which is the thing I was complaining about. When I do C programming in XEmacs, hitting TAB will immediately correctly indent the current line. If it doesn't, it's because I've screwed up somewhere.
There is something weird about this discussion. How does XEmacs know when the block is done? Does it read your mind? I would guess that unless you've written and AI in ELisp that it knows because you typed a curly brace. So you hit a key and get the right indent. In Python mode, you hit a different key and you get the right indent.
I will buy the argument that when you cut and paste Python code into another scope you need to be a little more careful to get the indentation right.
Slashdot Mirror
You get paid to contribute to closed source software. You can buy cook things with the money you make. You can quit if you like. You could have written the same software by yourself at home if you wanted. This is in no way, shape or form similar to slavery. I'd suggest you educate yourself on slavery a bit. Closed source software is "akin to slavery" like a stubbed toe is "akin to cancer."
what we have is CEOs taking advantage of underpaid high tech workers in countries that have no labor laws.
Sorry, that's just BS.Try walking down the row of cubes at work with the following offer - if you accept a layoff we'll add to your 401k as if you had an extra 1% of growth for 30 years in the company stock.
This makes no sense. You don't ask the employee "are you willing to be layed off?" You ask: "are you willing to let a very small percentage of your uncompetitive coworkers be layed off?" The unemployment rate bounces around between 4 and 8 percent. So if we make the likely false presumption that 4 is the "natural" rate of unemployment and 8 is where we'll end up due to outsourcing, we're talking about 4% of workers being layed off. If the rest see benefits in their mutual funds, it could well be a good deal overall.
Another thing Schwartz doesn't get: the possibility of forking is precisely what makes "Open source" open. The CIO does not want open source code because he wants his internal IT team to make a fork. He wants open source code because he wants the assurance that if Sun drops the ball technically or goes out of business (both possibilities) IBM or Red Hat or some mythical "Solaris Support Inc.) could pick up the Solaris ball and keep running with it. As long as it is proprietary to Sun, it gets bought by whoever buys Sun and it may be in their best interest to kill it. Mitchell Baker said it best: Open Source is about the freedom to choose leadership. Solaris users should be able to follow Sun's variant of Solaris as long as Sun continues to innovate and lead. But they should be able to follow someone else's variant if Sun starts to falter. This is all true for Java as well of course.
You say: I expect more of such problems could be solved when those companies specialized in enterprise bringing back good stuffs to Linux, and GPL. Isn't that exactly what Sun would do if they GPLed Solaris? Bring good enterprise stuff to the open source space?
In Python: print "hello world" Simpler still.
Here's what "Hello World" looks like in Python: print "Hello world" Fewer noise characters than BASIC. Simpler.
Don't you think that when you look at your Perl code?
Sorry...cheap shot...couldn't resist.
Fine, but you're doing no favour to your friends or neighbours if you still encourage them to learn BASIC when they could learn (e.g.) Python instead. Why shouldn't they use a language easier to use than Basic and also much more powerful and scalable with much better libraries.
If Miguel thinks that Longhorn is such a threat because it will incorporate the .NET framework, will he come out an admit the truth: that spending all that time and effort on Mono was a mistake and a waste? Trying to reinvent .NET for Unix/Linux never made any sense to me, since the components in .NET that people really want aren't available on anything but Windows.
Mono is not a "port apps from Windows" play. Mono is a "Microsoft has some good ideas, let's steal them" play.
What makes you think that sticking with Mono will work when MS might well modify the .NET framework by the time Longhorn comes out so as to make it unusable by anything but Windows?
Being compatible with Windows was never the primary goal.
Applications live on a spectrum of portability to platform-specificity. This is totally right and appropriate. Sometimes you care about portability and sometimes you do not. Java (the library, the books, the community, the copyright owner) are totally skewed towards the portability side of the spectrum. In addition, you have Sun criticizing people if they use graphical toolkits other than Swing. This closed-world mentalitiy makes Java unpopular for people building single-platform applications or even just applications that need to run fast and feel native on each platform they are ported to. Languages like C# and Python and Tcl make it easier for the developer to choose when to dip down into something non-portable (e.g. PyGTK) or something highly efficient (C via Pyrex or managed C). Java will succeed when Sun gets its head out of its ass and recognizes that they don't always need to dictate the GUI, the language, the server framework etc. Sometimes you need to use a language just as a language and make your own decisions about the rest. Sun makes this hard (e.g. compare JNI to Pyrex as a C binding mechanism).
Why not use the extra space for better sound quality rather than greater number of songs?
I'm sick of people who act as if jobs move in-toto. America still has millions of manufacturing jobs. America still has millions of farmers. There are people in America who sew clothes and weave rugs. When foreigners have more money to spend they will want to buy more American stuff: both the obvious, like Hollywood movies, Gangsta rap and cigarretes but also the subtle, like high-tech sewing machines and old-fashioned tractors. People against free trade have been predicting the middle class apocalypse for decades now. Now it is your job on the line. That doesn't mean that the myth changes to reality. It is still hokum as has been proved historically over and over again.
I can't tell you what the next big American industry would be any more than a person in the 60s could have predicted Silicon Valley or even the Californian wine industry. The rising income tide in the third world will boost demand for products from every country of the world including America.
If Scheme IS immune to this kind of leak then that is news to me. If it ISN'T immune to this kind of leak, then your post is off-topic. If you want to claim that this ISN'T a leak, then you could have said that in the original post rather than bringing Scheme up at all.
Leak has a very specific meaning. A memory leak is memory that is no longer referenced by the program, but is not freed within an indefinite period of program runtime.
If this is your definition of "leak" then Python cannot leak either. In my mind, if you are running a server application and over days, months or years the process grows for no outwardly observable reason, that application is "leaking".
I think FOLDOC agrees with me: A leak in a program's dynamic store allocation logic that causes it to fail to reclaim memory in the heap after it has finished using it, eventually causing the program to fail due to lack of memory
It is neither an implementation problem nor a language problem. There has been no such problem in any implementation of Python for years now.
Please moderators: this post is over-rated. Weak references are NOT the right way to deal with circular references. There is NO NEED to deal with circular references because Python has had NO PROBLEM with them for years.
An out-of-memory error is the end result of a long-term leak. You'll get the same out-of-memory error in Java, Python, C (reported as a malloc failure), etc. What do you mean by leak? Physical sims slipping out of the machine and onto the ground?
Argh...the garbage collector does handle circular references automatically and has done so for at least two years. Weak references are something totally different and are used e.g. for caches.
You do not need weak references to work nicely with circular data. Python has a cyclic garbage collector that works the same way that garbgage collectors in Java etc. do. Weak references are for referencing things without keeping them alive. e.g. for caches
It is clear you do not know anything about Python. You are not a long-time Python developer but rather a troll. The first hint is that you misspell Guido Van Rossum's name.
The second hint is that you cite a page from 1999. A Python developer would know that that was before Python had cyclic garbage collection. Here is an article from 2001 that describes how the issue was fixed.
The third hint is that you point to a page that describes how to avoid creating a memory leak by appending an infinite number of items to a list. Guess what: appending an infinite number of items to a list causes a memory leak in Java, C++, C, assembly, Scheme, sh, Perl and every other programming language in the world. If you ask the computer to store a continually growing list of items, it will do so...in any language.
If you think that Python can leak memory in circumstances where other languages would not, post an example program and we'll all test it out.
Geez I hope you are joking...but the moderators moderated you insightful, not funny.
Most of the replies to this article seem to miss the key point: The 40 some-odd programmers, quality-assurance engineers and customer support staffers who work in CollabNet's two-floor outpost in Chennai are mostly in their mid-20s. By mid-2004, the managers here hope to recruit about 15 more of them. The market for their skills has become so heated in Chennai that headhunters brazenly call them up in their cubicles to solicit their services, dangling pay hikes of 30 percent
This suggests that the massive shift to India is nearing its completion. Of course new generations of Indians will arise but universities have only so much bandwidth. There are other countries of the world to consider but there are few with a highly educated English-speaking workforce and one by one they are being pushed up the price curve. Ireland was the cheap place to be five years ago. Then it was totally saturated. Now it is India. It will be saturated soon also. At no point will any country come online fast enough to wipe out the American software industry.
XEmacs has no trouble detecting the start of a block (as far as I can see). The only ambiguity is at the end of a block, which is the thing I was complaining about. When I do C programming in XEmacs, hitting TAB will immediately correctly indent the current line. If it doesn't, it's because I've screwed up somewhere.
There is something weird about this discussion. How does XEmacs know when the block is done? Does it read your mind? I would guess that unless you've written and AI in ELisp that it knows because you typed a curly brace. So you hit a key and get the right indent. In Python mode, you hit a different key and you get the right indent.
I will buy the argument that when you cut and paste Python code into another scope you need to be a little more careful to get the indentation right.