The worst thing that can happen to copyright
on
Kazaa Owners Risk Jail
·
· Score: 2, Insightful
The worst thing that can happen to copyright -- is it being enforced.
If 30% of the US's population gets huge fines and jailtime for their copyright infringements and/or DMCA violations. If 90% of Israel's population gets jailtime for their copyright infringements. If similar numbers occur in various countries around the world...
It actually states it as its goal. It had intended on "taking C++ programmers and moving them half-way towards Lisp" and in that they succeeded.
But as a productive language, it is quite miserable, when compared with Python or other excellent languages.
And maybe it is just me, but my experience with Java apps is quite horrible. Learning that something was written in Java immediately lowers my expectations of it.
Like the famous quote says, "Linux is only free if your time has no value". It's a great operating system and superior to Windows in a lot of ways. However, ease of use counts for something, you know?
Bah. Cheap demogagy. Ease of use counts for a lot. That's why I use a KDE desktop, and not the various Windows desktops. They are so 90's.:P
I want my one-click centralized package listing.
I want my one-click upgrade of all software installed (Not just a specific vendor).
I want my virtual desktops.
I want access to all file system types (ftp, samba, sftp, etc) in _all_ of my file dialogs in all apps.
I want to see the contents of small text icons, and of web pages, in the thumbnails representing them.
I want to be able to drag & drop, copy & paste files between ftp's.
I want to be able to see tomorrow's weather in my panel.
I want to save all of my passwords from all applications in a single wallet.
I want tabbed powerful command lines.
I want my apps to respect me, not popup update dialogs on top of the movies I am watching.
I want my browser to keep my forms filled when I press the back button.
I want my menus to be organized by function, and not by vendor (The Windows Start->Programs menu is not scalable and becomes useless!)
I want my clipboard to have multiple entries.
I want to be able to click "always on top" on a button I can configure on all of my windows' title bars.
I want new windows created not to always be placed in the center, hiding windows, but to use free space.
There are literally hundreds or thousands of usability and ease of use improvements in the KDE desktop! Windows just fell behind, about 2 years ago.
Ease of use does matter, that's one of the reasons why I don't use Windows.
The point is not that Linux is inherently less powerful.
Its that for certain kinds of purposes, the current situation in the real world, is that, for no good technical reason, software only exists for Windows.
Due to this unfortunate situation, Windows is superior at achieving certain real world tasks.
People who just accept this and go through the path of ethical lazyness get bitten in the ass by the lockin they are themselves creating.
While the Visual Studio debugger has some nice features that gdb frontends lack:
Partial recompilation during runtime
Convinient stepping into assembly code
The two are largely equivalent.
I use emacs gdbsrc mode to debug my code, and I can set breakpoints, conditional breakpoints, step in, step over, print any expression, or call any function I want in the debugger. If I recall correctly, you cannot really manually call functions in the Visual Studio debugger, but correct me if I'm wrong.
There are also advantages to gdb frontends though:
They are more scriptable. You can run write code to execute at the debug breakpoint, not only for conditionally breakpointing, but also to modify the behaviour of the program.
The same debugger can debug accross multiple languages (this may be true with VS.Net, I have used the VS6 debugger).
Please explain what extra productivity or features you gain from the Windows debugger.
As for your selection of tools:
vim: I prefer Emacs:-)
gmake: Nice for tiny projects. Does not scale up. There are better alternatives (SCons, Python's distutils, Ant, etc).
Sure, you could redefine theft to include the lack of transfer of funds as may be required by the combination of law and license, or other definitions, but please don't.
The word theft is more useful when it refers to the act of reducing an owner's posession in order to increase someone else's.
When copying, you are merely increasing the posession of one, and not decreasing the posession of another.
Sure, you're violating what he demanded of you. Sure, you're violating the law. Sure, you're doing something many consider wrong.
But you're not stealing. Stop changing English in non-useful ways!
Its being repeated again and again, and people are actually taking it seriously. Calm down, people, the EULA is just a piece of paper, or a dialog box, void of any legal meaning.
"Linux" does not need uniformity! "Linux" is just a kernel!
There are plenty of crap OS's based on Linux, you are free to ignore them, I do!
Just choose one good OS (whether it is Linux-based or any other), and judge it on its own merits. It is not a disadvantage of Debian or another, that some other Crappo-Linux-based OS sucks.
I actually believe in no copyright on software, and a very short copyright term for art. Not because I believe it is crucial for the survival of art, but because I believe art is luxury, cannot cause "lock-in", and limitation on freedom there is just less problematic.
As for music copyrights, though, if you ever asked musicians what they would do if there was no copyright, they would tell you they'd continue to create music, because they love music. At least a significant percentage of them would say that. Whether or not this would actually happen, we can only know by trying. Musicians also have non-copyright means to make money.
This is actually a result of a lot of thought, and the only result that can be reached is agnostic. If you are sure that without Software copyrights the world will crumble down, then you have not thought it through. If you are sure that there will be no problems whatsoever, then you have also not thought it through.
I believe it is likely that it will not be problematic almost at all, and I am pretty sure that the gain will be much bigger than the loss, but the only way to know is by trying.
I would say that copyrights do more damage than good. I am far more certain of this in the case of software copyrights, than I am in the case of art, but I believe a test period of a few years (10-20) in a large country should teach us whether or not the burden on society is justifiable.
As for GPL and Copyright, it is not a contradiction to support one and disapprove of the other. GPL is a means to fight fire with fire. Once no copyright exists, there is no need for the GPL.
As for the class-definition macro example, if there's some way to do that in Python, that's great. I'm curious, though, what you do for syntax -- you still have to create a syntax for the high-level class definitions, and write a parser for that syntax, do you not?
Nope, you can just write a function that makes a class, for example:
I did not compare Lisp to C++. I compared macros to functions-accepting-closures.
C++ does not even have closures, so your comparison is a strawman.
The situation you are talking about is very possible in a dynamic language that can define a new class in a function. Its very possible to implement this in Python, with as little redundancy as in Lisp.
Actually [] denotes a closure in Smalltalk, and "do" may as well be called "doWhile" (it may called doWhile, its been a while since I used it). Its quite clear that a method called doWhile and takes a conditional closure argument and a body closure argument uses the predicate to determine whether to execute the body.
The fact it is being enclosed in a closure means that it is not evaluated here, but in the called "doWhile" method.
In an equivalent macro:
(do (< a 10)...)
it seems as though the (< i 10) expression is evaluated here and now, and not every iteration. This is the quirky evaluation behaviour I was talking about.
When I read somebody's code, I want him to be a coder, not a language designer, because I am willing to learn how his code works, but don't want to learn a new language every time I read a program.
Well, you're free to think that, but that's not the point. You say that functions taking closures are equivalently powerful to macros. If one can do things the other cannot, then that's not true, is it?
Technically, macros are stronger, by allowing to define new syntax and not just new semantics. I just don't think this extra tLisp echnical strength actually empowers the programmer in real-world scenarios.
The only "real-world examples" I've seen here to where macros actually add power that functions don't, is when they were used to extend already-macro-based systems, in which there's no way to use a function to "wrap" a macro. If all macros are replaced with functions, then suddenly it is possible to do all those things.
Also, I agree that a weak language with macros is much better than a weak language without them. But in my experience, especially seeing what macros are used for, is that a strong language does not require macros.
I think every problem I've seen solved by Lisp is solved at least almost as adequately, and in almost all cases, more simply and with a clearer syntax, by Python.
This presupposes that your language allows you access to the symbol table at runtime. In Lisp, most named function references are resolved at compile-time. Again, if you assume features the base language doesn't have, then you can always come up with a rebuttel. But the point is that macros are a single construct that can extend the base language, while here you are constantly inventing base language functionality for each thing that can be handled by macros!
Actually, I regret using the caller_namespace() hack altogether. You should use an explicit assignment in such a case, but it would force you to name the function twice. That's why Python does have a special syntax for assignment+naming in the same time.
I do think that the number of syntaxes required in a language, to solve the vast majority of problems is a finite number, and that the evolution of languages has already discovered all or almost all of this required syntax. As such, permissing new syntax for the supposed cases of lacking syntax, is not worth the readability it takes away from programs.
I can read programs in almost any language with virtually no learning curve, but I can say reading Lisp code, and defmacro's is much more of a challenge, despite knowing the concepts very well.
Maybe there's a way, in theory, to create a language with macros that doesn't suffer from such readability problems and a horrible learning curve, but for now, it does not seem so.
Lisp programs are not, as you would expect according to the claims you stand behind, orders of magnitude smaller than the equivalent Python, Smalltalk or Ruby programs.
But CLOS is heavily based on macros in the first place. So it would be hard to extend it in other ways. A system based on closures would allow modifying it by giving different closures.
When the multimethod definition of CLOS itself is a macro, how am I supposed to use a function to call a macro differently? You are assuming macros as a basis, and then explaining that closures cannot extend them as macros can. If you take the equivalent multimethod system that's not based on macros, it becomes extensible without macros.
Python does not support very nice closure syntax, so it is indeed difficult. But my argument is not about Python vs. Lisp, its about macros and their necessity.
Look at the implementation of loops in Smalltalk, they are implemented as methods that take closures and range objects, i.e:
[i <= 10] doUntil: [ i |.... ]
[i > 10] doWhile: [ i |.... ]
I find this very readable, and it does not have to break the evaluation rules of the language.
Slashdot Mirror
The worst thing that can happen to copyright -- is it being enforced.
If 30% of the US's population gets huge fines and jailtime for their copyright infringements and/or DMCA violations.
If 90% of Israel's population gets jailtime for their copyright infringements.
If similar numbers occur in various countries around the world...
Copyright will be abolished.
It actually states it as its goal.
It had intended on "taking C++ programmers and moving them half-way towards Lisp" and in that they succeeded.
But as a productive language, it is quite miserable, when compared with Python or other excellent languages.
And maybe it is just me, but my experience with Java apps is quite horrible. Learning that something was written in Java immediately lowers my expectations of it.
Who ever said that you had to type in a "domain name" anyhow?
The solution is to type something shorter than the domain name, not to make domain names shorter.
And guess what, the solution already works: When I type "slashdot" in my browser I already get to slashdot.
BSD/Public domain software is Opensource, but not Free software.
Bah. Cheap demogagy. Ease of use counts for a lot. That's why I use a KDE desktop, and not the various Windows desktops. They are so 90's.
Ease of use does matter, that's one of the reasons why I don't use Windows.
You changed the question though.
Nobody asked who is to blame. Ofcourse Linux is not to blame.
That's just not the point.
The point is not that Linux is inherently less powerful.
Its that for certain kinds of purposes, the current situation in the real world, is that, for no good technical reason, software only exists for Windows.
Due to this unfortunate situation, Windows is superior at achieving certain real world tasks.
People who just accept this and go through the path of ethical lazyness get bitten in the ass by the lockin they are themselves creating.
The two are largely equivalent.
I use emacs gdbsrc mode to debug my code, and I can set breakpoints, conditional breakpoints, step in, step over, print any expression, or call any function I want in the debugger. If I recall correctly, you cannot really manually call functions in the Visual Studio debugger, but correct me if I'm wrong.
There are also advantages to gdb frontends though:
Please explain what extra productivity or features you gain from the Windows debugger.
As for your selection of tools:
Is the correct term.
Sure, you could redefine theft to include the lack of transfer of funds as may be required by the combination of law and license, or other definitions, but please don't.
The word theft is more useful when it refers to the act of reducing an owner's posession in order to increase someone else's.
When copying, you are merely increasing the posession of one, and not decreasing the posession of another.
Sure, you're violating what he demanded of you.
Sure, you're violating the law.
Sure, you're doing something many consider wrong.
But you're not stealing. Stop changing English in non-useful ways!
Maybe, Aids is in fact the largest mistake in medical history.
Its being repeated again and again, and people are actually taking it seriously.
Calm down, people, the EULA is just a piece of paper, or a dialog box, void of any legal meaning.
Where is the power of the EULA derived from?
In my country (Israel), only a written signature or a verbal agreement constitutes a contract. Clicking "I Agree" buttons bears no legal meaning.
So is the EULA legally valid, or is it based on the repetition like a "big lie" until people learn to believe that it is true?
until you click "accept"
And according to the law in many states, not even then!
Only written signatures or verbal consent form an agreement.
"Linux" does not need uniformity!
"Linux" is just a kernel!
There are plenty of crap OS's based on Linux, you are free to ignore them, I do!
Just choose one good OS (whether it is Linux-based or any other), and judge it on its own merits.
It is not a disadvantage of Debian or another, that some other Crappo-Linux-based OS sucks.
I actually believe in no copyright on software, and a very short copyright term for art. Not because I believe it is crucial for the survival of art, but because I believe art is luxury, cannot cause "lock-in", and limitation on freedom there is just less problematic.
As for music copyrights, though, if you ever asked musicians what they would do if there was no copyright, they would tell you they'd continue to create music, because they love music. At least a significant percentage of them would say that. Whether or not this would actually happen, we can only know by trying. Musicians also have non-copyright means to make money.
This is actually a result of a lot of thought, and the only result that can be reached is agnostic. If you are sure that without Software copyrights the world will crumble down, then you have not thought it through. If you are sure that there will be no problems whatsoever, then you have also not thought it through.
I believe it is likely that it will not be problematic almost at all, and I am pretty sure that the gain will be much bigger than the loss, but the only way to know is by trying.
I would say that copyrights do more damage than good. I am far more certain of this in the case of software copyrights, than I am in the case of art, but I believe a test period of a few years (10-20) in a large country should teach us whether or not the burden on society is justifiable.
As for GPL and Copyright, it is not a contradiction to support one and disapprove of the other. GPL is a means to fight fire with fire. Once no copyright exists, there is no need for the GPL.
If he didn't create the Earth? What did he do?
Why do you believe he exists?
I own a PDA exclusively for the use as a Destinator, with a GPS.
Well, actually, I recently started using it for music too, but I think that's just a fad.
The only purpose Mono actually serves is to feed the myth that .NET is any more portable than ordinary Win32 programming.
As for the class-definition macro example, if there's some way to do that in Python, that's great. I'm curious, though, what you do for syntax -- you still have to create a syntax for the high-level class definitions, and write a parser for that syntax, do you not?
Nope, you can just write a function that makes a class, for example:
def f(base, bleh):
class TempClass(base):
blah = bleh
def bluh(self, x):
return bleh*2
TempClass.__name__ = 'bleh_class'
return TempClass
I did not compare Lisp to C++. I compared macros to functions-accepting-closures.
C++ does not even have closures, so your comparison is a strawman.
The situation you are talking about is very possible in a dynamic language that can define a new class in a function. Its very possible to implement this in Python, with as little redundancy as in Lisp.
Actually [] denotes a closure in Smalltalk, and "do" may as well be called "doWhile" (it may called doWhile, its been a while since I used it). Its quite clear that a method called doWhile and takes a conditional closure argument and a body closure argument uses the predicate to determine whether to execute the body.
...)
The fact it is being enclosed in a closure means that it is not evaluated here, but in the called "doWhile" method.
In an equivalent macro:
(do (< a 10)
it seems as though the (< i 10) expression is evaluated here and now, and not every iteration. This is the quirky evaluation behaviour I was talking about.
When I read somebody's code, I want him to be a coder, not a language designer, because I am willing to learn how his code works, but don't want to learn a new language every time I read a program.
Well, you're free to think that, but that's not the point. You say that functions taking closures are equivalently powerful to macros. If one can do things the other cannot, then that's not true, is it?
Technically, macros are stronger, by allowing to define new syntax and not just new semantics. I just don't think this extra tLisp echnical strength actually empowers the programmer in real-world scenarios.
The only "real-world examples" I've seen here to where macros actually add power that functions don't, is when they were used to extend already-macro-based systems, in which there's no way to use a function to "wrap" a macro. If all macros are replaced with functions, then suddenly it is possible to do all those things.
Also, I agree that a weak language with macros is much better than a weak language without them. But in my experience, especially seeing what macros are used for, is that a strong language does not require macros.
I think every problem I've seen solved by Lisp is solved at least almost as adequately, and in almost all cases, more simply and with a clearer syntax, by Python.
This presupposes that your language allows you access to the symbol table at runtime. In Lisp, most named function references are resolved at compile-time. Again, if you assume features the base language doesn't have, then you can always come up with a rebuttel. But the point is that macros are a single construct that can extend the base language, while here you are constantly inventing base language functionality for each thing that can be handled by macros!
Actually, I regret using the caller_namespace() hack altogether. You should use an explicit assignment in such a case, but it would force you to name the function twice. That's why Python does have a special syntax for assignment+naming in the same time.
I do think that the number of syntaxes required in a language, to solve the vast majority of problems is a finite number, and that the evolution of languages has already discovered all or almost all of this required syntax. As such, permissing new syntax for the supposed cases of lacking syntax, is not worth the readability it takes away from programs.
I can read programs in almost any language with virtually no learning curve, but I can say reading Lisp code, and defmacro's is much more of a challenge, despite knowing the concepts very well.
Maybe there's a way, in theory, to create a language with macros that doesn't suffer from such readability problems and a horrible learning curve, but for now, it does not seem so.
Lisp programs are not, as you would expect according to the claims you stand behind, orders of magnitude smaller than the equivalent Python, Smalltalk or Ruby programs.
But CLOS is heavily based on macros in the first place. So it would be hard to extend it in other ways. A system based on closures would allow modifying it by giving different closures.
When the multimethod definition of CLOS itself is a macro, how am I supposed to use a function to call a macro differently? You are assuming macros as a basis, and then explaining that closures cannot extend them as macros can. If you take the equivalent multimethod system that's not based on macros, it becomes extensible without macros.
Python does not support very nice closure syntax, so it is indeed difficult. But my argument is not about Python vs. Lisp, its about macros and their necessity.
.. ..
.. ..
Look at the implementation of loops in Smalltalk, they are implemented as methods that take closures and range objects, i.e:
[i <= 10] doUntil: [ i |
]
[i > 10] doWhile: [ i |
]
I find this very readable, and it does not have to break the evaluation rules of the language.