Why We Stick With PHP (and don't move to Ruby or Python)

http://blog.liip.ch/archive/2011/02/24/why-we-stick-to-php.html

by jv22222 • 15 years ago

151 133 15 years ago

blog.liip.ch

bad_user2• 15 years ago

I guess this is a joke; but in case it isn't, this is what I'm getting when visiting the website:

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

It's not, I guess, since the comment is available from here:

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...

Seldaek2• 15 years ago

Site got moved to EC2 http://twitter.com/#!/chregu/status/40712581702225920 - agreed though, leaking errors is unacceptable.

chregu4• 15 years ago

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)

Done since maybe 2 hours :)

damncabbage3• 15 years ago

Good God. MDB2?

(For reference: it's a very old, very deprecated DB abstraction library; it'd be like building GNOME apps with GTK v1.)

chregu4• 15 years ago

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.

latch• 15 years ago

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.

Udo6• 15 years ago

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.

eli• 15 years ago

Like many things, I guess it depends on the app you're building.

jasonlotito6• 15 years ago

> 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.

mirkules• 15 years ago

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.

coolgeek• 15 years ago

"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."

Philip Greenspun

http://philip.greenspun.com/book-reviews/web-operations

njharman• 15 years ago

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.

Egregore• 15 years ago

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.

smokestack• 15 years ago

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.

jdap• 15 years ago

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.

mnazim• 15 years ago

"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. :)

Just my thoughts!

oemera• 15 years ago

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:

http://www.paulgraham.com/gh.html

http://www.paulgraham.com/pypar.html

aDemoUzer• 15 years ago

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.

mak120• 15 years ago

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.

markbao• 15 years ago

I generally agree with this article, but...

"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...

kingofspain2• 15 years ago

They did say mainly and I would hazard a guess that most people are just writing CRUD apps.

ams6110• 15 years ago

Wouldn't most web apps be CRUD apps? Facebook is a CRUD app.

AffableSpatula5• 15 years ago

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.

Seldaek2• 15 years ago

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.

harisenbon2• 15 years ago

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.

morganpyne• 15 years ago

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.

kaylarose• 15 years ago

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.

bergie• 15 years ago

It looks like there is some hope for code sharing and consolidation through the Apache Zeta Components project: http://bergie.iki.fi/blog/php-finally_getting_an_ecosystem/

OstiaAntica• 15 years ago

Check out Yii http://www.yiiframework.com/

damncabbage3• 15 years ago

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.

xd6• 15 years ago

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.

rick8882• 15 years ago

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.

AffableSpatula5• 15 years ago

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.

rick8882• 15 years ago

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).

FreebytesSector2• 15 years ago

You should consider taking a look at the Yii framework. It is an alternative to CakePHP, it is new, and it is fun.

Joeri4• 15 years ago

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.

soulclap3• 15 years ago

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.)

kingofspain2• 15 years ago

Absolutely. If such a thing would happen, I would actually dance a jig. This more than just about anything is my last major gripe with PHP.

jasonlotito6• 15 years ago

> 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.

soulclap3• 15 years ago

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.

robryan3• 15 years ago

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.

hackermom• 15 years ago

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.

troels4• 15 years ago

Python is generally a bit faster than PHP though, and while Ruby is dog slow, both languages are in the heavy end for their class.

Ref: http://shootout.alioth.debian.org/u32/which-programming-lang...

towelrod2• 15 years ago

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.

igouy7• 15 years ago

Strangely you show Ruby 1.8.7 but not Ruby 1.9 or JRuby ;-)

http://shootout.alioth.debian.org/u32/which-programming-lang...

riffraff• 15 years ago

careful though, if you take into account equivalent abstractions (rails vs symfony vs django) this argument may toggle against php.

robryan3• 15 years ago

PHP isn't to hard to do away with the abstraction though, or just go with some lightweight helper libraries.

PedroCandeias• 15 years ago

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?

FreebytesSector2• 15 years ago

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.

bad_user2• 15 years ago

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.

zarski• 15 years ago

"server side language is just a glue between the front end and the data source"

I agree. Front end work is dominating my time in web app. development. Server side is getting less important day by day.

chregu4• 15 years ago

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.

carlocci• 15 years ago

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.

PaulHoule2• 15 years ago

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.

troels4• 15 years ago

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.

PaulHoule2• 15 years ago

PHP is definitely conservative in syntax, but it's not a dead language, like Java.

jbm• 15 years ago

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.

scott_s• 15 years ago

Most of the comments here agree with the article. I wouldn't call it controversial, but it's a topic people clearly want to talk about.

edw5193• 15 years ago

Normally I avoid these language war threads, but I just thought I'd mention that I have customers who use this 47 year old language:

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.

pavel_lishin2• 15 years ago

What do they use it for?

edw5193• 15 years ago

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.)

route66• 15 years ago

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.

EXIT

9elements• 15 years ago

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.

S_A_P• 15 years ago

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.

neovive• 15 years ago

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).

jrockway4• 15 years ago

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.

Zak• 15 years ago

[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.

kyenneti• 15 years ago

"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.)

uniclaude• 15 years ago

I'm no PHP fan, but you're a little wrong here. Please see [1], or provide a better source so we can all be enlighten.

[1] http://news.netcraft.com/archives/2011/

jrockway4• 15 years ago

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.

wvenable• 15 years ago

> 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.

KeyBoardG• 15 years ago

I stick with PHP because I've always viewed it as a "C++ for the web". C++ was the first language I wrote useful application with so it was familiar.

igorgue• 15 years ago

This guy is from the past.

I've been thinking: "Why stick with Ruby or Python and not move to Scala or Haskell?"

Joeri4• 15 years ago

Or go right back to Lisp, and get some real work done? ;)

trustfundbaby• 15 years ago

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.

Joeri4• 15 years ago

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.

stylejam2• 15 years ago

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 ? :)

sunkencity• 15 years ago

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.

Why We Stick With PHP (and don't move to Ruby or Python)

Related Stories