brian_d_foy writes "A long time ago Don Marti started the OS Sucks-Rules-O-Meter, and Jon Orwant wrote his own Sucks-Rules-O-Meter for computer languages. Recently Dan Brian improved on that with a little bit of natural language processing. Now The Perl Review makes pretty pictures of it all. Based on searches of AltaVista and Google, we found that not a lot of people think PHP or Lisp sucks, a lot think C++ and Java suck, and they put Perl is somewhere in the middle. Does Perl suck more than it use to suck, or has PHP just shot way ahead?"
Re:Ignorance is bliss
brian_d_foy on 2002-09-18T16:20:34
We shouldn't discount or try to explain away what people think. My guess is that PHP doesn't suck for a lot of people, which is why a lot of people (relatively) do not say that it sucks.
If we find out why, rather than treating the datum as an outlier, we can apply what we find to Perl.
For instance, several different people have told me that the PHP core documentation is organized better and available in other languages.
A lot of other people have also told me that the PHP documentation is more pragmatic, with lots of practical examples (unlike the perlfaq with lots of cute but not very useful examples).Re:Domain specific language
jjohn on 2002-09-18T17:05:40
Perhaps Perl needs better CGI specific documentation. Perl, being a general purpose language, has a broad range of problems it can be used for. PHP, baring the mutant server-side version, is a CGI-only language. It is a lot easier to write documentation for PHP that tells users how to process CGI args, maintain session state, read client environment variables than to do the same for Perl, for which there are a great many ways to do it (and more are invented everyday). There are reams of paper dedicated to Perl/CGI. O'Reilly even has some of those books online for free.
Perl shouldn't be further adapted to the needs of CGI users, since there are plenty of high quality extensions already in place (Mason, Template Toolkit, etc) to do just that. Perhaps if a Linux distro shipped with Mason or TT or ePerl all setup, as RedHat does with PHP, then the barrier to entry becomes lower for the webheads.
PHP is easier to learn but harder to extend. I would argue that it doesn't do much to make its users better programmers either (but that wasn't the goal of PHP [and yes, Perl has indeed made me a much better programmer]).
Saying "Perl is harder than PHP for web programmers" reminds me of the old joke:
"Doctor, it hurts when I bend my elbow like this."
"Ah well, don't do that."Documentation proposal
jdavidb on 2002-09-18T17:34:28
What happens when you type
perldoc perlcgi? Nothing. My point exactly.Maybe someone should write a manpage-length introduction to programming CGI with Perl and Apache that could be included in the core distribution. It could show the "right" way to do things (taint, strict, and CGI.pm) without having to comprehensively cover all of the alternatives. It could show how to accomplish common tasks. It wouldn't have to follow the usual maxim of, "That's a CGI issue, not a Perl issue, so it doesn't belong here."
Re:Documentation proposal
swiftone on 2002-09-18T17:58:48
"it could show the "right" way to do things (taint, strict, and CGI.pm) "
Maybe, but there are a lot of arguments even at that level. Do you use CGI to write your HTML? I, and a lot of others, consider that a bad practice, mixing code with HTML. Others, including a number of very talented programmers, feel differently.
So how do you document even a hello world cgi script? Do you teach them with CGI's commands, heredocs, outside files, or perhaps one of the many templating systems?
Sure, it's just a simple demo, but you're trying to encourage good behavior, and while we can agree on some bad behaviors (see your list), there are others that arise immediately that are still debated.
TIMTOWTDI, and while that's a great thing, the different philosophies behind them make even a simple script a heavy debate.
Of course, a document showing the major DIFFERENT ways to address, say, a "hello world", a form->email script, and a database search, would be awesome, it'd be quite a task to take on, and require some very skilled writing to keep clean.
Hmm. Perhapsperlcgicould just offer "DO NOT" list, plus mention the benefits/drawbacks to the different instruction sets, followed by a list of more detailed docs foreach one alaperldoc perl?
Re:Documentation proposal
knowmad on 2002-09-19T14:12:52
The nms project at SourceForge is doing a good job of creating some quality examples of common CGI applications. Perhaps the perldocs should reference that collection of software.Re:Documentation proposal
mshiltonj on 2002-09-18T19:28:39
What happens when you type perldoc perlcgi? Nothing. My point exactly.
try perldoc CGI::Application:)
Re:Documentation proposal
kennyg on 2002-09-18T19:45:42
or try perldoc -q cgi
I'm not sure if you saw this posted to the advocacy list, but, the newly formed Perl Documentation Project is looking for contributors.;) Re:Documentation proposal
jdavidb on 2002-09-24T16:30:54
I tried this, and got How can I generate simple menus without using CGI or Tk?.
Re:Ignorance is bliss
gabbleratchet on 2002-09-18T20:03:00
I am not a fan of PHP.
But one of its advantages (and source of its success) is that it is a relatively hassle-free Apache module.
Compared to mod_perl, it is:
* easy to compile
* easy to maintain
* hassle-free for ISPs
Part of PHP's simplicity is down to the language itself - for instance it's harder to slowly leak memory over time via unbroken circular references. But part of its simplicity is due to the fact that PHP is not so tightly integrated into Apache - it only handles the content phase of the Apache request cycle.
The other day I was wondering if a "mod_perl_lite" module would be possible - something that behaved much like PHP but used Perl for its language. How much of Perl's functionality would have to be sacrificed?
How would the template or embedded code side of it look?
And, ultimately is it worth all the trouble fighting to regain (some of) PHP's niche?
Michael
Re:Ignorance is bliss
chicks on 2002-09-19T11:54:37
And, ultimately is it worth all the trouble fighting to regain (some of) PHP's niche?Yes, for several very good reasons.
So we end up with a sitation where a vast amount of effort is being expended by people with too little information creating applications that fall apart under their own weight. I'm not going to pretend we don't have a lot of clueless perl out there too (there are far worse things than Matt's scripts even), but the perl that is out there tends to be written by people with enough software engineering experience to do things with a view of the future and a realistic expectation that others will come behind us and try to maintain it.
- PHP is just a watered down version of perl in the author's own words. From a language standpoint it's clearly a nasty failure. We don't want people to learn technology this bad. It tends to create bad habits...
- The previous point tends to lead to the fact that the vast majority of PHP code out there is just awful and nasty. The PHP community has done a much better job of putting full applications up for people to try than the Perl community has, but if you want to extend any of it or switch it from PostgreSQL to MySQL, good luck. The code and database design of most of these PHP projects is awful. This is made worse by the way database access and other things are done. The PHP community just doesn't value rightness very much, but the Perl community needs to show more results. PHPers think little at all, but Perlers seem to contemplate to the point of not doing anything. I expect whatever balance is to be found will land in the Perl community.
- PHP isn't hassle free! It's blatant disability at being extended without being recompiled hardly makes it hassle free. Any significant project I've ever seen in PHP has required that PHP be recompiled five or six times before the right versions of everything are there. This is a pain for the ISP, the developer, and the customer. With that and the previous point it's hard for me to believe that PHP is easy to maintain. It just isn't so when you get beyond a couple of pages.
So, the page designers who have picked up PHP to make a few interactive screens and figure they can make the latest web PIM make a pretty significant mongolian horde. Educating them would benefit all of us.
Re:Ignorance is productive
jjohn on 2002-09-19T14:01:16
PHP is an awful, awful language and programming environment. Nearly everyone on use.perl.org is going to largely agree this statement. YET LOOK AT Freshmeat. There are a hundreds PHP apps out there and more everyday. Why? Because PHP allows novice programmers (but perhaps experienced graphic designers) to whip up web apps quickly. Are these apps maintainable or elegent? Hell no, yet most of them sure look purdy.
That is the paradox of PHP. It's a just-good-enough tool for most (web) users. Perl is never going to get that market away from PHP. That's not where Perl competes. However, I believe PHP doesn't have an equivalent to mod_perl, that is a PHP API to apache (please correct me if I err). In the web domain, Perl can do everything from simple CGI work, to Templating, to Apache handlers. The only more powerful tool for doing Apache work is C. That's the spectum of Apache tools: PHP, Perl | Python, C.
Perl is a "middle child" for many tasks. At runtime, it is slower than C, but it's far faster to program and debug. Perl is more complicated to use than domain-specific tools (like PHP), but it is more robust and flexible. Given that one programmign tool can't be all things to all people (sorry Java), where should the development of Perl 6 focus? My money is on the power-users. Make Perl play nice for Big Applications. Give Perl a first class object system, a clean front-end and the ability to emit bytecode compatible with this year's compsci darling. If Perl can do this well enough, authors will use Perl to create even more domain-specific solutions.
That's a beautiful endgame.
Re:Ignorance is productive
chicks on 2002-09-19T14:18:21
If anybody has read this far and doesn't have a pet perl web app project somewhere in your life, please fix it!The best way to show the PHPers what they're missing is to create nice domain-specific perl web apps and do them well. There are lots of PHP apps out there to use as examples of how the screens should LOOK. Heck, start with their HTML! It's open source after all! They've stolen plenty of good perl ideas (like
/.) and reimplemented them in their nasty little language, so don't feel any guilt! I don't care if there are 30 web PIM's in PHP on sourceforge if we had one GOOD one in perl. And, yes, I'm working on fixing this myself.
Re:Ignorance is productive
jdavidb on 2002-09-19T14:39:48
I hate PHP slash clones. They feel so limiting. Slash works exactly the way I think, and every PHP slash clone tries to change that in subtle ways or fails to implement all the needed features.
I move my mouse over a topic icon, and there's no alt tag to tell me what the topic is.
Nested/threaded/flat means different things to different people, but at least I know what it means in genuine slash.
Re:Ignorance is bliss
kharris on 2002-09-24T13:29:02
I gotta agree here. Quite a few of the people that I know think PHP is great...of course these same people like JavaScript and think that VisualBasic is a powerful language.
From the above, we can deduce that I know - and have worked with - a lot of mouth-breathers.
I think the only reason that Lisp didn't rank higher on the suck-o-meter is because the same people who like PHP/JS/VB, et al, have not a clue what Lisp is.
kevin
The link above goes somewhere completely different. You probably want to go here.
