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.
"To me, the only significant aspects of Web development are data model, SQL queries and transactions, and page flow design. The rest is just glue code that marries HTML templates to information pulled from the database."
> I guess with the implication being that it's not really important.
You'd guess wrong then. The implication isn't that it's not important. Rather, that it's not important to the resulting web page. That the web page is written in Ruby or Python or Perl. This isn't to say that what inside doesn't matter to those working with it.
To provide a comparison: I don't care if a game uses C, C++, Objective-C, Java, etc. I care about the end result.
At least, that was my understanding of what was written.
> Rather, that it's not important to the resulting web page. That the web page is written in Ruby or Python or Perl.
Without going into a pointless flamewar about the definition of important, and what the author possibly meant as opposed to what was actually written, I believe the choice of technology stack does indeed influence the outcome of the project in many ways. But that's not really the point here at all. The author's assertion that PHP is "just" a glue component simply doesn't reflect the amount of heavy lifting done by it.
> I believe the choice of technology stack does indeed influence the outcome of the project in many ways.
Project.
> Rather, that it's not important to the resulting web page.
Web page.
I was merely referring to the HTML that gets sent to the browser. I wasn't suggesting that the technology being used doesn't affect the project.
> The author's assertion that PHP is "just" a glue component simply doesn't reflect the amount of heavy lifting done by it.
I just said I think you are reading too much here, and inferring things the author never intended, especially considering the context of the article, especially around the part being referenced.
I agree, it's useless to speculate. So, maybe you should focus on what's being said rather than putting your own spin on it? =)
> So, maybe you should focus on what's being said rather than putting your own spin on it? =)
This is the second time you used language designed to escalate this into some kind of personal attack. Why? Simply say you disagree and move on. (I even modded you up the first time.) It's not like one of us has a huge thesis to defend here. It's a minor point about a minor article.
> This is the second time you used language designed to escalate this into some kind of personal attack.
I've done no such thing. I've stated clearly my opinions. If you feel offended by my opinions, I apologise. That being said, I don't preface everything I say with weasel words.
I personally believe doing this (though you might disagree and if you do that's fine) that weasel words are mostly useless (though they do help at times for people who infer more than intended) and I really try to avoid using them as much as I can, though I have been known to fail at this. =)
> Why?
I haven't intended to do this. I didn't "design" anything. At most I felt that the previous statement could have been taken the wrong way, hence the smiley (Which is basically my way of saying I don't intend to start a flame war). You were, in fact, putting your own personal spin on things rather than discussing what was actually said.
I'm not offended, I just felt the discussion was taking an unnecessary turn towards the unproductive side, about a point that is simply not worth the effort we both have so far unwisely invested into this exchange ;-)
I do believe "weasel words" are important, not only because stating personal opinion as fact is impolite, but mainly because it can be vital for the structure of an argument to distinguish possibilities, speculation, belief, theory, and factual data.
Of course the result is what matters. But hypothetically, if you can throw together the basic CRUD of an app in 5 minutes with one toolset, and it takes 2 days in another, which one is more likely to let you hone in on the fine details? If one toolset lets you automate testing really easily, and the other doesn't, which one is going to make you feel freer to experiment and improve?
Yes, tools don't matter. Output matters. But tools affect output. So tools matter.
I'm not saying one should rewrite one's codebase in The New Hotness every 6 months - that would be crazy. Which maybe is the author's point.
Sorry, I probably confused you. I'm strictly referring to the actual HTML/JS output of a Ruby or PHP web application. Sure, production output matters, but my point is actual output doesn't necessitate using a particular language in this case. I believe that's is what the original author was referring to in his original post, especially considering the context.
As for your hypothetical situation, I imagine for those reasons and more, they continue to use PHP. PHP isn't devoid of these tools (and I'm not suggesting you are suggesting that), and they are widely used and fairly popular. And because they are proficient in PHP, they can use these tools easily.
As has been mentioned by the original author (in both the original post and in comments), they don't use PHP as a hammer, and they do explore other languages. Learning is good. Take what you learn, and apply in a language you are extremely proficient at.
When I read that. I instantly thought well of course they use it as just glue cause they are using a cruddy language.
There's lots of reasons to use BASH as a glue language (people should do it more) and there are lots of reasons not to use it to write whole software. PHP, same.
I'll go out on a limb here and say that most apps handle some kind of data structure on the server, and in many cases they facilitate some kind of interaction between the user and this data. While you can theoretically do the entire functionality in client-side JavaScript, I assert the idea is so abysmally bad it's not really worth considering as a valid counter example. Please note that I wouldn't include pure single user applications like http://www.diagram.ly/ in this category because they don't manipulate objects on the server that are in need of protection and validation.
I will argue that for mid to large applications, scripting languages are just the entry point to your entire application, as the author says, the glue. I would run a "real" application server underneath for the middle tier (i.e. to handle the business logic), and have the scripts handle the presentation layer only.
> I would run a "real" application server underneath for the middle tier (i.e. to handle the business logic), and have the scripts handle the presentation layer only.
Yeah, I believe you would. But not Facebook, Wordpress, or even large parts of the Google Apps landscape. I'm not judging either side, mind you. Do you by chance primarily develop business applications? Because business app people often favor this special type of multi-tiered design that typically has a Java app server behind everything.
Facebook could probably go in either camp. I'm sure they write some of their business logic in php, but they made Thrift for a reason. In particular, isn't their chat written in Erlang and feed stuff written in c++? I've read that they even use Java for some things.
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?
Just for the record: the "leaking errors" is fixed (and yes, that was bad), the site is responsive again (the server was too loaded with other stuff, so the additional traffic the article generated put him over the edge)
Even if there should be an exception (which of course can happen), it shouldn't show the stacktrace anymore. But we're not perfect, so I wouldn't rule out anything.
yeah, we ditched using that a long time ago (but the main contributor to MDB2 is actually working at Liip ;)), but our blog software still uses it. The next iteration of that will not, we're switch to doctrine2's dbal.
"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."
Some years ago I was coding for a inventory/financial administration completely built in OpenBasic (remember to leave space between your line numbers!), gosubs instead of functions and the like.
The problem is, that this was one of the most solid systems of this kind I worked on (think "hot code swapping" and "constraint driven development"), but mentioning it on a CV does not exactly evoke the same vibes as using node.js on couchdb.
Business systems: inventory, sales orders, purchasing, forecasting, accounting, etc.
One is one of the largest master distributors of industrial supplies in the world.
Another is a web-based and catalog distributor of consumer goods (mostly apparel.)
Each has acquired 5 competitors in the past 10 years, converting all of them from whatever they were running to their 20+ year old software written in 40+ year old technology. Both were super agile long before any of us ever used the term.
(All client side web software is written in javascript. Some things do change.)
I assume that since it's mostly industrial, they don't have a thousand hits a day, etc., form random web gawkers looking to buy a doodle for their home?
I don't think his point is about what's subjectively the best language to build websites, but rather that language is not the focus of how to make a highly successful business.
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?
There are many situations in which rewriting the entire codebase can destroy a project. I have seen it happen. People get excited about a new language or framework and decide to rewrite their code in it. They want to add a single new feature that would be easier to do in the new language. They could still do this in the old language, but it would take longer. So, they begin to rewrite. They get bored, and the project never gets finished or they are inexperienced, and the project takes much longer than anticipated to get up to the level of the original. It is an unacceptable delay in most cases. For new projects, use the appropriate languages, but rewrites for large businesses are often the nail in the coffin.
Comments of the type "they're just can't be bothered to change" are idiotic, and whatever works for them it is fine.
That said, for newer projects companies are better off choosing another platform more suitable to their domain.
For example, if you want to do data-mining / language processing, there is no better alternative than Python. It has mature libs in that regard, good visualization tools, books on the subject come with Python source-code, and has bindings for frikin' everything (you can script everything with it, from Emacs and Vim to Gimp). Native extensions are easy as pie, working with forked processes is as good as it gets (comes with lots of really sweat libs), and Python also has Google's App Engine.
And Ruby on Rails completely blows away (IMHO, YMMV) every alternative for fast web development ... it's beautifully designed, comes with best-in-class plugins and I haven't seen so much activity in any other web-related platform.
So for newer projects, companies should try experimenting / investing in newer tools; otherwise the competition might just gain an unfair advantage. You shouldn't reinvent the wheel when people have been working on the exact same problem for years.
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.
Python Paradox was written quite some time ago. Back then there were far fewer jobs for Python. python has become a lot more mainstream since then, hence your story of learning Python just for the sake of getting a job. IMHO, the idea of the Python paradox no longer applies to Python today.
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.
When I said PEAR I referred to the pear.php.net packages being PHP4 style and dependent on PEAR_Error and all. I am aware of the fact that Symfony and a couple of other large projects are available via PEAR distribution servers.
Haven't seen pear2.php.net before though but after a quick look just now - with just a couple of libs and hardly any updates in 2011, it doesn't look like it's doing very well. And again it seems to have dependencies and wants you to use custom error libraries.
And I am not sure what you mean to say regarding most code being jailed and this being a 'misconception'. If you aren't on PHP 5.3, you can't even find a lightweight (means not Doctrine) working standalone implementation of ActiveRecord, although lots of frameworks provide similar functionality. Just one example. And looking at the other comments here I don't seem to be the only one who noticed this.
And it's not that I am not seeing what's going on. I see that Symfony2 is making an effort but haven't worked with it yet. But I also see that I am watching 50+ repos of 'promising' more or less under-the-radar PHP 5.3 projects on github to prevent 'missing out' on something I could use in an upcoming project.
Just saying that it'd be great if someone steps up and manages to establish something like rubygems in the PHP world, most likely for PHP 5.3 and up, maybe based on phar but with emphasis on loose coupling, reusability and keeping things 'compact'. I don't have the perfect solution either, all up for discussion.
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.
"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."
So, what is database of choice for the web apps ? (I was thinking it is mostly MySQL. Looks like I am struck in old tech.)
The author of the article says he's using PHP for glue, not for writing CGI apps. There are certainly a lot of legacy apps are of the old-style "click a link, send HTML as a response". But the new "glue style" is about writing your web app as a JSON server that speaks HTTP, and then writing the UI in Javascript to run in the browser. That's what I'm saying nobody uses Apache for.
The way people write new apps now is with high-performance server processes that can handle tens of thousands of clients per thread. Apache and PHP do not do that. 99.999% of the Internet is legacy apps, and so Netcraft statistics will tell you how people were writing apps 5-10 years ago.
If you're serving tens of thousands of clients, each client has to have a very low server footprint, so that means you're not doing much in-memory manipulation of datasets. In business software, that would be the exception, not the rule.
I think a big driver behind PHP is the simplicity of the model. Each request can pretend it exists in isolation, having the whole web server to its own. Simplicity + good enough = popularity.
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.
Just a quick note - Symphony (the CMS) is different to Symfony (the Framework) - I presume you meant the latter? These two seem to get confused all the time.
IMO Symfony (especially Symfony2) is much more Rails-ish than CakePHP. Cake PHP is Railsish in that it an MVC with psuedo-scaffolding, but Symfony2 is much closer to the real thing.
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 feel like many developers are using RoR and Python simply because it's 'cool'. The old, reliable languages are boring. I also don't like the fact that many frameworks out there abstract layers away and make it so you don't really know what's going on underneath. This makes it easy to say you are a developer (because you can make something) when you are just mashing frameworks together.
I've also been using PHP for the last 10 years and have never had problems scaling or writing good code.
I choose PHP, all that time ago, because back then I was a C developer. I fell in love with the fact you could create your own C extensions and that the PHP syntax was similar to C syntax, so it was easy to pick up and make it do what I wanted it to do.
I've only every toyed with frameworks, never used one as such, because I built my own library up over the years that is suited to my needs.
Cmon man, I didn't say it is impossible to build scalable web apps with it. The php landscape's lack of an equivalent to rack is an insane situation for a 'web' language, and a good example of why it's a bad choice of platform if you have the option.
Yes, you can write scalable web apps with php.. you can also walk everywhere on your hands; but it's unnecessarily painful and awkward, so most sensible people avoid doing it on a regular basis.
It's not. Rack's a framework for composing applications of middleware/intermediary components by specifying conventions for delegating requests and responses.
From the blog on the rack website: "Rack aims to provide a minimal API for connecting web servers and web frameworks."
The PHP SAPI handles the HTTP request and dissolves it into super globals for the environment to consume. This is all you need to handle a HTTP request. It just doesn't get any more minimal than that.
I'm a big fan of Yii, and I use it a lot in my own projects. (The fact that it has an nigh-direct clone of Rail's ActiveRecord helps.)
It does, however, have the same problem that a lot of other PHP frameworks have in that, unless you're really careful, your components are "trapped" because of the Yii idioms and base classes.
I think Mr Spatula's point stands. Code reusability in PHP is nothing like what it is in the Ruby world.
That's probably only true because you hear about it here, which is a very self-selective group, who tend to lean towards Ruby, Python and the "popular" trends. In the PHP community being like ruby, or rails is not necessarily a plus and can in fact may be a negative depending on what you're trying to accomplish.
Frankly I'm sick of articles such as these, as if the author is pleading with this selective community that it's OK to use PHP. Somewhat sickening. They should feel confident in the tools they use without having to justify it to anybody.
Active Record (http://en.wikipedia.org/wiki/Active_record_pattern) is an architectural pattern and not something born in RoR. The parent just happened to mention an implementation (for which there are many in PHP) copied from RoR.
I'm curious, what other RoR influenced PHP framework features have you heard of?
The pattern is good. It's the extras on top of what the pattern proscribes, though, that makes Rails' implementation great, eg. composition via behaviors, easy validation and relations, and scoping for bundling sets of common query criteria.
PHP implementations run the gamut from basic low-hanging-fruit-grabbing attempts (like CodeIgniter's frankly, well, weird implementation) to fully-featured ones like Yii. I do agree that they goes as far as doing most of RoR's implementation and then just... stop.
> ... what other RoR influenced PHP framework features have you heard of?
RoR-like routing shows up frequently as well, and in Yii's case, Views templates have the same access to both directly-assigned template variables, and variables belonging to the controller instance itself.
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)"
Depends how thin the layer of JavaScript is over the CRUD part of the app. And if the app talks to a service hub for lots of offline processing, is it still a CRUD app?
Another "why" that was left out in the article, something that is of great concern to a lot of projects, is computational performance. A whole lot of good can be said about both Python and Ruby, but "swift performer" is definitely not one of those things.
That kind of performance just doesn't matter that much though. I recently benchmarked my fairly standard Rails app on 1.8.7 vs. 1.9.2, and the numbers for delivering a page are basically the same.
1.9.2 is much faster for calculating Fibonacci numbers, sure, but since webapps are mostly IO bound it just doesn't matter.
Oh - I fully agree. For most situations, raw computation is irrelevant. But even in the cases where it matters, PHP isn't remarkably faster than its closest alternatives.
Let's be honest. When people "use Ruby", it's very unlikely that they are using JRuby or Ruby 1.9. Similarly, when people "use Python", they are using 2.7 or lower, not 3.1.
The reason is because the older versions of each are the ones with the libraries.
But interestingly, this is not the case with Perl, as new releases have 99% backcompat with old releases. Even old code that uses a new piece of syntax (like "say" from 5.10) in the old way continues to work!
I don't have any hard numbers, but there's been a massive uptake in 1.9 since the release of 1.9.2. I've been doing all of my projects in 1.9 for a while now, and I very rarely run into compatibility errors.
I'm pretty involved in the ruby community, and I've generally seen an increase in people talking about using it. Also with the Rails 3 release, lots of people were waiting to do one big massive upgrade of both Ruby and Rails at the same time. It's been long enough now that lots of people have moved their projects over.
Like I said, I have no numbers, so fundamentally it is just a guess.
If you say that you're using Ruby 1.9 then not wanting to be quarrelsome that's good enough for me to accept that you are using Ruby 1.9.
And I'll grant that you're part of the community on your say so.
But being "part of the community" doesn't magically enfuse you with knowledge about what proportion of the community is using what version of Ruby. To be educated about that is to count the numbers.
You might as well have linked to NCAA Basketball scores!
Let's be honest. When people "use Ruby" (or Python) you really don't know what proportion of them are using which version. And the data you have a lot of does not help with that.
Nor does the data you have a lot of tell us what proportion of Perl users use which version of Perl.
I have to agree. Bolting a full stack framework on top of PHP just doesn't appeal much to me. If you want that kind of organisation in your application, I would much prefer something other than PHP. PHP excels at keeping complexity down. If you don't work within that paradigm, then Python or Ruby are probably better alternatives.
From the outside looking in the vast majority of people I know making web apps in ruby are doing so with rails. For better or for worse there is that full blow framework culture there that hasn't been replicated in PHP either due to fragmentation or the amount of functions built directly in the language.
True. I wouldn't say that it's because of the number of things built into the language though, it's more that Rubyists tend to care about software engineering, and so they'd rather do something the right way with full tooling than just throw up one page spaghetti scripts.
in short:
be careful in choosing the technologies you base your company on because most of the times the sane business decision is that you might be stuck with them for a loooong time.
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.