You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Mithun Bhattacharya <in...@yahoo.com> on 2002/10/30 09:10:24 UTC
Yahoo is moving to PHP ??
http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm
If nothing else this should be atleast generate some thoughts ?? It
does show the mod_perl logo so I assume the comments are applying to
mod_perl and not perl/cgi.
Mithun
--------------------------------------
Cons
� There�s More Than One Way To Do It
� poor sandboxing, easy to screw up server
� wasn�t designed as web scripting language
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
RE: Yahoo is moving to PHP ??
Posted by Oscar Serrano <os...@fondos.net>.
At 11:39 30/10/2002 -0500, Jesse Erlbaum wrote:
>Hi John --
>
> > Quasi-seriously, as someone who has had to maintain mountains of bad
> > perl code, I know TMTOWTDI can have a downside; but the openness of the
> > language is what has lead to its greatness ...
>
>This doesn't have to be as big a problem as it often is. Having coding
>standards makes a big difference no matter WHICH language you use. Have you
>ever seen bad Java code? Java has reached parity with Perl in that area,
>for sure! This is a problem in ANY language. You just can't "hire smart
>people" and send them out there without direction.
I completely agree. Bad code is bad code in any languaje (well, perhaps
with perl you can write the most encrypted code, but only if you are
looking for it).
I don't really know the ability of PHP to work with templates, but since I
discovered Template Toolkit 2, I've never written (nor will I) more web
applications without it. I cannot understand why don't want them to use
HTML templates. I suspect, the propietary languaje the were using was
similar in concept to PHP or ASP not allowing templates.
Oscar Serrano.
>At my company we base all our work on CGI::Application and HTML::Template to
>solve exactly this problem. CGI-App and HTML-Tmpl (or Template Toolkit --
>TT is compatible with C::A) "strongly suggest" a standard way of writing the
>uninteresting bits of a web application -- namely, state management and HTML
>separation. They go beyond what is provided by simply making a decision to
>use a particular API, such as CGI, mod_perl, PHP, Mason, etc.
>
>No software library will factor this problem out entirely. This is really
>a human problem -- not a software problem. However, choosing a specific
>tactic is a good start.
>
>TTYL,
>
>-Jesse-
>
>
>--
>
> Jesse Erlbaum
> The Erlbaum Group
> jesse@erlbaum.net
> Phone: 212-684-6161
> Fax: 212-684-6226
Re: [OT] Re: Yahoo is moving to PHP ??
Posted by Michael Johnson <mi...@firewing.org>.
On Wed, 30 Oct 2002, Richard Clarke wrote:
> List,
> You are probably not the best people to ask for an answer which
> might advocate PHP,
> but.....
> Can someone who is more proficient in PHP than I (I have used it
> for 5 minutes) explain to me why it is quicker to prototype things in PHP?
---> it isn't.
PHP blows.
[OT] Re: Yahoo is moving to PHP ??
Posted by Richard Clarke <ri...@likewhoa.com>.
List,
You are probably not the best people to ask for an answer which
might advocate PHP,
but.....
Can someone who is more proficient in PHP than I (I have used it
for 5 minutes) explain to me why it is quicker to prototype things in PHP?
I can't understand this statement. Surely this is only
applicable to people who are not proficient with mod_perl & [%
my_templating_engine %]?
Much of the code from PHP based websites which I have read has
seemed to take this prototyping idea too much to heart. It looks more
like an overly
complex prototype than a well working application.
/me doesn't get it.
Re: Yahoo is moving to PHP ??
Posted by Michael Johnson <mi...@firewing.org>.
On Thu, 31 Oct 2002, Gunther Birznieks wrote:
> You would think if they want an anal scripting language they would move
> to python not PHP. :)
Python isn't anal--it's a very clean, interesting, flexible language on
par with perl--perhaps superior in some ways and not as good in others
but, overall, on a similar scale.
In respect to the article, to me, anyway, most of the arguments weren't
particularly compelling from my outside viewpoint. The one point they made
was true--PHP was developed specifically for the web and doesn't have the
wide variability of perl (they seem to equate extensive flexibility, as a
trouble point leading to great variance in the code -- stylistically and
logically). I don't think this problem is neccessarily eliminated
comprehensively by switching to a crappy language like PHP. Some
standardization could be achieved via coding guidelines, approved
practices, code reviews etc. while still retaining the power and
flexibility of a perl. Many of the problems they associated with perl
aren't neccessarily eliminated by using PHP, including the issues with
code variance.
They still stated that perl would fuel many things on the backend, though,
so they haven't gone completely mad.
-mj
> John Saylor wrote:
>
> >Hi
> >
> >( 02.10.30 03:22 -0500 ) Perrin Harkins:
> >
> >
> >>They didn't make their decision on performance though. They seem to
> >>have been most influenced by the idea that perl allows too much
> >>flexibility in coding style, although I can't see how PHP is going to
> >>help with that.
> >>
> >>
> >
> >Wow, I'd like what *they* had for lunch!
> >
> >Quasi-seriously, as someone who has had to maintain mountains of bad
> >perl code, I know TMTOWTDI can have a downside; but the openness of the
> >language is what has lead to its greatness ...
> >
> >
> >
>
[OT] Re: Yahoo is moving to PHP ??
Posted by si...@siberian.org.
If they are going to inherently mangle their php and perl
and lose that abstraction layer I think in 2 years they
will look back and wish TMTOWTDI was their only
problem....
That said, Kudo's to yahoo for being this public about it.
These are the sorts of publically available presentations
that give those of us trying to justify our existence some
teeth.
Walking into a management meeting and saying 'Look, even
yahoo disdains Java and they have 4500+ servers and are
the biggest internet portal and have a lot of geeks
programming and even they admit modperl is awesome and
fast and they are only not using it becuase its TO
powerful' is a potent weapon. Cheesy yes, needed, yes..
John-
On Thu, 31 Oct 2002 00:12:02 +0800
Gunther Birznieks <gu...@eXtropia.com> wrote:
>You would think if they want an anal scripting language
>they would move to python not PHP. :)
>
>John Saylor wrote:
>
>>Hi
>>
>>( 02.10.30 03:22 -0500 ) Perrin Harkins:
>>
>>
>>>They didn't make their decision on performance though.
>>> They seem to have been most influenced by the idea that
>>>perl allows too much flexibility in coding style,
>>>although I can't see how PHP is going to help with that.
>>>
>>>
>>
>>Wow, I'd like what *they* had for lunch!
>>
>>Quasi-seriously, as someone who has had to maintain
>>mountains of bad
>>perl code, I know TMTOWTDI can have a downside; but the
>>openness of the
>>language is what has lead to its greatness ...
>>
>>
>>
Re: [OT] Re: Yahoo is moving to PHP ??
Posted by Perrin Harkins <pe...@elem.com>.
Tom Servo wrote:
>Check out their online map site, they do use Python for that.
>
I'm actually surprised they didn't go with Python, because the people I
know there love it. If their backend data processing ever gets moved
from Perl to something else, it would probably be moved to Python.
- Perrin
[OT] Re: Yahoo is moving to PHP ??
Posted by Tom Servo <to...@cnw.com>.
Check out their online map site, they do use Python for that.
snippet o' URL: http://maps.yahoo.com/py/maps.py?BFCat=.....
You know you're going to have a bad day when you see the sun come up.
Over the curb.
------------
Brian Nilsen
tomservo@cnw.com
On Thu, 31 Oct 2002, Gunther Birznieks wrote:
> You would think if they want an anal scripting language they would move
> to python not PHP. :)
>
> John Saylor wrote:
>
> >Hi
> >
> >( 02.10.30 03:22 -0500 ) Perrin Harkins:
> >
> >
> >>They didn't make their decision on performance though. They seem to
> >>have been most influenced by the idea that perl allows too much
> >>flexibility in coding style, although I can't see how PHP is going to
> >>help with that.
> >>
> >>
> >
> >Wow, I'd like what *they* had for lunch!
> >
> >Quasi-seriously, as someone who has had to maintain mountains of bad
> >perl code, I know TMTOWTDI can have a downside; but the openness of the
> >language is what has lead to its greatness ...
> >
> >
> >
>
Re: Yahoo is moving to PHP ??
Posted by Gunther Birznieks <gu...@eXtropia.com>.
You would think if they want an anal scripting language they would move
to python not PHP. :)
John Saylor wrote:
>Hi
>
>( 02.10.30 03:22 -0500 ) Perrin Harkins:
>
>
>>They didn't make their decision on performance though. They seem to
>>have been most influenced by the idea that perl allows too much
>>flexibility in coding style, although I can't see how PHP is going to
>>help with that.
>>
>>
>
>Wow, I'd like what *they* had for lunch!
>
>Quasi-seriously, as someone who has had to maintain mountains of bad
>perl code, I know TMTOWTDI can have a downside; but the openness of the
>language is what has lead to its greatness ...
>
>
>
Re: Yahoo is moving to PHP ??
Posted by Ask Solem Hoel <as...@startsiden.no>.
On Wed, 2002-10-30 at 17:09, John Saylor wrote:
> Hi
>
> ( 02.10.30 03:22 -0500 ) Perrin Harkins:
> > They didn't make their decision on performance though. They seem to
> > have been most influenced by the idea that perl allows too much
> > flexibility in coding style, although I can't see how PHP is going to
> > help with that.
>
> Wow, I'd like what *they* had for lunch!
>
> Quasi-seriously, as someone who has had to maintain mountains of bad
> perl code, I know TMTOWTDI can have a downside; but the openness of the
> language is what has lead to its greatness ...
>
> --
> .--- ...
Now we're going down to the ugly details of the article :)
As Perrin noted they are probably going to use C/C++ to make the
fundamentals of the application, like the framework the API, interface
whatever, and use PHP as a templating language to iterate over the
datastructures etc.
I've just converted some totally unmaintainable code from PHP to perl
(actually, i've rewritten it because everything was done in the wrong
way (tm)). To write big and advanced applications in pure PHP is a big
mistake IMHO, but to use it as a templating language doesn't sound as
such a bad idea.
Yahoo! is moving to open-source! Yahoo!
--
Ask Solem Hoel [+4722808579 | +4797962181]
ABC Startsiden AS [ http://www.startsiden.no]
RE: Yahoo is moving to PHP ??
Posted by Jesse Erlbaum <je...@erlbaum.net>.
Hi John --
> Quasi-seriously, as someone who has had to maintain mountains of bad
> perl code, I know TMTOWTDI can have a downside; but the openness of the
> language is what has lead to its greatness ...
This doesn't have to be as big a problem as it often is. Having coding
standards makes a big difference no matter WHICH language you use. Have you
ever seen bad Java code? Java has reached parity with Perl in that area,
for sure! This is a problem in ANY language. You just can't "hire smart
people" and send them out there without direction.
At my company we base all our work on CGI::Application and HTML::Template to
solve exactly this problem. CGI-App and HTML-Tmpl (or Template Toolkit --
TT is compatible with C::A) "strongly suggest" a standard way of writing the
uninteresting bits of a web application -- namely, state management and HTML
separation. They go beyond what is provided by simply making a decision to
use a particular API, such as CGI, mod_perl, PHP, Mason, etc.
No software library will factor this problem out entirely. This is really
a human problem -- not a software problem. However, choosing a specific
tactic is a good start.
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
jesse@erlbaum.net
Phone: 212-684-6161
Fax: 212-684-6226
Re: Yahoo is moving to PHP ??
Posted by John Saylor <jo...@worldwinner.com>.
Hi
( 02.10.30 03:22 -0500 ) Perrin Harkins:
> They didn't make their decision on performance though. They seem to
> have been most influenced by the idea that perl allows too much
> flexibility in coding style, although I can't see how PHP is going to
> help with that.
Wow, I'd like what *they* had for lunch!
Quasi-seriously, as someone who has had to maintain mountains of bad
perl code, I know TMTOWTDI can have a downside; but the openness of the
language is what has lead to its greatness ...
--
.--- ...
Re: Yahoo is moving to PHP ??
Posted by Tim Burden <ti...@psnetworks.net>.
I'm sure it is. This has been discussed on this list before: PHP in safe
mode is much more likely to be found on the offerings of virtual hosting
companies, which tend to use control panel things like Plesk, Ensim, or RAQ
boxes. If you do get mod_perl you don't get to play with everything, it
usually just means you get to run stuff in Registry. Therefore most people
will get to play in PHP and do projects for real customers in PHP at an
earlier stage in their careers. And inside of a year you'll have built some
fairly solid applications that work, and you'll be looking for work as a
"website programmer" because it was so easy to satisfy your customer, who
really just wanted to be able to update his real-estate listings without
phoning you twice a week.. Ooops, that's a lot of people right now. Jobs for
PHP guys are fewer and farther between than for Perl guys. Supply/demand
would tend to drive the price for PHP guys down, one would think.
Later of course you'll try to differentiate yourself from the masses, and
try to find out what Perl can do for your career and for your applications.
Sometimes, and this is not me, you'll find that you NEED to look at some
speed enhancement because your stupid website actually became popular.
Tweaking PHP, refining your queries, adding hardware, and doing stuff like
output caching would probably last you an awful long time before you had to
switch languages.
> I also wonder if it's cheaper/easier to hire and train PHP programmers
that
> Perl programmers.
>
>
> --
> Bill Moseley
> mailto:moseley@hank.org
Re: Yahoo is moving to PHP ??
Posted by Bill Moseley <mo...@hank.org>.
At 02:50 PM 10/30/02 -0500, Perrin Harkins wrote:
>Mithun Bhattacharya wrote:
>
>>No it is not being removed but this could have been a very big thing
>>for mod_perl. Can someone find out more details as to why PHP was
>>preferred over mod_perl it cant be just on a whim.
>>
>
>Think about what they are using it for. Yahoo is the most extreme
>example of a performance-driven situation.
I also wonder if it's cheaper/easier to hire and train PHP programmers that
Perl programmers.
--
Bill Moseley
mailto:moseley@hank.org
Re: Novice - How would I add a hidden form field to a LWP::UserAgent call?
Posted by Robert Landrum <rl...@aol.net>.
On Thu, Oct 31, 2002 at 10:28:32AM -0500, Chris Pizzo wrote:
> Hi,
> I'm trying to post data to a server that requires a hidden form field.
>
> This is what I'm doing:
> my $content = "info=somedata";
> my $rec_len = length($content);
> my $send_url = new URI::URL($url);
> my $hdrsend = new HTTP::Headers('Content-length' => $rec_len);
> $hdrsend->header('Content-type' => 'text/html');
>
> my $reqest = new HTTP::Request('POST', $send_url, $hdrs, $content);
> my $uasend = new LWP::UserAgent;
>
> my $resp = $uasend-> request($reqest);
>
I always just did
$req = new HTTP::Request('POST',"http://foo.bar.com/path/");
$req->content("info=somedata");
$ua = new LWP::UserAgent;
$res = $ua->request($req);
print $res->as_string;
Good luck,
Rob
>
> The response I get back is:
> <h3>Exception encountered.</h3><pre>Form post has no value for key "info".
> Form values are: {}
>
> If I create an HTML doc with a form it finds the data. Is there something
> special I need to do to get a hidden form field?
>
> Thanks,
> Chris
>
>
--
Robert Landrum
Systems Programmer
Novice - How would I add a hidden form field to a LWP::UserAgent call?
Posted by Chris Pizzo <ch...@artinside.com>.
Hi,
I'm trying to post data to a server that requires a hidden form field.
This is what I'm doing:
my $content = "info=somedata";
my $rec_len = length($content);
my $send_url = new URI::URL($url);
my $hdrsend = new HTTP::Headers('Content-length' => $rec_len);
$hdrsend->header('Content-type' => 'text/html');
my $reqest = new HTTP::Request('POST', $send_url, $hdrs, $content);
my $uasend = new LWP::UserAgent;
my $resp = $uasend-> request($reqest);
The response I get back is:
<h3>Exception encountered.</h3><pre>Form post has no value for key "info".
Form values are: {}
If I create an HTML doc with a form it finds the data. Is there something
special I need to do to get a hidden form field?
Thanks,
Chris
Re: Yahoo is moving to PHP ??
Posted by Cristóvão Dalla Costa <cb...@bsi.com.br>.
Perrin Harkins wrote:
>
> Have you written C extensions for both Perl and PHP and think Perl is
> easier?
Most certainly, using SWIG. I didn't have to recompile Perl two or three
times, or read Perl's source to figure out what to do. The PHP docs on
the subject were misleading and innacurate and wrong. That was about a
year ago, I do hope things have improved.
Re: Yahoo is moving to PHP ??
Posted by Vivek Khera <kh...@kcilink.com>.
>>>>> "PH" == Perrin Harkins <pe...@elem.com> writes:
PH> Sure. That's why Vignette used TCL: adding your own C commands to the
PH> language is easy. Probably the same story for AOLServer.
Considering that the whole purpose for TCL was to embed it into C
progams, one would hope that it would be easy...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Yahoo is moving to PHP ??
Posted by Perrin Harkins <pe...@elem.com>.
Iain 'Spoon' Truskett wrote:
>>In general, it makes sense that a simple language would be simple to
>>extend with C. That's why people like TCL.
>>
>>
>
>They do? =)
>
Sure. That's why Vignette used TCL: adding your own C commands to the
language is easy. Probably the same story for AOLServer.
- Perrin
Re: Yahoo is moving to PHP ??
Posted by Iain 'Spoon' Truskett <ia...@dellah.org>.
* Perrin Harkins (perrin@elem.com) [31 Oct 2002 14:26]:
[...]
> Have you written C extensions for both Perl and PHP and think Perl is
> easier?
I've only written XS for Perl. Not touched PHP with any C stuff. While I
must admit that my early XS was crap, that's mostly my fault.
Last time I looked at PHP, a while ago I admit, to extend it with C you
had to recompile the lot. Has that changed?
> Most people complain about XS being challenging.
XS isn't that challenging if you read the documentation. In particular,
that shiny new Jenness and Cozens book "Extending and Embedding Perl".
> The picture might be different when SWIG and Inline::C are taken into
> account, but I've never used them so I couldn't say.
I find it's useful to know XS to use Inline::C. SWIG, since it's not
Perl oriented, is possibly easiest. I'm not sure since I've not used it
to any extent.
> In general, it makes sense that a simple language would be simple to
> extend with C. That's why people like TCL.
They do? =)
cheers,
--
Iain.
Re: Yahoo is moving to PHP ??
Posted by Perrin Harkins <pe...@elem.com>.
Cristóvão Dalla Costa wrote:
> Perrin Harkins wrote:
>
>> They also have more of a
>> need than most people to integrate with C/C++, and I've been told that
>> it's easier to hack those into PHP.
>
>
> What a joke.
Have you written C extensions for both Perl and PHP and think Perl is
easier? Most people complain about XS being challenging. The picture
might be different when SWIG and Inline::C are taken into account, but
I've never used them so I couldn't say. In general, it makes sense that
a simple language would be simple to extend with C. That's why people
like TCL.
- Perrin
Re: Yahoo is moving to PHP ??
Posted by Cristóvão Dalla Costa <cb...@bsi.com.br>.
Perrin Harkins wrote:
> They also have more of a
> need than most people to integrate with C/C++, and I've been told that
> it's easier to hack those into PHP.
What a joke.
Re: [O] Re: Yahoo is moving to PHP ??
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Mike" == Mike Miller <mm...@crusoe.net> 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
<me...@stonehenge.com> <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: [OT]: In my Farthers House there are many mansions
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Tony" == Tony Bowden <to...@kasei.com> writes:
Tony> We're drifting further and further off topic here, but the trick to the
Tony> Schwartzian Transform is the caching, not the maps. The maps are just a
Tony> convenient construct that allows the whole thing to be written in one
Tony> command, without lots of temporary variables.
Exactly. You're caching the complex sort-function so that it
doesn't need to be recomputed for the various pairings, leading
to either a slowdown or phase errors.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <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: [OT]: In my Farthers House there are many mansions
Posted by Tony Bowden <to...@kasei.com>.
On Sun, Nov 03, 2002 at 11:48:55AM -0600, Steven Lembark wrote:
> >I'm not sure anyone has actually posited using map for performance, but
> >in most cases that would indeed be a pretty stupid reason to use it.
> See the Schwartzian Transform for an excellent example of
> where you would use map for performance.
We're drifting further and further off topic here, but the trick to the
Schwartzian Transform is the caching, not the maps. The maps are just a
convenient construct that allows the whole thing to be written in one
command, without lots of temporary variables.
In terms of speed, the difference between
my @sorted =
map { $_->[0] }
sort { $a->[1] <=> $b->[1] }
map { [$_, -M $_] } @files;
and
my @cache; push @cache, [$_, -M $_] foreach @files;
my @sorted_cache = sort { $a->[1] <=> $b->[1] } @cache;
my @sorted; push @sorted, $_->[0] foreach @sorted_cache;
is quite neglible compared with the speed difference of doing
my @sorted = sort { -M $a <=> -M $b } @files
especially as the cost of the operation (-M in this case) increases.
Tony
Re: [OT]: In my Farthers House there are many mansions
Posted by Steven Lembark <le...@wrkhors.com>.
-- Tony Bowden <to...@kasei.com>
> On Sat, Nov 02, 2002 at 12:13:19PM -0000, Jeff 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.
>
>> Have to agree 100% with Perrin - in my experience, refactoring for
>> performance is often used as an excuse for 'rewrite in my style',
>
> I'm not sure anyone has actually posited using map for performance, but
> in most cases that would indeed be a pretty stupid reason to use it.
See the Schwartzian Transform for an excellent example of
where you would use map for performance. Main advantage is
getting perl to manage the list space. If I find myself
writing for(blah){ push @foo, something } it can usually be
done more simply via @foo = map { something } ( blah ). If
you end up making large lists, especially in loops, then map
can be a speedup. It is also faster if you have to flatten
out strucures frequently (vs iterating over keys %foo and
assigning things one at a time).
map can also be convienent in allowing for lexicals that
are assigned when they are built, similarly grep:
if( my @process_this = grep {-s > $cutoff} @filz )
{
deal with @process_this here, know it won't
outlive the braces.
}
Defining the lexicals in a scope where the don't outlive
their purose can be a big help in maintainability.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
Re: [OT]: In my Farthers House there are many mansions
Posted by Tony Bowden <to...@kasei.com>.
On Sat, Nov 02, 2002 at 12:13:19PM -0000, Jeff 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.
> Have to agree 100% with Perrin - in my experience, refactoring for
> performance is often used as an excuse for 'rewrite in my style',
I'm not sure anyone has actually posited using map for performance, but
in most cases that would indeed be a pretty stupid reason to use it.
> and at this point, future maintainability is usually severly
> compromised. Someone decides to replace all foreach loops with map,
> because this is more advanced and kewl.
Automatically replacing all 'foreach' loops with maps would also be
pretty stupid. They're different thing, used for different purposes.
But using a foreach when you should be using a map is no better.
When someone misuses something, the wrong approach is to no longer use
it.
The correct approach is to educate people on the correct use.
Tony
Re: [O] Re: Yahoo is moving to PHP ??
Posted by John Saylor <jo...@worldwinner.com>.
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
#perl@irc.openprojects.net 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 ??
Posted by Rob Nagler <na...@bivio.biz>.
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 ??
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Perrin" == Perrin Harkins <pe...@elem.com> 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
<me...@stonehenge.com> <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 ??
Posted by Perrin Harkins <pe...@elem.com>.
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 ??
Posted by Tony Bowden <to...@kasei.com>.
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: [OT]: In my Farthers House there are many mansions
Posted by Les Mikesell <le...@attbi.com>.
From: "Jeff" <ja...@aquabolt.com>
> Another time, a contractor working for me complained bitterly about
> someone elses obtuse code and lack of comments - the other party
> said 'Why don't you scroll up?', which he did - lo and behold, about
> two pages of beautiful comment. Mmmm as he read the comments, from
> the top, the complainant highlighted each line [easier to read] and
> when he understood the point of it all, pressed Enter - not
> realising that this replaced two screens of comment with an empty
> line... ah ha! we finally figured out the answer to the song:
> 'Where have all the comments gone?'
Good story - and a good tie-in to the other off-topic thread about
whether on not it is worth the trouble to use CVS. If you make sure
that the only way to get between your workspaces and the test/production
servers is a commit/update step, cvsweb can always provide a color-coded
answer to questions like that.
---
Les Mikesell
lesmikesell@attbi.com
RE: [OT]: In my Farthers House there are many mansions
Posted by Jeff <ja...@aquabolt.com>.
> -----Original Message-----
> From: Perrin Harkins [mailto:perrin@elem.com]
> Sent: 01 November 2002 18:43
> To: Tony Bowden
> Cc: modperl@perl.apache.org
> Subject: 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.
>
snip...
> - Perrin
>
>
Have to agree 100% with Perrin - in my experience, refactoring for
performance is often used as an excuse for 'rewrite in my style',
and at this point, future maintainability is usually severly
compromised. Someone decides to replace all foreach loops with map,
because this is more advanced and kewl.
Does anyone else here remember the COBOL construct ALTER GOTO? I knew
a chap who styled himself 'Super Hot Software Systems', whose favourite
thing was ALTER GOTO - mmmm he soon got told where to go to! Look it
up - it's a nightmare.
Another time, a contractor working for me complained bitterly about
someone elses obtuse code and lack of comments - the other party
said 'Why don't you scroll up?', which he did - lo and behold, about
two pages of beautiful comment. Mmmm as he read the comments, from
the top, the complainant highlighted each line [easier to read] and
when he understood the point of it all, pressed Enter - not
realising that this replaced two screens of comment with an empty
line... ah ha! we finally figured out the answer to the song:
'Where have all the comments gone?'
8-)
Re: [O] Re: Yahoo is moving to PHP ??
Posted by Perrin Harkins <pe...@elem.com>.
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 ??
Posted by Tony Bowden <to...@kasei.com>.
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 h@x0r 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 ??
Posted by Perrin Harkins <pe...@elem.com>.
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 h@x0r 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 ??
Posted by Ask Bjoern Hansen <as...@develooper.com>.
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();
Re: [O] Re: Yahoo is moving to PHP ??
Posted by Franck PORCHER <fp...@esoft.pf>.
On Thu, 31 Oct 2002, Mike Miller wrote:
> On Wed, 30 Oct 2002 20:28:11 +0000 (GMT)
> Franck PORCHER <fp...@esoft.pf> 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 ??
Posted by Mike Miller <mm...@crusoe.net>.
On Wed, 30 Oct 2002 20:28:11 +0000 (GMT)
Franck PORCHER <fp...@esoft.pf> 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?
--M.
Re: Yahoo is moving to PHP ??
Posted by Franck PORCHER <fp...@esoft.pf>.
On Wed, 30 Oct 2002, Rob Nagler wrote:
> Tagore Smith writes:
> > 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).
>
> This raises the $64 question: If you could hire 10 PHP programmers at
> $50/hour or 4 Perl programmers at $125/hour, which team would deliver
> more business value over the life of the site?
>
> > 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.
>
> His On Lisp book is a classic on macros--which are similar to closures
> in Perl. You can download it for free: http://www.paulgraham.com/onlisp.html
>
> My guess is that Graham's answer to the above question would be:
> Hire two Lisp programmers at $250/hour. :-)
>
Or better, 1 CLP(CT) programmer at $500/hour...
Franck
====================================================
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: Yahoo is moving to PHP ??
Posted by Rob Nagler <na...@bivio.biz>.
Tagore Smith writes:
> 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).
This raises the $64 question: If you could hire 10 PHP programmers at
$50/hour or 4 Perl programmers at $125/hour, which team would deliver
more business value over the life of the site?
> 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.
His On Lisp book is a classic on macros--which are similar to closures
in Perl. You can download it for free: http://www.paulgraham.com/onlisp.html
My guess is that Graham's answer to the above question would be:
Hire two Lisp programmers at $250/hour. :-)
Rob
[O] Re: Yahoo is moving to PHP ??
Posted by Franck PORCHER <fp...@esoft.pf>.
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"
====================================================
Re: Yahoo is moving to PHP ??
Posted by Tagore Smith <ta...@tagoresmith.com>.
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
Re: Yahoo is moving to PHP ??
Posted by Rob Nagler <na...@bivio.biz>.
Perrin Harkins writes:
> The real application stuff is built in other languages. (At least
> this is the impression I get from the paper and from talking to
> people there.)
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.
Rob
Re: Yahoo is moving to PHP ??
Posted by Perrin Harkins <pe...@elem.com>.
Mithun Bhattacharya wrote:
>No it is not being removed but this could have been a very big thing
>for mod_perl. Can someone find out more details as to why PHP was
>preferred over mod_perl it cant be just on a whim.
>
Think about what they are using it for. Yahoo is the most extreme
example of a performance-driven situation. They have so much volume
that they are willing to write things in C++ just to get the speed that
is required. They pre-process and cache things as much as they possibly
can. The server-side scripting language they use is basically a
glorified include processor. They pull in pre-built include files and
read things out of dbms with it. That's all. The real application
stuff is built in other languages. (At least this is the impression I
get from the paper and from talking to people there.)
Given that, PHP is a reasonable fit. It's fast, has a less flexible
syntax, and uses less memory than mod_perl. They also have more of a
need than most people to integrate with C/C++, and I've been told that
it's easier to hack those into PHP.
Think about the implications of the memory graph. If they can run 5
more apache children at once on PHP because of its lower memory
consumption, 5 * 4500 = 22500 more users they can handle at any given
moment!
>Also how does one go about justifying the fact that Ioncube cache is
>doing a better cacheing than any mod_perl based solution ??
>
Sorry, I read that wrong. It was actually mod_perl that had the best
performance. The cache they use works just the same as Perl's normal
operation, i.e. once some code is compiled it stays in memory and
doesn't need to be compiled again. You don't have to do anything to get
that in Perl.
- Perrin
RE: Yahoo is moving to PHP ??
Posted by Jeff AA <ja...@aquabolt.com>.
> -----Original Message-----
> From: Mithun Bhattacharya [mailto:inzoik@yahoo.com]
> Sent: 30 October 2002 09:17
> To: modperl@perl.apache.org
> Subject: Re: Yahoo is moving to PHP ??
>
>
> No it is not being removed but this could have been a very big thing
> for mod_perl. Can someone find out more details as to why PHP was
> preferred over mod_perl it cant be just on a whim. I might be biased
> but considering the fact that PHP and mod_perl were neck to neck the
> cons should have made up for any slipup in performance.
err did you look at the same slides as me?
in all performance tests, YSP(perl) performed better than PHP, with
the exception of memory usage.
and there is a slide explaining why not Perl - the main objection
seemed to be:
<QUOTE>
"There's More Than One Way To Do It
so many different Perl styles
everyone's code looks different
problematic for development when many people working on
single codebase"
</QUOTE>
While there were Pros/Cons for Perl and the other rejectees, there were
no Pros/Cons for PHP unless you count the gotchas mentioned after four
months of using PHP:
<QUOTE>
Shallow learning curve
- very easy to get some pages up quickly
But mixed app/presentation problematic
- PHP code and HTML forever intertwined
- coding conventions help
*.inc for function and class libraries
*.php for web pages (call functions, echo $vars)
- use Smarty to enforce separation?
"The drawback of using a code in template system, is that your code and
HTML output quickly become forever intertwined. This makes changing the
appearance of your pages difficult. For example, if you check the user
cookie and load user database data in the "common-header" moving around
where you include this template will change where you retrieve the
database information for the user, possibly breaking other parts of the
page which rely on that data. "
http://www.clearsilver.net/docs/apples_to_oranges.hdf
The "implement twice" problem
- much offline processing done in Perl
- example: tax/shipping calculation for Shopping
PEAR != CPAN
- installer doesn't work in PHP 4.2.x
- repository smaller, less mature than CPAN
Surprises for people used to coding Perl
</QUOTE>
Interestingly our experience was/is similar - we chose PHP 2.5 years ago
for the development of our dynamic ASP interactive pages, and Perl for
all our data-processing and server management etc. Hindsight shows us
that it was the right decision at the time - we gained an 18 month lead
on the competition.
After 2.5 years, the 'have to write everything twice' problem has lead
us to plan a gradual migration from PHP to Perl. All our new pages and
products are being developed in mod_perl. I wonder if they will consider
a similar change? Unlikely give the number of developers and the
disruption?
There is one con for PHP that I disagree with - you don't have to mix
your HTML and application logic - just as in Perl, you can separate them
if you want to - we work extensively in PHP ordered hashes and isolate
the formatting and HTML generation in a few included utility
collections, making it easy to change the HTML we generate without
changing any of the underlying business information.
Regards
Jeff
Re: Yahoo is moving to PHP ??
Posted by Mithun Bhattacharya <in...@yahoo.com>.
--- Perrin Harkins <pe...@elem.com> wrote:
> Mithun Bhattacharya wrote:
>
> >http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm
> They also say they plan to continue using lots of perl in all the
> places
> they use it now: off-line processing, filling in the includes and dbm
>
> files that the server-side script assembles. Perl is not being
> removed.
No it is not being removed but this could have been a very big thing
for mod_perl. Can someone find out more details as to why PHP was
preferred over mod_perl it cant be just on a whim. I might be biased
but considering the fact that PHP and mod_perl were neck to neck the
cons should have made up for any slipup in performance.
Also how does one go about justifying the fact that Ioncube cache is
doing a better cacheing than any mod_perl based solution ??
I am assuming when Yahoo did their research they optimized everything
to the maximum possible they werent out to do a marketting propaganda
now were they ....
Mithun
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: Yahoo is moving to PHP ??
Posted by Perrin Harkins <pe...@elem.com>.
Mithun Bhattacharya wrote:
>http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm
>
>If nothing else this should be atleast generate some thoughts ??
>
It does: hooray! Yahoo is moving from a proprietary server-side
scripting tool to an open source one. Great news for all of us, since
they will help legitimize open source ("the largest site in the world
runs on it") and maybe feed good ideas back to the open source world.
(Of course Yahoo has used other open source tools forever.)
If you look at the performance graphs they made, mod_perl comes in neck
and neck with PHP. We always see mod_perl go faster than PHP in
Joshua's tests, but Yahoo was testing with this Ioncube cache that keeps
PHP code in memory (like mod_perl). The performance tests were so close
that a little optimization on the mod_perl side might actually turn it
around.
They didn't make their decision on performance though. They seem to
have been most influenced by the idea that perl allows too much
flexibility in coding style, although I can't see how PHP is going to
help with that.
They also say they plan to continue using lots of perl in all the places
they use it now: off-line processing, filling in the includes and dbm
files that the server-side script assembles. Perl is not being removed.
- Perrin