Ques: Use of "[ ]" in map
Steven Lee
I am new to Perl and would like to pose the following question
to the Perl gurus at large.
I have an array with the following data (fields if you like) for
each element - "host uid login_name full_name" (full name may be
none, one or more words). I wish to sort this array first by uid
then by login_name. After looking at examples from various sources
(books, Net, etc), I have come up with the following Perl code
which does the job I want.
@output = map { $_->[0] }
sort { $a->[1] == $b->[1] ? $a->[2] cmp $b->[2] :
$a->[1] <=> $b->[1] }
map { [ $_,(split)[1,2] ] } @output;
Being a newbie, naturally I had to take one bite at a time and
what has puzzled me is this.
When I use
@output = map { [ $_,(split)[1,2] ] } @output;
I get (when I print "@array\n")
ARRAY(0x400182f0)
:
:
:
But if I use (note: minus brackets)
@output = map { $_,(split)[1,2] } @output;
I get the expected result
Yet I need the brackets when I do the full sorting (refer to above)
otherwise I get blank lines in my output. I have looked up the same
sources but have not found any reference to the use of "[ ]". Can
someone pls explain this to me.
As I have said before, this is one of my first attempts at writing
Perl (though I have many years at writing shell scripts) so I have
kept it simple. Any pointers on how to do things better such as
using associative arrays (which I will try in my next cut) will also
be appreciated.
Thanks
Eric Arnold
I wonder if this chunk of code will haunt us forever. It's cool, but I
think it probably shouldn't be posted anywhere without the complete
explication. It's the sort of thing that if you're a programmer (even
a Perl programmer) it causes a long double take, and if you're not, it
causes you to turn to TCL or Python. I had a long talk with my uncle
whose department is converting to Python, telling him that Perl can be
written as clearly as C, if the programmer is willing. Now, I find that
this JAPH thing has become a wide spread example of Perl coding :-(
It's a showcase of "evil" Perl:
- lots of noise:
{ $_->[0] }
- implicit arguments and effects:
(split)[1,2]
- magic local/global variables:
$a->[1]
- 3 level nested looping (via the maps/sort)
>@output = map { $_->[0] }
> sort { $a->[1] == $b->[1] ? $a->[2] cmp $b->[2] :
> $a->[1] <=> $b->[1] }
> map { [ $_,(split)[1,2] ] } @output;
Anyway, the answer to your question is that [ ] returns a reference to
an anonymous array. The manual page, "perlref", discusses all the
stuff about references. It's also in the second edition Camel Perl
book, which is highly recommended if you plan to go much further, or
regardless.
The "map{ [ ] }" yields an array of anonymous arrays, passed up to
"sort". Because the conditional code block in "sort" dereferences the
elements:
> sort { $a->[1] == $b->[1] ? $a->[2] cmp $b->[2] :
^^^^^
all becomes well because "...->[1]" resolves to the first element
returned by "(split)[1,2]" :
> map { [ $_,(split)[1,2] ] } @output;
^^^
-Eric
In article <58341k$mf3@cdn_news.telecom.com.au>
Joseph N. Hall
Eric Arnold wrote:
>
> I wonder if this chunk of code will haunt us forever. It's cool, but I
> think it probably shouldn't be posted anywhere without the complete
> explication.
http://www.5sigma.com/perl/recipes.html
Or, if that isn't enough, Tom C's FMTYEWTK about sorting.
It's the sort of thing that if you're a programmer (even
> a Perl programmer) it causes a long double take, and if you're not, it
> causes you to turn to TCL or Python. I had a long talk with my uncle
> whose department is converting to Python, telling him that Perl can be
> written as clearly as C, if the programmer is willing. Now, I find that
> this JAPH thing has become a wide spread example of Perl coding :-(
Whine, whine, whine. The "Schwartzian Transform" is both efficient
and elegant. It isn't even that hard to understand once you've seen
the right narrative description of what's going on. ;-)
One of these days I'll get around to finishing the module containing
the "Hallacious Transform Wrapper," which allows you to implement
Schwartzian Transforms by just writing the appropriate transform
function.
-joseph
--
76% of all CGI questions posted in comp.lang.perl.misc are answered by:
"CGI.pm. LWP. http://www.perl.com/CPAN/modules/01modules.index.html."
....
Joseph N. Hall http://www.5sigma.com/joseph/ jos...@5sigma.com
Proprietor, 5 Sigma Productions P.O. Box 6250 Chandler AZ 85246
Perl instruction (http://www.5sigma.com/perl/), C++/C/Perl software,
web stuff, original music >>>Perl questions? mailto:pe...@5sigma.com
Tom Christiansen
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, jos...@5sigma.com writes:
:> It's the sort of thing that if you're a programmer (even
:> a Perl programmer) it causes a long double take, and if you're not, it
:> causes you to turn to TCL or Python. I had a long talk with my uncle
:> whose department is converting to Python, telling him that Perl can be
:> written as clearly as C, if the programmer is willing. Now, I find that
:> this JAPH thing has become a wide spread example of Perl coding :-(
:
:Whine, whine, whine. The "Schwartzian Transform" is both efficient
:and elegant. It isn't even that hard to understand once you've seen
:the right narrative description of what's going on. ;-)
No. Eric is right. I'm still pissed at Randal for having posted it,
especially the way he did. It's a great example of what's wrong with
Perl, and to some extent, of what's wrong with this newsgroup. It gives
Perl a bad name. If you want lisp, fine, go play with it, but it just
puts people off. Why do you think I spent hours of my life trying to undo
the damage he caused with that posting? I can't track down all of them.
If you only have time for a short, superclever, gee-ain't-I-smart
gee-aren't-you-a-fool posting, please don't post at all.
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
There is a need to keep from being locked into Open Systems. --IBM sales rep
Mike Stok
In article <58341k$mf3@cdn_news.telecom.com.au>,
Steven Lee <c82...@vuh263.telecom.com.au> wrote:
>I am new to Perl and would like to pose the following question
>to the Perl gurus at large.
>
>I have an array with the following data (fields if you like) for
>each element - "host uid login_name full_name" (full name may be
>none, one or more words). I wish to sort this array first by uid
>then by login_name. After looking at examples from various sources
>(books, Net, etc), I have come up with the following Perl code
>which does the job I want.
Fine looking schwartzian code, just be aware that this can be a
maintenance nightmare if you're not careful
>@output = map { $_->[0] }
> sort { $a->[1] == $b->[1] ? $a->[2] cmp $b->[2] :
> $a->[1] <=> $b->[1] }
> map { [ $_,(split)[1,2] ] } @output;
>Being a newbie, naturally I had to take one bite at a time and
>what has puzzled me is this.
>
>When I use
> @output = map { [ $_,(split)[1,2] ] } @output;
>I get (when I print "@array\n")
> ARRAY(0x400182f0)
[...]
>But if I use (note: minus brackets)
> @output = map { $_,(split)[1,2] } @output;
>I get the expected result
That's because [] used like this is an anonymous array constructor, it
copies the things inside the []s to a private list and then returns a
reference to that list. That's why the code abive uses $a->[$index]
because $a and $b contain references (similar to C pointers) to lists and
the -> is a dereferencing thing. So your
@output = map { [ $_,(split)[1,2] ] } @output;
is populating @output with array references which point at anonymous
lists, but
@output = map { $_,(split)[1,2] } @output;
will create a new array with more elements e.g.
("host uid1 name1 ...", "host uid2 name2 ...")
turns into ('host uid1 name1 ...', 'uid1', 'name1', 'host uid2 name2 ...',
'uid2', 'name2')
The sort code above never actually compares $a to $b, but supplies a
chunk of code to sort which uses $a and $b as pointers to lists
containing the interesting bits of data you have just split out.
In the debugger:
DB<1> @array = (1 .. 3);
DB<2> $arrayRef = [ 1 .. 3 ]
DB<3> X array
@array = (
0 1
1 2
2 3
)
DB<4> X arrayRef
$arrayRef = ARRAY(0x14019cc48)
0 1
1 2
2 3
DB<5> print $array[0]
1
DB<6> print $arrayRef->[0]
1
DB<7> print $$arrayRef[0]
1
DB<8> print $arrayRef
ARRAY(0x14019cc48)
Or, at the risk of being redundant
DB<1> @input = ("host uid1 name1 ...", "host uid2 name2 ...")
DB<2> @output = map { $_,(split)[1,2] } @input
DB<3> X output
@output = (
0 'host uid1 name1 ...'
1 'uid1'
2 'name1'
3 'host uid2 name2 ...'
4 'uid2'
5 'name2'
DB<4> @output = map { [$_,(split)[1,2]] } @input
DB<5> X output
@output = (
0 ARRAY(0x1401f92f8)
0 'host uid1 name1 ...'
1 'uid1'
2 'name1'
1 ARRAY(0x14020f058)
0 'host uid2 name2 ...'
1 'uid2'
2 'name2'
)
The debugger can be invoked thus
perl -de 1
and used quite profitably as a perl shell.
Check out the perlref and perldsc man pages for a fuller description.
Hope this helps,
Mike
--
mi...@stok.co.uk | The "`Stok' disclaimers" apply.
http://www.stok.co.uk/~mike/ | PGP fingerprint FE 56 4D 7D 42 1A 4A 9C
http://www.token.net/~mike/ | 65 F3 3F 1D 27 22 B7 41
st...@psa.pencom.com | Pencom Systems Administration (work)
Bennett Todd
On 4 Dec 1996 06:00:20 GMT, Steven Lee <c82...@vuh263.telecom.com.au> wrote:
>I am new to Perl [...]
Yowow! You're sure roaring in with afterburners engaged!
>I have an array with the following data (fields if you like) for
>each element - "host uid login_name full_name" (full name may be
>none, one or more words). I wish to sort this array first by uid
>then by login_name. [...]
>
>@output = map { $_->[0] }
> sort { $a->[1] == $b->[1] ? $a->[2] cmp $b->[2] :
> $a->[1] <=> $b->[1] }
> map { [ $_,(split)[1,2] ] } @output;
Almost perfect. The sort comparison function can be simplified: you want it
to return <0, 0, or >0 as the first element should come before, don't care,
or after the second, respectively. So rather than using a ?: ternary operator
to decide which field to sort on, just sort on the first one, unless that
comparison returns zero (equal), in which case sort on the second one:
... sort { $a->[1] <=> $b->[1] || $a->[2] cmp $b->[2] } ...
>Being a newbie, naturally I had to take one bite at a time and
>what has puzzled me is this.
>
>When I use
> @output = map { [ $_,(split)[1,2] ] } @output;
@output gets an array (map) of references to anonymous arrays (the outer [])
each containing the full record, as well as its second and third fields:
@output = (
[ @output[0], (split(@output[0]))[1], (split(@output[0]))[2] ],
[ @output[1], (split(@output[1]))[1], (split(@output[1]))[2] ],
...
);
That's what the map expands to.
>I get (when I print "@array\n")
> ARRAY(0x400182f0)
> :
> :
> :
Yup, you're asking to print (the contents of) an array full of references.
That's how Perl is printing them.
>But if I use (note: minus brackets)
> @output = map { $_,(split)[1,2] } @output;
This time @output is getting an array of all those triples, flattened out ---
three fields in the result for each field in the input:
@output = (
@output[0], (split(@output[0]))[1], (split(@output[0]))[2],
@output[1], (split(@output[1]))[1], (split(@output[1]))[2],
...
);
I.e. @output gets 3 times as many records.
>I get the expected result
Yup.
>Yet I need the brackets when I do the full sorting (refer to above)
>otherwise I get blank lines in my output.
Those brackets are constructing references to anonymous arrays --- and those
references are what you are sorting. Think of a reference as a very strongly
typed pointer, a pointer that knows a lot about what it's pointing at.
In fact, from perldata(1),
[...] references are strongly-typed uncastable pointers with built-in
reference-counting and destructor invocation.
A detailed description of these things can be found in perlref(1). And a
really, really exhausting (or was that exhaustive?:-) description of this
precise idiom, what it's doing, and how, can be found in
<URL:http://perl.com/perl/everything_to_know/sort.html>, "Far More Than
Everything You Ever Wanted To Know About Sorting".
-Bennett
Mike Stok
In article <32A530...@5sigma.com>,
Joseph N. Hall <jos...@5sigma.com> wrote:
>Eric Arnold wrote:
>>
>> I wonder if this chunk of code will haunt us forever. It's cool, but I
>> think it probably shouldn't be posted anywhere without the complete
>> explication.
>
>http://www.5sigma.com/perl/recipes.html
>
>Or, if that isn't enough, Tom C's FMTYEWTK about sorting.
It depends on the intended audience and purpose of the code. I'd
generally side with Eric as some of my code which was intended as a
"proof of concept" has made it into production and the people who have to
debug it suffer!
If you're showcasing reasons for using languages other than perl then
this is fine code if left uncommented, a lucid comment or commented out
equivalent code might well help the maintainer stuck without web access
at 3am with an angry boss and a listing... It's a matter of taste as to
which idioms are common enough to be considered not worthy of comment,
and if you feel happy leaving code like that uncommented then please just
leave your home phone number in the code somewhere!
Greg Bacon
[Posted and mailed]
In article <583v76$aor$1...@csnews.cs.colorado.edu>,
Tom Christiansen <tch...@mox.perl.com> writes:
:
: No. Eric is right. I'm still pissed at Randal for having posted it,
: especially the way he did.
What happened to TIMTOWTDI?
: It's a great example of what's wrong with
: Perl, and to some extent, of what's wrong with this newsgroup.
Perl, maybe; newsgroup no. For every obvious beginner who is greeted
with a gift from the JAPH f*ckin' mastah (sorry Pulp Fiction fans :-),
that beginner will probably get at least three other replies from
other readers either directly answering the original post, explaining
the JAPH, or both. What's wrong with this? The Father tells us
TIMTOWTDI, and if a Perl hacker posts JAPHs, perhaps it is because
he hears a different drummer.
: It gives Perl a bad name.
Maybe, but programming preference is often arbitrary, religious even.
Rich Stevens, a great programmer himself, called Perl a "write-only
language". So what? He has the right to his opinion, but that won't
cause me to emit one less byte of Perl code. IMHO, the variety of
solutions to the same problem shows what's blessedly *right* about Perl;
just some solutions are more readable than others.
: If you want lisp, fine, go play with it, but it just
: puts people off.
True if the Lisp solution is the only one submitted, but that is rarely
the case. What about TIMTOWTDI? Surely the Father knew that in
creating his hybrid beauty, people would try to program in BASIC with
Perl or Lisp with Perl et al.
: Why do you think I spent hours of my life trying to undo
: the damage he caused with that posting? I can't track down all of them.
It's unfair IMHO to say Randal caused damage with that post. That's not
to say that everything you've done for Perl has gone unappreciated. I
don't think anyone save Ray Helie would accuse you of doing any damage
(just look at everyone who came to your defense in that thread).
However, how can one cause damage with a solution when TIMTOWTDI? We
discussed this a few weeks ago, and everyone (Randal included) agreed
that the place for a JAPH is not in "real" code, and the JAPH's main
value lies in that it causes the onlooker to *gasp* think a minute and
maybe even learn something about the language. What's so bad about
that? Besides, if someone runs when code gets hairy, is she destined
to be a Perl hacker, or will she be another source of noise posts that
she could have answered herself with a little research?
If this makes me a pariah in the Perl Community for taking issue with
Tom, then so be it. If Perl's motto is TIMTOWTDI, then oughtn't we
stick by it? (For the record: just because it's *possible* to do
something one way doesn't necessarily make it a good way. Also note
that I never once accused Tom of mailbombing or spamming. :-)
Greg
--
Greg Bacon <gba...@cs.uah.edu>
Unix / Perl Consultant
Perl Institute Partner - http://www.perl.org/
Dave Thomas
On 4 Dec 1996 15:38:11 GMT, Greg Bacon <gba...@cs.uah.edu> wrote:
> <stuff about the amazing map sort...>
I think I agree with both of you. I agree with Tom that obscure code coesn't
help beginners, and may just put some of them off. I agree with Greg that
that doesn't mean that clever code doesn't have its place.
I feel that when posting solutions for people, or when illustrating a point
with code, you have to be aware of your audience. Keep things simple, and
try to engender a decent style. Perl is being used to engineer large
systems; we need to adopt more of an engineering approach.
I'm the first one to enjoy trying to decipher some obscure 2 liner, and I've
learned a lot doing it. But outside of some competition, I hope never to
write any production code that needs an hour per source line to understand!
Dave
--
_________________________________________________________________________
| Dave Thomas - Da...@Thomases.com - Unix and systems consultancy - Dallas |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Bennett Todd
On 4 Dec 1996 16:07:49 GMT, Dave Thomas <da...@fast.thomases.com> wrote:
>I agree with Tom that obscure code coesn't help beginners, and may just put
>some of them off.
I am afraid I disagree with you and Tom on that one. The code Randal posted
was moderately helpful to me as a beginner, and the response it provoked out
of Tom was _fantastically_ helpful.
>[...] But outside of some competition, I hope never to write any production
>code that needs an hour per source line to understand!
An hour per source line for _Who_ to understand? That's the really essential
issue. If it can't take an hour per line for someone to understand who knows
absolutely nothing about perl or programming, then you aren't going to get
very much work done. Yes, you can riddle your code so densely with explanatory
comments that it amounts to an introduction to the principles of programming,
but I don't think that's good engineering practice for production code.
For anybody who has gone through Tom's ``Far More Than
Everything You've Ever Wanted to Know About Sorting'' at
<URL:http://perl.com/perl/everything_to_know/sort.html>, these sorts of things
are fairly easy to read --- quicker to understand, and to let you convince
yourself it's _correct_, than the bulkier open-coded reimplementations.
That lovely little idiom is a great teaching example for bringing an
understanding of how some of Perl's builtins allow for clean and efficient
functional programming on lists, and this in turn opens up new ways of solving
problems. For instance, I recently posted an example I thought was
particularly clean and useful:
perl -le '$,="\n";print grep { -f } map { "$_/Config.pm" } @INC;'
which it just occurred to me could also be spelt
perl -le 'for (grep { -f } map { "$_/Config.pm" } @INC) { print };'
What fun! And I find this sort of thing useful, too --- having powerful
list-processing primatives available, and efficiently composable, makes the
language more expressive; it lets you avoid getting bogged down in open-coding
basic list operations.
-Bennett
Eric Arnold
In article <32A530...@5sigma.com>
jos...@5sigma.com writes:
>Eric Arnold wrote:
>>
>> I wonder if this chunk of code will haunt us forever. It's cool, but I
>> think it probably shouldn't be posted anywhere without the complete
>> explication.
>
>http://www.5sigma.com/perl/recipes.html
Hmm. Too little.
>Or, if that isn't enough, Tom C's FMTYEWTK about sorting.
Which is:
http://www.perl.com/perl/everything_to_know/sort.html
Hmm. Too much, or at least the explanation can't follow the code around.
> It's the sort of thing that if you're a programmer (even
>> a Perl programmer) it causes a long double take, and if you're not, it
>> causes you to turn to TCL or Python. I had a long talk with my uncle
>> whose department is converting to Python, telling him that Perl can be
>> written as clearly as C, if the programmer is willing. Now, I find that
>> this JAPH thing has become a wide spread example of Perl coding :-(
>
>Whine, whine, whine. The "Schwartzian Transform" is both efficient
I actually find the efficiency surprising. I had no idea that hash
lookups were so expensive (and it ain't linear neither). Is a 10000
element hash such a burden, or am I doing something wrong?
array len=1000
Benchmark: timing 10 iterations of hash, map...
hash: 2 secs ( 1.99 usr 0.01 sys = 2.00 cpu)
map: 1 secs ( 1.19 usr 0.01 sys = 1.20 cpu)
array len=5000
Benchmark: timing 1 iterations of hash, map...
hash: 7 secs ( 6.81 usr 0.01 sys = 6.82 cpu)
map: 1 secs ( 0.70 usr 0.07 sys = 0.77 cpu)
array len=10000
Benchmark: timing 1 iterations of hash, map...
hash: 36 secs (35.25 usr 0.06 sys = 35.31 cpu)
map: 2 secs ( 1.52 usr 0.09 sys = 1.61 cpu)
use Benchmark;
print "array len=" , $len = 10000 , "\n";
for ( $i = $len ; $i >= 0 ; $i--)
{
push( @array, "xx$i $i");
}
timethese(1, {
"map" => q{
@results = map { $_->[0] }
sort { $a->[1] <=> $b->[1] }
map { [$_, (split)[-1]] } @array;
},
"hash" => q{
for ( @array )
{
$h{$_} = (split)[-1];
}
@results = sort { $h{$a} <=> $h{$b} } @array;
}
});
>and elegant. It isn't even that hard to understand once you've seen
>the right narrative description of what's going on. ;-)
I'm not saying that I don't understand it, and I do admire its
elegance, but do you realize how hard it is to make converts to Perl of
people who aren't Lisp (or some other syntactically snarly language)
programmers, if they see something like this before (or even after)
they see a clearly written piece of Perl code? They don't care that it
takes a page of some other language to do 3 lines of Perl code; they
just don't want to come back in 6 months and see line noise on their
screen. Perl's domain has in large part been people of medium
technical expertise who just want to get a job done and have little
patience for syntactic puzzles, however enriching. I think Perl is a
better language than all the others I've seen, but I'm always
waging an uphill battle against clever Perl programs when trying to
proselytize.
I am saying that, at a minimum, to explain this:
@results = map { $_->[0] }
sort { $a->[1] <=> $b->[1] }
map { [$_, (split)[-1]] } @array;
it should be posted as something like this:
@results = # Start reading at the bottom.
#
map { # Take the new array returned by below "sort",
$_->[0] # dereference each element as anon. array ref.
# and return only the 0'th element so the
# final resulting array will have the same
# form as @array, but the new sorted order.
}
sort { # Take the new array returned by below "map",
# sort it by comparing pairs of elements in
# the special $a and $b variables, which
$a->[1] <=> $b->[1]
# must be dereferenced as references to anon.
# arrays before doing any comparison
}
map { # Take each element of @array and ...
#
[ # return a anon. array reference containing
# two (in this case, more if required) elements
#
$_, # ->[0] : the original @array element
#
(split)[-1] # ->[1] : the last value returned by split,
# which is operating on default arg ($_)
# and default pattern (whitespace). The ()
# around split makes a new array, which
# ()[-1] takes the last element of.
]
} @array; # We want to sort on the last field in each
# record of @array. Rather than splitting
# each time "sort" does a comparison, we are
# going to create a structure which caches
# and carries the last field into "sort".
# Flow:@array-->map-->sort-->map-->@results
The idea of putting a wrapper around it is a nice idea, but from:
http://www.5sigma.com/perl/recipes.html
the examples are still abstruse:
sub mksort {
my $xform = shift;
sub {
map { $_->[0] }
sort { $a->[1] cmp $b->[1] }
map { [$_, &$xform($_ . "")] }
@_;
}
}
$sort_nospace = mksort sub { $_[0] =~ tr/ //d; };
print join("\n", &$sort_nospace('a', 'a aa', 'aa')), "\n";
$sort_by_mod_time = mksort sub { sprintf "%015.6f", -M shift }; # or change cmp to <=>
print join(" ", &$sort_by_mod_time(@files));
If you do something like this instead (you also need a parametized
comparison):
sub ssort {
my $cmp_sub = shift;
my $xform_sub = shift;
return map { $_->[0] }
sort { &$cmp_sub }
map { [ $_, &$xform_sub ] } @_;
}
you have the option of doing the shorter version:
@results = ssort sub{ $a->[1] <=> $b->[1] },
sub{ (split)[-1] },
@array;
or you can be more verbose:
sub last_elem{
my $str = shift @_;
my(@fields) = split(/\s+/,$str);
return $fields[-1];
}
sub by_numval{
$a->[1] <=> $b->[1];
}
@results = ssort \&by_numval, \&last_elem, @array;
The down side is that they are all 2-3 times slower than the raw
version, and while that's only a problem with large sorts, you'd only
use this map/sort trick if you're looking for max performance. So, I'd
say the thing to do is make sure the comment-impregnated version gets
disseminated, since we can't ignore the trick's usefulness.
-Eric
Joseph N. Hall
Eric Arnold wrote:
> I'm not saying that I don't understand it, and I do admire its
> elegance, but do you realize how hard it is to make converts to Perl of
> people who aren't Lisp (or some other syntactically snarly language)
> programmers, if they see something like this before (or even after)
> they see a clearly written piece of Perl code?
The thing is, it IS clearly written. It is clearly written in the
same sense that declarations in C are clearly written. It is an
idiom. It is an elegant idiom. Perl is an idiomatic language in
which you can be elegant.
I'd be lying if I said I've never written a line of Lisp in my life,
but 1) it was for emacs, and 2) it was 10 years ago. I couldn't
write a Lisp program that printed "hello world" now if my life
depended on it, at least not without some documentation. I conclude
that Lisp has nothing to do with the perceived difficulty of this
construct and I don't know why people keep bringing it up. Maybe
it's because people want to understand Perl in terms of some other
language. I think Perl has progressed beyond that.
Finally, I think it's plain wrong for Tom and others to recoil from
the Schwartzian Transform and similar idioms on the basis that
"it's too scary for novices." Look, there are plenty of things out
there in the world made up of small, funny shaped pieces that go
together just so. Engines. Golf swings. Human beings. Just because
it's not blindingly obvious at first glance doesn't mean it's not
worth learning, or that no one will bother. Some people WANT to
climb the big hills. And for those who don't, there is plenty
of perl "baby talk" that is well documented.
--
Joseph N. Hall
Eric Arnold wrote:
> If you do something like this instead (you also need a parametized
> comparison):
I'm still looking at other ways of doing this, including a
parameterized comparison. But you don't "need" a parameterized
comparison for most cases. If you do use a parameterized comparison
you sure as heck shouldn't do it the way you suggest, since that's a
huge performance hit that you can't escape. The operator has to
be eval-ed as a string into the sort subroutine (which now has
to start as a string template rather than as a lexical).
The down side is that they are all 2-3 times slower than the raw
> version, and while that's only a problem with large sorts, you'd only
> use this map/sort trick if you're looking for max performance.
2-3 times slower ... not! That depends on how expensive the
key transformation is. If it's really expensive, say, stat(),
then any speed difference will be negligible. It also depends
on the details of the implementation.
What's meant by "max performance" is a matter of opinion. It's
easy to encounter cases where the performance hit of doing it the slow
way is obvious.
-joseph
Joseph N. Hall
Eric Arnold wrote:
> I actually find the efficiency surprising. I had no idea that hash
> lookups were so expensive (and it ain't linear neither). Is a 10000
> element hash such a burden, or am I doing something wrong?
In my experience ALL subscripting operations are significantly
slower than other alternatives. Maybe a better optimizer will partly
fix this some day, but the rule of thumb is to avoid using subscripts
whenever possible, and especially avoid using the same subscript
expression more than once (as in using $a[i] over and over again
inside a loop).
Joseph N. Hall
Gurusamy Sarathy wrote:
> If you have a post-5.003 perl, you can pre-extend the hash
> with that one line. Now, "hash" beats "map":
>
> array len=10000
> Benchmark: timing 10 iterations of hash, map...
> map: 31 secs (30.45 usr 0.06 sys = 30.51 cpu)
Geez. Now someone needs to fix "map." ;-)
Joseph N. Hall
Eric Arnold wrote:
> >http://www.5sigma.com/perl/recipes.html
>
> Hmm. Too little.
>
> >Or, if that isn't enough, Tom C's FMTYEWTK about sorting.
OK,
http://www.5sigma.com/perl/schwtr.html
-joseph
--
76% of all CGI questions posted in comp.lang.perl.misc are answered by:
"CGI.pm. LWP. http://www.perl.com/CPAN/modules/01modules.index.html."
....
Joseph N. Hall
Eric Arnold wrote:
> As to whether it's clear, in terms of Perl or other languages, it has
> things about it that I discourage in any project in any language that
> has to be maintainable:
I could argue each point, but it's obvious that you are in the "don't
dare use $_!" camp and I'm in the "why not learn the language, then use
it" camp, and we're just not going to find common ground.
What I do want to take exception to is this:
> Weird special cases another feature that fails to impresses any development
> manager, so if Perl can be shown to be fully useful and functional without
> them, it can better compete with other languages. [...]
> That means making
> the official presentation of it as accessible as possible to the full
> audience it is intended for.
comp.lang.perl.misc is NOT the "official presentation" of the language,
and
it never will be. No pointy-haired manager ever gave a rat's bunghole
about whether a language was supported by a USENET newsgroup, much less
how it was treated there.
(And of course the reason that Perl IS accepted by pointy-haired
managers
is that people come to them and say, "Hey, I can do this in a day with
Perl,
or four weeks with Java. Which would you prefer?")
The "official presentation" of the Perl language is books and classes.
We
don't subject "newbies" to rough treatment in either. If you comes to
comp.lang.perl.misc you takes your chances.
-joseph
--
Andrew M. Langmead
"Joseph N. Hall" <jos...@5sigma.com> writes:
>Whine, whine, whine. The "Schwartzian Transform" is both efficient
>the right narrative description of what's going on. ;-)
But according to the bencharking that Tom showed in "Re: Read
directory in timestamp order?" (MessageID
<4l36f0$g...@csnews.cs.colorado.edu>), the "Schwartzian Transform"
isn't any more efficient than the "sort the indicies" shown in the
first edition camel. (According to Deja News, this article is also the
earliest appearance of the term "Schwartzian Transform" on Usenet)
So you have code that is harder to read, is no more efficient, but
probably more than twice as short and "kind of neat" to people who can
find source code interesting.
I know for the code that I develop, there is no issue of which one to
use.
--
Andrew Langmead
Gurusamy Sarathy
[ mailed and posted ]
In article <ERIC.96De...@m-e-ir1.sun.com>,
Eric Arnold <eric....@sun.com> wrote:
>>Whine, whine, whine. The "Schwartzian Transform" is both efficient
>
>I actually find the efficiency surprising. I had no idea that hash
>lookups were so expensive (and it ain't linear neither). Is a 10000
>element hash such a burden, or am I doing something wrong?
That's a surprising result, but new technology can beat old
any day. See below.
>array len=10000
>Benchmark: timing 1 iterations of hash, map...
> hash: 36 secs (35.25 usr 0.06 sys = 35.31 cpu)
> map: 2 secs ( 1.52 usr 0.09 sys = 1.61 cpu)
>
>use Benchmark;
>print "array len=" , $len = 10000 , "\n";
>for ( $i = $len ; $i >= 0 ; $i--)
>{
> push( @array, "xx$i $i");
>}
keys %k = 10000;
>timethese(1, {
> "map" => q{
> @results = map { $_->[0] }
> sort { $a->[1] <=> $b->[1] }
> map { [$_, (split)[-1]] } @array;
> },
> "hash" => q{
> for ( @array )
> {
> $h{$_} = (split)[-1];
> }
> @results = sort { $h{$a} <=> $h{$b} } @array;
> }
>});
If you have a post-5.003 perl, you can pre-extend the hash
with that one line. Now, "hash" beats "map":
array len=10000
Benchmark: timing 10 iterations of hash, map...
hash: 22 secs (22.85 usr 0.07 sys = 22.92 cpu)
map: 31 secs (30.45 usr 0.06 sys = 30.51 cpu)
TIMTOWTDI.
- Sarathy.
gs...@umich.edu
Eric Arnold
In article <32A625...@5sigma.com>
jos...@5sigma.com writes:
>Eric Arnold wrote:
>> If you do something like this instead (you also need a parametized
>> comparison):
>
>I'm still looking at other ways of doing this, including a
>parameterized comparison. But you don't "need" a parameterized
>comparison for most cases. If you do use a parameterized comparison
>you sure as heck shouldn't do it the way you suggest, since that's a
>huge performance hit that you can't escape. The operator has to
>be eval-ed as a string into the sort subroutine (which now has
>to start as a string template rather than as a lexical).
There was no "eval" or strings. The new cost is the dereference of the
sub reference, and the overhead of a sub call (plus any local variable
copies, etc). The performance hit wasn't "huge", but was significant.
sub ssort {
my $cmp_sub = shift;
my $xform_sub = shift;
return map { $_->[0] }
sort { &$cmp_sub }
map { [ $_, &$xform_sub ] } @_;
}
@results = ssort sub{ $a->[1] <=> $b->[1] },
sub{ (split)[-1] },
@array;
> The down side is that they are all 2-3 times slower than the raw
>> version, and while that's only a problem with large sorts, you'd only
>> use this map/sort trick if you're looking for max performance.
>
>2-3 times slower ... not! That depends on how expensive the
>key transformation is. If it's really expensive, say, stat(),
>then any speed difference will be negligible. It also depends
>on the details of the implementation.
Well, I think I did an apples-to-apples benchmark, and that's what I
found. You could do something where a whole new subroutine is "eval"ed
into existence before you use it, but then you'd have to deliver the
comparisons and transforms as strings, and you'd lose the flexibility
of giving the user a subroutine to work with, but it is faster. As
for whether the key transform will dominate the times, that can be
true in any case; you can always find something to bottleneck the
process.
Benchmark: timing 3 iterations of eval, raw, subref...
eval: 5 secs ( 4.37 usr 0.14 sys = 4.51 cpu)
raw: 4 secs ( 4.30 usr 0.00 sys = 4.30 cpu)
subref: 9 secs ( 7.88 usr 0.02 sys = 7.90 cpu)
use Benchmark;
$len = 5000;
print "array len=$len\n";
for ( $i = $len ; $i >= 0 ; $i--)
{
push( @array, "xx$i $i");
}
sub ssort1 {
my $cmp_sub = shift;
my $xform_sub = shift;
return eval qq{ map { \$_->[0] }
sort { $cmp_sub }
map { [ \$_, $xform_sub ] } \@_;
};
}
# if you want to try a more expensive key transform:
sub split1{
for ( $i = 0 ; $i < 50 ; $i++ ){} # spin a bit
split;
}
sub ssort2 {
my $cmp_sub = shift;
my $xform_sub = shift;
return map { $_->[0] }
sort { &$cmp_sub }
map { [ $_, &$xform_sub ] } @_;
}
timethese(3, {
"eval" => q{
@results = ssort1 q{ $a->[1] <=> $b->[1] },
q{ (split)[-1] },
@array;
},
"subref" => q{
@results = ssort2 sub{ $a->[1] <=> $b->[1] },
sub{ (split)[-1] },
@array;
},
"raw" => q{
@results = map { $_->[0] }
sort { $a->[1] <=> $b->[1] }
map { [$_, (split)[-1]] } @array;
},
});
Eric Arnold
We aren't algorithmic luddites. The point is that if some chunk of
code becomes a widely cited example, then it should help the cause of
the language rather than hurt it. It isn't just a case of newbies
having trouble with it. There are many folks who might use Perl (to
their edification!) if it didn't have an (undeserved) reputation as a
line noise language. For production purposes, people just don't have
the time to riddle out clever code, whether its C or Perl or whatever.
I'm only picking on this sorting routine because it's gained
visibility. People are free to obfuscate whatever they like in
private.
As to whether it's clear, in terms of Perl or other languages, it has
things about it that I discourage in any project in any language that
has to be maintainable:
- lots of noise:
{ $_->[0] }
This has very little immediate semantic value. Programmers have
evolved beyond using single character register names for a reason.
- implicit arguments and effects:
(split)[1,2]
"split" is slyly using a global variable ($_), and performing a
special version of its operation because it was given no
arguments. It is returning a list apparently nowhere; nothing
explicitly receives the value, i.e. "@fields=split"). Programming
has evolved away from the use of global variables and hidden side
effects for a reason.
- magic local/global variables:
$a->[1]
More of the same.
- 3 level nested looping (via the maps/sort)
The deeper the nesting of a construct, the more difficult it is to
grasp. Reverse polish calculators were really cool, but they caught
on only because they were the only game in town for a while, and try
to find one now.
I understood the thing fairly easily because I have diddled with Perl for
years, and have a wide grasp of the language and it's weird special cases.
Weird special cases another feature that fails to impresses any development
manager, so if Perl can be shown to be fully useful and functional without
them, it can better compete with other languages.
I want to see Perl succeed, because I don't like the alternatives, and
I am fascinated by the unique direction Perl takes. That means making
the official presentation of it as accessible as possible to the full
audience it is intended for.
-Eric
In article <32A623...@5sigma.com>
jos...@5sigma.com writes:
>Eric Arnold wrote:
>> I'm not saying that I don't understand it, and I do admire its
>> elegance, but do you realize how hard it is to make converts to Perl of
>> people who aren't Lisp (or some other syntactically snarly language)
>> programmers, if they see something like this before (or even after)
>> they see a clearly written piece of Perl code?
>
>The thing is, it IS clearly written. It is clearly written in the
>same sense that declarations in C are clearly written. It is an
>idiom. It is an elegant idiom. Perl is an idiomatic language in
>which you can be elegant.
>
>I'd be lying if I said I've never written a line of Lisp in my life,
>but 1) it was for emacs, and 2) it was 10 years ago. I couldn't
>write a Lisp program that printed "hello world" now if my life
>depended on it, at least not without some documentation. I conclude
>that Lisp has nothing to do with the perceived difficulty of this
>construct and I don't know why people keep bringing it up. Maybe
>it's because people want to understand Perl in terms of some other
>language. I think Perl has progressed beyond that.
>
>Finally, I think it's plain wrong for Tom and others to recoil from
>the Schwartzian Transform and similar idioms on the basis that
>"it's too scary for novices." Look, there are plenty of things out
>there in the world made up of small, funny shaped pieces that go
>together just so. Engines. Golf swings. Human beings. Just because
>it's not blindingly obvious at first glance doesn't mean it's not
>worth learning, or that no one will bother. Some people WANT to
>climb the big hills. And for those who don't, there is plenty
>of perl "baby talk" that is well documented.
>
Brian L. Matthews
|people who aren't Lisp (or some other syntactically snarly language)
|programmers, if they see something like this before (or even after)
|they see a clearly written piece of Perl code?
If someone rejects a language based upon a single 3 line example,
they get what they deserve.
Brian
--
Brian L. Matthews Illustration Works, Inc.
For top quality, stock commercial illustration, visit:
http://www.halcyon.com/artstock
Bennett Todd
On Thu, 5 Dec 1996 00:23:08 GMT, Andrew M. Langmead <a...@world.std.com> wrote:
>So you have code that is harder to read, is no more efficient, but
>probably more than twice as short and "kind of neat" to people who can
>find source code interesting.
>
>I know for the code that I develop, there is no issue of which one to
>use.
Me too. Since I find this sort algorithm particularly clear to read, I use it
by preference.
I can eyeball a use of this function, and pretty quickly figure out what it's
doing and why --- and when I'm done, I'm convinced that it will do what I
expect. If you don't like the idiomatic use of map and an intermediate data
structure, then by all means code around the problem, building up helper
arrays carrying the sort key information, then sorting by reference to them.
But that doesn't make code "easier to read". "Easy to read" isn't an absolute;
it is relative to the particular reader in question. This reader is
comfortable with that idiom.
-Bennett
Greg Bacon
[Posted and mailed]
In article <ERIC.96De...@m-e-ir1.sun.com>,
eric....@sun.com (Eric Arnold) writes:
:
: We aren't algorithmic luddites. The point is that if some chunk of
: code becomes a widely cited example, then it should help the cause of
: the language rather than hurt it.
See my previous post in this thread. IMHO, Randal's JAPH sort didn't
hurt the language at all.
: It isn't just a case of newbies
: having trouble with it. There are many folks who might use Perl (to
: their edification!) if it didn't have an (undeserved) reputation as a
: line noise language.
More idiots might use Perl if their IQ was above that of the average
fern, but I don't think we ought to dumb down Perl for their sake.
: For production purposes, people just don't have
: the time to riddle out clever code, whether its C or Perl or whatever.
: I'm only picking on this sorting routine because it's gained
: visibility. People are free to obfuscate whatever they like in
: private.
True, and this was discussed *extensively* in another thread a couple
of weeks ago (between Randal, Dave Hammen, a few others and me).
: As to whether it's clear, in terms of Perl or other languages, it has
: things about it that I discourage in any project in any language that
: has to be maintainable:
How many projects assign novice programmers to maintanence?
: - lots of noise:
: { $_->[0] }
: This has very little immediate semantic value. Programmers have
: evolved beyond using single character register names for a reason.
Well, then let's start advocating Hungarian notation for Perl. Ugh.
Perl is like a natural language in that many ambiguities can be resolved
by looking at the *context*. $_ is a perfect example of this. In
examining the context, the above expression has immediate semantic value.
: - implicit arguments and effects:
: (split)[1,2]
: "split" is slyly using a global variable ($_), and performing a
: special version of its operation because it was given no
: arguments. It is returning a list apparently nowhere; nothing
: explicitly receives the value, i.e. "@fields=split"). Programming
: has evolved away from the use of global variables and hidden side
: effects for a reason.
How is it hidden? That feature is well documented and widely known.
If someone isn't sure what's going on, a mere glance at the fine manual
will clear the misunderstanding.
: - magic local/global variables:
: $a->[1]
: More of the same.
Again, the programmer only need RTFM or have 1% of a clue about Perl.
: - 3 level nested looping (via the maps/sort)
: The deeper the nesting of a construct, the more difficult it is to
: grasp. Reverse polish calculators were really cool, but they caught
: on only because they were the only game in town for a while, and try
: to find one now.
Can you say HP? Most business, engineering, math, and science majors
I know own a 48G series calculator. I like Joseph's remark about C
declarations. They're often difficult to grasp too, but that hasn't
stopped anyone from using them. C declarations' result is one of
tolerance: cdecl.
: I understood the thing fairly easily because I have diddled with Perl for
: years, and have a wide grasp of the language and it's weird special cases.
: Weird special cases another feature that fails to impresses any development
: manager, so if Perl can be shown to be fully useful and functional without
: them, it can better compete with other languages.
They're not weird when one develops an understanding of Perl. Do you
hire programmers who don't understand the language they're going to be
using? TIMTOWTDI in that one can write longhand Perl or Perl. Given
the innate laziness of programmers, most will opt for the elegant
(read 'least typing') solution.
: I want to see Perl succeed, because I don't like the alternatives, and
: I am fascinated by the unique direction Perl takes. That means making
: the official presentation of it as accessible as possible to the full
: audience it is intended for.
If you want the "official presentation", go read the Camel or Llama, or
get Tom or Randal to come give a training seminar. Like Joseph said,
Usenet is rarely the official presentation of anything.
Greg Bacon
In article <32A66C...@5sigma.com>,: OK,
:
: http://www.5sigma.com/perl/schwtr.html
Maybe someone should RFD comp.lang.perl.japh.authoring and
comp.lang.perl.japh.advocacy. :-)
Tom Christiansen
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
gba...@CS.UAH.Edu writes:
:: As to whether it's clear, in terms of Perl or other languages, it has
:: things about it that I discourage in any project in any language that
:: has to be maintainable:
:
:How many projects assign novice programmers to maintanence?
Nearly all of them, sadly enough.
--tom
Eric D. Friedman
In article <586s6v$c...@info.uah.edu>, Greg Bacon <gba...@CS.UAH.Edu> wrote:
>In article <ERIC.96De...@m-e-ir1.sun.com>,
> eric....@sun.com (Eric Arnold) writes:
>: - lots of noise:
>: { $_->[0] }
>: This has very little immediate semantic value. Programmers have
>: evolved beyond using single character register names for a reason.
This objection (at least) is easily addressed with the English module.
I wonder: has anyone written a little script that goes through a perl
script and 'anglicizes' it? Might be just what's needed to placate
those 'pointy haired managers' we keep hearing about, and it might
also be handy for novices (or others) who are having difficulty
keeping track of the mnemonic associations the Camel proposes for
$/ and the like.
--
Eric D. Friedman -- frie...@uci.edu -- http://www.oac.uci.edu/indiv/friedman/
"A book should be a ball of light in one's hands." -- Ezra Pound
Joseph N. Hall
Tom Christiansen wrote:
> In comp.lang.perl.misc,
> gba...@CS.UAH.Edu writes:
> :How many projects assign novice programmers to maintanence?
>
> Nearly all of them, sadly enough.
I have to agree with Tom here. It's a good way to break in a new
body. Well, at least sometimes.
-joseph
Joseph N. Hall
Greg Bacon wrote:
>
> In article <32A66C...@5sigma.com>,
> "Joseph N. Hall" <jos...@5sigma.com> writes:
> : OK,
> :
> : http://www.5sigma.com/perl/schwtr.html
>
> Maybe someone should RFD comp.lang.perl.japh.authoring and
> comp.lang.perl.japh.advocacy. :-)
How about comp.lang.perl.japh.authoring and comp.lang.perl.japh.d!
Joseph N. Hall
Ilya Zakharevich wrote:
> As many people discovered, English'ization makes Perl more
> obscure. You will not find many modules which use English nowadays (as
> opposed to the initial frenzy).
Some of it I don't mind (especially when I'm teaching). Will the
speed problems be resolved in the future?
Joseph N. Hall
> [...] the "Schwartzian Transform"
> isn't any more efficient than the "sort the indicies" shown in the
> first edition camel.
> So you have code that is harder to read, is no more efficient, but
> probably more than twice as short and "kind of neat" to people who can
> find source code interesting.
>
> I know for the code that I develop, there is no issue of which one to
> use.
I don't know why it is that I seem to be generating half the postings
on this thread, but here I go again.
I use the Schwartzian Transform approach for a variety of reasons:
1) It is efficient--if not the very most efficient, it is in the
ballpark with all the other most efficient approaches
2) It is the most syntactically compact approach (I guess that's
a fancy way of saying "shortest")
3) It uses no temporary variables.
4) It seems very "perlish" to me.
5) It's cool the first time you see it.
6) It's simple when you figure it out.
What I think it boils down to is, if you like using map, you'll
like using the Schwartzian Transform. Otherwise go ahead and
write your foreach loops.
-joseph
Chris Fedde
In article <32A745...@5sigma.com>,
Joseph N. Hall <jos...@5sigma.com> wrote:
>Greg Bacon wrote:
>>
>> Maybe someone should RFD comp.lang.perl.japh.authoring and
>> comp.lang.perl.japh.advocacy. :-)
>
>How about comp.lang.perl.japh.authoring and comp.lang.perl.japh.d!
>
> -joseph
>
I propose the name alt.fan.japh
chris
Ilya Zakharevich
[A complimentary Cc of this posting was sent to Eric D. Friedman
<frie...@medusa.acs.uci.edu>],
who wrote in article <587cma$b...@news.service.uci.edu>:
> In article <586s6v$c...@info.uah.edu>, Greg Bacon <gba...@CS.UAH.Edu> wrote:
> >In article <ERIC.96De...@m-e-ir1.sun.com>,
> > eric....@sun.com (Eric Arnold) writes:
> >: - lots of noise:
> >: { $_->[0] }
> >: This has very little immediate semantic value. Programmers have
> >: evolved beyond using single character register names for a reason.
>
> This objection (at least) is easily addressed with the English module.
> I wonder: has anyone written a little script that goes through a perl
> script and 'anglicizes' it? Might be just what's needed to placate
> those 'pointy haired managers' we keep hearing about, and it might
> also be handy for novices (or others) who are having difficulty
> keeping track of the mnemonic associations the Camel proposes for
> $/ and the like.
As many people discovered, English'ization makes Perl more
obscure. You will not find many modules which use English nowadays (as
opposed to the initial frenzy).
Ilya
Brendan O'Dea
In article <587cma$b...@news.service.uci.edu>,
Eric D. Friedman <frie...@medusa.acs.uci.edu> wrote:
>In article <586s6v$c...@info.uah.edu>, Greg Bacon <gba...@CS.UAH.Edu> wrote:
>>In article <ERIC.96De...@m-e-ir1.sun.com>,
>> eric....@sun.com (Eric Arnold) writes:
>>: - lots of noise:
>>: { $_->[0] }
>>: This has very little immediate semantic value. Programmers have
>>: evolved beyond using single character register names for a reason.
>
>This objection (at least) is easily addressed with the English module.
It is? Perhaps map { $ARG->[0] } may look a little less like line
noise, but I doubt that it makes what this map construct *does* any
easier to grasp.
Due to the heavy overloading of $_ in perl, I am personally dubious as
to the value of *ARG = *_ in the English module. $ARG carries little
(if any) more semantic value than $_ IMHO. You would need a whole
bucketful of typeglob aliases to make $_ more `meaningful' and
*CURRENT_LINE =
*CURRENT_BLOCK =
*FOREACH_VAR =
*MAP_VAR =
*GREP_VAR = *_;
is just plain silly (`#define begin {' anyone?).
I tend to think that if you are using $_ in such a way that it must be
explicitly written in the code too much, then you probably should be
using an appropriately named variable instead. If you were processing
a hosts-ish file:
while (<>)
{
chomp;
s/#.*//;
next unless length;
($addr, $host, @aliases) = split;
# ...
}
makes use of $_ for <>, chomp, s///, length and split, but never
actually needs to manipulate it explicitly. When all of the
preprocessing is done, the fields end up in meaningful names which
should keep the `pointy-hairs' at bay.
Admittedly, due to the nature of map, grep you *need* to write $_ when
manipulating an array with functions other than those which operate on
it by default.
As to the rest of the English module--I'm used to them punctuation
thangs, and although I agree that some of the variables less commonly
used than $_ may be confronting, I figure that relying on intuitive
variable names to express your intention is no substitute for an
appropriate comment:
undef $/; # Slurp whole files
undef $RS;
There is also a regex performance hit when you `use English' if you
don't intend to otherwise reference $` or $' (according to Jeff Friedl).
>I wonder: has anyone written a little script that goes through a perl
>script and 'anglicizes' it? Might be just what's needed to placate
>those 'pointy haired managers' we keep hearing about, and it might
>also be handy for novices (or others) who are having difficulty
>keeping track of the mnemonic associations the Camel proposes for
>$/ and the like.
A quick answer would be:
perl -ne 'print "s/\\\$\Q$2\E/\\\$$1/g;\n"' \
-e 'if /^\t\*(\w+)\s*=\s*\*(\^?\S)\s*;/' \
/usr/local/lib/perl5/English.pm >anglicize.pl
[where of course the path to English.pm should be set appropriately
for your installation]
perl -i.bak -p anglicize.pl <your-scripts-here>
A proper solution which ignored occurences in single quoted strings
(and q//, <<'TAG' etc.) constructs and other unforseen gotchas would
be a non-trivial task.
PS. This `pointy-haired' (-headed?) epithet which was introduced
somewhere into this thread piques my curiosity--what the hell is
it supposed to mean? Managers with crew-cuts? Pin-heads?
Regards,
--
Brendan O'Dea b...@compusol.com.au
Compusol Pty. Limited (NSW, Australia) +61 2 9809 0133
Joseph N. Hall
Yet another posting from me on this topic. Holy cow.
Mike Stok wrote:
>
> In article <58341k$mf3@cdn_news.telecom.com.au>,
> Steven Lee <c82...@vuh263.telecom.com.au> wrote:
> >@output = map { $_->[0] }
> > sort { $a->[1] == $b->[1] ? $a->[2] cmp $b->[2] :
> > $a->[1] <=> $b->[1] }
> > map { [ $_,(split)[1,2] ] } @output;
One minor point here: the Perl Gurus strongly prefer
$a->[1] <=> $b->[1] or $a->[2] cmp $b->[2]
which uses Perl's short-circuit logical operators the way
they were meant to be used, and features two thirds as many
time-consuming subscript operations. (See, if the first comparison
is 0, it returns the value from the second, else it returns
the value from the first. C doesn't work like this.)
Eric Arnold
In article <32A670...@5sigma.com>
jos...@5sigma.com writes:
>I could argue each point, but it's obvious that you are in the "don't
>dare use $_!" camp and I'm in the "why not learn the language, then use
>it" camp, and we're just not going to find common ground.
Hmm. Where do you draw the line? Is everything fair game? I knew a
programmer once whose guideline for writing good C code was, "Well,
it compiled...".
In article <586s6v$c...@info.uah.edu>
gba...@CS.UAH.Edu writes:
>They're not weird when one develops an understanding of Perl. Do you
>hire programmers who don't understand the language they're going to be
>using? TIMTOWTDI in that one can write longhand Perl or Perl. Given
>the innate laziness of programmers, most will opt for the elegant
>(read 'least typing') solution.
Is "least typing" an endorsement? "Well, it compiled...."
Seriously, though, I'm not an absolutist about $_ or other stuff. I
think there is a balance, depending on who your audience is. The
technical/wizard audience will take care of itself. I'm concerned
about:
- programming in production situations where clarity and
maintainability are paramount. What's clear to you won't
necessarily be clear to someone else. It's unfortunate but true
that interesting and "elegant" code is often painful to deal with
when you're under a deadline.
- programming by folks who want to get a job done, who are of medium
programming skill level, and who would rather use TCL or Python or
Java because the reputation of Perl (and perhaps what the local
Perl wizards have cooked up) is too unfamiliar for them to make the
leap, because they don't realize there doesn't have to be much of a
leap.
Speaking of audiences, a couple people remarked that USENET, and
comp.lang.perl.misc are not the "official presentation" of Perl. I'd
submit that almost everybody who uses or thinks about using Perl knows of
its Internet and USENET origins and ties. It's perhaps not as
"official" as the books, but for some things, it's a close second.
What about the FAQ? It's a C.L.P.M. beast. Widely posted idioms
become de facto Perlisms, and eventually affect the perception of
Perl.
I don't deeply care what happens to the Schwartian map/sort thing in
particular (though it would be nice to see it posted with comments),
what I am trying to do is get Perl wizards to see that Perl could have
a broader user base (which benefits us all) if care is taken to be less
elitist about what the capabilities of potential users should be.
-Eric
Joseph N. Hall
Eric Arnold wrote:
>
> In article <32A670...@5sigma.com>
> jos...@5sigma.com writes:
> >I could argue each point, but it's obvious that you are in the "don't
> >dare use $_!" camp and I'm in the "why not learn the language, then use
> >it" camp, and we're just not going to find common ground.
>
> Hmm. Where do you draw the line? Is everything fair game?
Well, sure. See next remark.
> - programming in production situations where clarity and
> maintainability are paramount. What's clear to you won't
> necessarily be clear to someone else.
When I write Perl for public consumption, I do two things:
1) I write the cleanest, most elegant, fastest code possible.
I polish that sucker.
2) I insert comments when necessary to clue people in. As in,
before a Schwartzian Transform (beating that dead horse), something
like "sort files by mod date." The maintainer can take it
from there.
I have seen this approach work well and often, so it suits me fine.
(I only wish I could persuade a few module authors to do the same.)
I can't understand why some people would rather dumb down the language
than just encourage people to stick in a few clues here and there.
Or at least that's the way it seems to me.
> what I am trying to do is get Perl wizards to see that Perl could have
> a broader user base (which benefits us all) if care is taken to be less
> elitist about what the capabilities of potential users should be.
<sputter>
Have you missed the hordes of would-be CGI programmers that post
here? I think Perl has lots of users without elitist aspirations.
In fact I think Perl has lots of users who intend not to understand
it at all. Does that have anything to do with the people who read
this group day in and day out? We still answer their questions
for free. What more could anyone ask for?
Joseph N. Hall
Eric Arnold wrote:
[...]
> Benchmark: timing 3 iterations of eval, raw, subref...
> eval: 5 secs ( 4.37 usr 0.14 sys = 4.51 cpu)
> raw: 4 secs ( 4.30 usr 0.00 sys = 4.30 cpu)
> subref: 9 secs ( 7.88 usr 0.02 sys = 7.90 cpu)
[... some code, for example ]
> @results = ssort1 q{ $a->[1] <=> $b->[1] },
> q{ (split)[-1] },
> @array;
Now I've got you doing my work for me.
This is cool. ;-)
-joseph
Martin Gregory
"Joseph N. Hall" <jos...@5sigma.com> writes:
>
> OK,
>
> http://www.5sigma.com/perl/schwtr.html
>
> -joseph
This page contains the following text...
quote '
@sorted_by_date =
map { $_->[0] }
sort { $a->[1] <=> $b->[1] }
map { [$_, -s] }
@files;
'
Que?
"sorted_by_date"?
--
-- Martin Gregory <mgre...@asc.sps.mot.com> | _--_|\
-- Modeling, Design, & Synthesis Team | / MASC \
-- Motorola Australia Software Centre | \_.-*._/
-- Phone: +61 8 8203 3612, Fax: +61 8 8203 3501 | v
Greg Bacon
[Posted and mailed]
In article <ERIC.96De...@m-e-ir1.sun.com>,
eric....@sun.com (Eric Arnold) writes:
:
: In article <32A670...@5sigma.com>
: jos...@5sigma.com writes:
: >I could argue each point, but it's obvious that you are in the "don't
: >dare use $_!" camp and I'm in the "why not learn the language, then use
: >it" camp, and we're just not going to find common ground.
:
: Hmm. Where do you draw the line? Is everything fair game? I knew a
: programmer once whose guideline for writing good C code was, "Well,
: it compiled...".
In many aspects, C and Perl are not comparable languages. See below.
: In article <586s6v$c...@info.uah.edu>
: gba...@CS.UAH.Edu writes:
: >They're not weird when one develops an understanding of Perl. Do you
: >hire programmers who don't understand the language they're going to be
: >using? TIMTOWTDI in that one can write longhand Perl or Perl. Given
: >the innate laziness of programmers, most will opt for the elegant
: >(read 'least typing') solution.
:
: Is "least typing" an endorsement? "Well, it compiled...."
In C, there is a difference between correct code and "code that works".
In a language like Perl where the language will do the Right Thing for
you, it is difficult to say what is and is not incorrect code. A
couple of weeks ago, Joseph nailed me in the while (<*.foo>) thread
when I said someone was using the wrong looping construct. Both work,
albeit with different semantics, but which is correct? One would be
hard-pressed to decide.
: Seriously, though, I'm not an absolutist about $_ or other stuff. I
: think there is a balance, depending on who your audience is. The
: technical/wizard audience will take care of itself. I'm concerned
: about:
When I write production code, I write clear code but not overly verbose.
I compose with the understanding that someone will have to maintain my
code, but the maintainer will have at least a decent understanding of
the language. If the maintainer (foolishly) chooses to put novices on
the job, then it's their problem. If they want my help, I'll give them
my hourly rates.
: - programming in production situations where clarity and
: maintainability are paramount. What's clear to you won't
: necessarily be clear to someone else. It's unfortunate but true
: that interesting and "elegant" code is often painful to deal with
: when you're under a deadline.
People's complaints that Perl looks like line noise are totally invalid.
If they took two seconds to understand the language and examine Perl code,
they'd notice that use of "weird" characters often draws attention to
that part of the code and makes the programmer ask what's going on.
Then in looking at the context, what's going on becomes clearer (unless
you're dealing with an OPCC entry, but that's an anomolous case :-).
: - programming by folks who want to get a job done, who are of medium
: programming skill level, and who would rather use TCL or Python or
: Java because the reputation of Perl (and perhaps what the local
: Perl wizards have cooked up) is too unfamiliar for them to make the
: leap, because they don't realize there doesn't have to be much of a
: leap.
If they're stupid enough to believe the hype, then let them wallow in
their own stupidity. Do we really want more morons posting FAQs that
could be answered in two seconds of trying it themselves?
: Speaking of audiences, a couple people remarked that USENET, and
: comp.lang.perl.misc are not the "official presentation" of Perl. I'd
: submit that almost everybody who uses or thinks about using Perl knows of
: its Internet and USENET origins and ties.
So? Almost everyone who uses or thinks of using Perl knows that it was
intended as a Unix programming language, but they still insist on
open FD, "C:\temp\beavis\america\neoclassicism";
Your argument doesn't hold.
: It's perhaps not as
: "official" as the books, but for some things, it's a close second.
: What about the FAQ? It's a C.L.P.M. beast. Widely posted idioms
: become de facto Perlisms, and eventually affect the perception of
: Perl.
c.l.p.m is an *informational* source. It's a place to find information
about Perl, not the definition of the language. Even groups like
comp.std.c aren't for reading the definition of the language. The
official sources are ANSI and ISO. Besides, what if someone were to
start alt.lang.perl and spread the myth that Perl is strictly object
oriented. Just because you find information within the bounds of
Usenet doesn't make it true, and I'm sure you know this.
: I don't deeply care what happens to the Schwartian map/sort thing in
: particular (though it would be nice to see it posted with comments),
: what I am trying to do is get Perl wizards to see that Perl could have
: a broader user base (which benefits us all) if care is taken to be less
: elitist about what the capabilities of potential users should be.
I disagree. Perl is not nor should it ever, ever, ever be a teaching
language. Could you imagine what would happen to the brains of students
trying to learn the fundamentals of programming if their first language
were Perl? There would probably be fewer CS majors. :-) However, if
you already have a language or two (or several) under your belt, Perl
should be no problem to pick up. If it is difficult to pick up in that
case (or if you're the "I want a compiiiiiiiiiiled language" weenie,
or "Java Ueber Alles", or "Bill rules my world") then you weren't
predestined to use Perl anyway. :-) (That was not directed at Eric;
the "you" was used in a general sense.) I'm more than happy to let the
morons stay where they are and do as they'll do.
Joseph N. Hall
Martin Gregory wrote:
> quote '
>
> @sorted_by_date =
> map { $_->[0] }
> sort { $a->[1] <=> $b->[1] }
> map { [$_, -s] }
> @files;
>
> '
>
> Que?
>
> "sorted_by_date"?
Eek. Missed one.
Well, at least someone's reading it. ;-)
-joseph
--
76% of all CGI questions posted in comp.lang.perl.misc are answered by:
"CGI.pm. LWP. http://www.perl.com/CPAN/modules/01modules.index.html."
....
Lloyd Zusman
On 6 Dec 1996 20:07:58 GMT, Greg Bacon <gba...@cs.uah.edu> wrote:
> [Posted and mailed]
>
> eric....@sun.com (Eric Arnold) writes:
>
> [ ... ]
>
> : Seriously, though, I'm not an absolutist about $_ or other stuff. I
> : think there is a balance, depending on who your audience is. The
> : technical/wizard audience will take care of itself. I'm concerned
> : about:
>
> When I write production code, I write clear code but not overly verbose.
> I compose with the understanding that someone will have to maintain my
> code, but the maintainer will have at least a decent understanding of
> the language. If the maintainer (foolishly) chooses to put novices on
> the job, then it's their problem. If they want my help, I'll give them
> my hourly rates.
I tend to pretty much agree with Eric Arnold's statement (above). Code
maintenance can be much more expensive than code development, and I go
by the old saying, "As time goes on, computer time gets cheaper and
man-hours get more expensive."
Therefore, I am willing to spend a little bit of time (always a small
percentage of the total development time) to use clearly understood
constructs and decent commenting, so that those who take over my code
in the future don't waste too much time having to figure it out. I
always try to use the most efficient constructs, but I will use a
slightly slower construct that is easy to understand before I will use
a faster construct that might be hard for someone other than me to
figure out ... that is, unless execution efficiency is of utmost
importance. And in that case, I will go out of my way to document the
difficult-to-understand construct so that future maintainers will both
understand what it does, and also understand why I chose to use it.
I believe that I'm usually giving the most value for the money that is
spent to hire me when I write clear, easily maintainable code, and
when my clients don't need to re-hire me to hack at my existing code
when a bug crops up or a change is needed.
In Perl there are very often several ways to perform any given task.
This gives me an opportunity to choose what I consider to be the
clearest and easiest-to-comprehend construct in almost any situation I
choose.
> [ ... ]
>
> People's complaints that Perl looks like line noise are totally invalid.
> If they took two seconds to understand the language and examine Perl code,
> they'd notice that use of "weird" characters often draws attention to
> that part of the code and makes the programmer ask what's going on.
> Then in looking at the context, what's going on becomes clearer (unless
> you're dealing with an OPCC entry, but that's an anomolous case :-).
Not every piece of Perl code I write is intended to be a Perl tutorial
for the uninitiated. In fact, very few scripts I write serve this
function. Nor am I interested in impressing people with my esoteric
Perl knowledge in the code I write. Therefore, if there is a
particularly difficult section of a program I have written, I would
rather go out of my way to make it clear by means of the most
understandable constructs I can use and via comments, than to rely on
this section's opaqueness to stimulate the curiosity of the next
maintainer. And besides, what actually tends to get stimulated by
this sort of thing is frustration in the maintainer and regret by my
former client that he or she paid me so much for a piece of code which
is costing extra time and money to maintain now that I'm gone.
> [ ... ]
>
> If they're stupid enough to believe the hype, then let them wallow in
> their own stupidity. Do we really want more morons posting FAQs that
> could be answered in two seconds of trying it themselves?
Yes. I think that this is worthwhile. I agree that the best way to
learn is to dive in and try it yourself, and that "it's better to
teach a hungry man to fish than to give him a fish." At the same time,
I'd rather just answer a FAQ than to post a condescending "RTFM" reply
which might take just as long to compose. And besides, there are ways
of answering FAQ's which give information and also encourage people to
seek further.
> [ ... ]
>
> : I don't deeply care what happens to the Schwartian map/sort thing in
> : particular (though it would be nice to see it posted with comments),
> : what I am trying to do is get Perl wizards to see that Perl could have
> : a broader user base (which benefits us all) if care is taken to be less
> : elitist about what the capabilities of potential users should be.
>
> I disagree. Perl is not nor should it ever, ever, ever be a teaching
> language. Could you imagine what would happen to the brains of students
> trying to learn the fundamentals of programming if their first language
> were Perl? There would probably be fewer CS majors. :-) However, if
> you already have a language or two (or several) under your belt, Perl
> should be no problem to pick up. If it is difficult to pick up in that
> case (or if you're the "I want a compiiiiiiiiiiled language" weenie,
> or "Java Ueber Alles", or "Bill rules my world") then you weren't
> predestined to use Perl anyway. :-) (That was not directed at Eric;
> the "you" was used in a general sense.) I'm more than happy to let the
> morons stay where they are and do as they'll do.
Well, I strongly disagree. Perl is a very useful language, and I
believe that the world of programming would be all the better if more
people would learn it and use it. Therefore, I want to *promote* its
use, even among novices. And by the way, isn't that what the Perl
Institute is all about? I quote from the very first line of the
letter that accompanied my Perl Institute membership kit:
"The Perl Institute is dedicated to making Perl more useful
for everyone."
Note the final word "everyone".
And therefore, I not only think that your use of the word "morons" is
uncalled for and condescending, but your attitude, if it was shared by
very many Perl enthusiasts, would have a chilling effect on the use of
this language and would stifle progress towards the goals that the
Perl Institute and many of us readers have concerning the language.
Since Perl is so powerful, a little learning can suddenly propel a
novice to great heights of accomplishment using this language. In
other words, today's "moron" could easily become tomorrow's "guru" in
a very short time with Perl, and I therefore, I invite novices from
all over the world to sample the language and learn it ... and to
please ask questions wherever it is appropriate to do so.
If some people want to prevent the FAQ's from tainting their Perl
discussions, then let's create comp.lang.perl.moderated and keep this
newsgroup as it is. In my opinion, the amount of time, effort, and
energy that is spent these days making clever, condescending "RTFM"
statements in response to FAQ's could be better spent moderating the
proposed newsgroup ... and with much more worthwhile results.
--
Lloyd Zusman 01234567 <-- The world famous Indent-o-Meter.
l...@AsFast.com ^ Indent or be indented.
Eric Arnold
In article <589ueu$k...@info.uah.edu>
gba...@CS.UAH.Edu writes:
>:In article <ERIC.96De...@m-e-ir1.sun.com>,
>: eric....@sun.com (Eric Arnold) writes:
>:
>: - programming in production situations where clarity and
>: maintainability are paramount. What's clear to you won't
>: necessarily be clear to someone else. It's unfortunate but true
>: that interesting and "elegant" code is often painful to deal with
>: when you're under a deadline.
>
>People's complaints that Perl looks like line noise are totally invalid.
>If they took two seconds to understand the language and examine Perl code,
..
>
>: Java because the reputation of Perl (and perhaps what the local
>: Perl wizards have cooked up) is too unfamiliar for them to make the
>: leap, because they don't realize there doesn't have to be much of a
>: leap.
>
>If they're stupid enough to believe the hype, then let them wallow in
The hype has a kernel of truth, you know. Perl is definitely abusable,
which is why I'm suggesting care be taken. People aren't stupid to try
to listen to what recommendations they can find.
>their own stupidity. Do we really want more morons posting FAQs that
>could be answered in two seconds of trying it themselves?
We hope people will try hard before posting questions, and use the FAQ,
but should try to guide them rather than call them names.
>
..
>
>: I don't deeply care what happens to the Schwartian map/sort thing in
>: particular (though it would be nice to see it posted with comments),
>: what I am trying to do is get Perl wizards to see that Perl could have
>: a broader user base (which benefits us all) if care is taken to be less
>: elitist about what the capabilities of potential users should be.
>
>I disagree. Perl is not nor should it ever, ever, ever be a teaching
>language. Could you imagine what would happen to the brains of students
Perl can be a fine teaching language. There are many aspects which
make life easy for beginners, and you can avoid the less advanced forms
of the language.
>trying to learn the fundamentals of programming if their first language
>were Perl? There would probably be fewer CS majors. :-) However, if
>you already have a language or two (or several) under your belt, Perl
>should be no problem to pick up. If it is difficult to pick up in that
>case (or if you're the "I want a compiiiiiiiiiiled language" weenie,
>or "Java Ueber Alles", or "Bill rules my world") then you weren't
>predestined to use Perl anyway. :-) (That was not directed at Eric;
>the "you" was used in a general sense.) I'm more than happy to let the
>morons stay where they are and do as they'll do.
>
>Greg
>--
>Greg Bacon <gba...@cs.uah.edu>
>Unix / Perl Consultant
>Perl Institute Partner - http://www.perl.org/
Gee whiz, man, that's harsh posting. I hope people don't get the idea
that the Perl community and the Perl Institute all have your attitude.
Perl can be a great language for a wide range of abilities.
-Eric
Joseph N. Hall
Eric Arnold wrote:
> Perl can be a fine teaching language. There are many aspects which
> make life easy for beginners, and you can avoid the less advanced forms
> of the language.
I have to agree with Eric here. Perl makes a great teaching language
for UNIX scripting, especially if the alternatives are shell and C.
-joseph
--
Tom Christiansen
I hereby propose that the aforementioned Lispism, yclept "Schwartzian
Transform", be recast in a less Teutonic albeit darker light; to wit,
"Black Transform", as this spelling more accurately connotes its sinister
subtleties. :-)
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
Besides, it's good to force C programmers to use the toolbox occasionally. :-)
--Larry Wall in <1991May31.1...@jpl-devvax.jpl.nasa.gov>
Greg Bacon
[Posted and mailed]
In article <slrn5ahht...@ingress1.ingress.com>,
l...@asfast.com (Lloyd Zusman) writes:
: On 6 Dec 1996 20:07:58 GMT, Greg Bacon <gba...@cs.uah.edu> wrote:
: I tend to pretty much agree with Eric Arnold's statement (above). Code
: maintenance can be much more expensive than code development, and I go
: by the old saying, "As time goes on, computer time gets cheaper and
: man-hours get more expensive."
Right. I agree. I'm not saying the production Perl code I write looks
like random characters to the average onlooker because "it's Perl and
if you can't read it, go away!". That's a completely absurd proposition.
It doesn't mean however, I'll forsake using $_ in loops for a regular
variable to enhance readability. Coupled with readable indentation
and judicious use of whitespace and the comment operator, $_ is almost
always the better path to take. Consider
s/foo/bar/;
$var =~ s/foo/bar/;
Using $_ reduces clutter. If it does appear, then, as I said before,
it draws the eye to it and makes the reader ask what's going on.
: Therefore, I am willing to spend a little bit of time (always a small
: percentage of the total development time) to use clearly understood
: constructs and decent commenting, so that those who take over my code
: in the future don't waste too much time having to figure it out.
This should be the underlying methodology used when writing production
code. Does that mean you'll forsake using the post- and preincrement
operators in C because "they're confusing to the novice"? Will you
not use pointers in C because "they're hard for the novice to grasp"?
I should hope not unless you're the victim of some pointy-haired
manager's attempts at forcing code to be readable to the newly hired,
despite the fact that you severly cripple the language and bind the
programmer's hands when you remove such constructs from the language.
The same is true of Perl.
: I
: always try to use the most efficient constructs, but I will use a
: slightly slower construct that is easy to understand before I will use
: a faster construct that might be hard for someone other than me to
: figure out ... that is, unless execution efficiency is of utmost
: importance.
I think we agree on these two points.
: And in that case, I will go out of my way to document the
: difficult-to-understand construct so that future maintainers will both
: understand what it does, and also understand why I chose to use it.
Right... have I said that I avoid such practices? If I did, let me be
the first to make it clear that I firmly believe in the above three
blocks. If more programmers followed what's quoted above, then this
discussion might not even be taking place. :-)
: I believe that I'm usually giving the most value for the money that is
: spent to hire me when I write clear, easily maintainable code, and
: when my clients don't need to re-hire me to hack at my existing code
: when a bug crops up or a change is needed.
Right, but you can't help it if someone who knows nothing, nada, and
niente about Perl (or whatever language the code's in) is assigned to
the job. They would struggle with even the simplest of constructs.
: In Perl there are very often several ways to perform any given task.
: This gives me an opportunity to choose what I consider to be the
: clearest and easiest-to-comprehend construct in almost any situation I
: choose.
Amen.
: > People's complaints that Perl looks like line noise are totally invalid.
: > If they took two seconds to understand the language and examine Perl code,
: > they'd notice that use of "weird" characters often draws attention to
: > that part of the code and makes the programmer ask what's going on.
: > Then in looking at the context, what's going on becomes clearer (unless
: > you're dealing with an OPCC entry, but that's an anomolous case :-).
:
: Not every piece of Perl code I write is intended to be a Perl tutorial
: for the uninitiated. In fact, very few scripts I write serve this
: function. Nor am I interested in impressing people with my esoteric
: Perl knowledge in the code I write.
Did I say that I do?
: Therefore, if there is a
: particularly difficult section of a program I have written, I would
: rather go out of my way to make it clear by means of the most
: understandable constructs I can use and via comments, than to rely on
: this section's opaqueness to stimulate the curiosity of the next
: maintainer.
You don't dumb down your code and go around the world to cross the
street just for the sake of understandability, do you? I realize under-
standability is of the highest importance when writing production code,
but it's simply crazy to expect
$scalar = $scalar + 1;
over
$scalar++;
: And besides, what actually tends to get stimulated by
: this sort of thing is frustration in the maintainer and regret by my
: former client that he or she paid me so much for a piece of code which
: is costing extra time and money to maintain now that I'm gone.
Let's say, for the sake of example, the Perl source code is production
code. Can even the most experienced C programmer just pick up the code
and say to herself, "Hmm.. okay, yeah.. I see" and start modifying and
bug fixing away? For complex software, one has to get into the groove
of the code. There's a whole list of Perl Porters who sometimes find
great difficulty in fixing bugs or adding functionality because of the
software's complexity. Does that make perl a bad product? Not IMHO.
: > If they're stupid enough to believe the hype, then let them wallow in
: > their own stupidity. Do we really want more morons posting FAQs that
: > could be answered in two seconds of trying it themselves?
:
: Yes. I think that this is worthwhile. I agree that the best way to
: learn is to dive in and try it yourself, and that "it's better to
: teach a hungry man to fish than to give him a fish." At the same time,
: I'd rather just answer a FAQ than to post a condescending "RTFM" reply
: which might take just as long to compose. And besides, there are ways
: of answering FAQ's which give information and also encourage people to
: seek further.
Right.
> Why doesn't chmod $file, 0755 work in my PERL script?
Your question is answered in Perl FAQ 4.10 "Why doesn't Perl
interpret my octal data octally?" You can find the Perl FAQ at
You'll find many such articles from me (and most of the regular readers).
I don't flame someone for posting a FAQ. Depending on my mood (and how
much time I have at that moment), I either ignore it or post something
like the above.
: > I disagree. Perl is not nor should it ever, ever, ever be a teaching
: > language. Could you imagine what would happen to the brains of students
: > trying to learn the fundamentals of programming if their first language
: > were Perl? There would probably be fewer CS majors. :-) However, if
: > you already have a language or two (or several) under your belt, Perl
: > should be no problem to pick up. If it is difficult to pick up in that
: > case (or if you're the "I want a compiiiiiiiiiiled language" weenie,
: > or "Java Ueber Alles", or "Bill rules my world") then you weren't
: > predestined to use Perl anyway. :-) (That was not directed at Eric;
: > the "you" was used in a general sense.) I'm more than happy to let the
: > morons stay where they are and do as they'll do.
:
: Well, I strongly disagree. Perl is a very useful language, and I
: believe that the world of programming would be all the better if more
: people would learn it and use it.
I don't see where you and I disagree.
: Therefore, I want to *promote* its
: use, even among novices. And by the way, isn't that what the Perl
: Institute is all about? I quote from the very first line of the
: letter that accompanied my Perl Institute membership kit:
:
: "The Perl Institute is dedicated to making Perl more useful
: for everyone."
:
: Note the final word "everyone".
I'm all for new Perl Converts, but they have to show a little effort on
their part too. How many posts have you seen even in the last week
looking to freeload off someone else? Part of me hopes Perl is never
taught in college curricula because then we'll start getting homework
questions posted like in comp.lang.c.
: And therefore, I not only think that your use of the word "morons" is
: uncalled for and condescending, but your attitude, if it was shared by
: very many Perl enthusiasts, would have a chilling effect on the use of
: this language and would stifle progress towards the goals that the
: Perl Institute and many of us readers have concerning the language.
How about "rude bastards"? Would you walk over to your neighbor's (who
is a carpenter) house and ask him to give you a shelf because he's good
at working with wood? Such a request would be considered rude and out
of line, but people don't seem to have any problem doing it in Usenet
groups.
I agree with the philosophy of TPI (that's why I became a partner);
Perl should be more useful for everyone. One could argue that guns should
be useful for everyone (i.e. for self defense, sport, etc.), but you
don't see the NRA pushing guns into the hands of those who refuse to
educate themselves on the subject, do you?
: Since Perl is so powerful, a little learning can suddenly propel a
: novice to great heights of accomplishment using this language. In
: other words, today's "moron" could easily become tomorrow's "guru" in
: a very short time with Perl, and I therefore, I invite novices from
: all over the world to sample the language and learn it ... and to
: please ask questions wherever it is appropriate to do so.
Your and my definitions of "moron" do not coincide. By my definition,
today's moron will not be tomorrow's guru (without changing her ways)
because today's moron is looking to freeload. I too invite novices
from any- and everywhere to learn the great and wonderful language
of Perl. I also think they should ask questions when appropriate.
Asking questions and looking to freeload are two different things,
though.
: If some people want to prevent the FAQ's from tainting their Perl
: discussions, then let's create comp.lang.perl.moderated and keep this
: newsgroup as it is. In my opinion, the amount of time, effort, and
: energy that is spent these days making clever, condescending "RTFM"
: statements in response to FAQ's could be better spent moderating the
: proposed newsgroup ... and with much more worthwhile results.
RFD it. :-) I'm sure you'd have a broad readership.
Greg Bacon
[Posted and mailed]
In article <58c80p$p5q$1...@csnews.cs.colorado.edu>,
Tom Christiansen <tch...@mox.perl.com> writes:
: I hereby propose that the aforementioned Lispism, yclept "Schwartzian
: Transform", be recast in a less Teutonic albeit darker light; to wit,
: "Black Transform", as this spelling more accurately connotes its sinister
: subtleties. :-)
I second Tom's motion. Who's the chair? :-)
Greg Bacon
[Posted and mailed]
In article <ERIC.96De...@m-e-ir1.sun.com>,
eric....@sun.com (Eric Arnold) writes:
:
: >: Java because the reputation of Perl (and perhaps what the local
: >: Perl wizards have cooked up) is too unfamiliar for them to make the
: >: leap, because they don't realize there doesn't have to be much of a
: >: leap.
: >
: >If they're stupid enough to believe the hype, then let them wallow in
:
: The hype has a kernel of truth, you know. Perl is definitely abusable,
: which is why I'm suggesting care be taken. People aren't stupid to try
: to listen to what recommendations they can find.
Sure. Most languages are abusable. How does the saying go? "C gives
you the power of the gun and a bullet to shoot yourself in the foot
with." Or is it something about rope to hang yourself with?
If you remove the abusability from a language, you end up with something
useless like Java or Pascal.
: >their own stupidity. Do we really want more morons posting FAQs that
: >could be answered in two seconds of trying it themselves?
:
: We hope people will try hard before posting questions, and use the FAQ,
: but should try to guide them rather than call them names.
Show me an example of any instance when I've called a novice names.
If you dig, you'll find that I post helpful answers to many people's
questions. Why is everyone so vehemently defending people who refuse
to do a minutes research on their own before posting?
: >I disagree. Perl is not nor should it ever, ever, ever be a teaching
: >language. Could you imagine what would happen to the brains of students
:
: Perl can be a fine teaching language. There are many aspects which
: make life easy for beginners, and you can avoid the less advanced forms
: of the language.
Some conveniences are nice, like direct assignment of strings,
transparent conversions between data types, etc., but like you said,
Perl is easily abused and could lead the unwary beginner down the
treacherous path of confusion. Would you rather use x86 assembly
language or 68k assembly language to teach assembly language programming?
I think most would opt for the 68k because when they say "general
purpose", they mean general purpose. The x86's instruction set is
full of implied operands and other sources of confusion. (Of course,
if you were shooting for a more practical sort of class, you'd probably
go with the x86... but that's beside the point.)
: Gee whiz, man, that's harsh posting. I hope people don't get the idea
: that the Perl community and the Perl Institute all have your attitude.
What attitude is that? That people ought to try to solve their own
problems before posting to c.l.p.m? That's what this whole thread boils
down to. There are some fantastic beginner-level Perl tutorial/
instructional materials available. Randal's llama springs immediately
to mind. I don't mean that someone who knows nothing about Perl should
be able to instantly be able to read Perl code, else bugger off. I am
saying that coupled with proper informational sources and a bit of effort
on their part, they should be able to pick up Perl easily. For such
reasons is why we have the Institute.
: Perl can be a great language for a wide range of abilities.
Right. The first time I came into contact with Perl was in looking at
the source for a chat server (talker) written by a guy named Evan Koffler.
I remeber how weird the code looked and wishing I could also come to
understand these cryptic runes so curious to the casual onlooker. That
was at least five years ago, and I had neither a Perl manual nor perl on
my system, so I put the code down without learning the language. (I
also didn't copy it to c.l.p.m saying "what does this do, and how can I
change it to do X?".)
A couple of years ago, Perl and I again crossed paths. I forget what
purpose I wanted to accomplish with Perl, but I borrowed a friend's
copy of the first Camel, and began avidly reading it. I read, and I
played, and I wrote umpteen test.pl's. Eventually, I began to get
better (but I still look back at some of my own code and shudder :-).
I learn more about the language with almost every article I read or
every question I submit an answer for. It's an ongoing process.
Still, even though Perl wasn't obvious at first brush, I was able to
pick it up with ample documentation and effort on my own part. We
have TPI so there won't be the problem of no documentation or no
perl on their machine. TPI is also another informational source on
the language. Does it make me a bad partner for wanting users to
at least *try* to solve their own problems? If so, please petition
for my dismissal.
Eric Arnold
In article <58cmna$m...@info.uah.edu>
gba...@CS.UAH.Edu writes:
>In article <ERIC.96De...@m-e-ir1.sun.com>,
[...]
>
>: Gee whiz, man, that's harsh posting. I hope people don't get the idea
>: that the Perl community and the Perl Institute all have your attitude.
>
>What attitude is that? That people ought to try to solve their own
Your post before last referred several times to "morons" and "stupidity" when
talking about people who didn't "get" Perl:
>> People's complaints that Perl looks like line noise are totally invalid.
>> If they took two seconds to understand the language and examine Perl code,
..
>> If they're stupid enough to believe the hype, then let them wallow in
>> their own stupidity. Do we really want more morons posting FAQs that
>> could be answered in two seconds of trying it themselves?
Your "two seconds" rule completely ignores the diversity of [valuable]
people in the larger world who have things to do that Perl can help them
with, but for whom programming is not their primary expertise.
Sure, I too am sometimes disappointed when people post questions that
show they haven't read the book, the manual, or hardly anything. I
know you don't hate all newbies because you do post answers often, so I
suppose it reflects frustration. However, a real newbie might need to
be educated in acceptable behavior as well as educated in Perl, which
is why it does no good to relegate them to "stupid" status.
In your previous post, you mitigate it some:
>>I don't mean that someone who knows nothing about Perl should
>>be able to instantly be able to read Perl code, else bugger off. I am
>>saying that coupled with proper informational sources and a bit of effort
>>on their part, they should be able to pick up Perl easily. For such
>>reasons is why we have the Institute.
I am saying that there are aspects of the language that are not easy
for people of all skill levels to pick up, or at least those aspects
create barriers. Don't forget the additive effect of these aspects.
One can argue that individually, they are easy to grasp, but if you
get enough of them operating together, you create obscurity:
>>> @output = map { $_->[0] }
>>> sort { $a->[1] == $b->[1] ? $a->[2] cmp $b->[2] :
>>> $a->[1] <=> $b->[1] }
>>> map { [ $_,(split)[1,2] ] } @output;
Code like this (especially if meant to be an idiom for posterity
because that makes people think that "everybody understands this, I can
use it without worry") should be posted heavily commented, or with a
clearly written counter example. A reference to a URL or some
explanation elsewhere is unlikely to deter it from ending up raw in
somebody's program for the successor to impale his/herself on.
>problems before posting to c.l.p.m? That's what this whole thread boils
>down to. [...]
Actually, no, the thread was not about posting FAQs to CLPM. It was
about trying to be sure that Perl remains accessible to people of
different programming capabilities, and in particular, to try to make
sure that widely cited idioms are understandable (or made to be) and
don't make Perl seem abstruse to the uninitiated (i.e. Schwartzian
sort/map transform).
-Eric
Michael J Assels
In article <58c80p$p5q$1...@csnews.cs.colorado.edu>,
Tom Christiansen <tch...@mox.perl.com> wrote:
>I hereby propose that the aforementioned Lispism, yclept "Schwartzian
>Transform", be recast in a less Teutonic albeit darker light; to wit,
>"Black Transform", as this spelling more accurately connotes its sinister
>subtleties. :-)
Sounds good to me. It'll make all the linguists happy, and the parallel
with the Black Perl is aesthetically pleasing, too. Anyway, I'm all for
anything that will stigmatize evil programming habits.
Michael
--
$@='@'^'@';$_='!'&~'"';$/='"'&~'!';$^='$'&~'!';$,='('&~'!';$#='$'&'"';$~='?'^
'/';$;='@';$_="".($_|$^|$#|$;).($_|$/|$#|$;).($,|$#|$;).($_|$/|$^|$,|$#|$;).($#
).($/|$#).($/|$,|$;).($_|$^|$~|$#|$;).($_|$/|$~|$#|$;).($^|$~|$#|$;).($#).($_|
$#|$;).($/|$^|$,|$#|$;).($_|$/|$^|$,|$#|$;).($^|$~|$#|$;).($,|$#|$;).($_|$^|$#
|$;).($/|$~|$#|$;).($#).($~|$;).($_|$^|$#|$;).($/|$~|$#|$;).($^|$,|$#|$;).($#)
.($,|$#|$;).($_|$#|$;).($_|$/|$#|$;).($_|$/|$,|$#|$;).($_|$^|$#|$;).($/|$~|$#|
$;).($^|$,|$#).($/|$#).($/|$^|$,|$~|$#).($/|$^|$#).($/|$~|$#);`$_`
Greg Bacon
[Posted and mailed]
In article <ERIC.96De...@m-e-ir1.sun.com>,
eric....@sun.com (Eric Arnold) writes:
:
: In article <58cmna$m...@info.uah.edu>
: gba...@CS.UAH.Edu writes:
: >In article <ERIC.96De...@m-e-ir1.sun.com>,
: [...]
: >
: >: Gee whiz, man, that's harsh posting. I hope people don't get the idea
: >: that the Perl community and the Perl Institute all have your attitude.
: >
: >What attitude is that? That people ought to try to solve their own
:
: Your post before last referred several times to "morons" and "stupidity" when
: talking about people who didn't "get" Perl:
Perhaps I was unclear. Those to whom I referred to as "morons" are
those who don't even try to learn the language or to solve the problem
themselves before looking for a free ride from the group. I don't know
that there are many of us here who belong to the complement of {Larry,
Tom, Randal} who don't at least occasionally run across something in
Perl with which we have little understanding or experience. Let me say
that I am most certainly not lambasting those who do not "get" Perl. As
you saw, I (as were most of us, I'm sure) among those who did not.
: >> People's complaints that Perl looks like line noise are totally invalid.
: >> If they took two seconds to understand the language and examine Perl code,
: ..
: >> If they're stupid enough to believe the hype, then let them wallow in
: >> their own stupidity. Do we really want more morons posting FAQs that
: >> could be answered in two seconds of trying it themselves?
:
: Your "two seconds" rule completely ignores the diversity of [valuable]
: people in the larger world who have things to do that Perl can help them
: with, but for whom programming is not their primary expertise.
Are you saying we as a group should condone the posting of questions
that obviously haven't been researched? There is a difference between
learning the language and looking for a gift of someone else's time and
expertise with no effort in return.
: Sure, I too am sometimes disappointed when people post questions that
: show they haven't read the book, the manual, or hardly anything. I
: know you don't hate all newbies because you do post answers often, so I
: suppose it reflects frustration. However, a real newbie might need to
: be educated in acceptable behavior as well as educated in Perl, which
: is why it does no good to relegate them to "stupid" status.
I agree 100%. I think we as the voice of the language ought to share
as many informational sources as we can about the language. We all
do. Look at any followup from any regular. Usually they contain
references to Tom's F7Ks or the manual pages or the FAQ or something.
None of us were born emitting Perl; we all had to learn it at some
point, and I am not professing to be some prodigy. We all had to learn,
and we have all benefited from the group in some way, and it is our
duty to repay that debt by helping others to learn Perl.
: In your previous post, you mitigate it some:
:
: >>I don't mean that someone who knows nothing about Perl should
: >>be able to instantly be able to read Perl code, else bugger off. I am
: >>saying that coupled with proper informational sources and a bit of effort
: >>on their part, they should be able to pick up Perl easily. For such
: >>reasons is why we have the Institute.
:
: I am saying that there are aspects of the language that are not easy
: for people of all skill levels to pick up, or at least those aspects
: create barriers. Don't forget the additive effect of these aspects.
: One can argue that individually, they are easy to grasp, but if you
: get enough of them operating together, you create obscurity:
:
: >>> @output = map { $_->[0] }
: >>> sort { $a->[1] == $b->[1] ? $a->[2] cmp $b->[2] :
: >>> $a->[1] <=> $b->[1] }
: >>> map { [ $_,(split)[1,2] ] } @output;
You make an excellent point.
: Code like this (especially if meant to be an idiom for posterity
: because that makes people think that "everybody understands this, I can
: use it without worry") should be posted heavily commented, or with a
: clearly written counter example. A reference to a URL or some
: explanation elsewhere is unlikely to deter it from ending up raw in
: somebody's program for the successor to impale his/herself on.
Perhaps. Just about a week ago, I posted a sort similar to this, but
I also provided the longhand, handholding version. In so doing (I hope
so at least) helped to solve the person's problem, but I also demonstrated
the expressive power of our wonderful language.
: >problems before posting to c.l.p.m? That's what this whole thread boils
: >down to. [...]
:
: Actually, no, the thread was not about posting FAQs to CLPM. It was
: about trying to be sure that Perl remains accessible to people of
: different programming capabilities, and in particular, to try to make
: sure that widely cited idioms are understandable (or made to be) and
: don't make Perl seem abstruse to the uninitiated (i.e. Schwartzian
: sort/map transform).
IMHO, the {Schwartzian, Black} Transform isn't an idiom, nor should it
acheive that status IMHO. It is a powerful demonstration of the
language's motto: TMTOWTDI. In most cases, there's a myriad of ways
to do it. It's just that Randal's way is uniquely his. What's wrong
with adding a little flair and art to one's code? (Yes, in a production
situation, this is often a Bad Thing.) Randal has given much to the
language, and if he sees fit to post in his own style, then we should be
grateful for his contribution instead of casting stones at him under the
pretense of being defenders of the faith. If you feel Randal was too
terse, then you have the right to post a followup too. (Just be sure to
Cc: it to the poor sod. :-)
Joseph N. Hall
Greg Bacon wrote:
>I don't know
> that there are many of us here who belong to the complement of {Larry,
> Tom, Randal} who don't at least occasionally run across something in
> Perl with which we have little understanding or experience.
I know for a fact that all three of {Larry, Tom, Randal} also
occasionally run across something in Perl that surprises them.
eieio comes to mind. The -> syntax also comes to mind. This is
only going to get "worse." The pile of minor little obscure tweaks
being generated by p5p will one day take nearly as much time to
explain as the basic language itself--at least if it keeps going
the way it's going now.
Joseph N. Hall
Gurusamy Sarathy wrote:
> In article <32AB6D...@5sigma.com>,
> Joseph N. Hall <jos...@5sigma.com> wrote down this random thought:
> >The pile of minor little obscure tweaks
> >being generated by p5p will one day take nearly as much time to
> >explain as the basic language itself--at least if it keeps going
> >the way it's going now.
>
> thinks *should* happen?
I *thought* it was an observation. How did you make the leap to
sanctimony?
Randal Schwartz
>>>>> "Greg" == Greg Bacon <gba...@cs.uah.edu> writes:
Greg> [Posted and mailed]
Greg> In article <58c80p$p5q$1...@csnews.cs.colorado.edu>,
Greg> Tom Christiansen <tch...@mox.perl.com> writes:
Greg> : I hereby propose that the aforementioned Lispism, yclept "Schwartzian
Greg> : Transform", be recast in a less Teutonic albeit darker light; to wit,
Greg> : "Black Transform", as this spelling more accurately connotes its sinister
Greg> : subtleties. :-)
Greg> I second Tom's motion. Who's the chair? :-)
Hey, wait a second. The next thing you'll be proposing is that
everything Tom writes is "Christ-like".
:-)
print "Just another Perl hacker," # but not what the media calls "hacker!" :-)
## legal fund: $20,495.69 collected, $182,159.85 spent; just 631 more days
## before I go to *prison* for 90 days; email fu...@stonehenge.com for details
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <mer...@stonehenge.com> Snail: (Call) PGP-Key: (finger mer...@ora.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
Gurusamy Sarathy
[ mailed and posted ]
In article <32AB6D...@5sigma.com>,
Joseph N. Hall <jos...@5sigma.com> wrote down this random thought:
>The pile of minor little obscure tweaks
>being generated by p5p will one day take nearly as much time to
>explain as the basic language itself--at least if it keeps going
>the way it's going now.
And, would you be so kind as to indicate what Your Sanctimony
thinks *should* happen?
- Sarathy.
gs...@umich.edu
Dave Hammen
In article <58804p$s...@tyndall2.tyndall.com.au>,
Brendan O'Dea, b...@tyndall2.tyndall.com.au writes:
>PS. This `pointy-haired' (-headed?) epithet which was introduced
> somewhere into this thread piques my curiosity--what the hell is
> it supposed to mean? Managers with crew-cuts? Pin-heads?
My first thought -- is this poster from Mars? So I checked the IP
address. Not quite - just Australia.
The epithet comes from *the* comic strip posted on more American
engineers' doors than all other comic strips combined -- Dilbert.
Here's the opening frame from Sunday, Dec 8:
Dilbert: "Our pointy-haired boss will be joining us by speakerphone."
(Scott Adams, copyright 1996, United Feature Syndicates, Inc).
Those from far away can get their Dilbert fix at
http://www.unitedmedia.com/comics/dilbert/
-----
I find this thread engaging. It's similar to one involving Greg
Bacon, me and others a few weeks ago. I haven't responded to this
one because I have had much better things to do than satisfy my
c.l.p.m. addiction. I coached a soccer team through an undefeated
regular season, an association championship, and then on to
district finals (didn't fare so well there, but we still had a
*great* season). I'm in a good mood. My computer crashed while
composing this note the first time, and I'm still in a good mood.
-----
In article <32A7B8...@5sigma.com>,
Joseph N. Hall, jos...@5sigma.com writes:
>I use the Schwartzian Transform approach for a variety of reasons:
>1) It is efficient--if not the very most efficient, it is in the
> ballpark with all the other most efficient approaches.
a) So what? Efficiency should not be a concern until one finds that
it is a concern. I have almost always found that one small section
of code in an application is the CPU hog. This critical code is
easy to identify. That section, yes make it efficient. The rest,
make it clear.
b) The other equally efficient approaches are much easier to
understand. Efficiency is a wash, so other factors like come into
play. I agree with Tom C; these other factors came into play first
(e.g. maintainability). The wash on efficiency just ices the cake.
>2) It is the most syntactically compact approach (I guess that's
> a fancy way of saying "shortest")
The hash mechanism beats map if one uses a name like %s. Make the
variable names a little more meaningful, map beats hash slightly.
Granted, map beats hash in semicolon count. Big deal. What really
counts is total size - code plus comments. Add the size of the
comment operator needed to make the code clear. So much for the
most compact approach.
>3) It uses no temporary variables.
Yes it does. That big array created from the innermost map exists, it
just doesn't have a name. Each element of that anonymous array is
an anonymous array reference that's really just an wierd data
structure with nearly anonymous names like '[0]' and '[1]'. The
Blacker than Black Transform with which this post is concerned
agravates this by using another real meaningful name like '[2]'. To
top it off, the Black Transform sorts this anonymous array of
anonymous arrays with anonymous elements. Too much.
All that anonymity obfuscates. IMHO, sorting the list of scalars one
wants sorted using a lookup into a hash table is much clearer than
sorting a wierd structure. The hash mechanism uses named temporary
variables? What in the world is *wrong* with that?
>4) It seems very "perlish" to me.
To me the most perlish of all perl code uses regular expressions and
hashes. Where are these?
>5) It's cool the first time you see it.
No comment.
>6) It's simple when you figure it out.
Which is why it takes hundreds of lines of HTML code to explain it?
>
Now Joseph and Greg, before you put words into my typing, don't. I
am not saying "never use anonymous arrays", just like I never said
"never say i++." Anonymous references certainly have their place.
For one thing, they completely eliminate the need for gensym-like
agents (a Lispification I found myself using in Perl 4). Nesting
references makes sense in some cases too. Complex problems beget
complex data structures. This particular sort problem is not
complex; a complex data structure is just silly.
What are we up against as sharp developers who need to build
maintainable code? Unfortunately, its a freshout.
... with a C average
... from some fourth tier school.
--
Dave Hammen / LinCom Corporation
Soccer rules
Bennett Todd
On 8 Dec 1996 01:12:23 GMT, Michael J Assels <mjas...@cs.concordia.ca> wrote:
>Anyway, I'm all for anything that will stigmatize evil programming habits.
I think I'm missing something here. What exactly is the "evil programming
habit"? Using list operators in a functional programming style? Writing code
that you find obscure? Using the "map" operator at all? What precisely is the
evil you wish to stigmatize?
I quite like this programming construct. When I first read it, then read Tom's
marvelous explication, I thought it was really fascinating. I've continued to
find uses for composing list operators, including lots of map{} invocations,
and generally I find that the results are compact, efficient, and correct by
inspection, where the laborious paragraphs of code to do the same thing are
anything but clear or obvious.
-Bennett
Gurusamy Sarathy
[ mailed and posted ]
In article <32ABA2...@5sigma.com>,
Joseph N. Hall <jos...@5sigma.com> wrote:
>Gurusamy Sarathy wrote:
>> In article <32AB6D...@5sigma.com>,
>> Joseph N. Hall <jos...@5sigma.com> wrote down this random thought:
>> >The pile of minor little obscure tweaks
>> >being generated by p5p will one day take nearly as much time to
>> >explain as the basic language itself--at least if it keeps going
>> >the way it's going now.
>>
>> And, would you be so kind as to indicate what Your Sanctimony
>> thinks *should* happen?
>
>I *thought* it was an observation. How did you make the leap to
>sanctimony?
A pretty useless "observation", since you neither bothered to qualify
it with the facts that prompted you to make it, nor offered anything
by way of suggestions.
And since I've never seen you contribute to discussion on p5p
in the last 2 years, I had no compunction about making that leap.
If you must respond to this, let's please take it off the air.
I'd hate to sully c.l.p.m with my episodes of outrage.
- Sarathy.
gs...@umich.edu
Tom Christiansen
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
jos...@5sigma.com writes:
:Maybe a better optimizer will partly
:fix this some day, but the rule of thumb is to avoid using subscripts
:whenever possible, and especially avoid using the same subscript
:expression more than once (as in using $a[i] over and over again
:inside a loop).
Any optimizer worth its salt will handle that case. I suspect
that good stuff along these lines will come of the compiler.
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
"111% of crap is everything." --Larry Wall
Chris Fedde
>
>--tom
>--
The motion has been made and seconded. All in favor say "aye." All
opposed say "nay." The "ayes" have it.
All future references to "The Schwartzian Transform" shall be
replaced with the words "The Black Transform". Note that this
refers specifically to the capitalized form of the string "The
Schwartzian Transform" which refers to the specific functional
composition of map(sort(map)) including the required key transform
and elimination. The general technique sometimes called functional
programming will _not_ be designated as such.
chris
Michael J Assels
In article <slrn5ao5i...@onyx.interactive.net>,
Bennett Todd <b...@interactive.net> wrote:
>On 8 Dec 1996 01:12:23 GMT, Michael J Assels <mjas...@cs.concordia.ca> wrote:
>>Anyway, I'm all for anything that will stigmatize evil programming habits.
>
>I think I'm missing something here. What exactly is the "evil programming
>habit"? Using list operators in a functional programming style? Writing code
>that you find obscure? Using the "map" operator at all? What precisely is the
>evil you wish to stigmatize?
Damn! I forgot my smiley. I hate it when that happens. I *meant* to be
funny by being anal in the body and oral in the signature (q.v.).
>I quite like this programming construct. When I first read it, then read Tom's
>marvelous explication, I thought it was really fascinating. I've continued to
>find uses for composing list operators, including lots of map{} invocations,
>and generally I find that the results are compact, efficient, and correct by
>inspection, where the laborious paragraphs of code to do the same thing are
>anything but clear or obvious.
I like it too, and not just because of its technical virtues. I think it's
*fun*. I agree that if c.l.p.m is to be considered a paedogogical medium
it's best to leave this sort of thing out, lest the novices be scared away.
But I also think Perl would be as boring as Pascal if it weren't for the
Black Transform, the Black Perl, etc. Let's hear it for the Black Bits.
Sorry about the missing smiley,
Bennett Todd
On 10 Dec 1996 13:39:28 GMT, Michael J Assels <mjas...@cs.concordia.ca> wrote:
>Sorry about the missing smiley,
And sorry for climbing all over you. It's a shame that smileys are so
necessary; you have a reasonable inclination to try to keep them down, since
they are a sort of annoying cutsieness, but then every time you try to leave
one off some humorless putz like me comes huffing up.
Oh well. Perl is cool. Comp.lang.perl.misc is cool. And it's _amazing_ that
someone who could write perltoot, with such classic gems as the Closures as
Objects section, would try to come down so heavy on map-sort-map. I guess he
did get a lot of people thinking, and debating, about good programming style,
so it has to be counted a successful salvo.
-Bennett
Greg Bacon
[Posted and mailed]
In article <58hmti$mk7$1...@keota.uswmedia.com>,
cfe...@keota.uswmedia.com (Chris Fedde) writes:
: The motion has been made and seconded. All in favor say "aye." All
: opposed say "nay." The "ayes" have it.
I rise to a point of order, Mr. Chairman! The question was never called,
so discussion is not yet finished.
:-),
Eric Arnold
In article <slrn5aqqv...@onyx.interactive.net>
b...@interactive.net (Bennett Todd) writes:
>Oh well. Perl is cool. Comp.lang.perl.misc is cool. And it's _amazing_ that
>someone who could write perltoot, with such classic gems as the Closures as
>Objects section, would try to come down so heavy on map-sort-map. I guess he
It's not the least bit amazing. I believe Tom was coming down, as
always, only against obscurity not the algorithm itself. He's spent a
whole lot of time trying to shed light onto the difficult parts of
Perl, and the map-sort-map code was presented without explanation or
alternative, and continues to be (even though detached explanations now
exist), which is why I chimed in.
What is amazing to me is that there are so many people who seem to be
missing the point about this, and thinking their right to use all
aspects of Perl is being jeopardised. Because Perl has so many useful
syntactic forms, two perceptions need to be more carefully nurtured for
Perl than for more restrictive languages:
1) that Perl can be completely on par with C in terms of writing
clear production code, and
2) that Perl can be good language for people of all capabilities,
even those who might *never* care to deal with something like the
Schwartzian map-sort-map.
These points were not emphasized prior to Perl5, since Perl5 ushered
Perl into the realm of a general programming language. The amount of
documentation and support has grown immensely with Perl5, but Perl5
has a legacy reputation to try to shrug off; it doesn't exist
everywhere, certainly, but I encounter it often enough to bother me.
>did get a lot of people thinking, and debating, about good programming style,
>so it has to be counted a successful salvo.
Amen.
-Eric
Roderick Schertler
On 5 Dec 96 04:24:12 GMT, eric....@sun.com (Eric Arnold) said:
>
> The new cost is the dereference of the sub reference, and the overhead
> of a sub call (plus any local variable copies, etc). The performance
> hit wasn't "huge", but was significant.
You can get around the cost of the deref by locally giving the anonymous
sub a name.
local *cmp_sub = $coderef;
@list = sort cmp_sub @list;
(I got this technique from somebody else when I posted a question about
the speed hit of C<sort &$coderef> some months ago, but I'm afraid I
don't remember who it was. It might have been Kenneth Albanowski.)
When I plugged code like this into your benchmark (as method "sub") I
got very respectable results:
array len=5000
Benchmark: timing 10 iterations of eval, raw, sub, subref...
eval: 35 secs (34.65 usr 0.39 sys = 35.04 cpu)
raw: 34 secs (34.30 usr 0.09 sys = 34.39 cpu)
sub: 39 secs (38.10 usr 0.12 sys = 38.22 cpu)
subref: 66 secs (66.45 usr 0.28 sys = 66.73 cpu)
--
Roderick Schertler
rode...@gate.net