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?"
...but who will use it for another year or two?
~Necromutant
This may well sever my last remaining link with Perl. While I used to ride the camel for web and shell scripting, I've now moved entirely to php for the web, and mostly php for shell scripting, with Perl used when its extra speed is useful. Presumably compiled php will eclipse Perl for scripting use now though, so (on Linux at least) I'll probably convert fully. Pity I have to stick with sed, awk and shell scripts on our old HPUX servers though...
Code, Hardware, stuff like that.
Doing PHP development has been my main source of income for a couple of years, the new release will make my life much easier, especially the new OOP model, let's just hope that web hosts will upgrade soon.
Thanks again PHP team!
The IT section color scheme sucks.
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.
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.
A good reworking of the PHP object model was definitely in order. Inheritance was a bit weird, destructors were odd to work with, and there weren't ways to declare stuff private.
The bigger question is compatibility. Will older code be ok? When will mainstream hosts migrate to the newer version? It'll be scary to find systems borken because of version updates.
As for a compiler, I'm not sure I'm comfy with the idea. Always figured if you wanted to write code for native compilation, you'd hack in C or maybe C++. Not that PHP wouldn't have its uses...as PHP is really handy and greatly increases the speed of development.
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.
Now that PHP has stopped imitating Perl, and started imitating Java, I can write some Java-look-alike code while still simple-mindedly sneering at that language as inefficient and bloated!
The compiler generates binary code that is executed directly by the CPU, avoiding the intermediate process of compiling to bytecode and running in a virtual machine
That's a true native compiler to me.
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
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".
For a list of PHP 5 related tutorials and articles check out this faqt or simply look around the faqts PHP 5 section.
Too late...
Hacker Public Radio is our Friend
Very cross-platform...obviously some things like file paths might have to be changed to reflect the filesystem they run on top of (/usr/bin/whatever vs c:\program files\whatever) but with few exceptions, PHP code written on any OS will work on any other one.
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.
...but Microsoft really did get there lightyears ahead of this, with a far more complete class library and a standardized language, as well as a scripting engine that supported true seperation of code, presentation and so forth.
Just to clarify this, consider the following:- ASP.net's been precompiled since the 2000 beta, and it's been production ready for years. The C# language is also fully documented and is a public standard ratified by the EMCA.
PHP5, however nice, is treading old water, and in terms of functionality is still lagging behind even Java/JSP. The whole reason I'm assuming people stuck with PHP4, rather than move to something more robust that provides this kind of capability, is that:-
1) They're apathetic about new technology.
2) If the old language does what they want, why upgrade. It's *Personal* Home Page, after all, not corporate homepage.
3) Why make things more complex, for very little benifit.
Performance wise, the compiled version advantages are fairly insubstantial, and 99.9% of the new stuff they've added could have been done in other ways using the existing language.
The whole thing seems pretty stagnant, and I'm guessing there's a small chance that the PHP guys are stuggling to find their own space between the land of true pre-compiled OO languages and the interperated world that lay behind it.
I've worked with PHP4 and ASP.net since both of them were betas, and if PHP wants to be a serious consideration for large scale development, it'd better decide which side of the OO fence its on, and stay there.
Ok, apart from the fact that you're obviously trolling, I don't really have a comment on most of your points as I've never used ASP, and I've used PHP enough to know that I hate it and everything it stands for, but I still have to question at least one of your points - "ASP includes database connection pooling, something that costs many thousands of dollars on Unix"
That sounds like you're quoting a marketing guy with no idea what you're talking about.
Sure, ASP may contain DB connection pooling, and sure, PHP may not have it, but "Costs many thousands of dollars on Unix" is the most ridiculous thing I've ever heard.
Show me this many thousands of dollars worth of "Database Connection Pooling On Unix".
Unix has nothing whatsoever to do with it. PHP runs in IIS quite nicely. And even if PHP was a Unix specific thing, there's nothing hard or expensive about connection pooling, and there are free libraries implementing it in just about any language that can access a database.
Advanced users are users too!
(Hurray for being modded as flamebait!)
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.
...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
The basic summary is, PHP does not support Unicode or any other encodings properly. PHP strings are 8-bit-per-character and do not have any explicit encoding. Sure, there is a multibyte string extension available, but when you look at the big picture, it's worthless.
/maybe/ the popular graphical extensions like GDlib). Which means that for those developers, PHP does not do Unicode at all.
The reason is that PHP's biggest strength is that these days, you can get a PHP-enabled host for virtually no money. However, most of these installs run a standard PHP, some even a locked down one.
The consequence is that anyone who wants to develop PHP software for a large audience cannot use any non-standard stuff (except
I don't see why they won't do native Unicode, when Perl, Python, Java and all the other popular web languages support Unicode with all the bells and whistles.
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.
I remember putting a CMS together with PHP4, something like Midgard, but pure PHP with multiple backends. It's not entirely a bad design even now, though I think Zope has a better answer.
... which did exactly the WRONG thing and implemented even DEEPER comparison. That was the point where I went over the edge and wrote off PHP. I hear this behavior has mercifully changed to a sane one in PHP5.
I ran into some awesomely dumb stuff. I mean "what are they smoking" stuff.
Brain dead parser: First of all, this requirement to put everything in tags or whatever brackets you have defined. What is this, javascript? (and even javascript doesn't need it if you use src="foo.js"). That alone, not so bad, but the parser would easily choke on any end bracket construct ANYWHERE -- in a string, in a comment, etc.
Flat namespace. OOP completely unused in extensions. Since PHP can easily call functions dynamically by name, and we have PEAR now, I consider the problem solved. No worse a hack than perl's OOP implementation, really. But I had other problems with OOP...
Pass-by-value: PHP4 would pass objects by value. Which is actually great if I want such value-type, but 99.9% of the time, I don't. What made matters worse was PHP's twisted notion of object identity -- it had no operator to test it. Equality comparison operators were always by value, and either "shallow" or "deep". I had to explain the concept of object identity, and for my trouble, got the '===' operator
Second-class-language attitude: I got choice responses from Zeev himself about how PHP is never intended to be more than a "web language" (apparently meaning limited to trivial scripting, because the web apps I use sure aren't trivial). PHP can be and has been used for powerful things, but I don't see writing a caching bulk DNS lookup service that tests against multiple RBL's using PHP if I can't get a serious contender to Net::DNS because PHP is "merely a web language" after all. I used Perl for that, then switched it to Python (stackless was ideal for this job) and then dropped it into the object publisher in mod_python. Painless. There is no such thing as a "web language", behind every web app there should be a *real* language.
Error handling: Nonexistent. Got an error, it would print a traceback to the output if you were lucky. Syntax errors would simply die without any useful diagnostic. No eval (well there is, but it would also just die on syntax errors). I've seen structured exceptions in C, but PHP's was awful. Awesomely brittle.
Hopefully PHP5 is migrating most of these warts away from PHP4. Perl certainly still has its own problems (mod_perl 2.0 is still not in a stable release state) so it's not too late for PHP among current perl users.
I've finally had it: until slashdot gets article moderation, I am not coming back.