A click-through license is not a binding contract. In fact, it is absolutely nothing, legally. Yes, EULA's are worthless pieces of text as well, and shown unenforceable in court.
I admit to have only done medium-sized projects in Python, but in actuality, the vast majority of projects are of that size.
I do not anticipate any difficulties in scaling up Python (or any other sane language) programs, as they can always be broken to small interacting, largely-independent parts - which can be verified and tested separately.
If anything, Python's powerful abstractions make this easier as applying design patterns becomes near-trivial without the type-hassle.
You may think that Java is only used in applets/cell phones, but that is not even its primary ussage I figured so, I was wondering why.
1) Scripting languages such as Python and Perl run at (and this is a very rough generalization, of course) 10% the speed of C++. Java runs at 80-90% the speed of C++. Unlike scripting languages, Java is compiled to very efficient native code as your program runs (this is part of the reason for slow Java startup time, the bytecode->native compiler is running at that point).
Have you tried psyco? A JIT compiler for Python. In some cases it makes Python code run faster than the equivalent straightforward C code. In others, Python code still runs with very comparable speeds to C.
2) While you CAN write code more quickly in scripting languages, scripting languages don't scale well to large projects (by this I mean that development time slows down, not runtime performance). Right around the time when you hit ~1000 source files, you start to realize the value of static type safety.
Python's expressiveness is so great, that you typically get 10-to-1 reduction or more in code size between C++ and Python. The powerful abstractions in Python make this non-linear in Python's favor. I do not have data about the relation between Java and Python, but it is likely similar, as C++ and Java take around the same amounts of code to perform similar tasks, given the existence of libraries. Thus a "large Python project" functionality-wise is quite a small one relatively to the equivalent Java one. I have written a lot of Python code, and scaling up is actually very easy in Python, as it is in every sane language in a sane environment of good developers.
3) Not having to do manual memory management really does save you a lot of development time over C++. This may not be apparent to you in a small 1-2 person project, but just wait until you're working in a 10-person project and the dumbass down the hall accidentally deletes the object you still have a reference to (or forgets to delete and then you have a memory leak).
Indeed, but writing 100% of a program in a low-level language like C++ is a thing of the past (and of the ignorant). You should typically write 10% (or less) of the code in a low-level language, because that code executes 90% of the time. In these small pieces of library code, memory management is not typically a big deal.
4) The standard API is very handy. Java comes with something like 10,000 classes built in. You're clearly not going to use these classes for the core of your project, but they're very useful for all the side things you have to do. Need to parse XML? Built in. Need to send an entire object graph over a socket? Built in. Need to draw a curve with anti-aliasing? Built in. Need to have 2 threads put stuff into a queue while a third takes stuff out? Built in. Need to load a JPEG or talk to a database through SQL? Built in. It goes on and on and on.
Funnily, all of the things you mentioned (except the anti-alised curve, not sure about that one) are also built-in in Python. So again, I can't see why that would be a factor. Especially moot seems your point that for "side things" Java libs are great. These little "scripts" and "side things" are the classic example where Python is so much better than Java. Show me the code of any such "side thing" in Java, and I shall show you the much-simplified and more-powerful Python equivalent.
5) The tools are incredible. I was an emacs guy for ~10 years but I was willing to give up my keybinding memory because the IDEs on the Java side are so damned amazing. Check out IDEA (or Eclipse if you're broke). It grays out variables that you're not using. It lets you highlight a block of code and hit a key and it makes a method out of the code, replacing the previous block with a method call (and in the latest beta, it detects duplicates of the code block and also replaces those with the method call). Accident
Massive libraries, super development tools, tremedous skillbase availability, vast 3rd party support, large literature on best practices etc. etc. etc..
What libraries does Java have that are inaccessible to Python (Especially with Jython being avaialable)? The development tools available for Python (xemacs, komodo, and various other IDE's) are all considered great. I have not personally used them and those of Java, have you? Can you write a few advantages of these tools during development?
The skillbase is surely a business factor when choosing Java. But when most create their own project, they can choose the language best fit technically - and that is not Java.
3rd party support and literature are not exactly lacking in Python and other alternatives either so that is a weak point as well.
Language features of marginal value (in some cases like dynamic typing the features can even be harmful to software reliability, making testing more complex and increasing the liklihood of runtime errors).
That is a common myth. Trusting the type-safety given to you by the compiler is not enough. You need to have run the code at least once to verify it is valid, and for that you must write unit-tests. If the code is not type-safe, then running it once in a dynamic OR static language will find the fault.
To say that generators, closures and other features not found in Java have marginal value is a sign of ignorance. Can you please describe those features and how they are typically used?
To underestimate the dynamic power of Python is also a sign of ignorance. Can you implement PyInvoke in Java? I challenge you to apply an RPC so easy to use as that.
Vastly superior toolchain starting with design and ending with installation and deployment. End of story.
Please describe why Java is superior, instead of uttering a chain of buzzwords.
You need a UT framework for all your code anyhow, if it is going to run correctly and not just run safely, so what's the difference if its a compilation error, or a UT run error?
It seems that the usefulness of Java is limited to web applets/cellphone-apps and other specific things.
Judging from its popularity, it seems people are applying Java elsewhere. Why?
Java does not excel in performance, expressiveness, simplicity or power. It does not have generators, closures, dynamic typing and powerful dynamic features.
Why prefer Java over Python in the general case? If your answer is performance, why not choose Pyrex or C for the performance-critical parts, for a much better/faster result?
That's what people mean by saying "Linux" here in the discussion. Maybe RMS's "rant" about accurate naming is not so unnecessary.
I can download and install a Windows utility more quickly than I can build and install a Linux package.
Oh? Easier than "apt-get install kde", kpackage, synaptic, aptitude or the other package management frontends? These download the packages and all the dependencies for you.
These tools can also keep all (in the thousands) of your packages up-to-date (unlike Windows update which keeps perhaps 20 packages up-to-date).
The fact you are mentioning building these packages yourself as a difficulty means you probably haven't used a Linux distro since early Slackware days.
Why not move to use "instant messaging" methods of direct connectivity between the sender and recipient, and only falling back to server storage when necessary?
This allows for much better knowledge of successful/failed delivery.
It may move more control of message reception to the recipients, allowing them to implement extra protections. For example, requiring arbitrary/configurable amounts of computation on the behalf of the sender to send them a message (increasing the cost of a message send) (unless ofcourse the sender is on a white list of known correspondents).
Is any such transition feasible in the near future?
is hardly the main productivity boost in people's programming environments. Sure it is a productivity boost, but not the main or even the biggest one.
The main productivity boost in Python, for example, is its dynamic typing. Its simplicity second, and automatic memory management as a third, perhaps.
Also, his claim that you don't have to debug memory leaks with Garbage Collection is a common fallacy. Garbage Collection makes it very possible to leak memory, often in more difficult ways to debug, since the developer is typically unaware of what memory is behind held by which objects as usually there is no need to put much thought into the issue.
until you try to do something too complex for Windows to handle, like find a file of an exact name, or directories that contain some files.
Not to mention shell scripting capabilities, or the ability to handle files that are already opened, and other awful annoyances Windows has. Then there's the fact that when you're a developer, it is kinda frustrating you cannot fix those annoying things and other bugs, because the source is closed.
That is not lost revenue, as those people would never pay for it anyway. It is simply people using Windows rather than OSS, and has no effect on the outside world (except for the participation in the distribution of worms).
It is the language's fault for making it difficult to track memory, and it is Windows' fault for making things difficult enough for the user to make a mistake.
in the long awaited death of copyright, which is simply absurd in the Digital Age.
You violate copyright, he violates copyright, everyone violates copyright because society cannot accept such limitation on freedom. Of course you only violate copyright because the songs are too expensive, or because you can't afford it, or because nobody knows and you wouldn't buy it anyhow. That self-righteousness is what all copyright abusers who tend to support copyright say. The support copyright has is a result only of the lack of enforcement - and thus copyright enforcement is a necessary and positive step in its ultimate destruction.
What exactly did the "pirates" take from anyone such that he does not have it now? Nothing, thus its not theft.
No, they did not "take" the money they would have paid, because saying that you're assuming that they would have paid anything in the first place, and that taking away something someone never had is theft. Its not.
Demonizing those who do not believe strong limitations on the freedom of everyone are necessary to create an incentive is worse than the act of "piracy" (Ok, lets try to say copyright infringement from now on, thank you).
Everyone infringes on software copyrights, except very few people (probably you, too), and once we have effective DRM, we shall see that. We will probably also see software copyright being undone or severely crippled. I don't think people would go along with this.
Software copyrights must be abolished. Vote with your software, use Free Software or at least don't pay for software.
Calling information sharing and helping a friend in nasty names.
If these video games wouldn't exist in order for us to regain the freedom to do these things - then video games should not exist, they are not worth our freedom.
I would never buy a copyright-protected piece of software because it is against my principles, and I also try to avoid infringing on existing copyrights because that also encourages the general use of the copyright-protected software.
Almost all of those who still support copyright only do so because it is unenforced, and they infringe on it themselves (with all sorts of self-justifying reasons).
Is a difficult dilemma, but that's because an overly complicated scheme is used.
There is a simpler and more powerful scheme that unifies swapping and disk caches, while allowing applications to persist between reboots, all with better performance than current systems!
EROS implements such a system. Generally it is referred to as "Orthogonal persistence", and functionally it behaves as though the computer is "always on", and returns to the exact state it was in after a reboot. The thing is, with orthogonal persistence, the structure on the disk is not a file system, but just the application data.
Since applications no longer work with the disk explicitly (open/read/write) but only with one type of memory (persistent memory), the OS manages all of the disk I/O, and it allows it to eliminate almost completely the largest delay in disk-work - the seek time in all writes. Since all application memory is just mapped to disk transparently, all RAM is just considered a "disk cache", and the kernel does not have to make nasty tradeoffs between disk caches (of explicit open/read/write calls) and virtual memory.
Of course there is still a problem if large work-areas of unimportant applications "swap out" smaller areas of important applications. I suggest solving that by prioritizing pages to the memory manager. In a system like *nix it is not a problem. In more secure systems however (EROS, for instance), it may create additional covert channels between applications so it was avoided.
Slashdot Mirror
can already do that.
One step further in the actual enforcement of copyright is one step further in its abolishment.
People will not stand for copyright when it actually enforced.
I always open up a Python shell.
:-)
Its a much nicer calculator, among other things
A click-through license is not a binding contract. In fact, it is absolutely nothing, legally. Yes, EULA's are worthless pieces of text as well, and shown unenforceable in court.
Python has always scaled up well for me so far.
I admit to have only done medium-sized projects in Python, but in actuality, the vast majority of projects are of that size.
I do not anticipate any difficulties in scaling up Python (or any other sane language) programs, as they can always be broken to small interacting, largely-independent parts - which can be verified and tested separately.
If anything, Python's powerful abstractions make this easier as applying design patterns becomes near-trivial without the type-hassle.
You may think that Java is only used in applets/cell phones, but that is not even its primary ussage
I figured so, I was wondering why.
1) Scripting languages such as Python and Perl run at (and this is a very rough generalization, of course) 10% the speed of C++. Java runs at 80-90% the speed of C++. Unlike scripting languages, Java is compiled to very efficient native code as your program runs (this is part of the reason for slow Java startup time, the bytecode->native compiler is running at that point).
Have you tried psyco? A JIT compiler for Python. In some cases it makes Python code run faster than the equivalent straightforward C code.
In others, Python code still runs with very comparable speeds to C.
2) While you CAN write code more quickly in scripting languages, scripting languages don't scale well to large projects (by this I mean that development time slows down, not runtime performance). Right around the time when you hit ~1000 source files, you start to realize the value of static type safety.
Python's expressiveness is so great, that you typically get 10-to-1 reduction or more in code size between C++ and Python. The powerful abstractions in Python make this non-linear in Python's favor. I do not have data about the relation between Java and Python, but it is likely similar, as C++ and Java take around the same amounts of code to perform similar tasks, given the existence of libraries.
Thus a "large Python project" functionality-wise is quite a small one relatively to the equivalent Java one. I have written a lot of Python code, and scaling up is actually very easy in Python, as it is in every sane language in a sane environment of good developers.
3) Not having to do manual memory management really does save you a lot of development time over C++. This may not be apparent to you in a small 1-2 person project, but just wait until you're working in a 10-person project and the dumbass down the hall accidentally deletes the object you still have a reference to (or forgets to delete and then you have a memory leak).
Indeed, but writing 100% of a program in a low-level language like C++ is a thing of the past (and of the ignorant). You should typically write 10% (or less) of the code in a low-level language, because that code executes 90% of the time. In these small pieces of library code, memory management is not typically a big deal.
4) The standard API is very handy. Java comes with something like 10,000 classes built in. You're clearly not going to use these classes for the core of your project, but they're very useful for all the side things you have to do. Need to parse XML? Built in. Need to send an entire object graph over a socket? Built in. Need to draw a curve with anti-aliasing? Built in. Need to have 2 threads put stuff into a queue while a third takes stuff out? Built in. Need to load a JPEG or talk to a database through SQL? Built in. It goes on and on and on.
Funnily, all of the things you mentioned (except the anti-alised curve, not sure about that one) are also built-in in Python. So again, I can't see why that would be a factor.
Especially moot seems your point that for "side things" Java libs are great. These little "scripts" and "side things" are the classic example where Python is so much better than Java. Show me the code of any such "side thing" in Java, and I shall show you the much-simplified and more-powerful Python equivalent.
5) The tools are incredible. I was an emacs guy for ~10 years but I was willing to give up my keybinding memory because the IDEs on the Java side are so damned amazing. Check out IDEA (or Eclipse if you're broke). It grays out variables that you're not using. It lets you highlight a block of code and hit a key and it makes a method out of the code, replacing the previous block with a method call (and in the latest beta, it detects duplicates of the code block and also replaces those with the method call). Accident
Massive libraries, super development tools, tremedous skillbase availability, vast 3rd party support, large literature on best practices etc. etc. etc..
What libraries does Java have that are inaccessible to Python (Especially with Jython being avaialable)?
The development tools available for Python (xemacs, komodo, and various other IDE's) are all considered great. I have not personally used them and those of Java, have you? Can you write a few advantages of these tools during development?
The skillbase is surely a business factor when choosing Java. But when most create their own project, they can choose the language best fit technically - and that is not Java.
3rd party support and literature are not exactly lacking in Python and other alternatives either so that is a weak point as well.
Language features of marginal value (in some cases like dynamic typing the features can even be harmful to software reliability, making testing more complex and increasing the liklihood of runtime errors).
That is a common myth. Trusting the type-safety given to you by the compiler is not enough. You need to have run the code at least once to verify it is valid, and for that you must write unit-tests. If the code is not type-safe, then running it once in a dynamic OR static language will find the fault.
To say that generators, closures and other features not found in Java have marginal value is a sign of ignorance. Can you please describe those features and how they are typically used?
To underestimate the dynamic power of Python is also a sign of ignorance. Can you implement PyInvoke in Java? I challenge you to apply an RPC so easy to use as that.
Vastly superior toolchain starting with design and ending with installation and deployment. End of story.
Please describe why Java is superior, instead of uttering a chain of buzzwords.
What's the difference?
You need a UT framework for all your code anyhow, if it is going to run correctly and not just run safely, so what's the difference if its a compilation error, or a UT run error?
It seems that the usefulness of Java is limited to web applets/cellphone-apps and other specific things.
Judging from its popularity, it seems people are applying Java elsewhere. Why?
Java does not excel in performance, expressiveness, simplicity or power. It does not have generators, closures, dynamic typing and powerful dynamic features.
Why prefer Java over Python in the general case? If your answer is performance, why not choose Pyrex or C for the performance-critical parts, for a much better/faster result?
Maybe you should stick to one flavor then?
Those of us who type really fast prefer to write many of our programs from scratch :-)
They come with a distro, or as packages.
That's what people mean by saying "Linux" here in the discussion. Maybe RMS's "rant" about accurate naming is not so unnecessary.
I can download and install a Windows utility more quickly than I can build and install a Linux package.
Oh? Easier than "apt-get install kde", kpackage, synaptic, aptitude or the other package management frontends? These download the packages and all the dependencies for you.
These tools can also keep all (in the thousands) of your packages up-to-date (unlike Windows update which keeps perhaps 20 packages up-to-date).
The fact you are mentioning building these packages yourself as a difficulty means you probably haven't used a Linux distro since early Slackware days.
Why do we need the mediating storage anymore?
Why not move to use "instant messaging" methods of direct connectivity between the sender and recipient, and only falling back to server storage when necessary?
This allows for much better knowledge of successful/failed delivery.
It may move more control of message reception to the recipients, allowing them to implement extra protections. For example, requiring arbitrary/configurable amounts of computation on the behalf of the sender to send them a message (increasing the cost of a message send) (unless ofcourse the sender is on a white list of known correspondents).
Is any such transition feasible in the near future?
You can't lift the supply depot!
You should have tried Qt from Trolltech. Qt has had far more powerful widget layout than .Net has, for years.
The Qt Designer is still the best GUI designer out there.
is hardly the main productivity boost in people's programming environments. Sure it is a productivity boost, but not the main or even the biggest one.
The main productivity boost in Python, for example, is its dynamic typing. Its simplicity second, and automatic memory management as a third, perhaps.
Also, his claim that you don't have to debug memory leaks with Garbage Collection is a common fallacy. Garbage Collection makes it very possible to leak memory, often in more difficult ways to debug, since the developer is typically unaware of what memory is behind held by which objects as usually there is no need to put much thought into the issue.
until you try to do something too complex for Windows to handle, like find a file of an exact name, or directories that contain some files.
Not to mention shell scripting capabilities, or the ability to handle files that are already opened, and other awful annoyances Windows has. Then there's the fact that when you're a developer, it is kinda frustrating you cannot fix those annoying things and other bugs, because the source is closed.
Sure its better.
That is not lost revenue, as those people would never pay for it anyway. It is simply people using Windows rather than OSS, and has no effect on the outside world (except for the participation in the distribution of worms).
If pirating is infringing on copyrights, I don't get it.
What did they steal? From whom?
It is the language's fault for making it difficult to track memory, and it is Windows' fault for making things difficult enough for the user to make a mistake.
When I have the Python/Pyrex/C hybrid?
Python is at least as portable for all practical needs, and far more expressive.
Python is already Free Software, so why use Java?
in the long awaited death of copyright, which is simply absurd in the Digital Age.
You violate copyright, he violates copyright, everyone violates copyright because society cannot accept such limitation on freedom. Of course you only violate copyright because the songs are too expensive, or because you can't afford it, or because nobody knows and you wouldn't buy it anyhow. That self-righteousness is what all copyright abusers who tend to support copyright say. The support copyright has is a result only of the lack of enforcement - and thus copyright enforcement is a necessary and positive step in its ultimate destruction.
What exactly did the "pirates" take from anyone such that he does not have it now? Nothing, thus its not theft.
No, they did not "take" the money they would have paid, because saying that you're assuming that they would have paid anything in the first place, and that taking away something someone never had is theft. Its not.
Demonizing those who do not believe strong limitations on the freedom of everyone are necessary to create an incentive is worse than the act of "piracy" (Ok, lets try to say copyright infringement from now on, thank you).
Everyone infringes on software copyrights, except very few people (probably you, too), and once we have effective DRM, we shall see that. We will probably also see software copyright being undone or severely crippled. I don't think people would go along with this.
Software copyrights must be abolished. Vote with your software, use Free Software or at least don't pay for software.
Calling information sharing and helping a friend in nasty names.
If these video games wouldn't exist in order for us to regain the freedom to do these things - then video games should not exist, they are not worth our freedom.
I would never buy a copyright-protected piece of software because it is against my principles, and I also try to avoid infringing on existing copyrights because that also encourages the general use of the copyright-protected software.
Almost all of those who still support copyright only do so because it is unenforced, and they infringe on it themselves (with all sorts of self-justifying reasons).
Is a difficult dilemma, but that's because an overly complicated scheme is used.
There is a simpler and more powerful scheme that unifies swapping and disk caches, while allowing applications to persist between reboots, all with better performance than current systems!
EROS implements such a system. Generally it is referred to as "Orthogonal persistence", and functionally it behaves as though the computer is "always on", and returns to the exact state it was in after a reboot. The thing is, with orthogonal persistence, the structure on the disk is not a file system, but just the application data.
Since applications no longer work with the disk explicitly (open/read/write) but only with one type of memory (persistent memory), the OS manages all of the disk I/O, and it allows it to eliminate almost completely the largest delay in disk-work - the seek time in all writes. Since all application memory is just mapped to disk transparently, all RAM is just considered a "disk cache", and the kernel does not have to make nasty tradeoffs between disk caches (of explicit open/read/write calls) and virtual memory.
Of course there is still a problem if large work-areas of unimportant applications "swap out" smaller areas of important applications. I suggest solving that by prioritizing pages to the memory manager. In a system like *nix it is not a problem. In more secure systems however (EROS, for instance), it may create additional covert channels between applications so it was avoided.