Renaming this to "We stick with PHP because it's what we know" would eliminate the need for most of the post. I'm not saying it isn't a valid point, I'm just giving a TL;DR.
The other two, less emphasized, points are: it isn't as stale as everyone thinks and you can be as [un]successful with it as anything else.
These are three very common and legitimate arguments. However, both sides of the language wars tend to see things in absolutes. Experience can be an asset, just like it can be a liability. The chance that you'll recognize your own experience as anything but an asset are slim to none.
There may be another point: the author asserts PHP is just glue "between the front and the back" of a web application, I guess with the implication being that it's not really important. However, I don't believe the glue analogy is valid. Typically, the server-side scripting language implements the business logic, the real data structures (as opposed to what's being saved to DB) and a large part of the layout. That's not just the glue, that's pretty much the whole neocortex.
PHP has one advantage and it is that you can deploy it on most cheap hosting providers and it just works, you shouldn't solve deployment problems (like DB drivers) and pay more as with Rails, Python or Java.
Hey, what can I say, if it works out for you ... :)
EDIT - I guess I'm upsetting people :)
I've got nothing against PHP or other technologies. If it works out for you that's fine.
But a big error stacktrace on an article that tries to explain your decision, coming from that same platform you've chosen, giving away the directory structure of your website and even some implementation details?
Come on, that's like a security consultant getting hacked :-) At least put a custom HTTP 500 handler in Apache through the ErrorDocument directive. How hard is that?
"I often get asked by potential employees and clients, why we do PHP and mostly PHP only. A valid question, of course and my first answer usually is (besides the "historical reasons" one), that nowadays all those server side (scripting) languages are mainly the glue layer between the front-end (the browser part) and the back-end (your storage and "database" solution) and not the one and only defining factor if your project will be a success. Or not.
Python, Ruby, PHP, they all have their merits and disadvantages, but could all do the job equally well for our daily business. The important deciding factors happen in other areas nowadays.
But, why don't we use a "cooler" and "cleaner" language then, if it doesn't matter?
For one, as said, historical reasons. We invested a lot in PHP, our whole company has deep knowledge in PHP, we know what PHP can do and what it can't. We attend a lot of conferences, know people who can help and we can even influence where PHP is heading to (to some extend, of course). And if there's something missing or broken, we can try to fix it ourselves.
Then all our code is of course in PHP and reuse is highly important to us. There's still code from the early Flux CMS days in some of our latest projects. Not because we're too lazy to re-factor our code (we do that all the time), but just because it works, is tested and proven to work. We can profit from the work we did years ago and don't have to start from scratch.
"But PHP isn't very innovative lately" you may say. While that's true somehow for PHP itself and there is certainly some lack of roadmap and governance there, it's certainly not true what's currently happening in the so called "next generation framework" space. With Symfony 2, Flow 3, Lithium and certainly many others, there's a lot of innovation going on. I'm sure those will change the way we write well developed PHP projects. The people in those projects also talk together and try to make reusing components between them easier. No more "this is my framework island" stories. We live in a very exciting time here.
So while you may think that PHP is stalling, it maybe just matured enough to enable such great projects as mentioned above. Innovation in the PHP as a language space isn't badly needed anymore, the magic happens in the frameworks on top of it (ruby and rails have the same relationship, I guess).
But nevertheless, PHP isn't doing a full stop. PHP 5.3 brought namespaces and closures. PHP/Next (whatever the version number will be) will for example bring traits and even more speed and memory improvements. Stuff the frameworks can really make use of.
One last thing for us, why we stick to one language only, is that it was our strategic decision to concentrate us on as few technologies as possible, but to be as good as possible in them. Of course, we still constantly reevaluate new technologies and introduce them when they fit (we even have a written process for that, called "techmatrix" :))
This is for example why we use only Symfony 2 for all our new projects. You need very good reasons for using another framework. And as Symfony 2 has a similar mindset as our own "old" framework Okapi, the switch isn't too difficult (and we can reuse code). I ported liip.to from Okapi to Symfony 2 in a few hours (without knowing Symfony 2 very well) and could reuse lots of code.
Yes, PHP is just the glue between the front and the back (Jackalope is one prime example for that), but a very good one at that and I'm sure we will be very happy with PHP for the foreseeable future. With all what's going on in PHP-userland (compared to the PHP core), we currently live in a very exciting time. And I'm really looking forward to see the outcome of that. Don't write PHP off just now."
The op makes an extremely valid point: php works for his company. Clearly they're more concerned about the end result than the means through which it's accomplished. And isn't that the way it should be?
We're not talking about a freelance web developer here, who can easily experiment with different languages for each new project. It's a company with a large existing code base, which needs to function properly and, as it happens, so it does. Why throw all that in the bin just to be cool?
Remember, the op does say they experiment with other languages at the company. They have yet to find one whose advantages are amazing enough to be worth a complete rewrite of the company's code base. That's not unresonable. So why all the "they're just can't be bothered to change" comments?
To be honest in most of these mentioned languages you can reach the same goal. There is nothing you can't do with a language which can't be done in the other from the end user perspective.
But I have the odd feeling that while it is good to stick to a language (for strategic reasons) it is bad for improving code, getting better at what you are doing from a developer perspective. If I hadn't learned Python and wrote something in Python I would never be the same developer as I'm now.
When you look at for example Ruby and Rails there are so much better things you can do in the testing area. Ever used RSpec and Cucumber? You should know what I talking about. This is awesome stuff and it will let you develop a quality web app in days which is also fully tested.
What I'm trying to say is that YOU HAVE TO stay hungry as a developer about what is next BUT you should carefully choose what to you use in business. Looking at the same stuff (PHP) and going only to PHP conferences and hanging around only with PHP developer won't help you to get a better developer in the overall perspective.
Last but not least I want you to read Paul Graham's essays about Python people and why you will get better Python developer than any other:
I had read the Python Paradox 2 months ago and had agreed with it.
A month ago, I got a job at a company which uses Python. I had not used it before, for I am a PHP-guy. I learned Python because I wanted to get the job. I continue to use PHP for my own personal projects. Hence, I disagree with the statement "people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know."
I am actually quite satisfied with PHP - it is still my primary language choice, while I learn Python on the side.
I'm the op and that's what I just posted as a comment on the blog for all the (very constructive) input I got from here and on the blog itself:
*
Some comments to your comments (thanks for the feedback):
First: We don't stick to PHP just because we have invested so much in the past and can't easily change. We stick to PHP because we think it's actually good and as Jordi said: "Gets the shit done" and therefore still do invest a lot all the time in PHP. We know there are other solutions to the same problem and we're sure they are also very good, but we don't think they are better than our approach with PHP for our use cases.
And we don't hire the wrong people (because most of them are actually using PHP as well in their non-work time). We specifically try to hire the best PHP people available, we're heavily involved in the PHP community and from time to time one from those communities comes to work for us.If one would say "I love coding Python, but for money I'd do PHP as well" THIS would be the wrong person for a job here.
So, everyone saying we're just sticking to PHP for historical reasons got it backwards. We're sticking to PHP because we think it has a future and still investing in it is definitively worth it (that we have such a large "rucksack" of PHP code and knowledge is an additional advantage, not the only defining one)
If we would think "Ou shit, we have used PHP so much, it's actually shitty and we'd all like to code in python" then something would be very wrong with this company and I'd have to expect a mass-exodus all the time :)
And one last thing: We of course do use other technologies. The obvious ones like Javascript and HTML5 (we think more and more interesting stuff happens there than on the server side), mobile stufff with eg. Phonegap, content storage with jackrabbit, redis, varnish, etc etc... We also use rake and python stuff in some projects (mostly for CLI-scripting). And last but not least we're starting using node.js as well. That looks indeed very promising.
As someone who switched from PHP to Python, I don't understand why this is so controversial as a statement. I'd expect 58 comments on Reddit or Slashdot, not on HN. (Aware of the irony of commenting on this myself, but please forgive me the blasphemy)
TLDR is "It works for us, why shake things up?". Doesn't that fit the Startup ethos?
Python and Django work for me far better, but I often find mod_php and php allow you to prep quick "small scripts" for sites that are far more easily deployed than an equivalent in Python or Ruby. I wouldn't build a whole site in PHP anymore, but I can see how one might feel the ease in testing / deploying might yield benefits.
The most promising point in this article is that they're mentioning that the newer PHP frameworks are trying to work out how to make components reusable.
Most of the good (and 'modern') PHP code is 'jailed' in frameworks right now or quite hard to find, hidden away in github repos that aren't getting any attention. Really wish PHP had a central place for new libraries like rubygems, based on phar. (And yes, I know PEAR but that's not very PHP5 at all.)
> And yes, I know PEAR but that's not very PHP5 at all.
Symfony uses pear to distribute itself. You can get Zend from pear. PHPUnit does as well. Numerous other highly respected PHP libs use pear. Granted, they use their own distribution channels, like Debian. Pear isn't intended to be a central hub, but rather a distribution method. Couple with this Pyrus (http://pear2.php.net/) and Pear2, it's widely used by experienced PHP developers. Then you have pecl on top of that.
The problem isn't pear or pecl or any of that. It's that people don't bother to learn what's out there. They just associate pear with PHP4 and leave it at that. This carries over.
The other problem is that your average PHP devs build environment isn't as server based as it is for perl or ruby. Most PHP people just upload a file directly to the server and refresh the web page.
I imagine most people would be surprised by the number of really cool and interesting things going on in the PHP world, but because it's PHP, they elect not to learn about it.
> Most of the good (and 'modern') PHP code is 'jailed' in frameworks right now or quite hard to find
That's another misconception. I think it's hard for 'new' people to PHP to get a handle on everything, and I think their would be great value in pulling it all together. The problem is, the people that know about all this stuff aren't new, and we haven't really stepped back to look. However, most modern frameworks are easy to mix and match, and use only the parts you want from it. Their is obviously cases where it could be improved, and their is always a push to do this better.
PHP code as a whole seems to lend itself to tighter coupling, as you say with some framework stuff to get the advantage of some things you need to adopt the lot. It is probably rooted in the pre-PHP5 culture where there was a lack of language constructs to make things as reusable as you would like.
These are all very good reasons for why they should stick with PHP, and for anyone else who has already invested a lot into PHP. I think minimizing your server-side technology to "glue code" is a mistake, and there still needs to be a good deal of weight placed on that decision for new startups, based (as always) on the problem and the people. It would be a disastrous mistake for a company in their position to suddenly switch over to python or ruby this far into it. For projects that aren't already that deep into the hole, there are usually better options.
I'd like to see some posts on practical experiences in cases where there's enough perceived benefit in switching from LAMP to justify the effort. I have experience a generation back, moving from proprietary stacks, and learnt two contradictory things:
1. Re-engineering projects constantly fail the catch-up test (the legacy system picks up speed under threat)
2. Legacy systems kill great companies slowly but surely
In that contradiction you also have the startup gap - if your v1 does a tenth of the incumbent's v100 and you can pick up some market share, you can win on pace and focus alone.
"server side language is just a glue between the front end and the data source" is the stupidest part of this post. Rest is fine, as latch said that sticking with what people know best is not bad and probably does not need a blog post. :)
It's not true that "PHP isn't being innovative"; recently PHP has added closures and it's also addressed issues in static inheritance that have been completed ignored by C#, ruby, python, scala and such.
I think you'll find that the problem with "late static binding" is being ignored in Ruby, because it's an non-existing problem.
PHP - as a language - is certainly not innovative. That's OK though - The strength of PHP is low complexity and stability. Innovation can be a threat to these goals.
The article makes some excellent points with regards to not throwing out existing/working code and knowledge. There's quite a few good articles about the problems of full code rewrites.
Regarding the "glue" reference, given the increasing popularity of JS on the client-side and server-side this is clearly becoming more true. Beyond business logic of your app (the one area where PHP can hold you back on large projects) more and more code is moving to the client-side. For a small to mid-size web app, it's entirely possible to write everything on the client-side and use PHP only for DB / Model interactions (and there are some excellent MVC frameworks to help with that -- Kohana for example).
I don't even understand why there has to be a blog post about this. When you make a major investment in a technology you don't just wake up one morning and rewrite it using another one.
Thats how you lose money and your competitive edge ... I had a small PHP app that I transitioned to Ruby on Rails ... it took 2 months (mostly because I was doing it part time and was only just getting serious with Rails) and that whole time I was falling behind to a competitor because I wasn't adding new features and fixing bugs.
I'm glad I did it in the long run, but still ... rewrites to take advantage of the flavor-of-the-month technology can be very overrated.
Especially because if the main argument is that "it works" you're not discussing the merits of the language, you're simply stating that it's turing complete (yes, you can do "everything" with it) and that it works (HINT: whitespace works too - http://compsoc.dur.ac.uk/whitespace/).
Doesn't seem very good points to me, but some kind of catch all statement: if it works for you, why in the hell should I have to question it ? :)
IMHO, beyond a certain project size, rewrites never make sense. You can build a different product to serve the same market, but there's no cost/benefit case to be made for blindly rewriting on a different platform.
I don't think PHP is that good of a language to use for a glue from frontend to backend. Compared with Perl, Python, and Ruby, PHP is missing a number of important features; ability to serve multiple requests in the same OS thread (coroutines / events), ability to abstract the database in an OO way (do they even have prepared statements yet?), and so on. Its JSON parser is also slow, and JSON is how browsers and servers communicate now.
Anyway, not buying it. PHP's asset is "you get MySQL and templating for free in pages served by Apache", but most web apps don't use MySQL, templating, or Apache these days.
[PHP lacks] ability to abstract the database in an OO way
I would dispute that this is a requirement for a good language. Object/relational impedance mismatch is a well known issue. It doesn't matter in some apps, but it does in others. The ability to do database queries by means other than manipulating SQL as strings is kind of useful though.
most web apps don't use MySQL, templating, or Apache these days
There's some syntactic ambiguity in this statement. Are you saying that most web apps don't use any of those anymore? I think even in the world of brand new web startups, you'll find a majority using at least one of those.
> ability to abstract the database in an OO way (do they even have prepared statements yet?), and so on.
PHP keeps on changing; this has been in the PHP core for years.
> most web apps don't use MySQL, templating, or Apache these days.
I disagree, most apps still use MySQL, templating, and Apache. But there is a whole class of applications, things like real-time chat, that PHP cannot handle well because it's tied to Apache.
I guess in the end it's all about a companies culture and economically it boils down to "can I sell it". I want to add some random thoughts:
- Probably PHP wasn't your first language, you came from somewhere maybe Perl, maybe Java. There were reasons why you'ved switched.
- Is switching so hard? In my experience it is not! Good programmers are good programmers in every language. Get an expert to make your transition as smooth as possible.
- You do sell innovation - why not have an elite unit that can be with the new stuff. You can do 80% in your biz with stuff you know.
It seems to me that there are few reasons to switch from one scripting/dynamic language to another. One would be a compelling framework/library, the other would be performance. However, it seems that switching from Python to Ruby to PHP would amount to negligible performance differences if the code was well designed. Otherwise, if it were a problem of scale, then you would likely switch to something lower level/compiled me thinks.
I have yet to come across a compelling web framework written in php.
If re-use between projects was really of concern for their community, they would've pushed for a standard http interface like rack - which they haven't, aside from a couple of brief (largely ignored) experiments.
php is a necessary evil in some instances simply because some useful apps have been built with it.. but if I'm writing a web application from the ground up there's no way I would opt for php.
I rather like CakePHP (it's like ruby on rails, in PHP!(tm)).
While it maybe doesn't live up to it's RoR hype, it is a really solid framework, and has cut down on my development time by more than I can possibly express..
I find it alot easier to use than Symphony, and you can generally get a CRUD up and running in about 10-20 minutes right out of the box.
Feel free to check Symfony2 at http://docs.symfony-reloaded.org/master/ - it does not have much to do with symfony1 by the way, in case you'd decide to dismiss it due to past experience.
Explain why you think it is a "necessary evil", really, I'd love to know what insights you have that I somehow missed over the last 10years of developing successful large scale projects with PHP.
You may also want to email the likes of Facebook, Yahoo, YouTube, Digg etc etc and let them know of the evil that lurks within.
I would have agreed a few years back, but these days the amount of PHP code I write relative to the project size is small enough that there's no ROI to switch platforms, even for new projects. Most of the code I write is static javascript, and PHP exists only to load and save the business data.
That's also why all of those frameworks aren't very relevant to me. I have no use for server-side MVC because the server isn't involved in the application UI. I have no use for ORM, because building up an object structure in memory only to deflate it again into a web service response is often overkill. I do use Zend Framework, but I use it to simplify my transactional DB logic and to assist in bootstrapping the web services.
I just started using the CodeIgniter framework. It has a small footprint and doesn't try to include the kitchen sink (which is one of the reasons I stayed away from frameworks for so long).
What I really like about PHP is that the language is built in such a way that an exception isn't fatal, a page can still render. Just print out the exception or log it, and then continue on and try to render as much as possible. Like a fighter taking a hit but still fighting on, instead of going belly up like finer languages do.
"nowadays all those server side (scripting) languages are mainly the glue layer between the front-end (the browser part) and the back-end (your storage and "database" solution)"
[+] [-] latch|15 years ago|reply
The other two, less emphasized, points are: it isn't as stale as everyone thinks and you can be as [un]successful with it as anything else.
These are three very common and legitimate arguments. However, both sides of the language wars tend to see things in absolutes. Experience can be an asset, just like it can be a liability. The chance that you'll recognize your own experience as anything but an asset are slim to none.
[+] [-] Udo|15 years ago|reply
[+] [-] Egregore|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] bad_user|15 years ago|reply
http://farm6.static.flickr.com/5131/5472866239_05117cc8a4_b....
Hey, what can I say, if it works out for you ... :)
EDIT - I guess I'm upsetting people :)
I've got nothing against PHP or other technologies. If it works out for you that's fine.
But a big error stacktrace on an article that tries to explain your decision, coming from that same platform you've chosen, giving away the directory structure of your website and even some implementation details?
Come on, that's like a security consultant getting hacked :-) At least put a custom HTTP 500 handler in Apache through the ErrorDocument directive. How hard is that?
[+] [-] kitsune_|15 years ago|reply
http://blog.liip.ch/
"I often get asked by potential employees and clients, why we do PHP and mostly PHP only. A valid question, of course and my first answer usually is (besides the "historical reasons" one), that nowadays all those server side (scripting) languages are mainly the glue layer between the front-end (the browser part) and the back-end (your storage and "database" solution) and not the one and only defining factor if your project will be a success. Or not.
Python, Ruby, PHP, they all have their merits and disadvantages, but could all do the job equally well for our daily business. The important deciding factors happen in other areas nowadays.
But, why don't we use a "cooler" and "cleaner" language then, if it doesn't matter?
For one, as said, historical reasons. We invested a lot in PHP, our whole company has deep knowledge in PHP, we know what PHP can do and what it can't. We attend a lot of conferences, know people who can help and we can even influence where PHP is heading to (to some extend, of course). And if there's something missing or broken, we can try to fix it ourselves.
Then all our code is of course in PHP and reuse is highly important to us. There's still code from the early Flux CMS days in some of our latest projects. Not because we're too lazy to re-factor our code (we do that all the time), but just because it works, is tested and proven to work. We can profit from the work we did years ago and don't have to start from scratch.
"But PHP isn't very innovative lately" you may say. While that's true somehow for PHP itself and there is certainly some lack of roadmap and governance there, it's certainly not true what's currently happening in the so called "next generation framework" space. With Symfony 2, Flow 3, Lithium and certainly many others, there's a lot of innovation going on. I'm sure those will change the way we write well developed PHP projects. The people in those projects also talk together and try to make reusing components between them easier. No more "this is my framework island" stories. We live in a very exciting time here.
So while you may think that PHP is stalling, it maybe just matured enough to enable such great projects as mentioned above. Innovation in the PHP as a language space isn't badly needed anymore, the magic happens in the frameworks on top of it (ruby and rails have the same relationship, I guess).
But nevertheless, PHP isn't doing a full stop. PHP 5.3 brought namespaces and closures. PHP/Next (whatever the version number will be) will for example bring traits and even more speed and memory improvements. Stuff the frameworks can really make use of.
One last thing for us, why we stick to one language only, is that it was our strategic decision to concentrate us on as few technologies as possible, but to be as good as possible in them. Of course, we still constantly reevaluate new technologies and introduce them when they fit (we even have a written process for that, called "techmatrix" :))
This is for example why we use only Symfony 2 for all our new projects. You need very good reasons for using another framework. And as Symfony 2 has a similar mindset as our own "old" framework Okapi, the switch isn't too difficult (and we can reuse code). I ported liip.to from Okapi to Symfony 2 in a few hours (without knowing Symfony 2 very well) and could reuse lots of code.
Yes, PHP is just the glue between the front and the back (Jackalope is one prime example for that), but a very good one at that and I'm sure we will be very happy with PHP for the foreseeable future. With all what's going on in PHP-userland (compared to the PHP core), we currently live in a very exciting time. And I'm really looking forward to see the outcome of that. Don't write PHP off just now."
Oh the irony...
[+] [-] damncabbage|15 years ago|reply
(For reference: it's a very old, very deprecated DB abstraction library; it'd be like building GNOME apps with GTK v1.)
[+] [-] Seldaek|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] edw519|15 years ago|reply
http://en.wikipedia.org/wiki/BASIC
and absolutely eat their competitors' lunch with it.
It's not how big your tool is, but how you use it.
[+] [-] PedroCandeias|15 years ago|reply
We're not talking about a freelance web developer here, who can easily experiment with different languages for each new project. It's a company with a large existing code base, which needs to function properly and, as it happens, so it does. Why throw all that in the bin just to be cool?
Remember, the op does say they experiment with other languages at the company. They have yet to find one whose advantages are amazing enough to be worth a complete rewrite of the company's code base. That's not unresonable. So why all the "they're just can't be bothered to change" comments?
[+] [-] oemera|15 years ago|reply
But I have the odd feeling that while it is good to stick to a language (for strategic reasons) it is bad for improving code, getting better at what you are doing from a developer perspective. If I hadn't learned Python and wrote something in Python I would never be the same developer as I'm now.
When you look at for example Ruby and Rails there are so much better things you can do in the testing area. Ever used RSpec and Cucumber? You should know what I talking about. This is awesome stuff and it will let you develop a quality web app in days which is also fully tested.
What I'm trying to say is that YOU HAVE TO stay hungry as a developer about what is next BUT you should carefully choose what to you use in business. Looking at the same stuff (PHP) and going only to PHP conferences and hanging around only with PHP developer won't help you to get a better developer in the overall perspective.
Last but not least I want you to read Paul Graham's essays about Python people and why you will get better Python developer than any other:
http://www.paulgraham.com/gh.html
http://www.paulgraham.com/pypar.html
[+] [-] aDemoUzer|15 years ago|reply
[+] [-] chregu|15 years ago|reply
*
Some comments to your comments (thanks for the feedback):
First: We don't stick to PHP just because we have invested so much in the past and can't easily change. We stick to PHP because we think it's actually good and as Jordi said: "Gets the shit done" and therefore still do invest a lot all the time in PHP. We know there are other solutions to the same problem and we're sure they are also very good, but we don't think they are better than our approach with PHP for our use cases.
And we don't hire the wrong people (because most of them are actually using PHP as well in their non-work time). We specifically try to hire the best PHP people available, we're heavily involved in the PHP community and from time to time one from those communities comes to work for us.If one would say "I love coding Python, but for money I'd do PHP as well" THIS would be the wrong person for a job here.
So, everyone saying we're just sticking to PHP for historical reasons got it backwards. We're sticking to PHP because we think it has a future and still investing in it is definitively worth it (that we have such a large "rucksack" of PHP code and knowledge is an additional advantage, not the only defining one)
If we would think "Ou shit, we have used PHP so much, it's actually shitty and we'd all like to code in python" then something would be very wrong with this company and I'd have to expect a mass-exodus all the time :)
And one last thing: We of course do use other technologies. The obvious ones like Javascript and HTML5 (we think more and more interesting stuff happens there than on the server side), mobile stufff with eg. Phonegap, content storage with jackrabbit, redis, varnish, etc etc... We also use rake and python stuff in some projects (mostly for CLI-scripting). And last but not least we're starting using node.js as well. That looks indeed very promising.
[+] [-] jbm|15 years ago|reply
TLDR is "It works for us, why shake things up?". Doesn't that fit the Startup ethos?
Python and Django work for me far better, but I often find mod_php and php allow you to prep quick "small scripts" for sites that are far more easily deployed than an equivalent in Python or Ruby. I wouldn't build a whole site in PHP anymore, but I can see how one might feel the ease in testing / deploying might yield benefits.
[+] [-] scott_s|15 years ago|reply
[+] [-] soulclap|15 years ago|reply
Most of the good (and 'modern') PHP code is 'jailed' in frameworks right now or quite hard to find, hidden away in github repos that aren't getting any attention. Really wish PHP had a central place for new libraries like rubygems, based on phar. (And yes, I know PEAR but that's not very PHP5 at all.)
[+] [-] jasonlotito|15 years ago|reply
Symfony uses pear to distribute itself. You can get Zend from pear. PHPUnit does as well. Numerous other highly respected PHP libs use pear. Granted, they use their own distribution channels, like Debian. Pear isn't intended to be a central hub, but rather a distribution method. Couple with this Pyrus (http://pear2.php.net/) and Pear2, it's widely used by experienced PHP developers. Then you have pecl on top of that.
The problem isn't pear or pecl or any of that. It's that people don't bother to learn what's out there. They just associate pear with PHP4 and leave it at that. This carries over.
The other problem is that your average PHP devs build environment isn't as server based as it is for perl or ruby. Most PHP people just upload a file directly to the server and refresh the web page.
I imagine most people would be surprised by the number of really cool and interesting things going on in the PHP world, but because it's PHP, they elect not to learn about it.
> Most of the good (and 'modern') PHP code is 'jailed' in frameworks right now or quite hard to find
That's another misconception. I think it's hard for 'new' people to PHP to get a handle on everything, and I think their would be great value in pulling it all together. The problem is, the people that know about all this stuff aren't new, and we haven't really stepped back to look. However, most modern frameworks are easy to mix and match, and use only the parts you want from it. Their is obviously cases where it could be improved, and their is always a push to do this better.
[+] [-] robryan|15 years ago|reply
[+] [-] kingofspain|15 years ago|reply
[+] [-] smokestack|15 years ago|reply
[+] [-] jdap|15 years ago|reply
1. Re-engineering projects constantly fail the catch-up test (the legacy system picks up speed under threat)
2. Legacy systems kill great companies slowly but surely
In that contradiction you also have the startup gap - if your v1 does a tenth of the incumbent's v100 and you can pick up some market share, you can win on pace and focus alone.
[+] [-] mnazim|15 years ago|reply
Just my thoughts!
[+] [-] PaulHoule|15 years ago|reply
[+] [-] troels|15 years ago|reply
PHP - as a language - is certainly not innovative. That's OK though - The strength of PHP is low complexity and stability. Innovation can be a threat to these goals.
[+] [-] neovive|15 years ago|reply
Regarding the "glue" reference, given the increasing popularity of JS on the client-side and server-side this is clearly becoming more true. Beyond business logic of your app (the one area where PHP can hold you back on large projects) more and more code is moving to the client-side. For a small to mid-size web app, it's entirely possible to write everything on the client-side and use PHP only for DB / Model interactions (and there are some excellent MVC frameworks to help with that -- Kohana for example).
[+] [-] trustfundbaby|15 years ago|reply
Thats how you lose money and your competitive edge ... I had a small PHP app that I transitioned to Ruby on Rails ... it took 2 months (mostly because I was doing it part time and was only just getting serious with Rails) and that whole time I was falling behind to a competitor because I wasn't adding new features and fixing bugs.
I'm glad I did it in the long run, but still ... rewrites to take advantage of the flavor-of-the-month technology can be very overrated.
[+] [-] stylejam|15 years ago|reply
[+] [-] Joeri|15 years ago|reply
[+] [-] jrockway|15 years ago|reply
Anyway, not buying it. PHP's asset is "you get MySQL and templating for free in pages served by Apache", but most web apps don't use MySQL, templating, or Apache these days.
[+] [-] Zak|15 years ago|reply
I would dispute that this is a requirement for a good language. Object/relational impedance mismatch is a well known issue. It doesn't matter in some apps, but it does in others. The ability to do database queries by means other than manipulating SQL as strings is kind of useful though.
most web apps don't use MySQL, templating, or Apache these days
There's some syntactic ambiguity in this statement. Are you saying that most web apps don't use any of those anymore? I think even in the world of brand new web startups, you'll find a majority using at least one of those.
[+] [-] wvenable|15 years ago|reply
PHP keeps on changing; this has been in the PHP core for years.
> most web apps don't use MySQL, templating, or Apache these days.
I disagree, most apps still use MySQL, templating, and Apache. But there is a whole class of applications, things like real-time chat, that PHP cannot handle well because it's tied to Apache.
[+] [-] 9elements|15 years ago|reply
- Probably PHP wasn't your first language, you came from somewhere maybe Perl, maybe Java. There were reasons why you'ved switched. - Is switching so hard? In my experience it is not! Good programmers are good programmers in every language. Get an expert to make your transition as smooth as possible. - You do sell innovation - why not have an elite unit that can be with the new stuff. You can do 80% in your biz with stuff you know.
[+] [-] zarski|15 years ago|reply
I agree. Front end work is dominating my time in web app. development. Server side is getting less important day by day.
[+] [-] S_A_P|15 years ago|reply
[+] [-] AffableSpatula|15 years ago|reply
If re-use between projects was really of concern for their community, they would've pushed for a standard http interface like rack - which they haven't, aside from a couple of brief (largely ignored) experiments.
php is a necessary evil in some instances simply because some useful apps have been built with it.. but if I'm writing a web application from the ground up there's no way I would opt for php.
[+] [-] harisenbon|15 years ago|reply
While it maybe doesn't live up to it's RoR hype, it is a really solid framework, and has cut down on my development time by more than I can possibly express..
I find it alot easier to use than Symphony, and you can generally get a CRUD up and running in about 10-20 minutes right out of the box.
[+] [-] Seldaek|15 years ago|reply
[+] [-] xd|15 years ago|reply
You may also want to email the likes of Facebook, Yahoo, YouTube, Digg etc etc and let them know of the evil that lurks within.
[+] [-] Joeri|15 years ago|reply
That's also why all of those frameworks aren't very relevant to me. I have no use for server-side MVC because the server isn't involved in the application UI. I have no use for ORM, because building up an object structure in memory only to deflate it again into a web service response is often overkill. I do use Zend Framework, but I use it to simplify my transactional DB logic and to assist in bootstrapping the web services.
[+] [-] OstiaAntica|15 years ago|reply
[+] [-] bergie|15 years ago|reply
[+] [-] rick888|15 years ago|reply
[+] [-] FreebytesSector|15 years ago|reply
[+] [-] sunkencity|15 years ago|reply
[+] [-] markbao|15 years ago|reply
"nowadays all those server side (scripting) languages are mainly the glue layer between the front-end (the browser part) and the back-end (your storage and "database" solution)"
Sorry, what? Maybe if you're writing CRUD apps...
[+] [-] kingofspain|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]