I haven’t given up on PHP — yet(phpadvent.org)
phpadvent.org
I haven’t given up on PHP — yet
http://phpadvent.org/2008/yet-by-marco-tabini
8 comments
Kind of like "cease and desist"? Doesn't cease have the same meaning as desist?
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. ;)
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. ;)
After some googling I found something:
http://plover.net/~bonds/genderedlanguage.html
"... 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... "
"... 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... "
Most style guides have something like the following:
(taken from Princeton's style guide)
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.
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.
PHP is a tool. Just like all other programming languages. If PHP can be used to solve your real-world problems then okay - Go for it. It's free, easy to use, the documentation is the best there is And lots of frameworks to choose from. If not, then use something else. But for me, after a few years of coding PHP, I haven't had anything that PHP can't do for me (in terms of web development). Especially these days that Code Igniter, Zend Framework and the likes are going more mainstream...
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
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
Summary: PHP is cluttered, people like to bitch about it but use it anyway, sometimes frameworks are good. The 'yet' is merely a weak thread through the vague, obvious noise. I want my 10 minutes back.
As an insider, it’s actually funny to see endless discussions on newsgroups or the latest PHP-bashing entry on the Slashdot-of-the-day web site where people who aren’t familiar with our platform disdain its ludicrous awkwardness while marveling at its popularity.
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.
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.
Could you name reasons why it was a costly mistake for you? Were there scaling problems or issues with maintaining existing code? I'm not trying to protect php, just curious.
PHP's main flaw from my point of view is its ugliness. It's almost impossible to distinguish bad code from good code. All of it looks equally bad (well, some of it looks even worse).
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.
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.
In my case, learning PHP before learning a language that (regardless of the language) was embraced by a more best/interesting-practices-oriented community would have helped me enjoy programming sooner.
If there were a product statement for PHP, it’d probably be something like "only a drunken Martian could come up with this."
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.
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.
Does PHP as a language have any qualities not found in other languages?
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.
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.
3. Before the designers grafted in objects, PHP was definitively not Java. It had one data structure, the array(). (I won't go so far as to call it a simple data structure, because its semantics are kind of nutty, but it's a lot simpler than the Java class system.) You can go very far in PHP without having to know what a class is.
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.
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.
I agree, coding in PHP is far less enjoyable now that the language is, in my opinion, polluted with Java-esque object orientation. Most new code that I come across nowadays feels horribly overengineered. Objects are a good thing when used sparingly, but PHP never needed design patterns to be viable. Drupal is a perfect example of robust, modular software that doesn't need verbose object syntax.
Also, very good user-annotated documentation (I don't know if this is still so, but it was when I started PHP) and a lot of existing code/libraries/applications (of varying quality) that you can use.
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).
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).
and a lot of existing code/libraries/applications (of varying quality) that you can use
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.
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.
That's the thing - the choice isn't between languages, but between tools. For example, having a lot of libraries is not strictly a language feature, but it does effect choosing one over the other.
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.
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.
That's the thing - the choice isn't between languages, but between tools. For example, having a lot of libraries is not strictly a language feature, but it does effect choosing one over the other.
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.
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.
1. Everything's a template.
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.
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.
You're forgetting the popularity of cheap shared hosting plans. PHP is offered on many hosting plans for $10 or less dollars a month and "just works" in that you upload a PHP file and it works with zero extra configuration. Most cheap hosts don't offer this low barrier to entry with Python, ASP, ASP.NET, RoR, etc.
I'm fully aware of this, but that can hardly be accounted for as a feature of the language itself, which was what I was asking about.
> Out of my mind I can think of perl, python, asp and asp.net which offers similar ease.
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.
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.
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.
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.
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.
[deleted]
PHP definitely has its flaws and lack of conventions but for me that is what makes it beautiful. It's a language which has allowed me to grow as a developer over the years. If I look back at how I structured and wrote my code when I first started it's nothing close to how I code now. Since PHP allows so many different variations I didnt have to conform to one style but instead developed my own. If I would have chosen a different language to start with I am quite sure I would have given up on programming quickly. PHP has allowed me to learn from my own mistakes and create my own unique way of solving problems.
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.
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.
10 years ago I wrote my first web application. I was hooked. The ability able to write an app that ran anywhere in the world was magical. My journey since has led me to PHP4 and the LAMP stack, away to C++ and Java and back to PHP5, away to C#, Scheme, and Python, and again back to PHP5.
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)
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)
Controller route prefixing seems suspicious. Do you include every controller at runtime and use php reflection with some regular expressions to parse all of their prefixes only to figure out what single route to use?
In development mode, yes. We look at every controller and form a routing tree.
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.
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.
I have to second how well frameworks like CodeIgniter can help developers progress into cleaner code. Those modern tools discourage tightly coupled PHP code and they feel almost like an entirely different language. If you find that you can't stand PHP, you might want to take another look at these-- you'll find the code a refreshing difference from traditional "raw PHP" websites that people hack together early when they're learning.
PHP is already extremely slow (slower than Ruby! (which is slower than Prolog!)).
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.
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.
Please back this claim with evidence. There are many things wrong with PHP. Performance is not one of them...it's very quick.
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...
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...
Bullshit, you linked to rankings (one where PHP's wart is omitted), not results, and your 'faster machine' is many times slower. It's not really so simple:
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.
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.
"writing your own high-level PHP inside PHP"
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.
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.
> 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.
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.
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.
That's a load of FUD and a fabricated horror story. Computationally intensive business logic should be implemented as a C/C++ extension in any case because PHP is still essentially a web language and a glue language. Rasmus Lerdorf, PHP's creator, has stated as much.
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.
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.
But as soon as you get into building extensions to mod_php, you've lost everything that's great about PHP: the deployment story / execution model.
And if you have the capability and good reasons to build your own extensions, deployment probably isn't much of a concern. But building and loading extensions into PHP is not very difficult, assuming dependencies are already met.
Well, I think you completely missed my point, since I didn't anywhere say that PHP can't scale in the sense you are talking about.
While we're at it, PHP is pretty bad for desktop GUIs and artificial intelligence...
blasdel > but on the meteor contest (which is the alioth people's favorite)
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)
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)
In many ways, PHP is itself a framework. Only an idiot would make a high-profile website using ZF or CakePHP. Good luck using straight Ruby for a website.
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.
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.
[deleted]
thomasmallen > Proportional results on a faster machine...
What makes you think an old Pentium 4 machine is faster than a quadcore Q6600?
What makes you think an old Pentium 4 machine is faster than a quadcore Q6600?
I assumed the units to be in seconds, but after looking closer, I can't find a good definition of the units used here. It's the mean of a series of ratios, but the base unit is not on this page. A combination of the lower totals and the fact that one machine was running Gentoo led me to believe that this machine was the faster of the two. (End backtrace of my thoughts)
thomasmallen > A combination of the lower totals
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
!
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
!
If the results are proportional between trials and are well-accepted (which these seem to be), I'll admit that I'm less interested in the specifics. If I saw aberrations, I would dig deeper, and I'll admit that my analysis was not rigorous.
I started programming when I was 12 and sadly my path to PHP looked something like this:
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.)
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.)
My evolution is like this:
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?
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?
Or perhaps humans are lazy by nature and, since PHP does a very bad job of keeping us in line, the less disciplined of us end up writing bad PHP code. Of course, if we don't know how to write good code to start with, it's not PHP's fault. I think the simple fact that you can write good, elegant PHP code goes to show that it simply demands a more disciplined programmer (or a framework to help with that discipline).
As someone who mainly write (and get to maintain) C# code these days, I have to say C# (nor any other language I've seen) sadly doesn't stop people from writing utter shit code.
It does no doubt seems more prominent in the PHP world though.
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?