I think the more interesting question is "How dense is the resulting object code which implements the semantics of the program?". This has been an on-going language design/implementation question for most of the history of computing. For example, a particular program can be implemented in "C" which performs a certain action or actions intended to solve a problem. A high level language like Fortran for example might result in much tighter higher performance object code than the same "C" program. "C" was deliberately designed to inhibit compiler optimizations - the philosophy of the language designers was that the programmer should have more control. Fortran on the other hand performs many optimizations by default and a "C" programmer would need to modify their first iteration of their program to achieve some of the same optimizations.
Personally, I prefer readability over terseness. The enemy of reliable, maintainable programs is the terse, clever programmer. Often these terse programs have subtle bugs that are quite difficult to ferret out. Additionally, good compiler designers can out-perform these terse unreadable programs using a myriad of object code optimizations. -Alex P.S. All bets are off however if the programmer implements a better algorithmn... ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Greater NH Linux User Group" <[EMAIL PROTECTED]> Sent: Tuesday, August 20, 2002 9:19 AM Subject: Re: sorting pathnames by basename > On 20 Aug 2002, at 8:07am, Kevin D. Clark wrote: > > It was a one-liner. Take it for what it was. > > I am curious: If that Perl code was optimized for education (as opposed to > source size), what would it look like? I am thinking, specifically, of the > Python example that was posted. Without even knowing anything about Python, > I suspect that code could be made denser, by eliminating temporary variables > and nesting things instead. Can the reverse be done to the Perl code? > > -- > Ben Scott <[EMAIL PROTECTED]> > | The opinions expressed in this message are those of the author and do not | > | necessarily represent the views or policy of any other person, entity or | > | organization. All information is provided without warranty of any kind. | > > _______________________________________________ > gnhlug-discuss mailing list > [EMAIL PROTECTED] > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss > _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss