Er, if you do buy CDs from the bands you like the sound of, why do you have any illegal MP3s in your collection at all? Do you just like accumulating music you don't want?
I suspect it's making collections without ultimately paying for the material that has the RIAA upset. And I don't blame 'em: like it or not, some people (e.g. computer programmers and musicians) make their living out if IP and if you don't reimburse them for what you take then you are stealing from them.
Say I buy a film reel and then an absolutely massive projector and screen and then lots of people turn up thinking it's a cinema and watch the film for nothing, how is that my fault for affecting local cinema ticket/DVD/VHS sales/rentals?
Strewth. The RIAA might be going about things arse-about-face, but do you honestly think the artists are going to thank you for shafting them?
Some fundamental performance problems for Java are caused by the language design and have nothing to do with going via an intermediate VM language (jitted or not.)
Java's weak type system does not support parametric polymorphism (or "generics" to everybody in OO-land) hence your code has to be sprinkled with downcasts from `object' (e.g. when looking up a value in a general purpose hash table); these are not cheap and their ubiquity costs big-time.
There is no sensible, safe, efficient way to implement algebraic data types.
It is almost impossible to have structured values with a small memory footprint.
The lack of support for closures is a pain; inner classes are something of a poor-man's solution to the problem.
Poor requirements specification (e.g. specifying the platform and/or the language in the requirements - a big mistake, especially when the language they specify results in code riddled with buffer overflows)
Are you seriously suggesting that a customer is going to specify "nobody will ever type more than twenty characters into this field and we require you not to bloat the application by checking for overflow etc."?
Overflow bugs and so forth are all bloody amateur mistakes to make in any language (although if universities were not pretty much required to teach non-stop Java/C#/C++/VB/... we could actually teach you some serious languages that would make all the difference.)
For the clueless, one might posit the following factors as being part of the picture:
too hot => everything's on fire and your chemistry is too fast and somewhat limited;
too cold => everything's frozen and your chemistry is too slow and somewhat limited;
too much gravity => everything's heavy and it takes a great deal of energy to do anything (although one could imagine atmosphere dwellers in the same way as we have deep sea fauna);
too little gravity => hard to hold on to an atmosphere, which may make it hard to hold on to surface liquids, which in turn leaves you with slow and limited solids chemistry.
I think you misunderstand the so-called wheel of reincarnation.
Throughout the history of computing, the rule has been that special-purpose co-processing devices have inevitably been retired in favour of doing the work on the main CPU (e.g. some may remember the days when paging and so forth was handled by a separate chip.)
The thing is that vastly more effort goes into improving the general device than the special-purpose device.
More to the point, the special purpose chips are exactly that: they exist because there are currently some things it is currently cheaper to throw hardware at than to do on the main CPU. While we have seen truly stellar improvements in graphics performance, you should not confuse this with generality. The CPU and the GPU are quite different animals.
The RISC philosophy is to include instructions that do the most work for the least cost, hence MMX and friends. On the other hand, I can't see a GPU generalising into a CPU of any merit.
This is going to go down like a cup of cold sick, but...
If you do this sort of thing for a living, it would pay to look into alternative tools that make your life easier. For instance, check out the available Haskell web/CGI/HTML/XML libraries. Coding plain and interactive web interfaces that are rock solid is so much easier it's not funny. A whole raft of bug classes are simply impossible using these schemes.
By the way, before anybody says otherwise, Haskell is a serious, full-blown industrial strength language.
I would argue that MS has lost pirated_copies * list_price.
It works like this:
if everyone (n) pays list price (p) for what they use, then MS grosses n * p;
however, if some number of criminals (c) do not pay for what they use, then MS only grosses (n - c) * p.
Net result: MS is out of pocket by c * p.
Put another way, pirating from MS effectively reduces the list price - the honest types end up subsidising the criminals (one might assume that MS has taken expected piracy into account when deciding on the list price.)
Under this line of reasoning, the fact that some users of the pirated software would never have paid even if they were willing and able to is neither here nor there: the fact is that either MS gets shafted if they assume 100% honesty when setting prices or the honest consumers get shafted because MS doesn't assume 100% honesty and consequently hikes up the price.
Let me draw an analogy. Say I spend a significant amount of time and money doing some research and I am awarded a patent for the results. (For the sake of argument, let us assume that the research was non-trivial and the patent is justified.) I plan to recoup the cost of the research by licensing the rights to my patented technology. Now you come along, reasoning thus: "I could really benefit from using Ralph's patented technology, but I am unwilling to pay for it. Therefore I am justified in using Ralph's technology and not paying for the right to do so, since I will not be stealing material good from Ralph." Have I lost out? Certainly. You are expecting to make a profit at my expense, yet I am not reimbursed for my effort and investment. The only reason I carried out the research in the first place was to make a living. Note that it is up to me to decide the licensing fee - if I set it too high, law abiding/socially responsible people will look for alternatives and I will lose out. If I set it too low with respect to the number of customers, I also lose out. You may disagree with my decision on the fee, but I am the one taking the risk.
The same argument also works for software (and music and so forth...)
So, going back to your original post, you seem to be advocating that "theft [of material goods]" is bad, but "theft of service [or freely reproducible goods]" carries no guilt.
I take it that you are not considering a career where revenue is generated from IP?
- Ralph
p.s. Given the excitable nature of this forum, I feel bound to point out that while I feel that current IP legislation is up the creek, I also believe that making a living from IP is perfectly reasonable.
Au contraire. If the originators had bothered to talk to any half-decent academics, you wouldn't have this mess.
For Heaven's sake, XML is pretty much just an extraordinarily verbose way of describing tree structures. There are issues of naming, cross referencing, quotation, and grammatical correctness - none of which are hard problems (although the prevalent hack-it-and-ship-it mentality consistently screws up; we should teach more basic theory and less Java/C++/object-babble at universities...)
Such words of wisdom as I've been able to muster in two decades of experience:
Comments are vital, but like all programming tools require judicious use to be effective.
It is easy for large comments to fall out of sync. with the code, so large comments should generally be reserved for high-level documentation of the kind one would expect to find in a literate program. Prefer a pointer (say, a URL) to a document explaining an algorithm than a block of text explaining the algorithm.
Brief comments on types and data constructors are vital where their use is not obvious. The same goes for functions, methods and procedures.
Function bodies should be small: it is better to have several small, easily understood functions (with names that clearly convey what they do) than one large block of code.
Use of formal language in comments keeps them short and clear. Compare the following:
take(N, Xs) is the first min(N, length(Xs)) members of the list Xs;
take(N, Xs) returns the first N members of the list Xs or the entire list if there are fewer than N members of Xs.
The term 'list' can be omitted if the function has an explicit type signature (even if your language is untyped, specifying types somewhere is invaluable documentation.) Another point to note is that these comments make clear what happens when N > length(Xs) - you should specify what happens in all circumstances, even if that just means saying "if these conditions are not met then the behaviour is unspecified."
Including sanity checks in code is a useful alternative to documentation.
It is a very good idea to annotate code with the invariants that should obtain at key points.
Eschew clever code. Nobody will be impressed and it's a maintenance nightmare. And you'd better be very sure you got it right...
Don't cut corners. Include *all* the error checks. Learning how to write elegant robust code is what distinguishes real programmers from cowboys. Managing both is an acquired skill.
Avoid globals. Seriously.
State and mutable update lead to unreusability, bugs, madness and divorce. Learn a functional programming language (add smiley if that helps).
Someone once said words to the effect that if you find yourself writing a bulky comment, ask yourself if you could restructure your code so as to make the comment unnecessary.
As with OOP itself, generic programming is a Really Good Idea
Despite the hype and received wisdom, it should be noted that OOP has singularly failed to deliver.
[plug] Take a look at the modern declarative languages (Mercury, Haskell, Clean, OCaml) to see how much easier life can be with modern languages. Mercury's foreign language interface is second to none - you can even write C/C++/whatever in-line. [/plug]
If your design brief specifies scalability to internet sized communities then you'd better take that into account early on in the design. Like security, it isn't something that can be effectively retrofitted.
The point I'm trying to make is that for a very large number of engineering problems there will be existing work done on the problem which should be examined before leaping in feet first. I thought this was one of the things CS degrees were supposed to teach.
In this case it seems that due attention was paid neither to the design objectives or the literature on the subject.
No, the complaint is not about the concept, but the gross lack of understanding exhibited in the design.
There are well known workable epidemic algorithms suitable for P2P that have been around for a long time. They generally provide statistical guarantees of success in return for scalable use of bandwidth.
Epidemic distributed systems should not be attempted by people who do not grok exponential growth. Planning for somebody wiser to innovate around your mess is not responsible.
One other thing: if you think that the remaining 60% of gun related deaths in the US were due to honest citizens defending themselves then you're dead wrong. Almost all of that 60% are suicides with a tiny smattering of accidental shootings. Worse, for every gun related death in the US there are two more gun related injuries (and despite what Hollywood might have us believe, gunshot wounds are serious.)
The CDC reported that in 1998 there were 30708 gun-related deaths in the US - that is, 114 deaths per million by population. 40% of the deaths were murders - that is, 45.6 murders committed with a gun per million by population.
In the UK there were 4.1 deaths per million by population in 1998 (I can't find figures giving the ratio of murders.)
The statistics for death by viewing porn (accidentally or otherwise) are hard to come by, but I'd wager they're vanishingly small.
Conclusion: if censorship and gun control are comparable at all then in terms of preservation of life you should focus on gun control.
I confess to being somewhat skeptical about claims that Intel developed an asynchronous Pentium that ran three times faster than its clocked cousins and on half the power. Why, pray tell, would such a thing not have gone straight to market?
Asynchronous design is aimed at low power applications, not high speeds. Asynchronous design is more energy efficient because state only changes when necessary, rather than on every clock tick. The cost of this is something like a three-fold increase in the on-chip logic to arrange for all the handshaking signals used between logic blocks to indicate that results are available for the next processing stage. This extra logic costs both in terms of silicon real estate (i.e. you have less room for on-chip cache) and in processing time (there are more gate delays between each processing stage).
Synchronous design is fast (a) because you set your clock rate as high as possible, limited by the longest gate delay in the circuit, and (b) because you can use all that extra silicon for cache which saves you from really taking it in the pants when you have to go to off-chip memory. One way of raising the clock speed (if that's your goal) is to reduce the gate delay for each processing stage, hence the longer pipelines of simpler stages as seen in the Pentium IV.
There is a problem of distributing a clock signal over the entire surface of a chip (capacitance effects come into play), so I am prepared to believe that there may be room for asynchronous interfaces between the larger logic blocks on a chip, but otherwise I very much doubt that largely asynchronous design as practised today will outperform clocked logic.
You're assuming that an OS has to work in multiple address spaces. This is not true. There is no reason why you can't share a single address space between all processes, each having their own access rights. Once you have such a thing, processes communicate via shared memory without the need for *any* kernel involvement. Check out the Nemesis OS work done at Cambridge University.
FOR THE LAST TIME, THE ICFP CHALLENGES ARE NOT TAILORED FOR DECLARATIVE LANGUAGES!
Do you think language researchers sit around thinking, "Hmm, today I will add yet another obscure and utility-free aspect to my carefully-constructed-to-be-useless language"?
These languages are designed for universal utility and/or to do research into better ways to solve problems faced by contemporary programmers working with C/C++/Java/... They are not niche languages.
It would be so nice if people would go and try these things out for real before spouting this sort of utility-divide crap.
It would be smashing if the results of the last four ICFP contests (the declarative languages generally left the imperative ones standing) at least encouraged more hackers to try functional programming and see what all the fuss is about.
For the record, the ICFP problems can hardly be said to be tailored to FPLs, although there probably is some truth in the suggestion that you get a higher proportion of docs/post-docs using them (lo! another hint!)
Slashdot Mirror
The WWF's science, figures, and publicity tactics are all way open to question.
It seems the world is in fine shape.
Er, if you do buy CDs from the bands you like the sound of, why do you have any illegal MP3s in your collection at all? Do you just like accumulating music you don't want?
I suspect it's making collections without ultimately paying for the material that has the RIAA upset. And I don't blame 'em: like it or not, some people (e.g. computer programmers and musicians) make their living out if IP and if you don't reimburse them for what you take then you are stealing from them.
Say I buy a film reel and then an absolutely massive projector and screen and then lots of people turn up thinking it's a cinema and watch the film for nothing, how is that my fault for affecting local cinema ticket/DVD/VHS sales/rentals?
Strewth. The RIAA might be going about things arse-about-face, but do you honestly think the artists are going to thank you for shafting them?
There is a simple, effective answer. Make sure you supply the phone number of a telemarketing firm on the forms instead.
Anyone seriously interested in VM work should take a look at VMGen, which does a great deal of the hard work for you and produces high quality output.
- Ralph
Poor requirements specification (e.g. specifying the platform and/or the language in the requirements - a big mistake, especially when the language they specify results in code riddled with buffer overflows)
Are you seriously suggesting that a customer is going to specify "nobody will ever type more than twenty characters into this field and we require you not to bloat the application by checking for overflow etc."?
Overflow bugs and so forth are all bloody amateur mistakes to make in any language (although if universities were not pretty much required to teach non-stop Java/C#/C++/VB/... we could actually teach you some serious languages that would make all the difference.)
For the clueless, one might posit the following factors as being part of the picture:
I think you misunderstand the so-called wheel of reincarnation.
Throughout the history of computing, the rule has been that special-purpose co-processing devices have inevitably been retired in favour of doing the work on the main CPU (e.g. some may remember the days when paging and so forth was handled by a separate chip.)
The thing is that vastly more effort goes into improving the general device than the special-purpose device.
More to the point, the special purpose chips are exactly that: they exist because there are currently some things it is currently cheaper to throw hardware at than to do on the main CPU. While we have seen truly stellar improvements in graphics performance, you should not confuse this with generality. The CPU and the GPU are quite different animals.
The RISC philosophy is to include instructions that do the most work for the least cost, hence MMX and friends. On the other hand, I can't see a GPU generalising into a CPU of any merit.
This is going to go down like a cup of cold sick, but...
If you do this sort of thing for a living, it would pay to look into alternative tools that make your life easier. For instance, check out the available Haskell web/CGI/HTML/XML libraries. Coding plain and interactive web interfaces that are rock solid is so much easier it's not funny. A whole raft of bug classes are simply impossible using these schemes.
By the way, before anybody says otherwise, Haskell is a serious, full-blown industrial strength language.
It works like this:
Net result: MS is out of pocket by c * p.
Put another way, pirating from MS effectively reduces the list price - the honest types end up subsidising the criminals (one might assume that MS has taken expected piracy into account when deciding on the list price.)
Under this line of reasoning, the fact that some users of the pirated software would never have paid even if they were willing and able to is neither here nor there: the fact is that either MS gets shafted if they assume 100% honesty when setting prices or the honest consumers get shafted because MS doesn't assume 100% honesty and consequently hikes up the price.
This is specious.
Let me draw an analogy. Say I spend a significant amount of time and money doing some research and I am awarded a patent for the results. (For the sake of argument, let us assume that the research was non-trivial and the patent is justified.) I plan to recoup the cost of the research by licensing the rights to my patented technology. Now you come along, reasoning thus: "I could really benefit from using Ralph's patented technology, but I am unwilling to pay for it. Therefore I am justified in using Ralph's technology and not paying for the right to do so, since I will not be stealing material good from Ralph." Have I lost out? Certainly. You are expecting to make a profit at my expense, yet I am not reimbursed for my effort and investment. The only reason I carried out the research in the first place was to make a living. Note that it is up to me to decide the licensing fee - if I set it too high, law abiding/socially responsible people will look for alternatives and I will lose out. If I set it too low with respect to the number of customers, I also lose out. You may disagree with my decision on the fee, but I am the one taking the risk.
The same argument also works for software (and music and so forth...)
So, going back to your original post, you seem to be advocating that "theft [of material goods]" is bad, but "theft of service [or freely reproducible goods]" carries no guilt.
I take it that you are not considering a career where revenue is generated from IP?
- Ralph
p.s. Given the excitable nature of this forum, I feel bound to point out that while I feel that current IP legislation is up the creek, I also believe that making a living from IP is perfectly reasonable.
Au contraire. If the originators had bothered to talk to any half-decent academics, you wouldn't have this mess.
For Heaven's sake, XML is pretty much just an extraordinarily verbose way of describing tree structures. There are issues of naming, cross referencing, quotation, and grammatical correctness - none of which are hard problems (although the prevalent hack-it-and-ship-it mentality consistently screws up; we should teach more basic theory and less Java/C++/object-babble at universities...)
Comments are vital, but like all programming tools require judicious use to be effective.
It is easy for large comments to fall out of sync. with the code, so large comments should generally be reserved for high-level documentation of the kind one would expect to find in a literate program. Prefer a pointer (say, a URL) to a document explaining an algorithm than a block of text explaining the algorithm.
Brief comments on types and data constructors are vital where their use is not obvious. The same goes for functions, methods and procedures.
Function bodies should be small: it is better to have several small, easily understood functions (with names that clearly convey what they do) than one large block of code.
Use of formal language in comments keeps them short and clear. Compare the following:
The term 'list' can be omitted if the function has an explicit type signature (even if your language is untyped, specifying types somewhere is invaluable documentation.) Another point to note is that these comments make clear what happens when N > length(Xs) - you should specify what happens in all circumstances, even if that just means saying "if these conditions are not met then the behaviour is unspecified."
Including sanity checks in code is a useful alternative to documentation.
It is a very good idea to annotate code with the invariants that should obtain at key points.
Eschew clever code. Nobody will be impressed and it's a maintenance nightmare. And you'd better be very sure you got it right...
Don't cut corners. Include *all* the error checks. Learning how to write elegant robust code is what distinguishes real programmers from cowboys. Managing both is an acquired skill.
Avoid globals. Seriously.
State and mutable update lead to unreusability, bugs, madness and divorce. Learn a functional programming language (add smiley if that helps).
Someone once said words to the effect that if you find yourself writing a bulky comment, ask yourself if you could restructure your code so as to make the comment unnecessary.
- Ralph
As with OOP itself, generic programming is a Really Good Idea
Despite the hype and received wisdom, it should be noted that OOP has singularly failed to deliver.
[plug]
Take a look at the modern declarative languages (Mercury, Haskell, Clean, OCaml) to see how much easier life can be with modern languages. Mercury's foreign language interface is second to none - you can even write C/C++/whatever in-line.
[/plug]
If you agreed to work for somebody for only 7 bucks an hour, would you bother to do your job?
Yeah.. didn't think so.
If your design brief specifies scalability to internet sized communities then you'd better take that into account early on in the design. Like security, it isn't something that can be effectively retrofitted.
The point I'm trying to make is that for a very large number of engineering problems there will be existing work done on the problem which should be examined before leaping in feet first. I thought this was one of the things CS degrees were supposed to teach.
In this case it seems that due attention was paid neither to the design objectives or the literature on the subject.
No, the complaint is not about the concept, but the gross lack of understanding exhibited in the design.
There are well known workable epidemic algorithms suitable for P2P that have been around for a long time. They generally provide statistical guarantees of success in return for scalable use of bandwidth.
Epidemic distributed systems should not be attempted by people who do not grok exponential growth. Planning for somebody wiser to innovate around your mess is not responsible.
One other thing: if you think that the remaining 60% of gun related deaths in the US were due to honest citizens defending themselves then you're dead wrong. Almost all of that 60% are suicides with a tiny smattering of accidental shootings. Worse, for every gun related death in the US there are two more gun related injuries (and despite what Hollywood might have us believe, gunshot wounds are serious.)
This is ridiculous.
The CDC reported that in 1998 there were 30708 gun-related deaths in the US - that is, 114 deaths per million by population. 40% of the deaths were murders - that is, 45.6 murders committed with a gun per million by population.
In the UK there were 4.1 deaths per million by population in 1998 (I can't find figures giving the ratio of murders.)
The statistics for death by viewing porn (accidentally or otherwise) are hard to come by, but I'd wager they're vanishingly small.
Conclusion: if censorship and gun control are comparable at all then in terms of preservation of life you should focus on gun control.
I confess to being somewhat skeptical about claims that Intel developed an asynchronous Pentium that ran three times faster than its clocked cousins and on half the power. Why, pray tell, would such a thing not have gone straight to market?
Asynchronous design is aimed at low power applications, not high speeds. Asynchronous design is more energy efficient because state only changes when necessary, rather than on every clock tick. The cost of this is something like a three-fold increase in the on-chip logic to arrange for all the handshaking signals used between logic blocks to indicate that results are available for the next processing stage. This extra logic costs both in terms of silicon real estate (i.e. you have less room for on-chip cache) and in processing time (there are more gate delays between each processing stage).
Synchronous design is fast (a) because you set your clock rate as high as possible, limited by the longest gate delay in the circuit, and (b) because you can use all that extra silicon for cache which saves you from really taking it in the pants when you have to go to off-chip memory. One way of raising the clock speed (if that's your goal) is to reduce the gate delay for each processing stage, hence the longer pipelines of simpler stages as seen in the Pentium IV.
There is a problem of distributing a clock signal over the entire surface of a chip (capacitance effects come into play), so I am prepared to believe that there may be room for asynchronous interfaces between the larger logic blocks on a chip, but otherwise I very much doubt that largely asynchronous design as practised today will outperform clocked logic.
You're assuming that an OS has to work in multiple address spaces. This is not true. There is no reason why you can't share a single address space between all processes, each having their own access rights. Once you have such a thing, processes communicate via shared memory without the need for *any* kernel involvement. Check out the Nemesis OS work done at Cambridge University.
Yeah, and millions of Americans will realize that they're the biggest polluters of the planet and back off to a more modest, sustainable lifestyle.
Nahhhhhh. That won't happen either.
FOR THE LAST TIME, THE ICFP CHALLENGES ARE NOT TAILORED FOR DECLARATIVE LANGUAGES!
Do you think language researchers sit around thinking, "Hmm, today I will add yet another obscure and utility-free aspect to my carefully-constructed-to-be-useless language"?
These languages are designed for universal utility and/or to do research into better ways to solve problems faced by contemporary programmers working with C/C++/Java/... They are not niche languages.
It would be so nice if people would go and try these things out for real before spouting this sort of utility-divide crap.
It would be smashing if the results of the last four ICFP contests (the declarative languages generally left the imperative ones standing) at least encouraged more hackers to try functional programming and see what all the fuss is about.
For the record, the ICFP problems can hardly be said to be tailored to FPLs, although there probably is some truth in the suggestion that you get a higher proportion of docs/post-docs using them (lo! another hint!)