Date: Sun, 23 Jun 1996 02:06:50 -0500 (CDT) From: Tony Kimball <alk@Think.COM> To: jkh@time.cdrom.com Cc: hackers@freefall.freebsd.org Subject: Re: cvs commit: src/etc/mtree BSD.usr.dist Message-ID: <199606230706.CAA04519@compound.Think.COM> References: <199606222151.QAA02311@compound.Think.COM> <7625.835481530@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoth Jordan K. Hubbard on Sat, 22 June: : So here's the $10,000 question: Would your opinion be affected were : someone to upgrade perl4 to perl5 in our distribution? The quality of the monolith (as an instrument suitable to the uses of its audience at large) would be improved, but my opinion that the monolith should be made more recognizably and usefully modular and that one of those modular divisions should include perlN would not. Whether my argument on this particular is recieved well or ill (and I shall revisit it before this missive wimpers its conclusion), I hope that my larger point will not be lost, q.v. the subsequent: : We have a lot of languages in FreeBSD now. Perl, TCL, C, C++, : Objective-C (someday again), fortran, awk, sh - I'm probably even : missing one or two. Why? Because things change and evolve over time. This is not a religious issue for me, but an engineering issue. There will very likely be a point in the future where the modular structure which is appropriate today will no longer be appropriate. (For the reader unfamiliar with Thomas Kuhn's "The Structure of a Scientific Revolution", Kuhn first popularized the notion of a revolutionary change in scientific world-view as being the result of accumulated evidentiary pressure causing catastrophic collapse of obsolete, ossified, familiar, comfortable, and socially reinforced belief strucutures. "Paradigm shift" crept into managerial parlance shortly thereafter.) This will occur similarly to a Kuhnian "paradigm shift". Global design change is necessary and desirable for reasons both of technique *and* application. But, allow me to wax in rhetoric for a moment in order to make a point about global design... : It's no use saying "This is my line of death! No code shall cross : it!" because languges and operating systems and just about everything : else around us is constantly evolving and you might as well attempt to : stop the tide. Moderate, control the flow in useful ways, that's all : we can do. To the contrary: Useful moderation will make that stand precisely because the line is an important feature of the global design. The global design of the system can and will change when it is rationally justified. It must not change organically! If the system is left to evolve in response to independent, contradictory pressures of application, technique, and politics, it will no longer reap the harvest of intelligent global design. Consider evolutionary history versus creation history: Virtually all species in the history of naturalistic "Darwinian" evolution are extinct, and man will become one more of these in time, by any rational projection. But in the theocratic history of creation, man exists because man is created in the image of God, and his role in God's creation is dynamic, yes, but perfect at all times, in accordance with the intelligence of its design. Which of these plights would you choose for the creature of your design, FreeBSD? Given the active ongoing addition of core value to the project in violation of the layering division I have advocated, perhaps the revolution is already apace, and I am part of the hoary phlogiston contingent, about to be swept away on the tide of Daltonian theory. I don't think so, but the possibility exists. But even if so, and it is necessary and desirable that my arguments about the layering position of perl should fall on deaf ears, I do still hope (to switch metaphors in midstream) that God will care well for His image, and wreak upon it the transfiguration of Messianic salvation necessary to adapt the old creation to the environs of His heavenly Kingdom, rather than the vanishing competetive niche and eventual nullity of the australopithecus. Thus ends the sermon for today. Now, as regards where perl lives: Given the current entanglement of parts, the current situation suffers only one defect, and that is the tension between perl4 (small and dusty) and perl5 (bloated and shiny). Were it not for the fact that most people who care will end up with two perl installations, I would call it a tie. As it is, perl5 is a winner. But that current entanglement is not necessary. I am convinced by your argument that it is not really any longer suitable to excise perl from the core system so long as the core system is taken to include documentation (and hence makewhatis, catman, sgmlfmt), administrative and configuration tools (such as adduser, kbdmap, vidfont, spkrtest, keyinfo). I am still convinced that parts should be separated more cleanly and that a conscious decision should be made, in accordance with project goals and resources, as to what their dependencies should be. Let the core underly both man and admin modules. The remaining issues are: Which of the configuration tools enumerated should be moved into the core module; and, whether it is acceptable for the man module to depend upon the admin module. Since this is a natural modularization which is not anticipated to change forseeably, it is important not to allow additional dependencies to feep (unless other countervailing considerations exist, such as getting a big donor or losing miffed, quirky, marginally sane contributors).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606230706.CAA04519>