Front page | perl.bootstrap |
Postings from July 2000
I think this "meta-topic" is perhaps the most important one addressed on this bootstrap list: Should the Perl system require code to be distributed as source? Here I am referring to programs written in the Perl language, tobe executed by the Perl system. Tom's opinion, captured below, is pretty strong. > -----Original Message----- > From: Tom Christiansen [mailto:tchrist@chthon.perl.com] > Sent: Tuesday, July 25, 2000 7:06 PM ... > And just to add to the allusion, I'd rather a Kiddie::Porn module > be added to the core than this Evil. But the situation is not so clear to me. Distributing object code has several advantages, and is widely practiced, by almost all programming languages. I think at least some discussion is in order. The advantages of object code include: 1. Helps protects the "intellectual property" of the creator. (Maybe not perfectly, due to the possibility of reverse engineering, to generally to a high enough degree in practice.) 2. May improve performance, e.g. reduced load time, reduced network transmission time, and reduced disk space consumption. There are some corollary advantages e.g. it is quicker to detect when one program is an exact copy of another. I believe that these issues can be subtle. For background reading I recommend the book Code by Lawrence Lessig. He discusses the 4 kinds of regulators: 1. architecture (e.g. the presence of a "shrouding" routine in the Perl core and/or a module, or its absence, or CPAN requiring all modules to be source code, etc.) 2. law (perhaps the government will pass an anti-virus law requiring programs to be distributed as source) 3. norms (Larry et al. encourage the Perl community to never shroud their programs) 4. the market (can developers make more money, or less, or none, for programs distributed as source vs. as object code) The Perl community can adopt the norm of source to such a high extent that no one ever considers shrouding their code (except for the obfuscated contest). But that is a decision that should only be made after some consideration of the issue. Hopefully helpfully yours, Steve -- Steven Tolkin steve.tolkin@fmr.com 617-563-0516 Fidelity Investments 82 Devonshire St. R24D Boston MA 02109 There is nothing so practical as a good theory. Comments are by me, not Fidelity Investments, its subsidiaries or affiliates.