Back in 2004, PHP was a very sensible solution: It was the language I knew best (we had little time for the project, so going with a language I knew felt sensible), it was easy to deploy and back then, there weren't that many alternatives anyways:
Ruby was in its infancy, for Python you had thread safety issues with mod_python or you went CGI, Java was and continues to be just ugly. JavaScript back then was still just a toy language. No Node.js or anything.
That would have left me with mod_perl, but looking at where we are today, that would have been an even worse decision it seems.
Fast forward 6 years.
The application consists of over 100'000 lines of PHP code alone now. It's in production use for many customers which serve tens of thousands of end users. It's not only a traditional web application, it also serves as an API for custom-made tablet pc applications (before we had the iPad), for GPRS-connected barcode scanners and last, but not least, for native Windows Clients (all developed by our company, using various languages).
While I really hate some aspects of PHP by now and I would love to have a Ruby or Python codebase to work with instead, rewriting all of this is out of the question.
Customers depend on this to work exactly the way it works now (they panic even if a link is two pixels off - welcome to the enterprise).
While I might be able to exchange some components with something else, I don't see the benefit it would provide - it would do nothing but make maintenance harder because I'd add another dependency to keep track of.
The only thing I could do is rewrite the thing. But by now, there's more than 30 man-years of work that went into this.
Sure. Redoing it wouldn't take the same amount of time, but considering it would have to look exactly the same (probably I couldn't even get customers to accept different URLs), where's the point in that?
OTOH, despite being done in PHP and tailored to sometimes crazy customer requirements, the code base is sufficiently clean to work with and it's constantly improving. Bad parts get factored out, good parts arrive, so it's not all-bad.
We are embracing new technologies as they become available and fit our product. Our CSS is now written in SASS, we moved from pure DOM scripting to Prototype to jQuery, we make use of the latest features of PHP (now Closures and anonymous functions from 5.3) and of our database (constantly running latest Postgres).
Even though it's PHP, it can still be fun.
Considering recruitment: Granted. It might be harder to convince a good programmer to work on this "ugly" PHP project. But a) we are not just doing PHP (just mainly), b) the code base is, as I said, quite clean and c) even though the code base might be in a language you don't like, the basic concepts of our profession still apply.
You can still discuss and solve interesting problems and you can still create great solutions to these problems.
If you don't want to take part in this adventure just because you don't like the language this is done in, then, frankly, you are not the person I want to hire.
Even though programming is the coolest thing you can do on this world, it's still a job and not everything can always be unicorns and rainbows. If you can't see this, then I don't need you.
If their CTO and I traded jobs, I wouldn't rewrite everything in other languages. I'd continue to solve interesting problems and recruit the best people I could. But I wouldn't take it personally if some of the people in the marketplace chose to pass on solving interesting problems in our environment with our tool chain.
It's not personal when I pass on someone talented who isn't a fit for us, and it wouldn't be personal if someone else passed on working for us because our tool chain wasn't a fit for them. Unicorns and rainbows don't enter into it.
It's like.... Oh I don't know, perhaps it's like locating your office in Toronto instead of the Valley. Some applicants want to live and raise a family in Toronto, some want to be where the action is in the Valley.
We solve interesting problems all the time in Toronto. But no, I'm not opening an office in the Valley for those who want to live there, just as you aren't doing work in Python just because there are talented people who want to use it.
I can respect that while simultaneously respecting those programmers who give your job a pass because they don't want to work with your tool chain. Just one of those things.
"Why not transition to a different language over time? One that more great programmers want to use?" which just isn't something you'd realistically do.
And then I thought about the fun we have here in the office and I thought about the nearly two hours of discussion I had with a fellow coworker about race- and lock free storage and merging of shopping baskets and it hurt me to think that people would throw all that away just because they don't like the language even though it was the only viable option when all of this started.
I might have been carried away.
So: Sorry. I didn't mean to insult anybody. I just think it's really shortsighted to judge a project, a team and a company based on the choice of language that might have been used at one time.
I just have to respond to the MUMPS bit, I thought I was the only person here that actually remembers the thing, let alone worked with.
The clearest experiences from my MUMPS days are the ones where I inadvertently wiped some string containing crucial functionality.
1) What is best for my business?
The answer may well mean sticking with a flawed technology that nonetheless is serving the business well. Remember there is still lots of COBOL chugging away.
2) What is best for me?
If it's my business, but I'm sick of PHP and would like to switch to Ruby, Lisp, Haskell, whatever, it might be better to sell the business and start a new one based on the new language, rather than risk a rewrite. Isn't that part of the freedom being a founder was supposed to buy?
One last thing (to convince more PHP people to downvote me) is, if you are spending most of your time on PHP or a web-only-language, you will never see the beauty of asynchronous I/O, socket programming, threading, hooking...
Update: When I mentioned "web-only-language", I was thinking of people who use & only use Ruby with RoR for web apps. I don't know how many developers who can't distinguish between Ruby & RoR but I guess it's not a small number. And of course, what I said is toward to those who aren't willing to learn new things. They always think about web & only web.
anyways. I have some reasons for my strong dislike of Java: a) checked exceptions, b) no method pointers or something similar and c) lots of the code produced by the community out there (and in the standard library itself) is full of FactoryFactoryFactories and other typing intensive, mind-bending and ultimately useless abstractions (most of them not DRY at all either).
Back in 2004 I did strongly consider Java though, but ultimately, I didn't have time to implement this web application AND learn a new library (learning the language is easy. learning the library is what makes you slow in the beginning).
As a side note: Said web application also accesses locally connected barcode scanners over the local serial port. Unfortunately the only way to do this (aside of a locally installed client) is still using a Java Applet which I've also written back in 2004. So I do have the Java experience to know that I don't quite like it :-)
Having said that I wonder if missing the 'beauty' of async I/O etc has more to do with the projects people take than the language. Would a python or ruby developer who focuses on creating web apps have any more familiarity with those concepts than a PHP developer?
FYI, JavaScript programmers use asynchronous I/O all the time. That's what the 'A' in AJAX stands for...
We (well. back then it was just me) began doing this back in 2004.
Fast forward 8 years.
sorry. corrected.
the cynical part in my brain now compels me to write something along the lines of "so this is the only thing you took away from that posting?".
So I'm writing it and I'll immediately regret it.
But whatever.
In 2004 you still only had cgi/erb for web development. While ruby was really cool, it just wasn't practical for web development.
What would have been so bad with mod_perl?
According to its documentation, this appears to be the most advanced language module for Apache, providing integration of Perl at all levels: http://perl.apache.org/docs/2.0/user/config/config.html
Also, Perl has a huge standard library. So what's the issue with Perl, compared to PHP?
The fact that you made sound engineering decisions and continue to improve on what you can (while being practical) means more to me than your language choice, even if I'd rather be dancing with Django :)
I would say, the blogging-about-programming elite, rather than the actual programming elite. I haven't coded PHP in years, but some of the most brilliant devs I know use it when it fits the task.
People who say PHP is badly designed, however, aren't talking about the implementation; rather, they're strictly talking about the language itself—the syntax, the semantics, and the standard library. There is no advantage to the way PHP-the-language does things; it makes nonsensical choices (like the flat, disorganized, all-libraries-included function namespace, the inability to chain method calls in a single expression, the extreme amount of "weakly-typed" cruft surrounding the comparison operators, etc.) which derive no benefit.
It would be strictly beneficial to the programming ecosystem if PHP-the-language were treated as an object-code for other, better-designed languages to target, such that PHP-the-implementation could be used without needing to write in PHP.
What's good about PHP is the execution/dispatch/deployment model, which papers over massive deficiencies in the infantile implementation (much less the know-nothing language).
Care to give some proof?
Say, performance-wise, MRI is not any worse than PHP[1]. And as far as I understand, PHP implementation is just plain horrible[2].
[1] http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...
[2] http://blog.paulbiggar.com/archive/introducing-malicious-cod...
PHP was great a few years ago, and by great I mean "one of the only options". PHP is active on every shared web host around. It's the norm. Only recently have the likes of Ruby and Python become popular on shared hosts. Personally I think that's fantastic.
* Java has a really repetitive syntax, but it's libraries might make up for that.
* C++ with all it's features has bazillion ways to shoot yourself, but it's arguably fast and the syntax is bearable.
But php has both an ugly syntax, horrendous stdlib, and fame of security issues.
Maybe COBOL or MUMPS could be worse than php... haven't used these though.
Your "worst" is probably ill-defined: C is bad for web programming, but is certainly an elegant language and pretty good in its niche.
In practice you disable stupid options, don't use quirky parts of the language, set up your IDE to autocomplete functions, and PHP stops getting in the way.
What you're left with is a decent OO language, which recently got namespaces and closures.
It's OK speed-wise (with APC) and has got stable implementation.
Imagine buying a car where the salesmen was saying "this is a great car, it will get you where you want to go cheaper and faster than anything else out there. The only thing you have to remember is; 40% of the buttons, pedals and handles in the car will actually make it explode into a rolling fireball if used. Don't do that. You'll also need to open the hood and physically remove 2 or 3 things that are even more dangerous. Oh yea, don't ever put anyone or anything in the back seat. If you remember all that, this car will be a dream!". Would you use such a car? I wouldn't and I wouldn't use a language like that either.
There's php.ini-recommended in the distribution and it's well-commented.
Not using variable-variables, undeclared variables, globals, unsanitised variables in paths, SQL without prepared statements, etc. is common sense and applies to other languages too. PHP might just bite harder if you lack that common sense.
Yet despite these warts standard transmissions are quite popular in most of the world, and people get around just fine in them.
Compare this to Perl, which everyone hates, but which has a modular-enough core that you can override core behaviors. The community has recently added all sorts of new features -- a new metaobject protocol, hooks on opcodes, macros, etc. Every day, it keeps getting better.
I might agree that PHP's flaws, from a language design standpoint, are okay. Who cares what character you use to separate namespaces from class names? But the deep design without any hooks for extensibility is a killer. Every day, the language will get worse and worse, because the other languages can be extended in themselves. PHP is stuck as what it is forever. And that's the deep problem.
(Actually, I'm not willing to concede that the language design failures can be worked around. A lot of the language design quirks are boneheaded enough that they're a deal killer. I had to use PHP for two projects at two jobs. They were both my last project for those companies.)
Also note that mod_perl for Apache provides several really good features for efficient web applications that are missing in all other language modules (including mod_php).
What's the upside? Conservation of intellectual momentum?
On the other hand, there's still other stupid stuff like "magic_quotes_gpc" that has only recently been deprecated.
There's no reason they couldn't (over the course of years) move to another language. I'm not suggesting a total rewrite, but they could start writing entirely new subsystems in a new language. It's very rare to have 100% of your code in one language anyway.
Recruiting great programmers is one of the most important things in a software startup. Why stick with PHP if it makes that far more difficult?
Language is not that important. Your engineers are. They will easily compensate for suboptimal tools.
The best hint for this is that most (>70%) of the money goes into salaries. Not software. Not hardware. Not office space. Salaries.
Great salaries is a great thing, but what if your competition offers great salaries and a less obnoxious programming environment than PHP (and better hardware, and better office space, for that matter)?
And, therefore, anything that makes your engineers more or less efficient goes directly to your bottom line.
(I agree that the comment you're replying to underestimates the cost of migration. But the problem isn't a failure to understand that salaries are the main cost; that's exactly the thing that makes moving to a better langage attractive.)
That's exactly his point: it's much harder to find great engineers who want to use PHP.
Disclosure: I'm a PHP developer who has had to hire PHP developers in the past.
I'm not sure what that proves, considering all the languages we're talking about are free, and the largest price you have to pay is probably for the IDE (which also tends to be free).
Great programmers can make great stuff using anything.
Probably because by the time they've transitioned to the more popular language, an entirely new programming language will be the one more great programmers want to use.
Although it feels 'dirty', the only thing I consistently read about ruby & python web apps are deployment issues and exactly the best way to deploy those apps.
With PHP it seems very straight forward and an easy way to avoid all those issues.
Your time as a human is far more valuable than the extra cost of an IIS server.
Ruby and Python actually offer some language advantages tho. Personally if I coded .NET in the day I would be looking at F# for webapps.
---------------------------
Thats news to me ... if anything deploying Ruby on Rails apps has become much much easier over the years with the advent of Phusion Passenger, Enterprise Ruby, cheaper VPS's, Heroku etc
Secondly, and this is my biggest bug bear, I know nothing about Python on a Mac and OS X. I am a Windows fan through and through, I love Windows 7 and I love the .NET ecosystem. Please don't assume that everyone on HN uses OS X / *nix
Transitioning to Ruby or Python or Scala or anything else will not make anything magically better. I recently converted a Rails project to Grails (actually, I'm in the middle of the conversion). I'd thought "it's Rails - we'll just go in and fix the current issues". It was a horrid nightmare of undocumented crap. It was started in 2006 - Rails 1, and had been added on to for nearly 4 years, and was still Rails 1 (1.2). No useful inline comments, no unit tests, undocumented magic method overrides for basic stuff that wasn't compatible with future Rails versions, and so on. It was horrid. But hey, it's Rails, right? Must be magically better than PHP!
I went back and forth on whether to rewrite in PHP or Grails, and either would have been fine. Why? Because part of the rewrite process is to use modern techniques - with a big helping of TDD tempering the process. Oh, and version control. Yeah - 4 years of a project with 0 version control is not fun to deal with.
So... I'll take PHP with a team of people using sane schedules, TDD/testing, version control, internal and external documentation, and other niceties, over Ruby for the sake of Ruby. Now, modern Ruby/Rails with all those niceties vs PHP with same niceties? Probably a more even draw, with no clear cut choice. But that doesn't seem to be brought up in these discussions.
Frankly, most of the stuff people point to as awesome about Ruby (or Groovy, in my case) in isolation can be detriment - metaprogramming in general can be confusing to someone new to the code without proper documentation as to what's being done. Whether those docs are in tests, inline or external is beside the point. Typically when I come in to a new code base in any language the documentation just doesn't exist (or, better yet, it's "self-documenting"... right...).
End of rant - PHP really is fine when used with proper development techniques. Most languages are. In my experience problems start (and get worse over time) when people rely exclusively on the language alone, rather than language + commonly accepted dev techniques.
Perhaps once a language becomes mainstream, and is adopted by many people, not just the early hacker adopters, the perception of the language as clean and elegant goes down. This isn't necessarily because the language has changed, but because the average person using it has become less skilled. Languages that are comparatively new and shiny are mostly used by the much more talented early adopters, and thus seem to be more professional and clean. (This is just speculation, so feel free to disagree if your personal experience doesn't reflect this.)
Of course some languages make it easy for inexperienced programmers to write bad code, but this doesn't mean that good code can't be written in that language.
In fact, I would go so far as to say that if you are a decent programmer you should be able to write clean, reusable, DRY, efficient code in just about any language.
So as far as your argument goes I agree. The important thing is the team doing the programming, not the language they are programming in. If they are a decent team they will be able to do good development in PHP, or any other language.
No, actually, the teams (people) could be the same. It comes down to lang X with sane processes (testing, documentation, version control, etc) vs lang Y with no (not enforced, standardized, adhered to) processes.
PHP is popular in the same way Miller Lite is popular: it's convenient, cheap to run (on shared hosting) and adequate. However, if you're used to something finer, Miller Lite simply will not do, and people who think it's fine are not going to understand.
I once had a Python programmer looking at the kind of stuff that I was doing with PHP and he was surprised that such things could be done in PHP.
This is an actual conversation that I had in a meetup:
Guy1: If PHP were to disappear, it would bring down a lot of the web with it, wouldn't it?
Guy2: Nah, but, that would be the case if Java or .net were to disappear.
Me: (to myself)Wtf!
Guy1: But, most of the links that I click on the web end with .php.
Guy2: um.....
Me: (to myself)pwn3d!
PHP is cool. I have found (http://fatfree.sourceforge.net/) and I couldn't be happier. It's similar to Sinatra and has everything a small app needs. It's simple and make separation easier. But if I need that complicated data structure processing that can be done with python or perl, I'll just write down that script and run it through php and get the results.
Between, this statement makes no sense for me
>> This is just going to get bigger and bigger as we grow by 500% or more _every year_
F3::route('GET /about',
function() {
echo 'No subliminal messages here...';
}
);I worked in PHP for five years before I worked in Rails, and I think PHP is a great language for web development.
Yeah but here's the rub. You can't compare Rails with PHP. You need to compare Ruby to PHP, and ask if the switching costs will outweigh any deficiencies; and you need to compare Rails to e.g. Cake or Symfony or similar, and ask if one language provides a framework whose advantages are so compelling that they too will outweigh those switching costs. I have yet to be convinced.
(weighting factors may apply for dev experience with one or the other, legacy code, hosting/infrastructure support, etc.)
I wouldn't develop in Ruby without Rails, but I wouldn't develop in PHP with a framework.
He hasn't heard of Google? :-P
As for using PHP, I'm sure it is used somewhere, but it is not a popular language at Google. Most Google developers have better taste than that.
It doesn't mean I like it though. It's still as ugly as sin. After all these years programming it I still get thrown by ($needle, $haystack) ($haystack, $needle) and have to look up which variant this particular function uses. I'd much rather be doing it all in Ruby. Or Lisp.
I don't think I agree. The end product's possibility to be exist at all depends on the mental health of your employees, how efficient they are, and what tools they use. Someone who is unmotivated due to using a language or a tool that is horrible will work only on work morale as a resource for motivation, and it's only a matter of time before that resource runs out, and they'll start feeling miserable and perform sub-optimally.
I don't have an opinion on PHP, although I've made a few cool things with it and enjoyed coding in it, so I don't think it's necessarily that bad.
It doesn't have to be the security blackhole or spaghetti monster it's made out to be.
No point in being condescending about someone else's choice of language.
The things I did to fix the performance problems are generally language agnostic. Improved database architecture, search indexer configuration, clustering, memcache, etc.
It's 2010 - link the post, not the blog
Edit: never mind, http://news.ycombinator.com/item?id=1819021 already posted it.
Programming is something I've done for the last 10 or so years (in various forms). It is essentially the only activity (in terms of 'work' or career) that I enjoy. The engineer in me just enjoys making things 'perfect' (where perfect is a definition perhaps only I understand, but generally its something built on solid engineering principles. Well-tested, reliable, modular, efficient, etc). When code looks 'just right', I enjoy the code regardless of whether it is bringing me any $$$. In that sense, for me, engineering is a fun activity, and not 'work'.
The hacker in me will enjoy a well built piece of software for its engineering brilliance regardless of whether the software got anything done at all.
In the last year or so I've been able to isolate these personalities and perhaps merge them. I do not scold the hacker just because he wants to try out new languages every month and is opinionated about his favorite ones. I get pissed off when this stops him from getting shit done.
I'm glad for the hacker in me who cares deeply about the tools (languages, IDEs etc) that he uses. Its this hacker that makes my job 'fun'. It is this hacker that has helped improve the quality of my code and my thought process for building good software. The 'getting shit done' would never have been enjoyment enough if it were not for the hacker.
But that's not really a problem.
I guess the problem is not that good devs can't code in PHP. And when they focus on the task at hand, they might not even notice. Because PHP has everything you need. I'd prefer coding a website in PHP than in Java, C, or C++, because PHP is dynamic, has first class functions and the kind of stuff you need to be expressive.
One of the problems is that if you think too hard about the fact that the language you use is suboptimal, it will affect the pleasure you take from doing your job.
The other problem is that a lot of PHP code is really horrible, so people have grown to associate PHP with bad code.
The problem is not that nothing interesting can be done in PHP. Lots of interesting can be done in any Turing complete language. It would be just 'plus points' if you would use for example Scala for the kind of task you described. I just cannot see why to use a dynamic language in a task where performance is important when there is a statically typed fast language which is as good and as concise as Scala. It is not that it is impossible that I would join a company developing in PHP. We have to make compromises all the time. It is just that developers evaluate companies, and join the one with the most 'plus points'.
In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.
It just is a red flag and makes me wonder about the sense of taste the developers at a PHP company have. Therefore it would take a lot to convince me that working for them is "alright". If they have bad taste, how are they supposed to write nice code?
Having to learn their proprietary solution to scaling issues only is not as tempting as it sounds. Yes, I am interested in working with scaling problems. But learning a proprietary PHP hack is not going to help my CV that much.
One of the applications I maintain is a convoluted machine made of half java half php on top of Quercus, and if freaking drives me crazy. I think the only thing I hate more than that is working in ASP.
I was kind of floored since I didn't exude a fan-boy mentality, I was simply answering the questions. That was more of an inner chuckle, but I wasn't surprised by his answer at the end of the day. By the time the interviews ended, I realized that PHP might be the last thing these guys will look at.
Coincidentally, I took another offer where the core is PHP + Symfony + Doctrine. I was very impressed at how well behaved, structured and developer friendly a good source base can be, no matter the language.
People never see the same need when starting a project in rails, even if it isn't that great a fit. One advantage PHP has for me is that nothing is abstracted away in a way that I don't understand the underlying components because I'm writing my own framework. Sure certain aspects I'll grab some cade as necessary but in general everything I'm doing I've either written it or parts of it myself.
I get all the semantic language arguments against PHP and largely agree, this has become less of a problem for me though with experience.
Unfortunately for this line of thought, Facebook wanted to move away from PHP 3-4 years back, specifically to Python I believe, and realized it would be too much work to rewrite their entire front end. So, they're trapped in PHP, not using PHP because they think it's the best choice.
This was mentioned in the article announcing HipHop.
I find it reliable, reasonably powerful and easy to use. It's major strength is brilliant documentation on the official web site (this is a major downside to Python in my experience).
Before I jump on this bandwagon I think I'll forget all about mailchimp, and think about all the many, many, many great companies (such as Facebook) that use PHP.
a) I find it more enjoyable to program in other languages.
b) I can generally get things done more quickly in other languages (feel free to ignore this point if you're the opposite :P).
c) Aside from speed, ubiquity, and the docs on php.net (which are awesome), I don't really get anything out of using PHP.
d) People will pay me more to program in other languages.
So yeah, I suppose my first reaction on reading "PHP" in any job description is "Eww". It's not really because I think PHP is wholly unsuited for programming, though. It's just not optimal for me, personally.
The submitted link requires clicking a "More" link in order to read the full entry. (And it will be out of date once they post another entry on the blog.)
It gets the job done, sometimes spectacularly, sometimes not so very much - depending on who did the work. It's a workhorse, and has been demonstrated as such millions of times so far. Performance depends a lot on deployment strategy, but it can be fast.
I really see no point in bashing PHP. It's a tool, it has tons of documentation, libraries and available helpful people. Sure, I'd like to have some tweaks here and there, but with what tool wouldn't you?
There is a saying around here, roughly translated: Rusty cock minds every(single) pube.
Based on my experience, I doubt they need their "highly sophisticated" PHP to do this -- plain old normal PHP would probably be fine so long as they choose the right out-of-the-box software to pair it with. (nginx, postfix, certain non-sql databases, and the right mysql setup)
I know PHP, and I've used it to put food on my table. Luckily that is no more. I'd consider doing PHP again only if my wife and kid were starving.
My advice to people stuck with PHP codebases - start changing the site backend first. Write everything not related to spewing HTML in a real programming language, and slowly limit PHP use as a simple template-processing tool that generates your app's HTML. Which is probably the only thing PHP is good for.
The one thing that bothered me was towards the end. In trying to justify PHP's coolness (which I am not arguing against), people continuously bring up Facebook as an example, even though they've repeatedly stated that they wanted to move away from PHP to Python years ago but realized they couldn't after having hundreds of thousands of lines in PHP.
PHP's cool. I love PHP. But, let's stop using Facebook as an example of a company "embracing PHP".
Damn! Are these all spammers?
"Once you get to the scale of computing we’re at, the language you use is much less important than the platform you build on it."