Date: Sun, 23 Jun 1996 20:18:36 -0500 (CDT) From: Tony Kimball <alk@Think.COM> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-current@FreeBSD.org Subject: Re: tcl -- what's going on here. Message-ID: <199606240118.UAA08752@compound.Think.COM> References: <199606222113.QAA02156@compound.Think.COM> <199606231052.MAA04019@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606240118.UAA08752>