Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!samsung!transfer!lectroid!jjmhome!smds!rh From: rh@smds.UUCP (Richard Harter) Newsgroups: comp.lang.misc Subject: Re: What does an anti-perl look like Summary: Little tools but fast interfaces Message-ID: <566@smds.UUCP> Date: 18 Jun 91 07:41:42 GMT References: <16867@helios.TAMU.EDU> <1991Jun05.013632.3198@convex.com> <2154@sheol.UUCP> Organization: SMDS Inc., Concord, MA Lines: 93 In article <2154@sheol.UUCP>, throopw@sheol.UUCP (Wayne Throop) writes: > > rh@smds.UUCP (Richard Harter) .... > A thought that occurs to me is that the rapid adoption of perl in the > Unix community is a back-door defection to a philosophy that Lisp folks > have been preaching for years. In perl, one is partly abandoning the > the notion of small, stand-alone tools that do one thing well, and > instead adopting the monolithic everything-in-one-language approach that > Lisp has always had. You know. "Swiss army chainsaw." Perl simply > makes this palatable to the Unix community by leaving out some of the > parenthesis and including a baroque syntax and idiosyncratic semantics. :-) Baroque?! How can you say such a thing. I opine (loverly word, opine) that the problem with the UNIX tool set approach is three-fold. The first fold is that it is (relatively) expensive to connect the tools together. This is intrinsic to the UNIX approach of making everything a process and the need to use temporary files for data flows that can't be shoe-horned into the redirect/pipe model. The second fold is simply that the various utilities are not all consistent. This is reasonable -- they were developed independently in an evolutionary fashion. After the fact one can look at the whole mess and propose [with the aid of hind sight] a rationalization of the utilities. In some sense this is what perl has done. The third fold is that the shell (sh, csh) which serves as the glue to tie all of the pieces together has a number of unfortunate features. > > The main point I would like to make is that it is not such a simple thing > > to design and implement a language, particularly one which is to have > > strong string manipulation capabilities. I didn't say what I meant, here. I had in mind a number of issues that regularly create syntactical awkwardnesses unless they are dealt with carefully. What I meant to say was that it's simple to design a language that has a number of messy little annoyances that you don't realize are there until after you start writing code in it. > Having had recent experience in doing just that (for the usual misguided > reasons), I mildly disagree. By compromising runtime speed somewhat, > one can put together a complete interpreted string-manipulation language > for well under 2000 lines of C code and a month or two of elapsed time. > This doesn't include design time. Double or treble or more that effort > if you then need to squeeze speed out of the thing. Does this match > other folks' estimates/experience? Sounds about right, particularly if you sensible about using canned library utilities. Lakota currently runs about 8500 lines of C and the time spent in development is much more. [There have been a couple of rewrites and a fair bit of work on speed.] Lakota does a lot more, which accounts for the difference in size. > As an aside, I also find it interesting that "everybody" seems to have > implemented or be implementing a tiny language or two, even if they > later repent. I don't know if that's good, bad, or indifferent, > but it seems to be so. Who has not cursed the languages that they had available and wished for better? It seems to me that it would be natural for someone with a modern CS background to implement a tiny language, given the common emphasis on language principles and implementation. > > However my point was really that it is not so simple to develop a general > > language that is a signifigant improvement on what is already available. > Ah. Now *this* formulation seems more apt. "Significant improvement on > what is already available" is the key. Part of the problem is, just > exactly what's "significant" is a difficult question, and easy to be > self-deceptive about. Wrangling with myself over exactly this issue is > what led me down the slippery slope of interpreter implementation. Self-deceptive? Is that to my address, sir? Name your seconds. It's pistols at dawn for you. :-) > Somebody who's name I forget just now, talking about TCP/IP and ISO, > coined an apt phrase in this regard. "Just because your local tire shop > doesn't have four-ply radials in stock is no reason to go out and > reinvent the travois." > As I said, I myself have a fine travois which I use daily. I don't > regret inventing it, and I learned a lot from it, and it is a fine and > dandy tool... but my original justification for writing it was, in > retrospect, insufficient. Ah yes. One's own travois is a much finer vehicle than any automobile from the workshops of Detroit. Most of the time my shell is a Lakota shell. My, ah, justification is that it looks just like the bourne shell except when I need something better. However the truth of the matter is that it is my very own travois. :-) -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.