Slashdot Mirror
PHP 5 Released; PHP Compiler, Too
TheTomcat writes "After years of anticipation, PHP 5 was released today. This release represents a milestone in the evolution of PHP. It sports the new Zend Engine II, a completely re-worked object model, and many many new features. Check it and the changelog out."
In other PHP news, remote_bob writes "There have been many attempts, like
BinaryPHP
and PASM,
but finally there is a complete
compiler
for PHP. The Roadsend compiler produces standalone, native executables, and supports the entire PHP language (but not all extensions). It uses
Bigloo Scheme
to do its job, a variant of Lisp, the language that
Paul Graham writes about.
Benchmarks say that performance is pretty good. Is this another sign that dynamic languages are the future?"
Remember, nobody's forcing you to upgrade that site running perfectly well under php4, and you probably shouldn't.
Is this another sign that dynamic languages are the future?
I'm starting to think there are no new ideas any more, just re-hashes of old ideas. Unix, almost 35 years old, looks to be once again the wave of the future. LISP is still teaching us lessons. And the command line is still the most powerful sysadmin tool we have.
Some folks were suspicious of PHP5, and being a longtime PHP programmer, I am very pleased with the changes and additions in PHP5. Can't wait to test it out. Personally, I'm not sure if I'll use *all* of the new stuff, yet I'm sure I'll have to play with the coolest additions for the hell of it, and sort out what I'll be using and what will remain vestigial in my scripts. I will add that some of the previous PHP version quirkiness seems to be fixed.
I am certain this is not the last we'll hear about PHP5 on Slashdot, yet I am only hoping that it's creative/cool stuff, and not security problem/exploit stuff.
I can't wait to see what kinds of changes I can make to my content management system that PHP5 will bring.
The dangers of knowledge trigger emotional distress in human beings.
It's too bad the compiler is $399 per year, and only currently available on Linux. If it was a little less, and not licensed annually, I'd be uninstalling a lot of other development tools right now.
Yes the official interpreter is cross-platform, it is available for *nix and Windows.
Check out the downloads section at php.net for Windows binaries and *nix source, and here you can find more details on PHP under Mac OS X.
As for the compiler in the story, I haven't tried it before so I don't know.
The IT section color scheme sucks.
http://www.roadsend.com/home/index.php?pageID=faq
$400 for the license, which is only good for one year. After that, it won't compile until you renew.
Doesn't seem worth it for the casual hobbyist...
If speed and not closed-source is your main consideration, then how does the Roadsend compiled code stack up against interpreted code fed through the Zend Accelerator, the Turck MMcache or other caches?
mmCache is OSS and free (as in beer), which is a big plus in my book.
-Charles
Learning HOW to think is more important than learning WHAT to think.
For those who are not new to php, but wan't a good primer for PHP 5 I would definatly recommend this book by George Schlossnagle. Advanced PHP Programming was recently reviewed here and it was upon reading that review that I decided to pick up a copy. It serves as an introduction to OOP to those who are unfamiliar and does a good job in covering the specific mechanics of how things operate in PHP. The book even includes some good info on some Zend Engine hacking.
Steal This Sig
Any decent language has full PCRE support these days. Perls days as regular expression king are in the past. Sure it may have set the standard for how it's done, but now it's no longer a selling point. Plenty of other nicer languages exist.
TODO: Something witty here...
PHP itself including the zend engine is 100% opensource, You can download the source you can browse the cvs to your hearts content and see everything.
The products they produce to support the development of php the closed source.
You do not need to touch, use or otherwise dirty your poor soul with any "non-free" software to use php.
There is nothing wrong with this business model, get over it.
Personal Website
I used to really be into PHP. It was great for creating a webpage in little or no time. It's syntax, while maybe not perfect, was pretty good. Until, that is, I tried to start developing my own libraries, and ran into weird quirkiness with object design, and trying to figure out the best way to do libraries, etc. It looks like PHP5 might fix the problems I had with how objects worked, and I'm not sure if it was my own fault with the messy libraries I ended up with, or whether I didn't find the best way to do it in PHP, but I eventually moved to Python out of frustration.
I had avoided Python for a long time, as I really disliked (and still do) the indentation-matters issue. But besides that, and its own set of quirks, it's a really great language, and for larger projects I have trouble even thinking about going back to PHP.
I think the biggest selling point to PHP over other solutions such as Python is that its simple. You don't have to make a whole of choices. For example, with Python you have a large number of packages to choose from: Zope, mod_python, twisted.web, Python CGI, and a bunch of variants on these. While choice can be good, it can also be overwhelming (like how do you know which package to go with until you've tried them all?).
I think I am not alone with some of difficulties I faced with PHP. So while it's great to hear that PHP has fixed many of its bugs, I think its worthwhile for people to also look at other solutions out there.
Just my $0.02.
...does the FBI know about this? I have heard about some of the PHP busts in recent years, but all this talk about how 'powerful' this new PHP is makes me wonder how dangerous it is. It sounds expensive, too. I hope that this doesn't lead nice young kids, into a life of crime. Imagine, hords of young, glassy-eyed kids stealing stuff like...video games and movies just to fund their PHP habbit.
Damn kids.
HA! I just wasted some of your bandwidth with a frivolous sig!
I would prefer to say "Begun, the PHP flame war has".
Too late...
Hacker Public Radio is our Friend
If you'd like to see what's new in PHP 5, we got some of the leading PHP developers to write about new extensions they developed.
I also posted the first chapter of my PHP 5 book in that section which gives an overview of what's new in PHP 5. This book will be part of the Bruce Perens series of Prentice-Hall and will therefore be open-source and freely accessible to anyone.
Roadsend is a development house unrelated to the PHP development team. I doubt that their compiler would make any noticable impact since they don't support many of the PHP's most useful extensions. I have not tested it but it looks to me that the people that would be interested in this are those that want to close source their own PHP code so I guess its only fair to pay for it.
Many useful PHP tools are open source. From the bytecode compiles such as APC and MMCache, debuggers (APD and XDebug).
I see tha fact that there are some companies out there providing commercial tools for PHP developers as a good thing(tm).
LISP's parentheses turn everybody off, including me, but the data structures really are a win for tree-like applications.
Uhm, the compiler is priced at a low, low introductory price of $399. I don't think it'll be taking the *NIX world by storm any time soon, or cause mass adoption to PHP executables anytime soon.
The price is nothing. If you're running a site that requires compiled PHP, $399 is a joke. The thing holding the compiler back isn't the price, it's the lack of Solaris support.
I think most people who have the skills to write something like a compiler generally want to make a living from their work
You mean except for those dirty commie gcc guys!
There's certainly nothing wrong with this business model, although that's no reason to not be concerned about potential problems. As you said, they create a significant part of the core for PHP and make it open source and available for free, all of which is good. In a perfect world, this would be the perfect solution.
However, it is right to be watchful (not necessarily concerned) when the core of an open-source app is created and driven by a for-profit company. Since they sell a lot of surrounding support applications to make their money, they are clearly driven at some level to pay for that development. At the very least, it means that any really good idea that they have will get turned into a commercial product instead of rolled into an open source solution. Again, perfectly fine business model, but not awesome.
The other thing it does is that there is a subtle but probably powerful pressure pushing other developers working in the PHP space to consider not working there, because they will by definition start out behind this core company. It wouldn't hold off a determined company, but if a determined company began to come into the mix, it would be surprising if the core company didn't somehow use the fact that they are so essential to their advantage somehow. Without competition they can be magnanimous, but with it much less so.
At any rate, I'm just pointing out that there's reason to keep an eye on it, even if nothing ever comes of it. It's also important to encourage more businesses to adopt this model so something as good as this can come along, and it's important for them to be watched by others to make sure they don't abuse it. The lessons of Microsoft, although in a different league entirely, are too strong to ignore.
First of all having PCRE support and having regular expressions heavily integrated into the language the way Perl does are completely different things. So when I need to do log parsing, I do it in Perl, not Python, not PHP. It is simply easier and things fit more nicely for me (I use Python and PHP for at least as much development as I do Perl, but Perl still has its uses).
Second Perl has some nice features that PHP and Python lack. Of course PHP has some nice features that Perl and Python lack, and Python has some nice features that..... You get the point.
Even Javascript has some nice features if you are scripting other components (i.e. in a XUL application) but the next time I ask someone how to itterate through a hash table in Javascript, they had better not say "you don't..."
LedgerSMB: Open source Accounting/ERP
Sometimes, it also implies things like dynamically extensible type definitions at runtime, automatic memory management, and support for various functional-style features such as closures.
Compiling a dynamic language to machine code is usually a challenging problem.
No, the correct response is, "So it is out... but will it get me laid?"
The answer is, "Depends on if you wrote PHP5 or if you just write with it."
Compiled PHP won't be much faster IMHO. If you want something compiled why don't you write your web apps in C? One of the main points about using an interpreted language is that your app can be changed quickly on the fly which is often nessicary in web development. Doubtful that people are going to start compiling PHP apps anytime soon.
/flame on
PHP for shell scripts? That's just strange. ick.
PHP 5 still lacks namespaces, that alone is a good reason not to switch. That and CPAN (and no before you mention it, PEAR doesn't come anywhere close)
Since I always get the same replies everytime one of these posts comes up I'll answer them all now.
I use PHP everyday, its part of my job (sysadmin/web-developer). Have been using it for 4 years. At first I thought it was alright, but the more I've used it the more I loathe it. I find it inconsistant and I find at its core everything that goes against what a well designed language should be.
Perl code is not ugly unless you make it ugly. You can make C or PHP ugly as well.
Perl can be used in projects with multiple developers, I work with one other developer on a regular basis, sometimes two. At the beginning of the project we plan core modules and set APIs and coding style, much like I would expect anyone would do for any language.
IMHO and experience mod_perl is faster than PHP especially in larger apps.
The Anti-Blog
I have a very difficult time debugging perl scripts and figuring out how to do new things with it.
:)
PHP is more like a more friendly. Allows you to fumble around and then gives you informative errors. Kind of like your first Girlfriend.
Well, the first week of her anyways.
Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.
The problem isn't the core of PHP, but the dozens of PHP extensions and third-party libraries they use. Even if a library claims thread-safety, it is not always so. Therefore, we (as in the PHP development team) recommend to use PHP with the pre-fork MPM of Apache 2 or with Apache 1.3.
I'm surprised with all this PHP vs PERL talk that no-one's mentioned that ZEND says you can use PERL from within PHP, as of release 5. Does no-one else find this highly interesting? Anyone tried it yet?
---- death to all fanatics
...but for some reason I'm rather disinterested.
Don't get me wrong; I've been doing PHP coding for a while. But the fact of the matter is that the more I code in PHP, the more I dislike it.
Granted, the new OOP features in PHP5 are a good thing; hell, they should've been in there a LONG time ago. And exception support has me jumping for joy.
But where for the love of all that is holy is support for namespaces? I mean, sure PHP has a ton of really handy extensions, but I am getting so sick to death with typing underscores that I'll be happy man if the world suddenly decided that underscores were bad and removed them from all character sets (oh, and keyboards) entirely.
And I've also come to the conclusion that the standard PHP api can't quite make up it's mind whether it's supposed to be emulating C, or maybe some other language. Some array functions are prefixed by array_. Some aren't. Some have their arguments in the reverse order that almost all the others do. It's a mess.
PHP is a nice language, good for beginners. But it's complete lack of namespaces, half-arsed support for functional constructs (damn I hate having to write callback functions out seperately when they're one liners!), and schizophrenic api are slowly pushing me towards more well thought-out languages like Python.
Sure, Python's "thou shalt indent" system annoys me a lot of the time, but other then that it's just a clean, logical language. Unfortunetly, support for it on web hosts seems to be all but non-existant.
Seriously, if the PHP devs really want to bring PHP up a few notches, they need namespaces, and to standardize the API naming conventions. I shouldn't have to constantly open up the PHP manual to work out whether the array sorting function has array_ out the front or not.
Still, it's a nice set of improvements, so credit where credit is due. Kudos to the PHP team.
We're geeks... We're the sorcerers of the modern-day world. --
Uh... no. They also changed the object inheritance rules so that overloaded child methods have to have the exact same number of parameters as the original class. So, now you can't have multiple constructors *or* have child constructors that assume certain values and reduce the amount of paramters accordingly.
Yuck.
As a person who codes entire 20,000+ line application libraries in PHP and has been watching the development of PHP 5 very closely, there are a lot of decisions the PHP developers have made that make me very hesitant about going anywhere near the new PHP version.
As an aside, the PHP developers have decided to make SQLite, a light file-based database engine, the default session handler. Even with all file locking turned off, this is at least 4 times slower than the current system used by PHP 4. Of course you can change this setting back to flat session files, but the fact this is their default should say something about other decisions they've made. This setting itself makes especially no sense to me, as all session variables go into the $_SESSION superglobal as associative array keys - there is absolutely no benefit to using a database-enabled flat file for this, as opposed to a regular flat file. It's as if the PHP group were excited about sqlite and tried shoving it into everything.
Just read the changelog very carefully. If you're already using PHP, and have gone deeper than casual use, your applications *will* break - especially if you turn on PHP's strict mode which kills backwards compatibility with PHP 4.
Read: Rabbit Rue - Free serial nove
i'm not quite sure where you're getting this from.
/* outputs:
i've been using php5 since the first beta and afaik it has never required overloaded child methods to require the same number of arguments as the parent class.
<?
error_reporting(E_ALL|E_STRICT);
class SomeParent
{
function __construct($var1, $var2)
{
echo "Parent: $var1, $var2\n";
}
}
class SomeChild extends SomeParent
{
function __construct($var1,$var2,$var3)
{
echo "Child: $var1, $var2, $var3\n";
}
}
$x = new SomeParent(1,2);
$y = new SomeChild(3,4,5);
$z = new SomeParent(6,7,8);
Parent: 1, 2
Child: 3, 4, 5
Parent: 6, 7
*/
?>
as for sqlite as session handler, it is not the default, nor has it ever been the default.
there was a patch to ALLOW it to be used as a session handler, by setting session.save_handler = sqlite in php.ini
but if we look at the php.inis in the php5 distribution:
[solidox@server150 php-5.0.0]$ cat php.ini-*|grep "session.save_handler"
session.save_handler = files
session.save_handler = files
both dist and recommended use flat files as the default session handler.