Perl e-commerce?

Nicholas Clark nick at
Wed Sep 14 20:42:54 BST 2011

On Wed, Sep 14, 2011 at 08:14:03PM +0100, Simon Wilcox wrote:
> On 14/09/2011 19:47, Andrew Suffield wrote:
> >PHP is a thorough and effective solution to the following problem,
> >which is also its main design goal:
> >
> >How can stupid people create poor-quality web sites cheaply?
> >
> >Turns out this is in high demand, due to the large quantity of both
> >those things in the world.
> I refer the honourable gentleman to Matt's Script Archive. It's easy to 
> write crappy code in any language.
> You do Perl a disservice with such mindless and ill-considered attacks.
> PHP solved the problem of making web-based applications easy to install. 
> Something that all the 'big brains' of Perl still haven't solved. Ease 
> of installation leads to ease of adoption. Hence why PHP has hammered 
> Perl into the ground for web apps.

These three I agree with completely.

> These days it is just as possible to write a secure PHP application as 
> it is to write an insecure Perl one.

Agree. Mediawiki is a good example of this.

But I'm not convinced that core PHP developers are competent at release
engineering. [recent example is crypt, but there was an earlier case
where they changed the behaviour of arrays. Citation fail on my part]

I'm not convinced that their language design is sane
[specifically, adding 'goto' to a language that worked without it,
in particular when changing break to take a label rather than an integer
would have addressed most of the problem space in a structured way]

I'm not convinced that using \ as a package separator is sane.
Double quoted strings, hello? Haven't Windows pathnames taught you anything?

I'm pretty sure that decent code review would have flagged
"Paamayim Nekudotayim" as something that doesn't fit in a programming
language otherwise documented, for better or worse, in English.

I remain unconvinced that date_sunrise() and date_sunset() belong in the
global namespace of functions.

I'm not sure that being "case insensitive" is a great idea, but doing it
based on locale isn't, when it's the same locale as userspace uses.
(Remember, in Turkish the uppercase of 'i' is not 'I', and vice versa.
But third party code was relying on that? Oh dear...)

And the most risky of all the things I'm typing - many of the bugs in the
"month of PHP bugs" were core interpreter bugs. Most other dynamic
languages [at that time] failed to have that many unresolved structural
security bugs in their core interpreters.

But yes, agree totally, as far as mass-market web apps go, they are wiping
the floor with everyone.

Nicholas Clark

More information about the mailing list