From owner-freebsd-current Sun Jun 23 18:16:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA09489 for current-outgoing; Sun, 23 Jun 1996 18:16:16 -0700 (PDT) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA09484 for ; Sun, 23 Jun 1996 18:16:14 -0700 (PDT) Received: from Early-Bird-1.Think.COM by mail.think.com; Sun, 23 Jun 96 20:54:40 -0400 Received: from compound.Think.COM by Early-Bird.Think.COM; Sun, 23 Jun 96 21:15:56 EDT Received: (from alk@localhost) by compound.Think.COM (8.7.5/8.7.3) id UAA08752; Sun, 23 Jun 1996 20:18:36 -0500 (CDT) Date: Sun, 23 Jun 1996 20:18:36 -0500 (CDT) From: Tony Kimball Message-Id: <199606240118.UAA08752@compound.Think.COM> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-current@FreeBSD.org Subject: Re: tcl -- what's going on here. References: <199606222113.QAA02156@compound.Think.COM> <199606231052.MAA04019@uriah.heep.sax.de> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Quoth J. Wunsch on Sun, 23 June: : As Tony Kimball wrote: : > be willing to rewrite those few perl kludges which are current. : : They are not ``kludges''. The authors of those tools deliberately : choose Perl for them You are absolutely right. I blew it by using the word "kludge". Sorry. : Something like text processing (or pattern matching etc.) in C is : simply a kludge, where Perl allows for elegant (and easier to : maintain) solutions. This is arguable. Maintainable perl requires substantial skill to write, and will quickly degrade when touched by less enlightened hands. Maintainable perl is nearly as rare as maintainable APL. : please, don't burden _us_ with a higher maintenance load a C kludge : would cause just for the reason that _your_ embedded controller might : be bloated. Again, you are correct in your response to my statement, which was at least partially mistaken. As mentioned elsewhere (hackers), my *real* complaint is about the failure to adhere to what I understand to be a reasonable modular dependency scheme in the global structure of FreeBSD. All of my other complaints are merely consequences. They are legitimate concerns, however: regardless of whether you feel they are determinative, they do at least corroborrate my central thesis. My point is not to burden you in order to make it trivial to install my controller, it is to help you whether you want to be helped or not:-) In my current position, enlightened by your comments and some reflection, I hold that there is a layer (or several) of user-land in which perl code has *no* place. Layers on top of that are free to exploit their dependency by exploiting the benefits of perl as appropriate. Layers beneath it have no business doing so, regardless of whether or not the perl solution would be more maintainable (about which I would urge great reserve in judgement, as it very often takes much more skill to write maintainable perl code than it does to write maintainable C code, at least beyond a certain application size). Regardless, I say, because maintaining coherent modularity is worth much more to the long-term maintainability of the project as a whole than is the micro-scale maintainability of a mono-function script. (Incidentally, any single perl expression that comes to my mind, at least, can be expressed in a single C function call. It's just a matter of taking the library which implements those function calls as being just as much a part of the implementation language as are the perl run-time structures which permit the perl code to run. Again, I'm not arguing against perl here, just balancing a statement which appears to me to gloss over important details. This issue is entirely tangential, of course.)