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?"
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.
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.
I can vouch that, to the extent that I've been trying it, all of my PHP4-developed code has been working fine with the PHP5 interpreter so far. As andig suggests above, I suspect that only a few cases where someone relies heavily on 4.x "quirks" will cause a problem.
I was slightly disappointed to find that the "native Java/PHP integration" support was quietly dropped from PHP5 - I'd been wanting to play with that. Oh well.
Hacker Public Radio is our Friend
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.
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).
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.
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.
Ruby is basically a superset of Python and Perl.
;-)
If you've ever been programming Python and wished it was cleaner and less "arbitrarily verbose", you'd like Ruby. If you wonder why Python arbitrarily makes you say "len(str)" instead of "str.len()", you'll like Ruby. If you wonder why Python makes you type "def foo(self)" instead of just "def foo", you'll like Ruby. If you wonder why you should type verbose hard-to-read stuff like "[f for f in n if f < 4]" instead of something like "n.each { |f| f<4 }", the give Ruby a whirl.
If you ever programmed Perl and wished it had an actual object model, so you don't have to do stuff like "UNIVERSAL::isa($val, 'FooClass')", but can just treat each variable the exact same way like "foo.kind_of? Integer" you'll like Ruby. If you hate how Perl lets you make objects that are hashrefs OR arrayrefs OR scalarrefs, making extension of existing classes utter madness, you'll like Ruby.
If you like adding your own methods to base types like Arrays, Hashes, Integers, etc., you'll just go nuts with Ruby.
If you like distributed programming you'll get a kick out of DRb (comes with Ruby).
Do you need extended your languages with external C libraries? You will positively, absolutely shit yourself three times when you try out Ruby/DL, which lets you extend Ruby with arbitrary C libraries at run time without any compiling or setup.
If you wonder why Java takes 3-5 lines of code just to parse an XML file or set up a loop you will find Ruby quite a change. And REXML is the most lightweight easy to use XML parser I've ever used (PHP5's new parser comes *close*.. but PHP is not Ruby).
If you like writing code FAST without worrying about heavy syntax or arbitrary design choices, you'll like Ruby. If you like passing anonymous code blocks to your functions like SmallTalk, you'll get a kick out of Ruby (and if you don't do that, learn, it will make your programs tighter). If you are into agile programming and merciless refactoring, you'll like Ruby (unless you are a lover of lisp macros, then you'll find Ruby blocks a little limiting, can't help you there).
If you use a Mac you'll like it because Ruby is pre-installed.
If you do MVC-type web apps, your mouth will hang open when you use the highly dynamic Ruby on Rails (how do you add a new object to your app when you add a new database table? ONE LINE OF CODE. How do you add a new field to your object when you add a new column to the database? DO NOTHING.)
Ruby is the only language I can say with a straight face is "beautiful" AND useful.
So unlearn a couple of those languages and try Ruby!
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. --