Date: Wed, 19 Jun 1996 12:42:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@sri.MT.net (Nate Williams) Cc: terry@lambert.org, current@FreeBSD.org Subject: The FreeBSD Way Message-ID: <199606191942.MAA13802@phaeton.artisoft.com> In-Reply-To: <199606191856.MAA06876@rocky.sri.MT.net> from "Nate Williams" at Jun 19, 96 12:56:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Many of us have a long history, either as employees or as tier-one > > developers for major UNIX systems houses. The reason we are here > > is to Do The Right Thing The Right Way. > > Actually, the reason I'm here is because this is 'fun'. And, there is > prestige to be had for being a contributor. The latter is the reason we > do things the 'right way', because if you do crappy work the prestige is > lessened. However, sometimes 'the right way' gets in the way of 'fun', > due to time constraints and other issues, so the developers settle for > 'the best job given the current situation'. Yes; this is an issue of expediency. I'm *not* saying "don't be expedient"; what I *am* saying is "if you choose to be expedient, admit it". The difference is significant. I think we are already at the point where we can do the necessary expedient things without making more compromises in the name of "time to market" or "compete with Linux" or the other incentives for expediency which we already face. > If that means using TCL and having a workable solution next week > vs. spending 2 years writing a end-all/be-all/do-all front-end that is > the 100% correct solution then I'm for using TCL. I think you need to reexamine the premises. There's nothing saying that a front end could not be written as a TCL script, and use TCL. It has to do with the tools philosophy, and following a defined interface to allow us to agregate tools. This is *definitely* in line with the existing long term UNIX philosophy of being able to add general purpose things together with a special purpose thing and get a special purpose thing with astonishingly wide scope. I'm against the inclusion of TCL in the main line source tree for the same reason that I don't believe an "add user" script should be written in PERL: because it limits the reusuability of the code by blurring its boundries to the point that the algorithm is not fundamentally seperable from the interface implementation. To put this another way "if all you have is a hammer, everything looks like a nail". I'm against importing hammers to avoid abrogating all of the small problems into nails of one sort or another. UNIX is a tools OS. You *can* take apart a motorcycle with a crescent wrench, but it's much less satisfying to twiddle the adjustment up and down than it is to have a good set of sockets that *exactly* fit the standard-sized bolts. There is never an issue of misadjustment, and you don't strip your bolts. > That doesn't mean 'crap' is allowed, but there are certain tradeoffs > that are acceptable, such as allowing GPL'd code into the tree when > there is nothing BSDish that fits the bill. But, it also means that we > didn't accept the SVR3 style shlib either because in the long-run it'd > make like *more* difficult for both the developers *and* users. I'm not trying to imply TCL (or PERL, or anything else) is "crap", only that it promotes expedient soloutions to problems that could be more beneficially solved using a method more in line with the base UNIX philosophy. They promote laziness, and laziness promotes the "crap". > Claiming that we only do the '100%' pure thing is simply leading people > astray. I don't claim that we do. I *do* realise that eventually a software project has to ship software, or it isn't a software project. This is probably the bone of contention at the heart of the "Stallman/Lignux" debates. On the other hand, per the example of SVR3 shared libraries, it is sometimes better to avoid expediency to incent quality. I think that the importation of tools like TCL incent expediency, even if they are, themselves, quality code -- a slightly less obvious version of the SVR3/BSD shared library debate. The difference between a tree where these things are "ports" vs. where they are "standard components" is the difference between tacit disapproval or approval of importation of dependent code into the tree, also as standard components. If you tacitly approve, then it *will* happen; it will start small, with the standard "adduser" requiring the standard PERL, and build from there. I would prefer to incent "tools-based", instead of "tools-using", soloutions, if at all possible. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606191942.MAA13802>