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.
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.
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.
> Rather, that it's not important to the resulting 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? =)
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.
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. =)
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.
Basically, no offence was intended.
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.
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.
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.
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.
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.
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?
Done since maybe 2 hours :)
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.
(For reference: it's a very old, very deprecated DB abstraction library; it'd be like building GNOME apps with GTK v1.)
"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...
and absolutely eat their competitors' lunch with it.
It's not how big your tool is, but how you use it.
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.
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.
The two companies I cited use InfoBASIC, each on a different variant of the old Pick operating system:
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?
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.
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:
A boy can dream...
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 :)
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.
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.)
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.
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.
You might be interested in this: http://pearhub.org
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.
Just my thoughts!
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.
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).
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.
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.
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.
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.
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 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.
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.
- 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.
I agree. Front end work is dominating my time in web app. development. Server side is getting less important day by day.
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.
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.
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'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.
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.
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.
You can, if you want, take it a step further and add request routing, i.e. http://framework.zend.com/manual/en/zend.controller.router.h...
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.
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.
I'm curious, what other RoR influenced PHP framework features have you heard of?
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.
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.
"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...
1.9.2 is much faster for calculating Fibonacci numbers, sure, but since webapps are mostly IO bound it just doesn't matter.
If "it just doesn't matter" then what's the point of 1.9.2 performance improvement?
If 1.9.2 really made every HTTP request go 2x as fast, don't you think every Ruby shop would have switched to 1.9.2 at least a year ago?
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!
Like I said, I have no numbers, so fundamentally it is just a guess.
And of course this is just a guess too - "It's been long enough now that lots of people have moved their projects over."
Maybe we could step from wag to anecdote if there has been a straw poll at some recent Ruby conference asking which version the attendees were using?
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.
The reason is you have no data.
But interestingly, this is also the case with Perl - you have no data.
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.
The culture has just decided that at least using a little bit (even if it's only 1500 lines) of framework is worth it.
I've been thinking: "Why stick with Ruby or Python and not move to Scala or Haskell?"