Octavian Râşniţă wrote:
*From:* David Ihnen <mailto:dav...@norchemlab.com>
> I tried to convince some programmers that Perl is better than
PHP, but without any success.
> How could they know, if they have never used it? I was far less
convinced that PHP was a blight on the face of scripting science
until I got a
> job working in it, after all.
They know it because everybody tell them so. Most web sites are done
in PHP, most job offer for web programmers ask for PHP experience...
Then they don't know, they just repeat what others say. So I guess all
we can do is repeat what we know from experience, and hope that others
repeat it too...?
> Pay them to do it in perl, and after they get through the
learning curve they'll probably be much happier with it.
I can't tell that in my country there are no software companies
specialized in perl programming because I don't know all the software
companies, but if there are some, they could be counted on fingers,
and they aren't probably very big.
So who should pay those PHP programmers in order to motivate them?
Somebody who wants a program, and is smart enough to know that the
engineers are better choosers of the software language than they are.
Any consultant, firm, company, consultant, or contractor can pay, and
spend his time, to learn perl. They simply have to make the decision to
do so. Perhaps you could do so.
Can perl programs run on share hosting web sites? There are some
such hosting companies that don't even offer perl support, and
those who offer it, offer just the standard Perl distribution,
which don't offer a web framework, or templating systems, or
ORMS, or form processors, and in these conditions I can't tell
that perl is so great.
Isn't that to the denigration of the hosting company? Not
supporting the framework is no way to support your user base. As
long as the dollar is more important than the feature, there's not
much we can do about this. These are not things that should be
built into the core distribution of a language, its the main
reason PHP is so awful.
I agree that those things shouldn't be built in the core distribution,
but there could be more distributions, like the one offered by
ActiveState, or Strawberry Perl or others, just as the Zend PHP
distribution contains the Zend Framework.
It could be helpful to have a perl distribution that includes the
latest versions of Template-Toolkit, HTML::Template, Mason, Catalyst,
CGI::Application, DBIx::Class, Moose, HTML::FormFu and other helpful
cpan modules.
A hosting company may want to install that distribution, and it would
really offer a much better support than the one offered by PHP.
Yes, those modules won't be updated frequently, but it would be much
better than simply a CGI.pm support.
Now you're talking about something that just about anybody (even you)
could do if they put their mind to it, don't you think? Its just
creating a distribution, after all. Its just not a very perlish thing
to do to limit. Maybe it would be cool if you could have an interface
that lets you request and install the latest CPAN module on the shared
servers without having root or shell. It might be even better, not
limiting anything.
> Can they hide the source code? (Because who knows who can get it
from those free hosting web sites)
> Who cares? Hiding source code is valueless.
Maybe in your country. In my country 10 euro means too much and
actually even 1 euro means too much if the same thing can be got for
free, legally or not.
You taking it and using it doesn't impact anything, and the companies
have to understand that. Its just some ideas and organization,
pretending you can keep other people from knowing how you did something
just makes it less supportable by anybody - good software can be bad
software just because its obfuscated like that. Those who matter will
actually pay for your software because they want the support and
customization that comes with it. If they're not going to pay up front,
they're more likely to pay later - keeping them from using the software
at all won't help. So why obfuscate or worry about it?
> I found that they can hide it, but only after installing Open
SSL and a perl module, which they can't do, because those sites
don't offer > root access and neither shell access.
> You get what you pay for I guess.
Well, they can get a free support offered for Zend Optimizer (or how
it is called the Zend Decoder).
Free support as in open-source community stuff? Or as in a commercial
company spending their time to help you with something that they don't
get paid for?
In order to show them how good is perl, I told them that they
would need to have a dedicated server, or a VPS, but the cheapest
VPS costs much more than a shared hosting solution, so in this
case perl has another disadvantage.
If they care that much about a few $ on a monthly fee for their
web site, they're not going to pay enough to get a skilled
programmer in ANY language, to do the programming.
Of course they care. If the same thing can be done cheaper using PHP,
they will surely choose PHP.
(The quality doesn't matter, because here the things are so fast
changing, and the easiness of maintenance doesn't matter for most,
because who knows what will happen after a few years.
Experience says in a few years, you'll want to augment and enhance your
application. But they don't have the experience, eh? Well, if they
want throw-away programs they'll get throw-away programs. And have to
pay for them over and over again. The savings are false. The companies
who chose wisely will get further. But that is a subtle pressure in the
market - perhaps even less so than the idea being implemented - thus
making our advocacy more or less moot. A working program is all that
matters to an end user, not a good or badly engineered program. How can
we convince them that the underlying engineering is important? Short of
organized crime techniques at least. >:)
> They've also told me that they know that perl is harder to
learn than PHP.
> What can I tell them? That it is not true?
> Yes, but you may or may not be right. We all agree that coming
into perl is confusing - too much old data about how to do
> things is out there in the world. That makes it harder to
learn - not because the language is harder to learn - but because
its not clear what the proper way to learn it is.
I've seen that the newbies always want recommendations, and think that
there should be a recommended way of doing things, a best way.
Do you think there is a way to stop them from thinking that?
Well, there is no such thing for perl. Perl is not a language, but it
is more languages.
If a programmer uses Catalyst and DBIx::Class and HTML::FormFu there
is a language, if he uses CGI::Application and Rose::DB::Object it is
another language, if he uses CGI.pm is another one, and there may
appear other differences if they use mod_perl or fastcgi or just CGI,
or if they use classic OOP or Moose, Template-Toolkit or Mason.
It is not bad that we can choose, but the beginners don't know what to
choose, and finally they would find all these confusing and start
using RoaR or PHP.
Which is a state but not a solution. Are we supposed to agree on a
'best in class solution pattern' and advertise/promote it on sites like
perl.org as a way to counteract the 'too many options' indecisive nature
of humanity?
> Of course that I could have told them that for real good big
projects, perl is easier to use than PHP, but most of the PHP
users don't
> care about that kind of projects. They care about simple
projects created from scratch, that don't even use a web
framework or an
> ORM or a form processor.
> Sounds like the people who buy expensive fixed-lense cameras,
then the moment they get interested in photography discover that
they could
> have bought an SLR, more capable and flexible, for the same
price. But they swore they didn't need the capability to do that
when they >
> bought the original cameras, so now they're screwed.
Not exactly, because most of the PHP programmers don't work for
themselves, but for other clients
Now you're getting down the fundamental risk levels. The bad programmer
is a risk to his employer, not to himself. This is a very interesting
pattern in our economy.
, and yes, they would find that they are scrued if they would need to
update a program, but the really scrued is the client, because the
programmers will ask more money for upgrading that software, because
they would need more programmers to do it.
So its not the programmer in the end that made the bad decision, its the
client? Yet, the client trusted the programmer to choose a technology.
There's something afoul here. There can be no evolution to better
programmers because the badness of the programmer has almost no effect
on the decision.
The good news is that some software companies started to see that this
is a problem and don't consider PHP a great idea anymore.
Thank Dog. Now to get that pattern more widespread. Ideas?
The bad news is that those software companies start to use more and
more DotNet and Java, and don't even think to Perl, because they know
that perl is harder to maintain, that perl is write-only and other
things like these.
But they don't even really know. Do they know they don't know?
Yes, Perl 4 style of programming, or using CGI.pm might create code
which is harder to maintain, but there isn't a big software company
that promotes perl and tell them that this is not true anymore.
By this I assume you mean that you have to be 'big' in order to have any
credibility in choosing your technology?
David
