Re: [O] Re: Yahoo is moving to PHP ??
Perrin Harkins writes: Correct Perl style is probably not something that any two people will ever agree on. If you use Extreme Programming, the whole team has to agree. Collective ownership, pair programming, and refactoring all suffer if you don't have a common coding style. The use of map, unless, closures, eval, etc. needs to be discussed and agreed on. It's a sign of a weak team if you can't agree on these details. I've seen some hideous Java code at this place that really takes the wind out of the Java is more maintainable argument. I thought all Java code is hideous. ;-) Rob
Re: [O] Re: Yahoo is moving to PHP ??
Perrin == Perrin Harkins [EMAIL PROTECTED] writes: Perrin Someone else will eventually have to maintain them, so I Perrin write in a way that a novice with a copy of Learning Perl has a hope Perrin of understanding. Perrin When I work in an environment that is more Perl-centric, I expand the Perrin vocabulary of my code more. This is the position we support during our code review services as well. You can use fancy stuff, but be sure to point to where you learned it. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [O] Re: Yahoo is moving to PHP ??
On Fri, Nov 01, 2002 at 01:42:45PM -0500, Perrin Harkins wrote:
It sounds like you're saying that you should only use a subset of Perl
as some programmers may not understand the other parts of it?
That is what I'm saying. I'm aware that this is a controversial opinion
in the Perl world. However, I think it's reasonable to know your
audience and write for them. That's the good part of More Than One Way.
The New York Times writes their articles for a certain reading level,
and I do the same with my code.
In principle, I broadly agree with this ... but ...
Note that different audiences have different levels. You can expect
someone who opens up the code in a module on CPAN to be pretty fearless
about advanced Perl ideas. On the other hand, the people in my current
office are mostly novices so I try to take it easy on them when writing
code for work. I will still use a Schwartzian Transform if I need one,
but I'll put in a comment saying this is a Schwartzian Transform, see
such and such URL for an explanation. Same deal with things like
hash-slices, and I try to avoid using $_ when it isn't necessary.
... but I think that there should be a certain level of ability that
should be assumed when coding commercially ...
I'm all for abstracting away the really deep magic and serious perl
wizardry into modules that less experienced programmers shouldn't need
to delve into in the normal course of things, but things like map,
hash slices, and even $_ aren't what I could class as advanced Perl ideas.
I would expect anyone being paid to work with Perl to understand these -
they're going to be popping up all over the place in code, and aren't
that easy (or sensible) to hide away.
And the best way for novices to learn these concepts is to see them
properly used throughout the code base, not for their use to be shied
away from.
So would I, in that situation. It's not that map is so evil, but rather
that I have often seen people overuse it (especially after a
first-reading of Effective Perl), and write confusing code with it by
jamming too much into the map { some stuff } list form.
Agreed.
But 'proper' use of map can be explained fairly simply. It's not a
difficult concept.
Tony
Re: [O] Re: Yahoo is moving to PHP ??
Tony Bowden wrote: ... but I think that there should be a certain level of ability that should be assumed when coding commercially ... My current situation is somewhat unusual because Perl is not the language that the people I am coding with were hired to write. They are mostly Java programmers, and I'm just doing some useful admin and database scripts in Perl because it's so much quicker than doing them in Java. Someone else will eventually have to maintain them, so I write in a way that a novice with a copy of Learning Perl has a hope of understanding. When I work in an environment that is more Perl-centric, I expand the vocabulary of my code more. things like map, hash slices, and even $_ aren't what I could class as advanced Perl ideas. Perl is a large language, and not all of it needs to be used all the time. I wouldn't call $_ advanced, but I know I hate reading code where people use it more than they have to. Hash slices and map are uncommon enough that I had been writing fairly challenging OO Perl for quite a while before I ever saw one. I don't use them when something more basic will do just as well. Correct Perl style is probably not something that any two people will ever agree on. This used to bother me more before I realized that all languages have this problem, even though they try to deny it. I've seen some hideous Java code at this place that really takes the wind out of the Java is more maintainable argument. - Perrin
Re: [O] Re: Yahoo is moving to PHP ??
Franck PORCHER wrote: But for is a lot easier to read and debug, IMHO Is there a significant performance difference in using map instead? My experience is that in most cases, the for construct is used to apply the same treatment to all the elements of an array, whence the map construct. In those cases, the readibility is definitely altered by the index that get in the way. I think you're forgetting that for is just a synonym for foreach. You don't need an index. Of course, this is a quick analysis not taking into account other factors like readibility versus efficiency. In fact, regarding the efficiency of the map construct, I often wondered whether Perl detects map being ran in a void context, so as to give it an iterative interpretation, avoiding to build the output list. It's really not a matter of efficiency, but rather of correctness. Using map in a void context is a mistake. There is a time and place for map: when you want to do something to each element in an array and return the array on the other side. Otherwise, use for, like this: some_function($_) for array;. Even when map is not incorrect, I usually avoid it because it has a tendency to take your code from nice, readable perl to evil hx0r PERL in 3 characters. This is the kind of thing that Yahoo was probably worried about when the decided not to use Perl. - Perrin
Re: [O] Re: Yahoo is moving to PHP ??
On Fri, Nov 01, 2002 at 03:10:54AM -0500, Perrin Harkins wrote:
There is a time and place for map: when you want to do something
to each element in an array and return the array on the other side.
Otherwise, use for, like this: some_function($_) for array;.
Even when map is not incorrect, I usually avoid it because it has a
tendency to take your code from nice, readable perl to evil hx0r PERL
in 3 characters. This is the kind of thing that Yahoo was probably
worried about when the decided not to use Perl.
This statement surprises me somewhat.
It sounds like you're saying that you should only use a subset of Perl
as some programmers may not understand the other parts of it?
I'd say that if this were true the problem is in training the programmers.
map and grep are very powerful constructs, and when used correctly lead
to much more readable and maintainable code once you understand them:
Given:
sub square { $_[0] ** 2 }
my nums = (1 .. 10);
Which would say is more readable and maintainable?
1)
my squares;
push squares, square($_) for nums;
2)
my squares = nums;
$_ = square($_) for squares;
3)
my squares = map square($_), nums;
I'd go for (3) every time.
Tony
Re: [O] Re: Yahoo is moving to PHP ??
Tony Bowden wrote:
It sounds like you're saying that you should only use a subset of Perl
as some programmers may not understand the other parts of it?
That is what I'm saying. I'm aware that this is a controversial opinion
in the Perl world. However, I think it's reasonable to know your
audience and write for them. That's the good part of More Than One Way.
The New York Times writes their articles for a certain reading level,
and I do the same with my code.
Note that different audiences have different levels. You can expect
someone who opens up the code in a module on CPAN to be pretty fearless
about advanced Perl ideas. On the other hand, the people in my current
office are mostly novices so I try to take it easy on them when writing
code for work. I will still use a Schwartzian Transform if I need one,
but I'll put in a comment saying this is a Schwartzian Transform, see
such and such URL for an explanation. Same deal with things like
hash-slices, and I try to avoid using $_ when it isn't necessary.
Given:
sub square { $_[0] ** 2 }
my nums = (1 .. 10);
Which would say is more readable and maintainable?
1)
my squares;
push squares, square($_) for nums;
2)
my squares = nums;
$_ = square($_) for squares;
3)
my squares = map square($_), nums;
I'd go for (3) every time.
So would I, in that situation. It's not that map is so evil, but rather
that I have often seen people overuse it (especially after a
first-reading of Effective Perl), and write confusing code with it by
jamming too much into the map { some stuff } list form.
- Perrin
Re: [O] Re: Yahoo is moving to PHP ??
Hi
( 02.11.01 13:42 -0500 ) Perrin Harkins:
It's not that map is so evil, but rather that I have often seen people
overuse it (especially after a first-reading of Effective Perl), and
write confusing code with it by jamming too much into the map { some
stuff } @list form.
As a former map addict, I was shown the error of my ways on
#[EMAIL PROTECTED] when it was pointed out to me that map
returns a value. If you're not going to use that value, just use
for[each].
This way the code is easier to read and the extra overhead of the return
value [minute as it is] is avoided.
--
.--- ...
Re: [O] Re: Yahoo is moving to PHP ??
Mike == Mike Miller [EMAIL PROTECTED] writes: Let's prey that those PHP geeks quickly discover the true joy of working with functionnals (map and al.). I have often wondered about the ratio of Perl programmers still using the C-like for construct. I guess it's rather low. Mike But for is a lot easier to read and debug, IMHO Is there a Mike significant performance difference in using map instead? He said C-like for. Your for is probably a foreach, if you're comparing it with map. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [O] Re: Yahoo is moving to PHP ??
On Thu, 31 Oct 2002, Mike Miller wrote: On Wed, 30 Oct 2002 20:28:11 + (GMT) Franck PORCHER [EMAIL PROTECTED] wrote: Let's prey that those PHP geeks quickly discover the true joy of working with functionnals (map and al.). I have often wondered about the ratio of Perl programmers still using the C-like for construct. I guess it's rather low. But for is a lot easier to read and debug, IMHO Is there a significant performance difference in using map instead? My experience is that in most cases, the for construct is used to apply the same treatment to all the elements of an array, whence the map construct. In those cases, the readibility is definitely altered by the index that get in the way. I think that the adoption of map is mostly cultural, depending on one's background experience with functionnal programming, basically splitting the way of thinking about collections of objects between the array/for construct (fortran programmers for instance) and list/map construct (lisp programmers). Of course, this is a quick analysis not taking into account other factors like readibility versus efficiency. In fact, regarding the efficiency of the map construct, I often wondered whether Perl detects map being ran in a void context, so as to give it an iterative interpretation, avoiding to build the output list. Does someone know about this ? Franck. --M. -- ESSENTIAL SOFTWARE - Ingénierie Informatique Solutions Linux Open Source en Polynésie française http://www.esoft.pf/ Tél: (689) 562 395 / 508 288-289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Lassé des virus? Osez Linux, le choix moderne des gouvernements et des entreprises Fortune 500
Re: [O] Re: Yahoo is moving to PHP ??
On Thu, 31 Oct 2002, Franck PORCHER wrote: In fact, regarding the efficiency of the map construct, I often wondered whether Perl detects map being ran in a void context, so as to give it an iterative interpretation, avoiding to build the output list. IIRC (but I might not) then it does since version X, where X is relatively recent. - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
[O] Re: Yahoo is moving to PHP ??
Let's prey that those PHP geeks quickly discover the true joy of working with functionnals (map and al.). I have often wondered about the ratio of Perl programmers still using the C-like for construct. I guess it's rather low. Franck. On Wed, 30 Oct 2002, Tagore Smith wrote: Rob Nagler wrote: I think Yahoo Stores is written in Lisp. I also believe it handles the front and back end. Would be interesting to know why this was left out of the discussion. Yahoo store was originally ViaWeb and was written in Common Lisp. It was one of the first large applications made available over the web. Paul Graham has an article about it at http://www.paulgraham.com/paulgraham/avg.html ViaWeb was deployed using clisp, a very portable, but somewhat incomplete, common lisp implementation that compiles lisp to bytecode. I believe (take this with a grain of salt, as it's third hand) that ViaWeb only presented dynamic content to the merchant, not to the user of the merchant's site- it was a web application that built static web sites. Each merchant had their own dedicated lisp listener to nteract with. This probably isn't the model that Yahoo had in mind, and it might not have occured to them that the commercial Lisps have native threads. Using clisp would also obscure one of the big advantages to using lisp- many lisp implementations compile to native code, so they're very efficient. Also, I'd imagine that you can hire just about any programmer to work on a PHP system; even if they haven't seen PHP before they'll pick it up quickly (once they get used to the weird reference semantics), and most of the work will be in learning the libraries. Graham's system uses macros extensively, and from other code of his that I've read (Graham wrote a couple of books about Lisp), I'd bet that he uses recursion and mapping functions a lot as well. I think it would be harder to hire people to work on his system (of course you'd probably also get more experienced people, so that might not be such a bad thing). Tagore Smith -- ESSENTIAL SOFTWARE - Ingénierie Informatique Solutions Linux Open Source en Polynésie française http://www.esoft.pf/ Tél: (689) 562 395 / 508 288-289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Lassé des virus? Osez Linux, le choix moderne des gouvernements et des entreprises Fortune 500
