Xref: utzoo comp.lang.perl:1621 comp.unix.wizards:22652 Path: utzoo!attcan!uunet!convex!convex.COM From: tchrist@convex.COM (Tom Christiansen) Newsgroups: comp.lang.perl,comp.unix.wizards Subject: Re: Looking for balanced critique of Perl Message-ID: <103428@convex.convex.com> Date: 27 Jun 90 03:30:21 GMT References: <4811@muffin.cme.nist.gov> Sender: usenet@convex.com Reply-To: tchrist@convex.COM (Tom Christiansen) Followup-To: comp.lang.perl Organization: CONVEX Software Development, Richardson, TX Lines: 148 I suspect that most readers here have already read things I've posted extolling the virtues of perl programming over shell programming, so I'll try to skip such scintillating remarks. On the darker side, I honestly do maintain that there are several areas in which perl is weak and therefore a sub-optimal pick as the programming tool of choice. Interacting with binary data is cumbersome and error-prone, albeit feasible. I say cumbersome and error-prone because even if you set things up to automagically rebuild the perl version of when the C version in updated (I do), you've probably got an $acct_t variable somewhere to serve as the format for pack/unpack conversions, and this WON'T get automagically rebuilt. So you lose and there's nothing to warn you of this. I'm not entirely convinced that socket-level networking is really moost appropriately done in perl, although I've written some programs of the order of 500 lines that do appear easier in perl. There are no facilities for RPC calls. I'm not sure there ought to be, either. I don't know that I'd be thrilled to see Xlib built into perl, and while I know Larry's adding curses, or at least providing the ability to do so, I wonder how well this will work out. I'm concerned about efficiency and ease of coding of these things. Will the ability to patch in your own C functions cause people to turn from C in cases where this is not honestly merited? I also wonder how well perl scales to very large applications. My largest single perl program (man) is itself a bit over 1300 lines long, not a long program as programs go, but due to the frequency with which it is run and the annoyance factor of having to wait a couple seconds for the parse to complete each time, I've undumped the script into an a.out, at which point it does beat the C version man program (and does a lot more, too.) But I'm sure there must be a point of diminishing returns. I've also had plenty of experiences with bugs, although to his credit I must admit that Larry's been a lot more responsive in this arena than any software vendor I've ever had dealings with, even though THEY were getting paid for maintenance. Still, sometimes you encounter a nasty bug and get a core dump or wrong answer and spend hours isolating it to prove to yourself it's not your own fault. Sometimes even when I'm convinced it's not, it really is, such as a sprintf() problem I had with a %-1000s field or some such similar nonsense. The bug that bites me worst right now is that sometimes in large programs, function calls under the debugger mysteriously return 1 rather than the value they are supposed to return. This problem evaporates when subjected to intense scrutiny: if run NOT under the debugger, or reduced to a small test case, all works well. One of the criticisms that one can make of perl is that it's prone to obfuscation, even more so than C. The regular expressions can easily become illegible, and with the ability to eval newly generated code on the fly, all things are possible. Of course, much of the guilt lies on the individual programmer for poor coding and commenting habits, but nonetheless there seems something in the language that too easily lends itself to obfuscation. Don Libes, the original poster, mentions that most of what he's read in magazines and on USENIX has been over-enthusiastic, with little criticism to the contrary. Well, if you've read Kolstad's UNIX REVIEW articles of the past three months (inspired/derived to a certain extent from my USENIX tutorials), you'll see that Rob has in several places been less than fawningly complimentary. He mentions that it's a kitchen-sink language, perhaps a little feature heavy. He speaks of the daunting, information-dense man "page". He complains that how are you supposed to just "know" that to access the aliases DBM database you have to concatenate a null byte, as in $aliases{'kolstad'."\000"}. (This latter actually makes sense when you figure it out, but I won't try to explain it here.) So he's at least trying to acknowledge some of the difficulties people may have with it. [Don Libes also ponders what "real computer scientists" have to say about the language. Well, what's it take to be a "real computer scientist"? Do O/S people count, or only language designers and compiler writers? Do you need certain degrees, publications, or world renown?] It's true that I was the first here to use perl; I grabbed it when the first version came out. But unlike Don Libes's site, there are quite a lot of people using perl here. Some of these are for projects purely in perl, some are as auxiliary tools for major projects involving C and C++, while others are for automated software test scripts or system administration purposes. It was originally for purposes of system management that it was first appreciated, but in the last year or so many others have embraced it as well. I don't really know how many perl programmers we have here now: it's well over a dozen, maybe two, and the number continues to grow weekly. So in answer to Don's question, yes, I do think that other people than Larry can program in perl. I might amend that to say that the answer is a qualified yes. The qualification is that I don't believe anyone can program quite so effectively in perl as can Larry. He of course understands not just some but each and every one of the semi- and undocumented nuances of the language. I think I'm pretty good at programming in perl, but still most of what I do still comes out looking like C with embedded sed. Larry takes a problem, looks at it a different way, and often comes up with something two orders of magnitude simpler and faster because of his intimate acquaintance with the language. It's only now and then that I come up with something that doesn't look very C-like, as in: next if $sections && !grep($mandir =~ /man$_/, @sections); and even then I feel somewhat guilty about it. :-) I hope that most of the subtleties of the language will be outlined in that fabled tome, the perl book he and Randal are working on. I'm especially interested in matters of efficiency and optimization. Larry often writes thing with big multi-line evals, and I'd like to have a better grasp on why this is so often so important for getting the promised 'faster-than-sed' performance. I think that this book has the potential for making perl more accessible to the general public. One final concern still makes me wonder, and is not a new one: just where is this thing called perl going to? Towards what is it evolving? Will it reach a point in its evolution when it is "done"? I hope so, but let it not be at the hands of some maiming standards committee. Let it be the handiwork of just one craftsman, one vision. I'd like to be fair and optimistic without an undue quantity of zeal fueling my discussions. I, too, am very interested to hear what others who've used this tool long enough to have a balanced view of it have to say. I've heard, and myself written, plenty of the good, and I, too, would appreciate hearing the darker experiences people have had about it. There is no ultimate answer to anything, let alone programming. But for what it was designed for, perl is a refreshing and pleasant change of pace. I'm reminded of around a decade ago on a little Z-80 running CP/M with only an assembler how very painful it was to generate any program at all. When I finally got a C compiler, it was such a refreshing pleasure, I cranked out a new tool on nearly a daily basis. (Of course, some may argue that the pleasure was as that of stopping banging your head against the wall. :-) I will dare to suggest that some of the bad experiences people may have had with perl stem from trying to use the wrong tool for the job, but I don't know that for sure. All I know is that for much of the quotidian toil that faces the tool builder and the system administrator, who often have to whip together a passably functioning piece of software in nothing at all resembling the normal, well-deliberated process of planned software development, that perl is a true blessing. It is in my sincere and considered opinion the most significant piece of general-purpose software to hit the software community since awk, and in that respect far exceeds awk's humble ambitions. --tom -- Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in : Editor too big!"