PHP5 Just Around the Corner

HitByASquirrel writes "Just doing the rounds and I found that Zend has released PHP 5.0 Beta 4: 'This fourth beta of PHP 5 is also scheduled to be the last one (barring unexpected surprises, that did occur with beta 3). This beta incorporates dozens of bug fixes since Beta 3, rewritten exceptions support, improved interfaces support, new experimental SOAP support, as well as lots of other improvements, some of which are documented in the ChangeLog.' Hopefully they won't have any 'unexpected surprises' and we'll see this before summer!"

Comments

Zzz...

[blackrat]

... wake me up when PHP 5 final is ready.

The superiority of PHP over Pearl

[Anonymous Coward]

Hello Slashbots,

Recently I've had a chance to do some web design with PHP. Previously I'd used Pearl because I'd heard from many people that Pearl was the end all and be all of scripting languages for the web. Imagine my suprise to discover that PHP was vastly superior! I know this is a bold statement, but I have solid arguements to support it.

Before I begin, let me just clarify something. I'm not arguing that PHP is better than Pearl in all cases. There is certainly still a use for Pearl. Also, PHP isn't perfect but it does manage to fix many of the shortcomings I've had with Pearl. Here are a few of the things I've noticed about PHP. Finally, I'm not the most talented Pearl programmer out there. I generally prefer to use the vastly superior Phyton, but can use Pearl if I have to.

1. Ease of use. After about a day I had an excellent understanding of both PHP and SQL. I was able to get a stable, useable and presentable website up within 24 hours of reading the basics of PHP. Learning Pearl took me weeks and I'm still not even as good with it as I am with PHP. I would definitely not recommend anyone new to programming begin with Pearl.
2. The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Pearl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Pearl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.
3. Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Pearl seems limited to MySQL and PostgreSQL, and its really a kludge for the later. I've heard that this will be fixed in upcoming versions of Pearl though.
4. Speed. PHP is one of the fastest languages I've ever used. While it won't be replacing assembly or C, its definitely faster than Pearl in almost every case, particularly in regex which has long been Pearl's strongest point. I'm sure there are cases where Pearl is equal to PHP, but I can't think of any at the moment.
5. Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new McIntosh servers and have it run without having to change a single line of code. Try doing this with Pearl! Its as though it was written in assembly, Pearl requires that much rewriting.
6. Graphics. PHP comes with a nice little graphics library. While I wouldn't use its to code the new Doom (VB would be a better choice) its adequate for most web pages, and should be considered as a substitute for Flash for certain things. Pearl lacks a graphics library of any kind.
7. Data Structures. Under PHP you can create any type of datastructure you need: Linked lists, binary trees, hash tables, queues, inverse Reiser-biased recursion trees, etc. Under Pearl you're extremely limited in what you can do. This is because Pearl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers. Some of you may notice that PHP lacks pointers, but look deeper! Behind the scenes, hidden from the user pointers are used. Because of this, PHP can support complex data structures.

Again this is just my experience. I don't mean to offend any Pearl coders because Pearl was an excellent language. However, in certain cases it may behoove one to write the back end in PHP instead of Pearl.

Re:The superiority of PHP over Pearl

[retards]

gah, the parent is a troll from usenet over a year back...

get a life, copy-cat

Re:The superiority of PHP over Pearl

[moro_666]

php might be a simple scripting language easy to
use but,

just wanted to point out :
1) php has no real threading support e.g. other than
simple webscripts are impossible to create
2) using whatever wierd forking in your php scripts
still leaves you without shared variables and so on.
3) php has still very slow interface to shared memory
(shmop), which makes it even more pointless to use in
real enterprise applications even for web
4) even the new php-s oop structure is still out of date
when compared to java or c++ or even perl (where are
protected variables and callbacks? why does the php still
not have a normal automatic class searching system and
still relies on user own written inclusion lines? etc.)
5) php developers are heartlessy disgarding every kind of
backward compatibility with every new minor version they
write, e.g. your old scripts which worked finely for 4-5
months may be buggy without you even knowing it after 1
mysterious update.

just wanted to make this statement. php has still a long
way to go to make it to the real enterprise market where
perl and java are already ready. the new version of php
doesn't include any major necessary components to achieve
the raise to real enterprise developement market.

still hope they will make the jump to real applications
cause the idea of php is quite good. only the
implementation needs be improved. php6 maybe ?

Re:The superiority of PHP over Pearl

[smittyoneeach]

just wanted to make this statement. php has still a long way to go to make it to the real enterprise market where perl and java are already ready. the new version of php doesn't include any major necessary components to achieve the raise to real enterprise developement market.

Possibly PHP targets a different market. *HP did originally mean Home Pages, IIRC.
Thus, PHP may be positioning itself to support individual efforts, or prototyping for the enterprise market. Not nececcesarily a Bad Thing, more of a Why Bother thing.
I, for one, yawn at Yet Another Tool For Which Plenty of Other Solutions Exist. I submit that, over time, the market is going to weed out the tools, and the ones that last will have compelling mixes of licensing, speed, and capability.

Re:The superiority of PHP over Pearl

[Anonymous Coward]

Where I may agree with you on the majority of your points, about number 4 : PHP5 does have protected variables, and callbacks have been available since PHP3 or so (albeit in a slightly hacky way, non-entirely useful way) :

(From http://www.php.net/zend-engine-2.php)

class MyClass {
private $Hello = "Hello, World!\n";
protected $Bar = "Hello, Foo!\n";
protected $Foo = "Hello, Bar!\n";

...
}

and :

function myCallback( $var ) {
echo $var;
}

function doCallback( $callbackFunc ) {
call_user_func( $callbackFunc, 10 );
}

doCallback( "myCallback" );

=> 10

I would try and disagree with number 5 too, but I fear you have more than enough counterpoints to make it impossible for me to win.

Re:The superiority of PHP over Pearl

[Seahawk]

TBH - I hope not - Like so much in the computerworld, its hard to make a tool that does all the jobs great.

So I'd rather have a couple of tools which are all REALLY good in their own niche.

And if I want the goodness that I can use in java, I'll use java - if I want to code for fun, I can use PHP - and I sure hope it stays that way! :)

Re:The superiority of PHP over Pearl

[Michalson]

5) php developers are heartlessy disgarding every kind of backward compatibility with every new minor version they write, e.g. your old scripts which worked finely for 4-5 months may be buggy without you even knowing it after 1 mysterious update.

That has to be the absolute worst. Not only do the minor versions break large numbers of scripts, they do it for the sillest reasons - php has some incredible powerful and language changing options (like magic quotes, which entirely change how you handle input), yet they insist on changing the defaults for these every time they increment a number. The real business world doesn't have the time and re$ource$ to be constantly updating code and mangling configurations just because some open source team can't make up their mind.

Re:The superiority of PHP over Pearl

[dan_bethe]

How do they expect anything different than this...

(barring unexpected surprises, that did occur with beta 3)

...when they're constantly pulling juvenile crap like this...

rewritten exceptions support, improved interfaces support, new experimental SOAP support, as well as lots of other improvements, some of which are documented in the ChangeLog.

?

I would expect that serious PHP application engineers would be leaving tons of features unused rather than risk needlessly rewriting tons of code. Who, anywhere, at any price, could possibly afford to develop major cutting edge PHP apps? How much work is it? And why would they use PHP rather than any enterprise worthy language? I could understand this behavior in the early days, around 1.0. I'd honestly like to know. See the rest of the replies to this parent.

Re:The superiority of PHP over Pearl

[Tablizer]

php has no real threading support e.g. other than simple webscripts are impossible to create

What is an example of such need? Web-based interfaces generally don't need that kind of multi-threading.

php has still very slow interface to shared memory (shmop), which makes it even more pointless to use in real enterprise applications even for web

Php philosphy is generally to use the database for shared information, not RAM. If you want an "enterprise" application, then get a big-iron RDBMS like Oracle, DB2, etc. to use with Php.

even the new php-s oop structure is still out of date...

Again, Php tends to use the database for "noun modeling" instead of OO. Thus, it tends to de-emphasize OO. If you are an OO affectionado, then Java will make you happier. Relational thinking and OO thinking tend to collide in Philosophyville. Php tilts toward the DB side.

Re:The superiority of PHP over Pearl

[not_cub]

The real business world doesn't have the time and re$ource$ to be constantly updating code and mangling configurations just because some open source team can't make up their mind.

Conversely, open source projects shouldn't hold themselves up because real world businesses are too busy cutting costs to look after their intellectual assets.

not_cub

Re:The superiority of PHP over Pearl

[Anonymous Coward]

That's a nice thought, but very few real world businesses give two shits about PHP -- the market is pretty much dominated by JSP, ASP, Perl, ColdFusion, and ASP.NET.

The cost of PHP incompatibility is primarily borne by open source coders, who get to spend time working for free tracking the platform rather than adding new features.

Re:The superiority of PHP over Pearl

[moro_666]

>>What is an example of such need? Web-based interfaces
>>generally don't need that kind of multi-threading.

for example an web page which would need to
fetch data from multiple databases on different
machines at the same time..
doing it in multiple threads would be much faster
than in one thread

Re:The superiority of PHP over Pearl

[Tablizer]

for example an web page which would need to
fetch data from multiple databases on different
machines at the same time...doing it in multiple threads would be much faster than in one thread

Only if there are very few users. If there are a lot of simultaneous users, then it probably won't make much difference because you would have at least twice as many queries in the process queue at any given time.

Re:The superiority of PHP over Pearl

[Anonymous Coward]

weird
weird
weird

NOT wierd

dumb ass

Re:The superiority of PHP over Pearl

[Anonymous Coward]

php has no real threading support e.g. other than simple webscripts are impossible to create

What is an example of such need? Web-based interfaces generally don't need that kind of multi-threading.

Sometimes there are queries that take a long time to complete. You can start it off a few pages ahead of time in the workflow and store the result in the user's session. The user will spend less time waiting for page loads. That's just one example.

php has still very slow interface to shared memory (shmop), which makes it even more pointless to use in real enterprise applications even for web

Php philosphy is generally to use the database for shared information, not RAM. If you want an "enterprise" application, then get a big-iron RDBMS like Oracle, DB2, etc. to use with Php.

You're kidding, right? Enterprise applications try to avoid hitting the database as much as possible.

You've obviously never worked on a maintainable enterprise web application. With PHP, you have to make dirty hacks to get support for MVC, and even still there's no way to make a clean break between logic and presentation because you have to put looping code in a page to make it output a table.

Re:The superiority of PHP over Pearl

[Anonymous Coward]

To make the database as shared memory approach even more ridiculous, PHP doesn't even have connection pooling.

unexpected surprises?

[Anonymous Coward]

forgive the ingnorance guvnah, but what were the unexpected surprises from Beta 3?

Re:unexpected surprises?

[Dreadlord]

his fourth beta of PHP 5 is also scheduled to be the last one (barring unexpected surprises, that did occur with beta 3).

this release is supposed to be the last beta for 5.0, and the next release should be a production one, the surprise isn't in the beta itself, the author wants the production release to be next, and not another beta.

No upload progress support in 5.0

[dostick]

The much-requested feature of Upload progress did not make in PHP5.0
Too bad. Now we need to wait until PHP5.1 or something.
And meanwhile stick with PHP sourcecode patch or perl method which is nightmare.

Re:No upload progress support in 5.0

[Anonymous Coward]

What do you mean by "upload progress"?

Re:No upload progress support in 5.0

[dostick]

possibility of having hook to display progress when uploading file using HTML form in PHP: http://www.zend.com/zend/week/week161.php

Re:No upload progress support in 5.0

[Anonymous Coward]

Sorry, that link isn't at all helpful, it gives zero technical details.

The problem of user feedback on file upload is a browser issue, plain and simple. There isn't any *reliable* way of faking it on the server, various kludges involve frames, Javascript, etc, all of which have their various tradeoffs. I very much doubt anything like this will go into PHP.

Re:No upload progress support in 5.0

[Anonymous Coward]

It tells you something that PHP coders are crying for upload progress bar, while environment lacks basic appserver features like connection pooling.

Re:No upload progress support in 5.0

[cortana]

Please log in so you can be moderated up!

A progress bar for file uploads is clearly the responsibility of the user-agent.

Why no lexical closures?

[ajagci]

Does every little scripting language have to repeat the same mistakes? Lisp 1.5 thought it could get by without. Perl did. Python did. Lua did. In the end, they all added them.

Come on, guys, learn something from history, avoid making the same mistakes over and over again, and add lexical closures to PHP.

Re:Why no lexical closures?

[trompete]

Please elaborate on this concept.

Re:Why no lexical closures?

[WayneConrad]

Please elaborate on this concept.

Closure (programming)

Re:Why no lexical closures?

[trompete]

Ahhhh....so that's what those things is LISP are called :) Thanks!

Re:Why no lexical closures?

[FrangoAssado]

Well, for a quick and simple example, instead of writing

function f($a, $b) { return strcmp($b, $a); }

usort($array, 'f');

you could just write something like

usort($array, function ($a, $b) { return strcmp($b, $a); });

With this, functions would be first-class objects, which probably complicates the internals of the language, but it could be added when the reestructuring for improved OOP was done.

Re:Why no lexical closures?

[scrytch]

<? function a() { echo 'all work and no play makes jack a dull boy '; a(); } ?>

The question is, does PHP have tailcall elimination, or does jack blow the stack?

Re:Why no lexical closures?

[gid]

So what's the matter with doing it the old way?

Maybe I'm missing something, but it seems defining the function inline makes the code less readable, and more cluttered. PHP isn't really about being able to mimick the perl one line "goodness". Written properly, php code is very readable and easily maintainable. If feel that's one of the major reasons for it's popularity.

That and the low learning curve and excellent online docs. I have a one stop shop for php documentation. I rarely need any other docs besides php.net/searchstring

Re:Why no lexical closures?

[Tablizer]

The vast majority of things that closures would be used for can be done with "eval()" and "execute()" like functions that evaluate in context. Although they may not be as "clean" as pure closures, eval and execute are conceptually simple and will do the job for the occassional times dynamic execution is needed. Closures just tend to frighten away people from a language. Closures == "those damned math nerds got their fingers into it" :-)

Re:Why no lexical closures?

[Anonymous Coward]

Moderators, please explain why you labelled this "flaimbait"? The "damned math nerds" comment was meant to convey the *impression* people get, not actually give a value judgement to math nerds.

Re:Why no lexical closures?

[andyh1978]

usort($array, function ($a, $b) { return strcmp($b, $a); });

Well, you can already do:

usort($array, create_function('$a,$b', 'return strcmp($b, $a);');

Which is relatively close.

Re:Why no lexical closures?

[ajagci]

Let's say I write:

usort($array, create_function('$a,$b', 'return $direction*strcmp($b, $a);');

Which variable does $direction refer to?

Doing function pointers right isn't hard and the current design only has disadvantages. Why is this still not fixed in the fifth major version of PHP?

Re:Why no lexical closures?

[ajagci]

So what's the matter with doing it the old way?

The matter is that (1) you are referring to functions by their name, not as an object, and (2) that you can only write functions that refer to global variables.

Maybe I'm missing something, but it seems defining the function inline makes the code less readable,

Lexical closures have nothing to do with whether the function is written in-line or not. It has to do with functions being data objects rather than strings, and it has to do with variables being resolved correctly.

Just think about this snippet for a moment:

function mysort($array,$direction) {
$compare = function($a,$b) {
return $direction * strcmp($a,$b);
}
return usort($array,$compare);
}

That's how things should work.

Re:Why no lexical closures?

[ajagci]

The vast majority of things that closures would be used for can be done with "eval()" and "execute()" like functions that evaluate in context.

Closures aren't "used for anything", they just give the language straightforward and sensible semantics, as opposed to the mess that results when you name functions by strings, like PHP does.

Although they may not be as "clean" as pure closures, eval and execute are conceptually simple and will do the job for the occassional times dynamic execution is needed.

What does dynamic execution have to do with resolving variable references correctly?

Closures just tend to frighten away people from a language. Closures == "those damned math nerds got their fingers into it" :-)

Actually, if you are talking about impressions, the main impression the current language leaves is that the PHP language designers just don't know what they are doing. There is no conceivable technical or practical reason for not implementing lexical closures correctly.

Re:Why no lexical closures?

[Anonymous Coward]

How about an example of something reasonably common that closures significantly improve on compared to eval/execute.

Re:Why no lexical closures?

[ajagci]

Closures improve things every time you pass a function/method as an argument to another function/method. The reason is that they make it clear which environment the function argument is going to be evaluated in.

They also happen to let you nest functions in the obvious way, as in:

function mysort($array,$direction) {
$compare = function($a,$b) {
return $direction * strcmp($a,$b);
}
return usort($array,$compare);
}

That simplifies code significantly and removes the need for global variables that can get trashed in unexpected ways.

It's not that this is a hugely important feature, it's that closures are obviously the right thing to do and they are so easy to implement that there is no reason to stick with the current system. The only impression that the current language design gives is that its authors are somehow afraid of doing the right thing because they don't know quite how to implement it or what it means.

Re:Why no lexical closures?

[Tablizer]

But you could do the same thing with eval. One just sends it a string to evaluate for each compare:

function mysort($array,$direction) {
$toEval = $direction . ' * strcmp($a, $b) ';
return usort($array, $toEval);
}

(Note the use of single quotes so that $a and $b are treated as parts of the literal string.)

Like I said, such techniques may not be technically superior to closures, but they are conceptually easier for most programmers, and situations where closures are used are perhaps not common enough to justify the extra learning curve. Closures appear to scare people away. I am just the messenger. It is an observation about human behavior, not so much technology.

Re:Why no lexical closures?

[Mr. Slippery]

Come on, guys, learn something from history, avoid making the same mistakes over and over again, and add lexical closures to PHP.

PHP has create_function().

Re:Why no lexical closures?

[Mr. Slippery]

Closures aren't "used for anything", they just give the language straightforward and sensible semantics, as opposed to the mess that results when you name functions by strings, like PHP does.

In other words, you don't like the syntactic sugar. PHP has the mechanism, you just don't like it's looks. And you're surprised that this isn't a hot issue in the development of the language?

Re:Why no lexical closures?

[ajagci]

But you could do the same thing with eval. One just sends it a string to evaluate for each compare:

No, you cannot do "the same thing". The code you wrote does something entirely different. In fact, it may well open up a gaping security hole.

Like I said, such techniques may not be technically superior to closures, but they are conceptually easier for most programmers,

Closures were in Pascal, for God's sake, one of the simplest teaching languages ever used. Pascal was trivial compared to the complexities of PHP.

and situations where closures are used are perhaps not common enough to justify the extra learning curve.

There is no learning curve--you just don't have to know about them if you don't want to know about them.

Closures appear to scare people away. I am just the messenger. It is an observation about human behavior, not so much technology.

What it is is an observation about is the state of the PHP community and the PHP implementors. And that, frankly, scares me away from PHP, and it should scare anybody else away, too, because that state of mind and skill level is bound to result in poor software quality and lousy security.

Re:Why no lexical closures?

[Tablizer]

No, you cannot do "the same thing". The code you wrote does something entirely different. In fact, it may well open up a gaping security hole.

Yes, one has to be careful with eval/execute in that regard. In this case the parameters are likely "internal", so it would not be a problem.

because that state of mind and skill level is bound to result in poor software quality and lousy security.

Well, it seems to be what companies want, so it looks like PHP is bound for "success", and languages like LISP are frowned on by CEO's.

Re:Why no lexical closures?

[ajagci]

Well, it seems to be what companies want, so it looks like PHP is bound for "success",

Sure, the same companies that have gaping security holes and lose your credit card numbers to hackers. The fact that there is a lot of stupidity out there shouldn't give people an excuse to contribute to it.

and languages like LISP are frowned on by CEO's.

Yes. Lisp was a hacker language that got adopted from the bottom up, then it was overhyped and oversold. And when it turned out to be not so great in real-world software projects, it got dropped. And it was features like "eval" and poor scoping rules that made Lisp such an incredible mess.

And that's pretty much the same path that PHP is following: the same reliance on poorly thought out primitives and scoping rules, the same kind of "we can hack it together somehow" mentality. The only question is whether PHP will learn from history and clean up its act before it gets a bad reputation or whether it will be "frowned on" by CEOs as well when their projects start falling apart.

Re:Why no lexical closures?

[Anonymous Coward]

You sound like one of those Discipline and Bondage Eiffle weenies.

Re:Why no lexical closures?

[Loe]

I hate it when I think I'm smart and then somone starts talking about lexical closures and I have _NO_ idea what he is talking about... I'm not a CS major though.

Re:Why no lexical closures?

[Anonymous Coward]

Well, and you sound like your knowledge and judgement of languages is superficial.

Lisp-style or PHP-style languages are great, but passing around strings and calling eval is just stupid and inconvenient. Dynamic typing is convenient; lack of lexical closures is inconvenient and error prone.

Re:Why no lexical closures?

[Anonymous Coward]

Looking at PHP5, it's probably too late for PHP.

On one side it's been superceded by better application frameworks for web programming (.NET, Struts, etc.).

On the other, their last chance to break with the past and /do something/ with the language (eg remove all the global pollution and get the libraries into their own namespaces, make the array stuff part of the language, instead of an inconsistent bunch of tag-along functions, or as the parent suggests, offer lexical closures instead of hacks) has been lost. From this point on, it will continue to maintain backwards compatibility and become a more highly-evolved dinosaur.

Personally I'd like to work with the Python language within the .NET framework (a la ActiveState). But as that isn't practical in a production environment, I've jumped to C# for any web project beyond the trivial, and Python for any housekeeping tasks that I need to take care of.

Will the docs still be full of Perl envy?

[jonadab]

Are they rewriting the docs to actually explain the features of the language
and how to use them? I tried to learn PHP, but I got really tired of reading
about how much "better" PHP is than Perl because it's Not CGI(TM). Come on,
stop *saying* it's better and *show* me it's any good. What features does
the language have? How would I go about using them? If PHP is so good, the
docs ought to be able to convince me of that without endlessly repeating it.

I also got tired of seeing what ought to have been one-liners written in
fifteen or twenty lines of PHP. Is the language really that needlessly
verbose, or are those just bad examples?

In summary, the documentation is so bad, I can't even make a decent evaluation
of whether the language is any good. The *first* thing the PHP crowd needs to
fix is the documentation. It ought to be rewritten from scratch.

Re:Will the docs still be full of Perl envy?

[hymie3]

Uhm, huh? Is this a troll? The only *really* good thing PHP has going for it is the online documentation. The user comments make PHP bearable to use. They explicitly provide real-world examples of how to do things and how to work around kludgey PHP interfaces and bugs. PHP's documentation makes a so-so product into a good product. Perl is a really good procut that would be a lot better if it had something similar. It's online FAQ is good, but somehow seems to never contain *MY* frequently asked questions.

Re:Will the docs still be full of Perl envy?

[hymie3]

(ack. missed a tag. sorry) .In summary, the documentation is so bad, I can't even make a decent evaluation
of whether the language is any good. The *first* thing the PHP crowd needs to
fix is the documentation. It ought to be rewritten from scratch.

Uhm, huh? Is this a troll? The only *really* good thing PHP has going for it is the online documentation. The user comments make PHP bearable to use. They explicitly provide real-world examples of how to do things and how to work around kludgey PHP interfaces and bugs. PHP's documentation makes a so-so product into a good product. Perl is a really good procut that would be a lot better if it had something similar. It's online FAQ is good, but somehow seems to never contain *MY* frequently asked questions.

Re:Will the docs still be full of Perl envy?

[Anonymous Coward]

Are they rewriting the docs to actually explain the features of the language and how to use them?

No, the current documentation does that just fine. There's a tutorial, the user manual, and extensive user-contributed notes on the manual, all linked to from the PHP homepage.

I tried to learn PHP, but I got really tired of reading about how much "better" PHP is than Perl because it's Not CGI(TM).

Care to point out where the PHP documentation states that? Or are you just judging the language by a vocal minority of its users?

What features does the language have? How would I go about using them?

Have you tried sitting down with a tutorial rather than whining about Perl?

I also got tired of seeing what ought to have been one-liners written in fifteen or twenty lines of PHP. Is the language really that needlessly verbose, or are those just bad examples?

"Verbosity", in relation to the average Perl script, is not a bad thing. The clearest, most maintainable Perl scripts I have found don't use the "line-noise" shortcuts that Perl offers. PHP simply never bothered putting them in. If you want to write unmaintainable, unreadable scripts, then by all means, avoid PHP and choose Perl.

Re:Will the docs still be full of Perl envy?

[jonadab]

> > I tried to learn PHP, but I got really tired of reading about how
> > much "better" PHP is than Perl because it's Not CGI(TM).
>
> Care to point out where the PHP documentation states that? Or are you
> just judging the language by a vocal minority of its users?

Huh. It appears to be *gone*. It was there, honest. I googled for PHP,
went to the first result that wasn't a paid advert, and clicked on a link
that said something like "tutorial" or "documentation". This was a little
while ago, though (at least a year).

Still, the manual at http://www.php.net/manual/en/index.php seems to me
to be a revision of the same documentation I was reading. A lot of the
wording in it is very very familiar to me, so I'm almost sure it's the same
document (or the one I saw copied from this one, or vice versa, or something).
However, all that negative CGI-bashing is *gone*, as if someone has edited
the document ad interim and cleaned all that junk out.

So, um, ignore my ranting; this issue appears to have already been fixed,
and I'm just behind the times. There's nothing to see here; move along.

Re:Will the docs still be full of Perl envy?

[scrytch]

In summary, the documentation is so bad, I can't even make a decent evaluation of whether the language is any good. The *first* thing the PHP crowd needs to fix is the documentation. It ought to be rewritten from scratch.

I have experience with both PHP and perl. I have a raging bias against PHP, but I'll try to tell it straight:

PHP's a lot easier to install than mod_perl, full stop. That is to say, mod_perl might be a package install away, but configuring it to get its features working takes some work with trial and error. By being essentially an embedded evaluator first and foremost and last, PHP doesn't confuse you by dealing with apacheisms like request handler objects. Of course it doesn't confuse you with having any real general-purpose functionality either (I'm told there's actually a gtk binding, but I can't seriously consider this as more than a toy).

PHP's syntax is more regular and reduced than perl's. It has only one sigil, $foo, as opposed to $foo @foo %foo and $foo. It lacks most of the line noise constructs like $#foo. References are managed internally (though you must explicitly pass by reference to functions) so there's no difference in syntax between an array and a reference to one. PHP5 will pass objects by reference by default. PHP4 always passes a copy unless you explicitly pass by reference. I found this to be really quite a misfeature in PHP4 that I'm happy to see fixed. I certainly hope the === operator has its extremely broken semantics fixed (it does the deepest of comparisons instead of the shallowest) but I'm not holding my breath.

PHP doesn't auto-splice lists. In fact it doesn't auto-create them from the various contexts perl does, you must use the "array" function to get a list. One gets used to this, and ultimately it's not much worse than lisp's list function. Arrays are much like lua arrays, and can have numeric or string keys, there is no separate "hash" type or hash syntax to go with them.

PHP4 has no structured exception handling at all. In fact there's no mechanism whatsoever to trap many errors that simply result in a dead stop of execution, with an error message if you're lucky, otherwise no response whatsoever, more akin to a killed CGI. Older PHP4 scripts are rife with uses of automatically populated global variables that make them targets for cross-site-scripting and sql injection. Don't trust a PHP script from before 2002 or so. PHP5 is supposed to address these issues.

Re:Will the docs still be full of Perl envy?

[Anonymous Coward]

However, all that negative CGI-bashing is *gone*

CGI is an irrelevent issue when comparing PHP and Perl. PHP is available as mod_php and CGI PHP, Perl is available as mod_perl and CGI Perl. Usually, criticisms of CGI are spot on.

Re:Will the docs still be full of Perl envy?

[Anonymous Coward]

Whoa, this is the first time I've heard the PHP documentation called "bad".. I think it's some of the best docs out there.

Also if you need a good learning tool for PHP, try the O'Reilly PHP cookbook. It's a wonderful book, very clearly and thoroughly written. No preaching or "my language is better than yours" crap, just good advice from a couple guys who use PHP to get work done.

Besides, if you know Java, PHP5 is pretty much a no-brainer.

Re:Will the docs still be full of Perl envy?

[Anonymous Coward]

The impression I got was that the PHP docs were more of a "cookbook" for newbie cut-n-paste types than real programmer documentation. The notation system is nice, but I think people like for the wrong reasons.

PHP5 References

[djace]

Yeah, sure, "just around the corner". That's what they said a year ago :P

Some interesting slashdot PHP5 references:
"PHP5 is well under development and a beta is expected out by March 2003 and released summer 2003"
Introduction to PHP5

General PHP5 References:
Changes in PHP 5/Zend Engine 2.0
Pidget: The PHP Widget Library

Re:PHP5 References

[HitByASquirrel]

hahaha yea I read that when I was looking to see if this had been posted, its like the Doom3 of web languages. lets just hope Zend can pull it together this time.

Very easy to learn if

[Anonymous Coward]

You know C. I never "sat down & learned" PHP - a coworker told me how to use echo (and print_r() for arrays, etc), and how to do open tags ... and the rest "just worked", as they say. Oh, that plus www.php.net's function search ... um ... function ... helped.

Half of it is just learning database usage; the other half is knowing C-style (C/C++/C#/Java) syntax, and it really shouldn't be hard to adapt to even if you're not familiar with any of those.

The best part is that you can even use it on a server to write scripts (logging, etc., w/o a mindset shift). Or that no plugins are needed b/c it's server-side.

Yes, I'm a fanboy. But it deserves it.

Re: PHP and Backward Compatibility

[Paul Burney]

You said...

5) php developers are heartlessy disgarding every kind of backward compatibility with every new minor version they write, e.g. your old scripts which worked finely for 4-5 months may be buggy without you even knowing it after 1 mysterious update.

Thank you for bringing that up. That's been my biggest complaint with PHP. Some examples include:

• redefining the way that strtok works
  
  
• changing the syntax for the deleting cookies without mentioning it in the change log or documentation (for 3.1 - 4.someting you could just call setcookie('variablename','') to unset the cookie. They switched it so you needed to add all the parameters to the function call, date, server, path, etc.)
  
  
• breaking the error_reporting() function for several versions, forcing users to rewrite their calls using ini_set() instead.

It seems that any time there is an update for PHP, something else gets broken. I cringe when my sys admin tells me he wants to update it, because I know it's going to lead to hours of debugging work that I shouldn't need to do.

PHB

[bayankaran]

Is it only me...I read 'PHB just around the corner'.

Re:PHB

[Anonymous Coward]

and you stayed around long enough to type that comment??? any self respecting-geek would have bolted.

How Much?

[DAldredge]

How much will it cost for the add-ons necessary to run PHP on a high traffic server? You know, the cache that should be included in the base product but isn't because it would hurt Zends market.

Re:How Much?

[Angst Badger]

How much will it cost for the add-ons necessary to run PHP on a high traffic server? You know, the cache that should be included in the base product but isn't because it would hurt Zends market.

There are several free third-party caches that work just fine. The PHP folks even provide links to them.

That being said, I work for a company that has a high-traffic site -- about 3 million page-views per day, and we run it without a cache. It takes eight load-balanced web servers to do this, and the main bottleneck is response time from the MySQL server. (This is not a slam against MySQL -- it's chugging along at about 10,000 queries per second.) We could get by with less hardware if more non-sensitive data was shoved into cookies instead of the database and more trivial UI stuff was migrated to client-side Javascript.

PHP's main problem, in terms of implementation, is that it's a bit of a memory hog. There's a huge amount of metadata that goes along with PHP variables, and a PHP array of n elements consumes several times as much memory as the equivalent Perl array. If this has been addressed in PHP 5.0, it will be a big damn deal.

Don't forget to check Zope

[axxackall]

Just for a case if there are people here who don't know about Zope but who are tired from primitivenesses of PHP and who would be interesting in migrating to Zope from PHP:

There is much better alternative to PHP. It's called Zope. In fact, Zope has two similar (but very superior) markup languages: DTML and ZPT, both using Python for underlying scripting.

Just go to the site and check brief functional description - you will be surprise how far their technology has been developed for the last year.

Personally, I was developing on PHP before (like SquirelWebMail plugins, database applications), but I don't see any reason to write PHP anymore. All my current and upcoming web-projects are only Zope-based.

Re:Don't forget to check Zope

[Anonymous Coward]

Just for a case if there are people here who don't know about Zope but who are tired from primitivenesses of PHP and who would be interesting in migrating to Zope from PHP:

That is comparing apples to oranges. Zope is a web publishing framework, not a programming language. There are publishing frameworks for PHP also. Zope leaves a bad taste in some people's mouths, as if it is an attempt to be an OO paradise tickling your OO glands rather than being practical. Some also say it is not relational-friendly.

Re:Don't forget to check Zope

[Anonymous Coward]

The difference between mediocre languages like PHP and mediocre languages like Python is that the PHP folks have no delusions that their language is anything more than a quick hack to get your work done.

Zope is a stunning example of over-engineered mediocrity.

Re:Don't forget to check Zope

[geoffspear]

You know a markup language (DTML) is horrible when the people writing the documentation repeatedly tell you not to use it right there in the middle of the documentation, but to write Python scripts instead.

Re:Don't forget to check Zope

[axxackall]

Explain yourself, and better with examples, please. Or admit that you've just done some trolling.

DTML documentation never said to write Python scripts instead, as DTML is a markup based on Python. On this esense, DTML is no different than PHP, just using Python (very common language even outside DTML!) as underlying scripting instead of something that you never find outside PHP.

The only advise to use something instead of DTML is to use ZPT, which is namespace-aware naturally-further generation of DTML.

In both cases, with DTML and ZPT it is advised that in case of complicated scripts you can write scripts in separate files and call them from DTML/ZPT tags. But that is called structuring you program code, which is a good thing.

So, stop trolling and talk with facts in your hands.

Re:Don't forget to check Zope

[axxackall]

that their [PHP] language is anything more than a quick hack to get your work done.

That reminds me Perl: you can cook a quick hack very quickly, but no chances you can read it after few weeks. In other words: your job can be done with PHP quickly, but it cannot be maintained after that.

Re: PHP and Backward Compatibility

[timothv]

Just as an example as to how backwards compatiblity should work, Python has it about right.

For example, the current python version returns 2 when you type 5/2. In Python 3.0, the behavior would be changed to returning a float (2.5).

This could break plenty of scripts, such as parse_lines(file_size/2) where the argument could only be an int. Now, to the magic:

These future changes are announced years before the actual forced change in the language. However, for your current Python 2.3 program you can import future behaviors, like so:

from __future__ import division

Which will make sure that your division doesn't break once python reaches 3.0.

Not a troll - PHP docs woefully inadequate

[Ars-Fartsica]

You often need to look at the contributed comments to get even a basic description of the topic at hand. You can tell by the tone of some of the contributed comments in the docs that the authors are astounded they needed to add their annotation.

Re:Not a troll - PHP docs woefully inadequate

[Anonymous Coward]

>> You often need to look at the contributed comments to get even a basic description of the topic at hand.

You're telling me I need to look at information contributed by the community in order to get more information about topics covered in the documentation?? OMG what has the world of open source come to?

Unicode string support yet?

[sproketboy]

Just wondering if PHP has come out of the 80s yet.

Re: PHP and Backward Compatibility

[Triumph The Insult C]

here's an idea

read the ChangeLog that gets posted with each new version to see what changes. that might give you an idea of what is going to break

PHP Sucks

[Space_Soldier]

It is ugly as hell, what's up with object.__copy()? PHP had it's good days when ASP 3.0 was arround, but now with full OO, application oriented, instead of scripting oriented developing, it sucks. ASP.NET is supperior, just put mod_mono in your apache and enjoy compiled applications with C# or any other .NET language.

PHP docs...

[scott_davey]

I think PHP's documentation has a mix of good and bad.

The function reference is usually quite good, and the contributed comments make a good reference excellent. It could be further grouped to become easier to navigate, grouping all the "database access" functions together in a deeper heirarchy, for example. (PHP in general is suffering from having too many functions IMHO - that may be fixed in PHP5 though).

However, the language reference, which is intended as an introduction to the language, is not great for beginners. It definately needs tutorials, and a quick reference to common functions used in real-life scripts. An overview to accessing a database would be good in here - connecting, fetching, resource handles, etc - rather than having to go to the function reference and guess the functions you might need. Also, it could contain a language-to-language comparison of commands and concepts to entice ASP/PERL/Python/LanguageX programmers to easily convert.

I can see that beginner programmers, or PERL/Python/LanguageX converts, would find some troubles coming up to speed quickly with the launguage based on the current manual. But as a seasoned PHP programmer I now find it is a great resource.

I agree with the parent poster that the user contributed comments are essential in understanding some functions, and this probably highlights some deficiencies in the manual. But the fact that a good community exists to add these comments, plus the manuals ability to store them, makes for an excellent resource.

All in all, I think the PHP development group is doing a great job, and I look forward to PHP5 (well, perhaps 5.02 :-)

Re: PHP and Backward Compatibility

[Anonymous Coward]

This is a valid and insightful point.

We use PHP in the real world, for 600+ websites. We have learned the hard way not to upgrade, to stick with the same PHP version and upgrade maybe once a year at most - when we build a new server. Sounds daft but it's the best solution here.

out of curiosity...

[cliveholloway]

Are you using the MySQL Query Cache? If so, what's your opnion of it in action?

If not, and MySQL is your bottleneck, I'd be curious to know how it affects that when enabled.

.02

cLive ;-)

Re:out of curiosity...

[Angst Badger]

No, we're not using it. But thanks for the tip -- I'll be checking it out. Something on the order of 30% of our read queries could probably benefit from this.

O'Reilly book

[sbszine]

If, like me, you find the PHP docs frustrating, then please consider the O'Reilly Programming PHP. I'm working on a large PHP project at the moment and this book has clarified a lot of PHP's counterintuitive strangeness (especially with respect to scoping) for me.

Re: PHP and Backward Compatibility

[mgkimsal2]

READ HIS POST.

The point is some of these changes ARE NOT IN THE DOCUMENTATION OR CHANGELOG. The behvaiour of 'get_object_vars()' changed dramatically from 4.1.2 to 4.2 without a word in the changelog. I couldn't even find the commit where the behaviour changed. Only months later did someone acknowledge that it had changed.