I haven’t given up on PHP — yet
phpadvent.org
phpadvent.org
Besides how I feel about it; it's been great for all the projects I've worked on and now for the first time I'm using a framework (Codeigniter) for my startup and it's proving to be even more solid and progressing my style even more.
I believe PHP code is as good as its developer. Like mentioned in the article; you can paint a mess or a masterwork, all the colours and brushes are there.
The truth is I have a love-hate relationship with PHP. The linguist in me abhors PHP sprawl and the pragmatist in me adores PHP’s simple execution model and practical ubiquity.
Upon returning to PHP this September it felt both familiar and unsettling. The feeling of returning to the town you grew up in. Frameworks, like familiar faces, looked the same as when you last saw them just heavier and a bit more mature. Nowhere as spectacular as the framework heroes of other towns like of Pythonville or Rubyfordton. City council was still making unorthodox decisions like enforcing backslashes for namespaces. Yet downtown was booming- many of the greatest internet successes of the world had since established themselves here: Facebook, Flickr, Yahoo!, and others.
So I set out to create an open source framework called "Recess!" which will be available on GitHub in preview form "any day now".
I just recorded its first screencast that dives into how it Recess! handles routing. Interested to hear your thoughts:
http://www.recessframework.com/screencasts/routing/index.htm...
(disclaimer: the flash video may be slow to load - until which you'll see an empty black page)
In deployment mode that routing tree is serialized and cached. Only a single (matching) controller is then touched. Unserializing the data structure is extremely fast and finding a match is roughly an O(log n) operation.
Using a pure-PHP framework (a template system built in a templating language) leads to pitiful rock-bottom performance -- orders of magnitude slower than any of the popular templating systems that exist for Perl, Python, or Ruby.
I'll start: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...
Don't sweat it, Ruby's only 50% slower!
Proportional results on a faster machine: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
They go back and forth, but on the meteor contest (which is the alioth people's favorite) Ruby's delta is 260, while PHP's is 36,117 (!!)
My main point was that templating frameworks written in PHP are WAY slower than using PHP directly, as you're doing a ton of pointless string operations. Benchmarks back this up, even ROR is >= the PHP frameworks (especially when there's no opcode cache): http://www.avnetlabs.com/php/php-framework-comparison-benchm...
PHP is really fast when you use it as a straight templating system, but once you start writing real applications in it, writing your own high-level PHP inside PHP, it is the slowest thing around.
If you're smart, like smarty, you'd compile your high-level PHP into PHP and then you're not doing a ton of pointless string operations.
This is what I find most people underestimate about PHP - it scales badly in a slightly unique sense: it scales badly with application size. The problem is incremental and therefore hard to deal with.
You start off with one small PHP file. It's wicked fast! 3 months later you have a dozen PHP files and most of them include some common library scripts that are shared between them. It's still fast. A year later your library scripts have grown and grown. Each PHP file is now including 4 - 5 library scripts and those themselves are getting up to thousands of lines long. You try to refactor things but the problem is PHP is such a dynamic and loose language and has such poor abstractions that it's really hard to do that successfully. So soon just to spit some HTML on the page your poor application is interpreting thousands of lines just to render some simple HTML. You look at FastCGI but your cheap web host doesn't support it and then you realize that there are a host of compatibility issues on top that you never thought about when you started that will cause problems.
By the time it is mature your PHP application is slow because it is spending all its time parsing the thousands of lines of poorly structured PHP and very little actually rendering HTML.
Finally, you look at PHP accelerators like Zend etc. and realize that you're going to have to pay for a commercial solution and the free stack you thought you were building with is not actually free any more and you see that even then there are a bunch of compatibility problems. And then you wish you had built with python ... or java ... or groovy ... or ruby ... or anything else but PHP.
It's the poor support for modularization and abstraction combined with the interpreted nature of the language that leads to this.
Any claim that PHP can't scale is at this point a dead letter, as are more dated claims that Java is too slow, etc.
Which of the "alioth people" told you the meteor contest was their favourite?
blasdel > you linked to rankings (one where PHP's wart is omitted), not results
If it's their favourite then why do you think "the alioth people" don't include meteor contest in their ranking?
Yes, compare language implementations directly one-against-another for all the benchmarks.
As thomasmallen is so keen on the old Pentium 4 machine, compare PHP with Ruby Core 1.9.0 ;-)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...
(Disclaimer - Obviously the benchmarks game webpages are written in PHP)
Please don't force me to link to some of Terry Chay's work. There's a very good reason that PHP is used for many high-profile websites whereas Ruby is not.
What makes you think an old Pentium 4 machine is faster than a quadcore Q6600?
Don't you need to know about the numbers that make up those totals?
Like if on Pentium 4 the nbody input value is 20,000,000 but on Q6600 the nbody input value is 50,000,000 ...
thomasmallen > the fact that one machine was running Gentoo led me to believe that this machine was the faster
!
QBasic -> Visual Basic -> HTML/CSS -> PHP
C -> Bash -> Java -> HTML/CSS -> PHP
After 15 years, I'm finally putting in the time to learn the language I should have started with: C. I really wish it was the first language I learned because it would have made learning other languages so much easier (and learning those other languages would have made me a much better PHP programming when I started using it).
I believe every language has its uses and PHP is no different. While its a shame there is so much crappy PHP code out there, open-source projects like WordPress have shown it has its place. (If WordPress themes and plugins were not so easy for non-programmers to learn how to create and modify, I don't think WordPress would be where it is today.)
Pascal (object oriented) -> C++ -> C# - > PHP
Despite a reasonably strong background in developoing software, I've found it way too easy to build crappy code in PHP. But, I think it's as much me as it is PHP.
Perhaps PHP brings out the evil that is lurking inside of us as programmers?
It does no doubt seems more prominent in the PHP world though.
"... did so specifically to solve his or her immediate problem in a manner that catered to his or her unique needs ..."
I understand that speaking/writing like that you come across as a super-cultured, modern liberal or whatever, but am I the only one who finds this bastardization of English awkward? I've learned this language about 8 years ago at the age of 23 (relatively recently) and even then it wasn't so crippled by such idioms, and to this day every time I stumble upon a sentence like that, it pings my ear, kinda like seeing "chickenfucker" in the middle of Declaration of Independence, totally out of place, out of context.
Does anyone else feels this way?
I read that the legal doublespeak comes from English roots. When the Anglos and Saxons had to start getting along, their lawyers had to use a word from both languages. Big [citation needed] here, so I hope someone obliges. I'd love to know the truth.
But back to "his or her." I often use simply "her," to be both consise and politically correct. ;)
"... The problem is that in the English language, the "traditional" gender-neutral form -- "his" -- happens to be the same as the masculine form. And to say or imply that an arbitrary or unknown person must be male, as those who use "his" are claimed to do, is discriminatory... "
Don't say “he” when referring to an unspecified person. Instead, recast the sentence into the plural, or avoid the use of pronouns altogether.
Example: Each student is expected to turn in his paper by the deadline. Better: Students are expected to turn in their papers by the deadline.
I'm very familiar with PHP. I built my first start-up on it, and it was a costly mistake. I know PHP very well and loathe it for many good reasons.
I think the author should try giving up on PHP now. He may well find that the world seems like a better place after that step.
The downside of that is that you don't get the automatic "bad feeling" when you put in a hack. It just doesn't stand out like a sore thumb (like it would in Ruby), so it's very easy to ignore the hack. Since PHP is an extremely hack-friendly language, where it is very easy to take damaging shortcuts, and it lacks the feedback mechanism to make you aware of when you've taken a bad shortcut, every large PHP project seems to eventually end up the same: a monstrous pile of hacks, one uglier than the other.
I don't have that problem with Ruby at all, for the record. Ruby is very hack-friendly too (even more so than PHP), but because of its natural elegance, whenever you do something plain bad it is immediately visible and remains so until you clean after yourself.
I could talk about all the cruft in the global namespace, the lack of consistency in the API, the appalling OO implementation, the lack of a super-successful framework like Rails... but ultimately, what bothers me is the result of all those problems: ugly code that keeps getting uglier.
Why did ugly code bother me with my first start-up? Because it is hard to care for ugly code. Once your beautiful start-up's code turns into a pile of spaghetti, you start to wish you were doing something else. And that's a pretty bad place to be when you are the sole maintainer of your start-up's code. It won't stop you from ploughing on - but it will slow you down a lot, and you don't need that when you're a start-up.
EDIT: just wanted to add that I have been wanting to use Tools like Ruby on Rails, but when I think of it -- it is so much easier to do this and that in PHP.
i have read books on RoR, etc. but haven't find the time to implement on a real-world project yet. maybe it's just me or that i'm too lazy :D
I know I'm pretty much stating the obvious, but this is the problem that will keep PHP cemented in its current state for years and years.
Like everyone knows, and like stated in the post, PHP is riddled with inconsistent naming-convetions for functions, inconsistent parameter-order and inconsistent functional behaviour. Let's also not forget how 99% of the functions in PHP are "binary safe", like treating text like binary data is a good thing. There is code out there working on binary data and relying on string-operations to work properly.
Let us for a second assume the PHP developers are actually capable of making good and thought trough decisions and just ignore that whole backslashed namespaces incident.
If the PHP developers were to address the inconsistencies of the language and actually standardize on something, even with some decent refactoring-tools, this would still be a rather big undertaking and would no doubt lead to more bugs in the core framework until all the itches get sorted out.
And for what? PHP is well known for causing applications to break between releases, but intentionally breaking and crippling all PHP code in existence? They might as well give it a new name and release it as something different than PHP all together.
But why would anyone actually bother to do that? Does PHP as a language have any qualities not found in other languages? Does PHP, besides existing codebase which in this case would be a moot point, offer anything which isn't already offered everywhere else?
For PHP to solve its problems they would have to abandon the only thing which support it as a platform. I postulate that PHP, in its current shaky state, is the way PHP will remain for as long as it is considered relevant.
Yep.
1. Everything's a template. This is a double-edged sword.
2. mod_php is stupid simple. Makes deployment is a cinch.
I'll update this list if I think of others, but these two are a boon for new and impatient developers alike.
Now that every schooled developer has been exposed to Java ad nauseum we're all blind to the fact that OO is not at all intuitive. You've got to keep a bunch of abstract hierarchies in your head simultaneously. (Classes can inherit from other classes; objects are instances of classes; objects can contain other objects.) You've got to learn a bunch of odd semantics. (Constructors look like functions but are called by the new operator. Destructors never get explicitly called at all. There's static members and public members and private members.) Then you've got to know how to use objects properly or you'll just make a mess; that involves learning a moderate amount of OO theory or reading one of those doorstopper-sized patterns books. As every DailyWTF reader knows, even a lot of ostensibly-trained professional developers do not actually understand this. It's a lot to ask of a person who just wants to learn how to rearrange the widgets on their Wordpress blog.
There are, of course, a few other languages that don't impose OO on people at time zero, so this is hardly a unique feature of PHP. But it is a feature. Or it was, anyway... PHP now has a tacked-on object system that is vaguely reminiscent of Java.
The value of PHP is not in the language itself, but in the fact it is easy to pick up and easy to deploy. This often causes people with strong coding background to dismiss PHP, but empirically it seems most people care a lot more about easy deployment than, say, closures or namespaces (or even consistent function naming).
My question was what qualities PHP has on its own, as a language, which would merit keeping it around if the language were to be cleaned up and break compatibility with that existing code.
easy to deploy
I also wouldn't say ease of deployment in PHP is in any way unique or easier than deploying for instance perl or python. Heck, even super enterprisey Asp.net can do with the same simple deployment procedure as PHP has.
On its own, as a language, PHP doesn't have much going for it. You can clean up PHP and break compatibility, but then you've lost much of its value (and what you'd get wouldn't be better than Ruby or Python anyway). I'd bet most PHP users don't even know PHP, they just install Wordpress or Drupal to run their site and maybe modified some templates etc.
As for deployment, it's easier because it's already there. Almost all hosting companies support it. Most (I think) Apache installs have it on (or easily activated) by default. This is the reason other languages don't have anything comparable (in popularity, not in features) to the above CMS.
I'm not going to be stupid enough to deny this, but my argument was that PHP as a language doesn't offer anything unique, so if they were to actually clean it up and break all compatibility there would no incentive to move to this "new" cleansed PHP platform as opposed to existing, better languages and platforms.
You are pretty much in agreement with my original statement.
Hardly unique. Microsoft's (now deprecated) ASP had this. ASP.Net can also be treated like this if this is desired, although most of the time it isn't.
2. mod_php is stupid simple. Makes deployment is a cinch.
As I have mentioned in another reply, the easy of deploying PHP solutions is hardly unique. Out of my mind I can think of perl, python, asp and asp.net which offers similar ease.
In fact it can be argued that PHP's problematic compatibility betweens, dependency on server-settings and other similar less predictable parameters when deploying on a random hosting service makes PHP deployments more problematic than those mentioned above.
My experience with Asp.net would lead me to believe that Asp.net deployments are just as easy and can be done much more reliably without encountering deployment issues.
Back in the day, Damon Courtney and I created mod_rivet ( http://tcl.apache.org/rivet/ ), which utilizes Tcl. It was very fast, because it cached the byte-compiled versions of scripts/pages in memory. It also let you do either template pages (.rvt) or pure Tcl files (.tcl), so you could construct things in a slightly nicer way than all templates all the time.
ASP is not supported, so throw that out. And every language with template engines built for it can be treated like this; that doesn't prove anything.