I have to agree with you there. It's much easier just to write a HTML document and throw in a few extra PHP tags than it is to construct a Perl program.

I think that's why the major shift to PHP. People see it as being easier.

I blame it all on cheap domain names and cheap web hosting. The number of crap sites on the net have rocketed since the introduction of cheap hosting and cheap domains. Well, saying that, does anyone else remember the days when domain names were free?

Gone are the days of amateur sites being thrown together on Geocities, AOL and Ourworld/Sprynet.

More and more people without a clue what they're doing are getting access to PHP/MySQL and all these powerful tools for next to nothing - and in some cases for nothing.

Someone somewhere should devlelop a crafty perl program where you can not write a single line of perl code without reading the entire camel book.

My point was simply that comparing mod_php to Perl CGI is comparing apples to oranges. Many people see that mod_php is faster than Perl CGI (unless you get into long-running processes), and therefore mistakingly make the conclusion that PHP is faster than Perl. It isn't - it's actually considerably slower. So, if you want to compare actual language speed, you really need to put them on the same level - either both under CGI, or both compiled into the web server.

Can you explain what that code does? It isn't intuitive enough on its own to make sense of. What is "_stripform"? And what does $result[] = ... do? (I'm guessing it pushed onto the end of the array, but it certainly isn't intuitive). And why do you assign back to $this->results at the bottom? Is it not possible to change a value inside a loop in PHP? Jason Rhinelander Gossamer Threadsjason@gossamer-threads.com

Which language is uglier is not going to go very far here, I think - but I will give you that Perl can be ugly. But, the fact that Perl can be ugly is a strengh, not a weakness. One of Perl's main tenants is that there is (almost) always more than one way to do something. PHP's philosophy is a little different - basically, it tells you what the way you should do something is.

Ultimately, I suppose the biggest difference between the two comes down to how creative and intriguing you want to be with your programming. With the different interfaces you can write in a module to do the same thing - via tie()ing, autoloading, prototyping, overloading, etc. you can come up with very "cool" ways of doing things in Perl that usually don't look ugly, but rather look kindof cool.

Could I do something like that in PHP? It's doubtful. Most likely, I'd have to call something that returns an array, and extract the information from various predefined positions in the array. Personally, I prefer the above - it is simple to see what it does from just looking at it. In reference to your other post, will I be able to read it 5 minutes from now? Yes. You don't know Perl, yet you can see exactly what that does. On the other hand, I can't look at your PHP example and figure out what it does.

That code could do exactly the same thing - but you'd be right in this case; that is a little ugly. Many people would probably be tempted to write it that way - or worse. My point is that just because some Perl code is ugly, doesn't mean that all Perl code is ugly. Jason Rhinelander Gossamer Threadsjason@gossamer-threads.com

Can you explain what that code does? It isn't intuitive enough on its own to make sense of. What is "_stripform"? And what does $result[] = ... do? (I'm guessing it pushed onto the end of the array, but it certainly isn't intuitive). And why do you assign back to $this->results at the bottom? Is it not possible to change a value inside a loop in PHP?

oookay *lol*. _stripform is a function inside the actual class ($self) you wrote. would have been suggested by the (), i think. $result[] adds a value to a number-indexed array. i think it's pretty intuitive.

$result[2] = 1;

puts 1 to the result array wich you can access by the index nr 2, not giving a number will simply create one for you..

i assign back "$results = $this->results" at the bottom 'cause i'm just too silly ;)

Yes. You don't know Perl, yet you can see exactly what that does. On the other hand, I can't look at your PHP example and figure out what it does.

i'd say the opposite

In Reply To:

I could write the same code so that it looked like this: [.] Many people would probably be tempted to write it that way - or worse. My point is that just because some Perl code is ugly, doesn't mean that all Perl code is ugly.

yes. but of course if you can't write ugly, you won't write ugly. there is NO reason to write ugly, never.

In Reply To:

But, the fact that Perl can be ugly is a strengh, not a weakness.

Basicly i think you should force the user to write in a good style. you should never support users wich write ugly code. i'm reading pretty much code the hole day. i don't think having various ways to solve something is pushing creativity. it rahter stops it, 'cause you've to hold more things in your mind. more code. more ways to solve something.. ok, this really may be discutable (even if i'd never agree..)

uh bad :) hey you HAVE to agree that this MUST be wrong - allowing both ways to do it? we're able to simply differ a class variable and method by looking if there are parantheses, but you have to ..?

Code:

print $var; { // things here in }

uh - that's ugly :) what does the "{" stand for? basically they are a block wich should either be repeated (loops) or called by name (functions, methods). having a more straight defined ways to do something allows different behavior on little code change.

In Reply To:

I could show you 5 or more variations in perl but how about this (for shits and giggles)..

so are you proud of? ;)

PHP has less language to learn, wich is then more readable, easyer to learn, and easyer to write, as you have to learn less.

the more complicated the language, the more your script will be buggy, hard to write, hard to read. you'll not be able to do write the most complicated thing with the most complicated language.

with less and clearer, more logical rules you're able to do more sophisticated. Citing' Eric Raymond if he maybe has more weight in his writings (as you sayd, my english sucks..):

Quote:

This kind of thing is called metaclass hacking and is generally considered fearsomely esoteric--deep black magic. Most object-oriented languages don't support it at all; in those that do (Perl being one), it tends to be a complicated and fragile undertaking. I had been impressed by Python's low coefficient of friction so far, but here was a real test. How hard would I have to wrestle with the language to get it to do this? I knew from previous experience that the bout was likely to be painful, even assuming I won, but I dived into the book and read up on Python's metaclass facilities. The resulting function is shown in Listing 3, and the code that calls it is in Listing 4.

That doesn't look too bad for deep black magic, does it? Thirty-two lines, counting comments. Just from knowing what I've said about the class structure, the calling code is even readable. But the size of this code isn't the real shocker. Brace yourself: this code only took me about ninety minutes to write--and it worked correctly the first time I ran it.

Gossamer Threads is a Vancouver-based company with over 23
years experience in web technology. From development to hosting, we
partner with leading organizations around the globe and help to build
their web presences, strategies and infrastructures.