Xref: utzoo comp.lang.misc:6775 comp.lang.perl:4390 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!convex!news From: tchrist@convex.COM (Tom Christiansen) Newsgroups: comp.lang.misc,comp.lang.perl Subject: Re: Which to use :- Perl, Python, Icon, ... ? Message-ID: <1991Mar06.161812.28059@convex.com> Date: 6 Mar 91 16:18:12 GMT References: Sender: news@convex.com (news access account) Reply-To: tchrist@convex.COM (Tom Christiansen) Followup-To: comp.lang.misc Distribution: comp Organization: CONVEX Software Development, Richardson, TX Lines: 130 Nntp-Posting-Host: pixel.convex.com From the keyboard of bevan@cs.man.ac.uk (Stephen J Bevan): I'll answer from the questions from a perl standpoint, and let others address the others. I'm afraid I'm not eminently qualified to make comparisons, and I've only look at, not actually programmed in, the other languages mentioned. :As a guide to the sort of things I'm interested in :- : : + Does the language have any arbitrary limits? e.g. the length of a : line ... etc. This is one of perl's strong points: it has no such arbitrary limits. Any variable (including of course the current input line) can be as big as your virtual memory space allows, your regexps can be as long as you want, you can have any number of elements in your lists and tables, and binary data is handled gracefully, meaning strings with null bytes or 8-bit data don't confuse anything. If you say: $unix = `cat vmunix`; and you can malloc that much, you'll get the whole kernel in your string. : + How fast is it? This can be compared to whatever you like, but each : other preferably. I'm not really interested if XXX is only, X% : quicker than YYY on average (whatever that maybe). It really depends on what you're trying to do. For some things, Perl has a speed comparable to C: these are things that require a lot of pattern-matching. Perl's regexp facility are very rich, powerful, and highly optimized. Perl does B-M one better. Instead of just compiling your regexps, you can do something like compiling the pattern space with the study operator, which can make your program really scream. On the other hand, for most general programming, it is definitely going to be slower than C (2-5x), but faster than if you'd stitched the component sed and awk pieces together with sh. : + Does it give `reasonable' error messages? i.e. something better : than the equivalent of `awk bailing out on line X'. Perl always tells you the file and line in error, as well as printing out the next two tokens it was looking at when the parser got indigestion. It can find run-away strings or regexps (newlines aren't end of statement tokens -- they're just like spaces) and tell you where you went wrong. It doesn't just bail-out on the first error, but tries to recover and give you as much as it can find. Usually it makes a decent stab at this. Furthermore, it's easy for you do generate your own error messages, even of this form. You can get at the current errno/strerror message, the current file and line information for you (or your caller), and even any syntax or other fatal runtime errors that occurred in code protected by an exception handler. : + Does it have a debugger? If not, are there any extra facilities : for debuggging above and beyond simply inserting `printf' (change : as appropriate) statements. Yes, perl comes with a fully-featured symbolic debugger that does most of what you're used to if you're an sdb or dbx user: breakpoints, searching, tracing, examining or setting of variables, etc. In fact, the perl debugger is often used as a form of interactive perl to test out new things, since you are free to type legit (or otherwise) perl at the debugger, and you'll get immediate feedback. : + Does it allow conditional interpretation/compilation? i.e. : anything like +FEATURE in Lisp or #ifdef FEATURE/#endif in C. Sure -- perl will call cpp if you add a -P flag to it. That way you can say things like #if defined(sun) || defined(vax) An alternative is to execute system-dependent code (symlinks, dbm stuff, etc) in an active exception handler to trap any fatals that might occur if one of these isn't supported by your O/S. A few other features perhaps worth noting: + It's easy to develop library routines for run-time inclusion by your other programs. These library modules have control over visibility of identifiers so you don't accidentally stomp on commonly-used variable or function names. Scoping is in general of the dynamic nature, although the package protection mentioned above provides for a sort of static scoping on a module basis, i.e. modules can have their own private "file static" kind of identifiers. Modules can also have private initialization code. + Perl is very well integrated into the UNIX environment. It's easy to open pipes to and from other processes, set up co-routines via pipes and forks, and get at low-level things like file descriptors to dup or fcntl or ioctl. Perl already has hooks for most of the common system calls and C library routines, so you have to call fewer external programs, which speeds up your program. For system calls not covered, you can get at them via the syscall() function if your system supports it. You can even link in your own C functions if you want, such as for interacting with SQL or the like. Extensive library routines are already provided, doing things like getopts, tcsh-like completion, "infinite precision" arithmetic, termcap functions, plus a bunch more. + While only scalars (atoms) and lists are what the purists might call first-class data types (anonymous temporaries), you can pass all three basic data types (scalars, lists, tables AKA assoc arrays) as function params or return values. For other semi-data types, like filehandles, picture formats, regular expressions, and subroutines, you can use a scalar variable instead of a literal identifier and indirect through it. And of course, if all else fails, you can always use an eval. This means you can write a function that builds a new, uniquely-named function and returns you the name of the new function, assign that to a variable, and call the new function through the variable. + Other support facilities include translators for your old sed and awk scripts, a sort of "perl lint" switch (-w), and a security checking mechanism for setuid programs that catches brain-dead moves that are likely to be exploitable by a cracker, something even C can't do. + Because Perl derives so heavily from C, sed, and awk, if you already know these, your ramp-up time will be much less than if you were really starting from scratch. --tom -- I get so tired of utilities with arbitrary, undocumented, compiled-in limits. Don't you? Tom Christiansen tchrist@convex.com convex!tchrist