From owner-freebsd-hackers Thu Nov 21 12:19:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA14641 for hackers-outgoing; Thu, 21 Nov 1996 12:19:30 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA14636 for ; Thu, 21 Nov 1996 12:19:27 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA13751; Thu, 21 Nov 1996 13:00:51 -0700 From: Terry Lambert Message-Id: <199611212000.NAA13751@phaeton.artisoft.com> Subject: Re: Who needs Perl? We do! To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 21 Nov 1996 13:00:51 -0700 (MST) Cc: davidn@sdev.usn.blaze.net.au, terry@lambert.org, roberto@keltia.freenix.fr, hackers@freebsd.org In-Reply-To: <199611210344.OAA10837@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Nov 21, 96 02:14:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I think that there's a very important line to be drawn between "I > don't think I need it in the system" and "It should not be in the > system". > > The former is fine, and probably applies to a lot of people. Then > again, it can also be applied to 90% of the system for 90% of users - > the point being that when you aggregate everything that people > want/need, you cover prettymuch everything. > > My point is that there are a sufficient number of people that consider > Perl a 'should-have' to justify its inclusion on those grounds. [ ... ] > I'm still open to argument on this; I just haven't heard a counter > that holds up under scrutiny. How about "because no important system component depends on it"? My main argument against inclusion of additional software in the same class as PERL ("foundation sotware upon which layered components are built") has been that it increases the complexity of the dependency graph. Over time, if a tool exists, people will use it to create expedient (not necessarily "optimal", not necessarily "elegant", but not necessarily "incorrect", either) soloutions to problems. If these soloutions adddress *real* problems, then you have created a dependency, and damaged the ability to create a "minimal system" without the additional software on which the tool is layered. You can think of this as an argument for a tools environment "microkernel", if you insist on an analogy. This is why I argue against TCL scripts. It's why I argue against bash-specific shell scripts, like "configure". It's why I argue against non-bmaked source inclusions, which would add a dependency on GNU make. This is *not* a "bloat/anti-bloat" argument. It is a complexity argument. I have absolutely no problem with an "admin tools" package requiring "perl component", and installing PERL as part of the install of the tools package. But encouraging an increase of complexity in the "minimal system you can create" is, IMO, a bad idea. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.