In which case, don't researchers have a duty to publish the program in order to help show the validity of their research, in all cases, not just this one?
I don't think so, because some research tools are just tools. If they can convince the reasership that their methodology is sound without spending the effort to clean up and distribute their tools, then that might be just fine. We don't currently have a culture where every artifact of the research process needs to be publicly available in order to have confidence in the results. (Again, because of the interest in the code and the controversy about their results, I think that in this case they really should be publishing their code to back up their method!)
I also believe that we should have higher standards of argument in our scientific papers (as a CS researcher I hope that soon many of our papers will be accompanied by machine-checkable proofs, as some are now, for instance). However, source code is, in the current scientific culture, not much different from other kinds of artifacts (lab notebooks) that remain private, and that is the basis of my position.
The perfect SDK, to me, has a "two faced" nature. The first face is a dumbed-down thing that makes it easy to get started, or to use some shallow function of the SDK as part of a project that's mostly focused on something else.
1. It should be easy to do an obvious thing with the SDK, without reading the whole manual.... it should come with an example, or set of examples, that compile right out of the
box and are maximally simple.... the interfaces should use base types as much as possible (strings, arrays of bytes,
filenames) to make them easier to invoke, even if this is not general enough for
all purposes.... the user shouldn't have to install many dependencies for aspects of the SDK he isn't going
to use.
The second face exposes you to all the details, and the maximal generality. Here, reader and writer objects (or whatever is appropriate for your language) take the place of files and byte arrays, unicode support is standard, etc. Generally the first part is just stubs around this.
In my opinion, there's no reason to provide middle ground, and it tends to clutter the interface.
IMO, the SDL is a good example of a well-designed SDK.
should they be allowed to generate 'closed-source' solutions at the taxpayers' expense?
I think it's not fair for a public-funded project to do something like create a product and sell it without source code, or patent their work. But that doesn't mean that every artifact of the research project needs to be made public, necessarily. In this case, the end product that the grants paid for is the scholarly paper, not a computer program. Just as we don't demand their notebooks, time cards, e-mails, and meeting transcripts, it seems okay to not require them to publish the source code of a tool they wrote in the course of doing research. So I don't believe this is a behavior we should be legislating against.
But this only addresses the question of "should we require them to release the source?" Another undertone of the article is, "should they release the source?" I think it's clear that their work is at the center of a controversy, and that other researchers want to try to reproduce their results. It seems clear that making their specific methodology public (source code) would help answer the controversy, so as researchers interested in the truth, they should release it.
Production ML code sure does use lists, and they are efficient for what they are. But if you want fast random access, lists are simply not the right data structure. (And you don't even necessarily need to resort to imperative structures to get this; functional splay trees or functional arrays can get you at least good asymptotic performance, if not good constants!)
Anyway, map and fold are available for arrays as well as lists.
Having to differentiate between HashTable.insert and SkipList.insert sort of defeats the purpose of abstract types
I disagree. The purpose of abstract types is to syntactically enforce layers of abstraction. Overloading can save you typing (in my opinion, it usually makes programs less clear in the process), but it doesn't really have anything to do with abstract types.
Except for some questions of how they'd interact with the module system, Haskell's type classes are compatible with eager functional/imperative languages like ML, so I don't think your holy grail is that far off (except that the ML community doesn't like overloading much).
One of the joys of programming in ML is that you can write most of your code in a really nice, functional way, and (if necessary) put in the effort to write a tight inner loop, perhaps in an imperative style for speed. I don't see this as a disadvantage, and ML compilers often do a better job of optimizing such loops than C compilers, in part because of more information being available in the type system. (And if they don't, it's trivial to invoke C subroutines.) Also, if performance is really an issue, you might try mlton (which is for SML, very similar to Caml); its whole-program approach often produces significantly better code than O'Caml.
However, as an every-day ML user I find it very unlikely that your program would be a thousand times slower if you're using it "the way it's meant to be used." I am guessing that your implementation is asymptotically worse, since using map and fold correctly should really only be a constant factor slower than C, at worst. (mlton can often inline and optimize these into essentially the same code you'd write in C!) How about posting your code?
Customer one would have to be Santa Claus, and the developer clueless.
Huh?
And how will this larger and larger percentage of software become free?
Well, free software remains free, and tends to do a good job of replacing proprietary software (though it often takes many years). Since free software can be copied more easily, there are fewer impediments to it spreading.
I agree with you in theory on this one but the question is how do you get person one to pay the development cost on a product that person 2 will get for zero cost?
If person one and I have a mutually beneficial arrangement to exchange money for my services, then it shouldn't matter that person two can free-load. It's just added value in the system. If person one and person two are competing, then we need to come up with a contract that benefits all of us. (Do you think that designers worry about buying Photoshop, because it supports Adobe, which supports their competitors as well?)
Anyway, you're right that people are not used to buying software this way, but that doesn't mean it can't work. (Actually, I think it is almost inevitable, once a larger and larger fraction of software becomes Free.)
This is easy: Charge for the things you do. Making software isn't easy--it takes time and effort--so you should be paid to make software. Supporting software isn't easy, either, and so you should also be paid to do it. (Making copies of software is easy, so it's not fair for you to be paid to do it.) Neither of these sources of income are incompatible with free software. It's simply a matter of compensating people more directly for the services they provide.
Make two versions of your file available. Use "zip" for its universality, so anyone on any platform can get your file, if they want.
Then, make a more efficiently compressed one for those who know how to download and use it. Bzip2 seems to be the current favorite, especially for text.
It's still pretty bad if you want to develop open-source plugins, because you can't distribute the source code in a way that a normal user can build against.
The most interesting of these rumours is the possibility that Halo 3 is in the works already
Uh, really? You mean they're working on a sequel to their best-selling series of games? The one that ends abruptly with a total cliffhanger? That is an interesting rumor!
Well, I'm afraid I find your argument irrelevant because it lacks scientific detail. Not only is there no nail in the coffin, in my opinion the current atmosphere of doubt about evolution is entirely due to scaremongering, not any kind of real scientific controversy.
As for prediction, well, evolution is routinely tested and validated in laboratories in single-cell organisms, by people I know personally. Famously, Darwin was able to reject lord Kelvin's (incorrect) estimation for the age of the sun based on his theory of evolution. I don't know what kind of prediction you expect from a theory that tries to explain events on a geologic time scale, but there is no crisis here. Evolution makes the prediction that species will continue to change. We usually can't say how (other than in relation to some fitness measure), but being incomplete is not the same as being wrong. Certainly, alternative "theories" like creationism and intelligent design do a significantly worse job at prediction.
Classical physics (for example) did fall to a new theory, but that was because there was physical data that disagreed with it. We face no such conundrum with evolution.
By the way, it takes slightly more than 365 days to get around the sun, not less.
The modern debate is about neo-darwinism, which is decades old anyway. What is a specific crack in the current theory? Have there been new discoveries that seem to contradict our current model of evolution?
OK, you guys got me, I lost that the original poster was talking about circumvention for fair use, and not circumvention in general. I stand corrected.
Slashdot Mirror
Is no no the same as yes?
In which case, don't researchers have a duty to publish the program in order to help show the validity of their research, in all cases, not just this one?
I don't think so, because some research tools are just tools. If they can convince the reasership that their methodology is sound without spending the effort to clean up and distribute their tools, then that might be just fine. We don't currently have a culture where every artifact of the research process needs to be publicly available in order to have confidence in the results. (Again, because of the interest in the code and the controversy about their results, I think that in this case they really should be publishing their code to back up their method!)
I also believe that we should have higher standards of argument in our scientific papers (as a CS researcher I hope that soon many of our papers will be accompanied by machine-checkable proofs, as some are now, for instance). However, source code is, in the current scientific culture, not much different from other kinds of artifacts (lab notebooks) that remain private, and that is the basis of my position.
The perfect SDK, to me, has a "two faced" nature. The first face is a dumbed-down thing that makes it easy to get started, or to use some shallow function of the SDK as part of a project that's mostly focused on something else.
... it should come with an example, or set of examples, that compile right out of the ... the interfaces should use base types as much as possible (strings, arrays of bytes, ... the user shouldn't have to install many dependencies for aspects of the SDK he isn't going
1. It should be easy to do an obvious thing with the SDK, without reading the whole manual.
box and are maximally simple.
filenames) to make them easier to invoke, even if this is not general enough for
all purposes.
to use.
The second face exposes you to all the details, and the maximal generality. Here, reader and writer objects (or whatever is appropriate for your language) take the place of files and byte arrays, unicode support is standard, etc. Generally the first part is just stubs around this.
In my opinion, there's no reason to provide middle ground, and it tends to clutter the interface.
IMO, the SDL is a good example of a well-designed SDK.
should they be allowed to generate 'closed-source' solutions at the taxpayers' expense?
I think it's not fair for a public-funded project to do something like create a product and sell it without source code, or patent their work. But that doesn't mean that every artifact of the research project needs to be made public, necessarily. In this case, the end product that the grants paid for is the scholarly paper, not a computer program. Just as we don't demand their notebooks, time cards, e-mails, and meeting transcripts, it seems okay to not require them to publish the source code of a tool they wrote in the course of doing research. So I don't believe this is a behavior we should be legislating against.
But this only addresses the question of "should we require them to release the source?" Another undertone of the article is, "should they release the source?" I think it's clear that their work is at the center of a controversy, and that other researchers want to try to reproduce their results. It seems clear that making their specific methodology public (source code) would help answer the controversy, so as researchers interested in the truth, they should release it.
Propaganda or not, this is about the most boring shit I've ever seen. It's just a bunch of guys typing on IRC and instant messenger. THAT IS BORING.
Production ML code sure does use lists, and they are efficient for what they are. But if you want fast random access, lists are simply not the right data structure. (And you don't even necessarily need to resort to imperative structures to get this; functional splay trees or functional arrays can get you at least good asymptotic performance, if not good constants!)
Anyway, map and fold are available for arrays as well as lists.
Having to differentiate between HashTable.insert and SkipList.insert sort of defeats the purpose of abstract types
I disagree. The purpose of abstract types is to syntactically enforce layers of abstraction. Overloading can save you typing (in my opinion, it usually makes programs less clear in the process), but it doesn't really have anything to do with abstract types.
Except for some questions of how they'd interact with the module system, Haskell's type classes are compatible with eager functional/imperative languages like ML, so I don't think your holy grail is that far off (except that the ML community doesn't like overloading much).
Why do you consider that lucky?
I'm often annoyed by effects that other people don't perceive, and I personally find it, well, annoying.
My mistake, the code is posted.
One of the joys of programming in ML is that you can write most of your code in a really nice, functional way, and (if necessary) put in the effort to write a tight inner loop, perhaps in an imperative style for speed. I don't see this as a disadvantage, and ML compilers often do a better job of optimizing such loops than C compilers, in part because of more information being available in the type system. (And if they don't, it's trivial to invoke C subroutines.) Also, if performance is really an issue, you might try mlton (which is for SML, very similar to Caml); its whole-program approach often produces significantly better code than O'Caml.
However, as an every-day ML user I find it very unlikely that your program would be a thousand times slower if you're using it "the way it's meant to be used." I am guessing that your implementation is asymptotically worse, since using map and fold correctly should really only be a constant factor slower than C, at worst. (mlton can often inline and optimize these into essentially the same code you'd write in C!) How about posting your code?
Customer one would have to be Santa Claus, and the developer clueless.
Huh?
And how will this larger and larger percentage of software become free?
Well, free software remains free, and tends to do a good job of replacing proprietary software (though it often takes many years). Since free software can be copied more easily, there are fewer impediments to it spreading.
I agree with you in theory on this one but the question is how do you get person one to pay the development cost on a product that person 2 will get for zero cost?
If person one and I have a mutually beneficial arrangement to exchange money for my services, then it shouldn't matter that person two can free-load. It's just added value in the system. If person one and person two are competing, then we need to come up with a contract that benefits all of us. (Do you think that designers worry about buying Photoshop, because it supports Adobe, which supports their competitors as well?)
Anyway, you're right that people are not used to buying software this way, but that doesn't mean it can't work. (Actually, I think it is almost inevitable, once a larger and larger fraction of software becomes Free.)
This is easy: Charge for the things you do. Making software isn't easy--it takes time and effort--so you should be paid to make software. Supporting software isn't easy, either, and so you should also be paid to do it. (Making copies of software is easy, so it's not fair for you to be paid to do it.) Neither of these sources of income are incompatible with free software. It's simply a matter of compensating people more directly for the services they provide.
Make two versions of your file available. Use "zip" for its universality, so anyone on any platform can get your file, if they want.
Then, make a more efficiently compressed one for those who know how to download and use it. Bzip2 seems to be the current favorite, especially for text.
Sign my online petition to bring back Sidetalkin'!
It's still pretty bad if you want to develop open-source plugins, because you can't distribute the source code in a way that a normal user can build against.
How about "open sourcing" (or just making freely available) the damn Photoshop plugin SDK?
The most interesting of these rumours is the possibility that Halo 3 is in the works already
Uh, really? You mean they're working on a sequel to their best-selling series of games? The one that ends abruptly with a total cliffhanger? That is an interesting rumor!
Yes!!!!
To compound his crime, ... I downloaded it to iTunes, and it played just fine (but now I suppose I'm a criminal, too).
Most copyright infringement isn't a crime.
Halo 2 has sensitivity settings. Did you try that? (!)
Well, I'm afraid I find your argument irrelevant because it lacks scientific detail. Not only is there no nail in the coffin, in my opinion the current atmosphere of doubt about evolution is entirely due to scaremongering, not any kind of real scientific controversy.
As for prediction, well, evolution is routinely tested and validated in laboratories in single-cell organisms, by people I know personally. Famously, Darwin was able to reject lord Kelvin's (incorrect) estimation for the age of the sun based on his theory of evolution. I don't know what kind of prediction you expect from a theory that tries to explain events on a geologic time scale, but there is no crisis here. Evolution makes the prediction that species will continue to change. We usually can't say how (other than in relation to some fitness measure), but being incomplete is not the same as being wrong. Certainly, alternative "theories" like creationism and intelligent design do a significantly worse job at prediction.
Classical physics (for example) did fall to a new theory, but that was because there was physical data that disagreed with it. We face no such conundrum with evolution.
By the way, it takes slightly more than 365 days to get around the sun, not less.
The modern debate is about neo-darwinism, which is decades old anyway. What is a specific crack in the current theory? Have there been new discoveries that seem to contradict our current model of evolution?
OK, then what is a specific problem with evolution?
OK, you guys got me, I lost that the original poster was talking about circumvention for fair use, and not circumvention in general. I stand corrected.