Slashdot Mirror
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!"
Please elaborate on this concept.
More than enough BS
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.
You said...
Thank you for bringing that up. That's been my biggest complaint with PHP. Some examples include:
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.
<?php while ($self != "asleep") { $sheep_count++; } ?>
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.
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.
Proud member of the Weirdo-American community.
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" :-)
Table-ized A.I.
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.
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.
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.
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:That's how things should work.