Hacker News new | past | comments | ask | show | jobs | submit login
Ewww, You Use PHP? (mailchimp.com)
276 points by moozeek on Oct 22, 2010 | hide | past | favorite | 226 comments

What you need to understand (and most of us hackers too) is that there is a difference between the 'hacker' and 'get shit done' mentality.

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.

I think you can write good software in any language. Moreover, PHP is a powerful language, in its last versions at least, it's just that the way it has been developped would make anyone serious about programming language developpment vomit.

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.

PHP's warts are shallow — syntactical quirks, disorganized standard library, idiotic config options.

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.

If you have to go learn what things are dangerous and must be shut off, and what parts of the language to avoid, surely it would be better to just use a system that doesn't have these kinds of issues?

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.

Are you talking about C++ perhaps? ;)

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.

>Are you talking about C++ perhaps? ;)

C++ very much applies. :)

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

This is a subset of what you have to avoid in PHP. Further, things like globals can have uses. That's the difference with a really poorly designed language: there are things in there that have no good use case. Not things that are only used in rare cases, things that should never be used.

PHP will bite you, common sense or not. The language has serious misfeatures – platform-dependent integer sizes, or cgi.fix_pathinfo=1 by default allowing the interpreter to execute files without a .php extension, just off the top of my head – that require knowledge and action well above and beyond "common sense" to work around.

And all of these faults in the language, even the minor ones, just contribute to the unnecessary cognitive load of using the language. So the way I see it, if I'm starting a new project then why not just pick a sane language like Perl or Ruby or Python instead and save myself all the headaches? It's not 2004 any more, we're no longer constrained to languages that have good Apache modules, and with that constraint gone there are very few reasons to pick PHP over the competition.

How about buying a car with a standard transmission. There is a lot to learn! It actually takes both hands and both feet just to drive it. You can permanently damage the transmission by shifting carelessly. In some cases you can wear out the clutch over time merely by driving with your foot in contact with the clutch pedal. How could you guess that on your own?

Yet despite these warts standard transmissions are quite popular in most of the world, and people get around just fine in them.

But because of PHP's internal design, you can't cleanly shut off features or add new ones. You can mentally ignore the parts you don't like, but you can't fix 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.)

> Compare this to Perl, which everyone hates, but which has a modular-enough core that you can override core behaviors.

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 are these features?

You can hook on any internal apache processing step, not just the final page generation (as with mod_php, mod_rails, etc). This allows you, for example, to use Perl code instead of Rewrite Rules, and still using Apache's fast to finally deliver static content. Moreover, you could theoretically provide the whole Apache configuration via Perl code.

Although that kind of stuff may sound complicated, it allows for great flexibility and I've been told that this actually simplifies things.

The mod_perl docs provide more information: http://perl.apache.org/docs/2.0/user/config/config.html

That's still a tough sell; you subset off the awful bits and are left with nothing but a "decent OO language"?

What's the upside? Conservation of intellectual momentum?

Three things quickly pop to mind: ease of deployment, very detailed documentation and large base of programming talent to pull from.

Ah yes, the PHP docs -- where you learn 10 horribly wrong ways to not solve your problems.

But hey, that's what copy-and-paste is for!

The docs themselves are fine. It's the solutions suggested in the comments that are an offense to humanity.

large base of programmers, not a large base of talent. disclosure: I write php daily.

PHP-powered sites accounted for a lot of vulnerabilities through the years. Part of it was due to its popularity (like VB was back in the day), but part of it could also be blamed on certain design decisions e.g. register_globals.

That true, but also consider that the especially idiotic "register_globals" has been disabled in PHP for many years. If people are still enabling that manually, it is solely because they use very outdated scripts which depend on this. Then, however, the real problem is relying on those crappy old scripts, and not the usage of PHP itself.

On the other hand, there's still other stupid stuff like "magic_quotes_gpc" that has only recently been deprecated.

For new development you should disable all legacy/noob options, enable all error reporting and use PDO with prepared statements.

If you have application that relies on register_globals or magic_quotes, you can assume it's vulnerable. PHP allows enabling these on per-directory basis, so at least you can somewhat isolate the legacy code.

Also note that the Zend-Framework for PHP became mature in the last few years, which also helps a lot to get over PHP's deficiencies.

"Despite its popularity, PHP is considered by the programming elite, almost without exception, as one of the worst languages currently in use today"

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.

PHP is a programming language (that is, a formal grammar for specifying the operations a computer should perform), but also an implementation of an interpreter for that grammar. You're talking about the implementation, which is of fair quality (certainly better than, say, MRI Ruby) and very widely-deployed, a combination which many devs (brilliant or not) take advantage of.

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.

PHP-the-implementation is pretty spectacularly shitty too — it'd be even worse than MRI for persistent processes of any sort.

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

PHP is not supposed to have persistent process of any sort. It's stateless (if you shard/share sessions well, it's super easy to scale).

Excellent point, and often (as now) overlooked. PHP does have some brilliant design choices, for example attaching itself to the Apache process, terminating when the request ends - this makes a lot less vulnerable to issues like memory handling. Some extensions may leak like a sieve, but since it's all cleaned up when the request ends it never really becomes a problem.

> certainly better than, say, MRI Ruby

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 has been able to chain method calls and members since 5.0. The main thing that can't be chained outside of PHP trunk is array access after a method or function call.

I spent a few years immersed in both PHP the language and PHP the implementation. Each is as shitty as the other.

I kind of agree. But I still find 90% of extremely talented programmers breath a sigh of relief when they find they're not having to use PHP. Even for web development.

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.

63.5% of stats are made up on the spot.

He did say "But I still find 90% of..." as opposed to "90% of..." making it an opinion, not a pure statistic.

edit: that's not to say he didn't make up the statistic for his opinion.

Also, AWS/Heroku/GAE give you non-shared-hosting ways to deploy. Still, another tool in the box.

Ok, I'll admit, this may sound a bit trollish, but if PHP is not one of the worst languages, then what languages do you rank below PHP? C comes to mind, not as a bad language itself, but lack of web libraries, but that's about it.

It's hard to find a worse example than php, because when many "bad" languages fail in one or the other category, php seems to fail in most categories.

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

I wouldn't call C a worse "language" than PHP by far.

It has messy stdlib (gets()!) and lots of features that you can shoot yourself in the foot with (software security would look very different if it had arrays like D).

The C standard library is very clean. gets is left in the C89 and C99 standards for backward compatibility an deprecated right now. Nobody uses gets nowadays.

Of the mainstream languages there probably aren't too many. But probably COBOL? C++ is pretty hateful too. Oh, bash is a nasty language too.

Your "worst" is probably ill-defined: C is bad for web programming, but is certainly an elegant language and pretty good in its niche.

VBScript is worse. There's always that.

I don't think PHP is a beautiful language. But that's beside the point. Sometimes you need a hammer, sometimes a screwdriver. You don't dismiss a tool because it's not pretty.

Hammer and screwdriver are equally ugly/pretty. But that's beside the point - it's not the ugliness of php that puts people off, it's the clumsiness and awkwardness of the tool.

I don't care that my hammer or screwdriver are ugly. My hammer drives in nails, and my screwdriver inserts and removes screws quite well.

To me, both are effective at the tasks I need them to accomplish.

Great, if a standard of mere adequacy is your goal it suits perfectly.

That's quite a broad statement.

Is Instapaper merely adequate, or is it better? Would it have been that much better if it was constructed in Rails?

IIRC, Instapaper's a PHP application. I could have mentioned a larger site, but Instapaper was probably a better example, since it's quite popular with HNers.

Well, I hate Rails so that wouldn't be my first comparison.

But yes, it would probably be more easily maintainable if written in a better language, and the developers would be able to add new features more quickly.

To comment based on your metaphor, the problem is not that the screwdriver/hammer is ugly. It's that the grip doesn't feel right and it's unbalanced. You can turn the screw and drive the nail, but it takes more effort and might leave your hands scraped up.

But grip, feel and balance are very personal, individual things. What fits for one person may not work for another. Just like programming languages.

Someone else may have mentioned something like this, but I can't find it, so I'll chime in.

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.

I agree. It isn't the language which makes the project good. A bad programmer will write bad code no matter what language they use, and a good programmer should be able to write good code in any language, even PHP.

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.

You'll take language X with team A and process 1 over language Y with team B and process 0? Help me understand what, if anything, this says about languages X and Y?

In some ways it doesn't, which was the metapoint. People get extremely hung up on "php sucks" or "python rules" or "C# kicks ass", but the language is only one portion of the equation. How the language fits in to the bigger process of development is a huge factor that is often/usually ignored in these discussions.

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.

That isn't a strong meta-point, it's like saying it isn't the bike, it's the cyclist. Sure Lance can beat me on a junker bike. But he can't win the Tour on a junker.

So if you want to succeed, and you have a choice about language, you still need to pick the best language for your circumstances. The importance of people and process doesn't invalidate that any more than the importance of Lance Armstrong invalidates the importance of bicycle engineering in the Tour.

All that being said, I agree with the last sentence of your comment. It's just that I don't meet many people who say that with the right language they don't need anything else, so I'm not sure who you're debating. For example, all of the Rubyists I know fetishizes testing. None of them have ever said to me that thanks to Ruby, they no longer need tests. What they actually say is that Ruby makes testing easier, which is your point.

So yes, process and people are important, we all agree. So who, exactly, says anything to the contrary?

I see where you're going, and I'm probably not as clear as I wanted to be (and probably don't have time to be!)

The ruby community is interesting because of the testing focus, which possibly negates my point a bit. However, I meet plenty of Rubyists who are so focused on tests (which are easy to do because of the language) that they eschew documentation, of any kind.

I've talked to more than a few Rubyists who are now in the 'my code is self-documenting because Ruby is so elegant and my method names and variables are so awesome and I can metaprogram anything I need that there's 0 need to have any comments or documentation - just read my code and the awesomeness of Ruby will overtake you'.

I don't particularly care how elegant your code is, having some inline comments will not hurt. Having external documentation, and sane commit log comments, and so on, are vital in my view. I'm not picking on Rubyists here specifically, that's just the few that spring to mind.

You know what? I need a browser plugin that delays posting all comments until I've finished my second coffee. You make some good points, I suspect we agree on almost everything.

In a way, good languages are interesting because they make good practices so easy they're invisible.

Which makes me very interested in the question of documentation. Throwing tests out the window as documentation for the purposes of this discussion, how do you feel about DSLs as one form of self-documenting code?

Not opposed to them, and probably have some good points (javadoc/phpdoc is probably, at a stretch, an example of that.

I've got to run now, but email me at mgkimsal@gmail.com to carry on :)

I use PHP at work for creating not only web applications but, also to do a lot of non-user facing backend stuff. It's great to know that someone out there is using PHP at a much bigger scale for backend stuff.I hope he shares more technical details. If you don't like PHP, fine, but, don't think all PHP programmers are stupid.

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!

I wouldn't say that anyone has the impression that "all PHP programmers are stupid." Rather, it's more that PHP, on top of attracting O(N) competent developers like any other language, also attracts O(k >> N) marginal developers who barely know enough to get off the ground, and couldn't really manage to code in any other language. When you randomly select a "representative" PHP coder (such as by listing "knows PHP" as a criterion for resume submissions), you get a marginal one.

Stupid was a bit too strong, but, I stand by what I said based on my experience. Articles like these exist partly because of the belief that PHP programmers in general are not competent. You do not hear such frequent rumbling on Python and it's practitioners. One could apply the same O(N)and O(k>>N) logic there as IMO, Python is not harder to learn/program in compared with PHP.

I really don't understand why a language is so important. Since you have your own VPS or dedicated server, you can use C or any other programming language, create executables that do complex and targeted work and send the result to PHP, rails, python... You can use all of the languages at the same time. It really doesn't matter what main language you are using for routing your websites.

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_

Thanks for this, this framework looks real interesting!

Agreed! This one snippet from the fatfree docs dispelled a good bit of my lingering hesitance to revisit PHP after a good while away:

  F3::route('GET /about',
  	function() {
  		echo 'No subliminal messages here...';

The problems is that many popular hosts have not deployed PHP 5.3 yet. So, if you're planning on using this framework, you need to make sure your host and anyone you distribute it to are using at least 5.3. This nullifies one of the common reasons for using PHP ("it's supported everywhere").

this is fast becoming a myth. a lot of hosting companies are moving up. godaddy already offers php 5.3 shared hosting.

That just means the situation changing as time goes on, not anything about a myth. Of course at some point everyone will be running >=5.3, but I still hear about PHP 4 after all...

Link to the actual blog entry: http://www.mailchimp.com/blog/ewww-you-use-php/

Thanks, it was not possible to edit the URL once I submitted.

The web stack at Last.fm is PHP, for better or worse. It's certainly not a pretty language. Or consistent. Or advanced. I've got a theory on why so many large websites use PHP though - from Facebook, through Flickr, Yahoo and Last.fm. I think it's a combination of PHP being the best option available at the time many of these large websites were set up, and it being a very simple language. Yes, I actually think that can be an advantage. In PHP you don't spend any time beautifying things. You don't bother writing "clever" code because you can't, really. Writing in PHP pushes you towards making "the simplest thing that could possibly work" - which is so in sync with the most fruitful startup mentality.

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.

The string functions are (haystack, needle), the array functions are (needle, haystack). And, no, knowing that doesn't actually help me because I always seem to mix them up anyway during coding.

Why not transition to a different language over time? One that more great programmers want to use?

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?

Probably because you overestimate the added value of Python and Ruby over PHP and underestimate the cost of language migration.

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.

Well, the post does imply that they've had problems recruiting exactly because they're using PHP. It's no mystery to me either, I imagine it must be hard to find great engineers willing to spend all their days dealing with the idiosyncrasies of PHP.

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

> most of the money goes into salaries.

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

> Language is not that important. Your engineers are. They will easily compensate for suboptimal tools.

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.

If you think it is difficult recruiting good PHP developers in your area you will have almost no hope getting good Ruby or Python developers.

At my office we use a mix of languages. PHP for the services, Ruby for one set of management panels and Python for one of our other systems.

So during interviews we're happy with anyone that knows any of these with the intention of cross training when needed. During times when there is a shortage of good PHP developers to be found there is usually a shortage of good developers period.

I would understand why a great engineer might get annoyed by having to use PHP, but I think that the larger quantity of people that do know PHP would probably make it easier to find a great engineer in a pool of people that know PHP.

I disagree with this. It shows a lack of maturity to reject a job over a specific tool.

Why take a job where you would be working with a language that makes you miserable? It would be bad for both you and the company when you leave in several weeks.

I've turned down a job before specifically because I didn't want n years using MUMPS on my CV.

(Okay, they didn't actually offer me the job, but I would have turned it down anyway.)

What? Lack of maturity? You only live once. I'm not going to spend my formidable years toiling away with tools that make my miserable any more than I would work for a manager who thought yelling/bullying was a valid management technique.

"The best hint for this is that most (>70%) of the money goes into salaries. Not software."

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

and if an engineer moans and moans about his tools, and refuses to work in anything but his favorite language, I would say he's an absolutely terrible engineer.

Great programmers can make great stuff using anything.

Great programmers can make great stuff using anything.

Just because I _can_ doesn't mean that I _want to_.

I'm willing to work in lots of environments. In the last 2 years I have done projects for pay in Perl, PHP, Java, C++, Python and various in house languages you probably haven't heard of. However I have to be paid a healthy premium for the displeasure of working with PHP. And if I was asked to do it all the time, eventually I'd leave and find a better job working in something else.

I thought the actual programming problems also mattered to great programmers.

Would you rather do something boring in a beautiful language vs. something interesting in an ugly language?

That's a false dichotomy. There are plenty of interesting problems to be solved out there offering the use of better tools than PHP.

Only if they're greenfield projects. But if you're a job hunter, and there's a really interesting project using legacy code in a language you don't like, are you going to turn down a job offer because of that?

Then hand out the ed editor to all your engineers who should be programming in assembly. If they're great they'll be just as good with all that, right?

Or maybe they'll bitch up to high heaven because doing that makes them slower. Engineers don't bitch about using shitty languages to be whiny Prima Donnas. They bitch because using shitty languages makes them slower.

People like to feel like they're getting things done. If they're using a language that looks like it was put together from newspaper clippings every step takes much longer than it does with proper tools. And that makes people mad. In fact, I would go so far as to say the ones who don't bitch are the absolutely terrible engineers because they must be doing it just for the billable hours.

Go find the most genius engineer you can in any other field and make him work with the crappiest tools you can find that he can still eventually get his work done with and see how well your assertion holds.

Yes but good coders figure a way around it.

Forced to use PHP? And it's crappy and slow to build stuff in? So write some tools that compile to PHP.

What I'm saying is that great programmers work with the limitations and build the tools they need to make the limitations moot.

Presuming you're a great engineer that dislikes PHP, you'd take a crappy language and build hacks on top of it? Your great engineers would probably have better things to do with their time. Artificial constraints are great for creativity; for engineering, they're just time-wasting and your good engineers will go elsewhere.

(unless you're the single exception where your business is just that compelling...)

PHP isn't even a good compilation target. There's no native FFI (you can't write pure PHP code that makes arbitrary syscalls), the extension interface exposes extremely brittle guts of the interpreter, it performs very poorly (compared to, e.g., JVM bytecode), and calling user-defined functions to work around the stupid misbehavior of the builtins (e.g., == which isn't even an equivalence relation) is only going to make its performance worse.

"if an engineer moans and moans about his tools, and refuses to work in anything but his favorite language, I would say he's an absolutely terrible engineer."

Let's say he's great enough to get lots of job offers. And let's say that among those, the ones in his favorite language - the one he actually enjoys using - also tend to pay more, and his average coworker in them is more proficient.

Is he terrible to start filtering his job searches by that language?

Ah, finally.

Why not transition to a different language over time? One that more great programmers want to use? There's no reason they couldn't (over the course of years) move to another language

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.

This. Why chase the latest fad while you can spend that time on working on the product? The workarounds for the issues that the proven solution has are well-known, and learning them is a sunk cost. The issues of the new platforms are yet to be found, maybe you need to fix them yourself, maybe the issues are different and you can fix it with different architecture.

What's so bad about PHP? I’d assume the goal in web development is the end product or service and not the means to it. It seems easy to miss the forest for trees, and delve into cult-like arguments of whatever software stack is hip.

> I’d assume the goal in web development is the end product or service and not the means to it.

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.

I used to be in the "eww, PHP" crowd, but only until I really started using it.

It doesn't have to be the security blackhole or spaghetti monster it's made out to be.

I agree. Every language is as good as the programmer that uses it.

I'm maintaining a huge web application mostly written in PHP. We (well. back then it was just me) began doing this back in 2004.

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.

I like everything about your post except the bit at the end. It seems like those words are taking things personally. Look, I worked with ReallyBigCo, a B$44 business. They used Oracle. Java. SQLServer. .NET. And MUMPS. So I have PHP beat hollow for uncool technology. I'll say it again. MUMPS.

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.

I agree that the end bit might have come out a bit too personal. I wrote this after reading the excellent linked article and then seeing the first comment on HN which was

"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'm leaving a PHP job soon to start a Ruby job. The language was not the decisive factor, but it was a factor - I wanted to move to Ruby at some point.

The company I'm leaving solves complex, interesting problems in solid PHP code. There are developers here who are a lot smarter than I am. So my attitude is far from "you guys suck" or "I'm better than you."

But when I look out over the programming landscape, I see a lot more energy and activity right now in the Ruby community. A lot more people building new things and inventing new best practices. This is a simplification, but it seems like great ideas come from Rails and move back to PHP eventually.

PHP jobs run the gamut from high-tech and awesome to grunt work. Rails jobs tend to be more cutting-edge, because the technology is newer and there's just more stuff happening there.

So for me, the question is this: if the Ruby / Rails community is the leading edge for new ideas, and the AVERAGE (not to say all) developer in that community is better, and the AVERAGE job in that language / framework is cooler, doesn't it make sense for me to move that way? All other things being equal, isn't that a good career move?

It isn't snobbery, it seems like the most pragmatic thing to do. This is on top of the fact that I genuinely like the Ruby language a lot more than PHP.

So I don't think you have to feel slighted personally. And I'd expect this cycle to repeat someday: there will be a lot of Ruby / Rails apps that need maintaining, and a lot of developers will prefer some hotter, newer thing. Just the way it goes. But it's nothing personal.


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.

Two questions:

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?

I hate to say this and I know I will be downvoted by "hackers" but I really don't understand why people (who know limited or nothing about Java & blindly follow the norm) always pick the word "ugly", "stupid" for Java? What superior of PHP to Java when with Java I can program from a stand-alone app to webapp, from client side to server side, from desktop to mobile app?... If you are a coder, you must pick a language & a standard lib to be master, and I would say that picking a language that only sticks to a very specific application platform (web-only, desktop-only...) is a very bad choice. I started from C/C++ and moved to Java and I feel very comfortable to use/study Python, C#, Scala & Ruby.. but PHP, get off, never & never ever!

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.

beauty of threading? shudder

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

"beauty of threading? shudder"

Indeed, this whole thread's reminding me of:

"Combining the sanity of threads with the robustness of web development" http://wearehugh.com/public/2010/08/html5-web-workers/

Java throwables come in two flavors: Exceptions like IOException which must be checked, and Errors like AssertionError which do not need to be checked. If you really, really don't like checked exceptions you can easily build libraries and write code that rely exclusively upon unchecked exceptions. I wouldn't personally recommend this design methodology.

Errors and unchecked Exceptions in Java should not be confused. An Error is typically reserved for the runtime environment for a "this ship is sinking, abandon all hands" kind of unrecoverable error. More properly Exceptions in execution that aren't checked in Java extend RuntimeException and not Error.

The stigma that Java has too many checked exceptions is no longer true with modern Java code. Everyone is using unchecked children of RuntimeException almost exclusively. Of course, there is still plenty of legacy code out there using outdated checked exception paradigms.

lots of the code produced by the community out there is full of FactoryFactoryFactories and other typing intensive, mind-bending and ultimately useless abstractions (most of them not DRY at all either

So what? Why does the code produced by others in "the community" affect your perception of the language and/or tools, if you aren't using their code?

Whether you fall in line or not, the culture around Java is around writing code to a certain style. Agree or disagree, there's an argument that by writing in a style that is familiar to Java programmers, your code is easier to read and maintain.

If you're one guy off in a corner, write however you want. But if you're not, you have to take the culture into consideration. And if you are one guy in a corner, why are you using Java?

I just started working for a large enterprise corporation (one of the biggest financial companies in the world). We have a lot of old code written in Java that needs to be maintained. I've been trying to advocate new ways of doing things, but almost every time the other developers will respond with, "that's just not how we do things here."

Java has a very strong culture around it. I worked in academia and startups previously and I didn't realize that there is a huge number Java programmers who do nothing but program in Java. They aren't interested in learning new languages and will only grudgingly learn a new framework. Their biggest concern making sure the lowest common denominator can still maintain the (unmaintainable) code.

An example is unit testing. Our current "unit" tests start up a JBoss instance, connect to the development databases, and take ~5 minutes to run just one test. But I've been told not to waste my time working on anything more modular and that if I'm going to put in any time working on unit tests, I should contribute to the framework everyone else is already using.

It can be quite soul crushing.

Where do you sit? I'm on the 5th floor, by the stairwell.

I was on two, but Lumburgh asked me to go ahead and move my desk downstairs into the storage locker.

Did you find the can of pesticide I left down there for you?

> It can be quite soul crushing.

Always remember: "It's easier to ask for forgiveness than for permission."

If you want to do better than the cultural norm demands, nothing's keeping you. What's the worst that can happen?

I'm already doing it. I set up cucumber + webrat to run through some quick UI tests. I wrote a mock-object framework into the last feature I designed so I could test it. There's still a huge resistance to change. I'm just hoping I can show how useful it is in the long run. In the short run it just looks like I'm wasting a lot of time tinkering on silly side projects.

I don't think that your company's conservative attitudes are because of their usage of Java.

I think that "one of the biggest financial companies in the world" would be just as conservative and anxious about the tiniest technology changes with any language: Ruby, Perl, or Fortran.

The attitude you describe sounds like it has more to do with being a large financial institution and the type of place where software development is a "cost center", not a profit maker.

This is exactly why java was invented (IMO). So you could pay someone $10/hr as a cog to solely work on the SupportEmailButtonFactory's

It is MUCH easier to show someone how something like a single 5 minute unit test holds them back from being bigger better badder. Unit testing should take less than a minute for ALL of them in a project to run.

Ask for forgiveness after you do something...

The other way to go about it is to 'gingerly' find the single ally, and build on that.

Because when we call Java "ugly" or "stupid," it's the community we're talking about. My room mate is an extremely talented Java programmer, and he can fly around Eclipse[1] like a giant rainbow steamroller[2]. He uses Java like it should be used, and it's great. But I don't think he represents the community.

He tells me horror stories of code he refactors at work written by people in his own office, or worse, outsourced companies, and it's bad. It seems to me that that kind of code is more representative of the community.

When you're going to join a project, you have a better chance of encountering code not sucking if the overall culture of that language is better.

[1]: http://www.youtube.com/results?search_query=eclipse+sorcery [2]: http://theoatmeal.com/comics/literally

Ha, if you are thinking that way, I would suggest VB.NET or C# instead. Why? I remember the first time I was creating an MFC project using Project Wizard, I felt like I'm a fool looking at a bunch of auto-generated text & having no clue what it is about. And once again, I was in the same situation when I was using VS.NET to generate code for my first ASP.NET web app. But I still completed that webapp without even knowing what code is for. Does that make VB.NET/C# community more stupid than Java? Does that mean C#/VB.NET should be the ugly & stupid thing other than Java? So, you should better have another way to explain that.

I think for web applications, most people use a "community" provided framework, various libraries, etc. Java has been a locus for that mindset (as in the classic: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.... ) It's not just parody though: http://www.docjar.org/docs/api/org/outerj/pollo/xmleditor/Fa...

do you think you'd have been better off with a statically typed language though?

personally, I prefer the dynamically typed languages.

but I hate. No. HATE PHP's type conversions with its == operator.

    0 == 'foobar'

    true == 'foobar' && 0 == false

    true == false ?

Yeah. I know === exists. But if you have to compare strings and numbers, why is the default conversion method you do the lossy one? If you compare a number to a string, why can't you convert the number into a string and compare the two strings? Why convert the string into a number which will be lossy in most cases?

There's == and === - they do separate things.


It's not that hard to get your head around, and at least one other major language does it this way.

agreed, but == being a non-associative operator is still just sick.

I think you mean non-transitive. But yes.

Sometimes it is "easier" to just type: if (isThisReturningEmpty()) {} instead of typing: if (isThisReturningEmpty() === "") {}

And if you know something could return 0 (which is not empty), you should know to do a type-sensitive check). You are trading off HAVING to set types with HAVING to check types when needed (I think the latter is better).

Note that this isn't anything to do with dynamic typing: Python is very dynamic, but it doesn't have this weird coercion (or is it "automatic type conversion"?).

I hate this as well, but, I love dynamic typing. They aren't the same thing.

Since when are there pointers in PHP?

there are none, but to implement a callback you also wouldn't have to declare an inner class implementing some interface that in turn declares tens of methods just to react to that one callback.

In PHP 5.3 you'd just pass the function (which of course will pass a pointer to that function) and in earlier versions you'd hack something with eval or variable-variables which, while bad, is still better than either writing half a screen full of empty methods or inheriting an inner class from some meaninglessly named class that only exists for you not to have a screenful of empty methods.

In all versions of PHP, callbacks are extremely easy (no eval or variable-variables required). You just have to pass the name of function or method around and use the call_user_func() function to call it.

I disagree that you have to pick one language and one language only to be really good at. At least after you've become a decent programmer. As a polyglot (I can start a project comfortably in PHP, Python, Ruby, JS, Erlang, and wouldn't feel too out of place working in Clojure or Objective C), I think a "master" programmer is someone who's gotten to that point to realize that a programming problem is a programming problem regardless of language. Language is only the syntax you use to formulate your answer.

I do agree with what you say, but there is a gamut with 'programming problems' on one end and 'work' on the other. Especially on the web, most of programming is work, not problem solving. When doing work in a language/framework, knowledge of other languages/framework can distract you. For example, a Java-only specialist would know whether substring takes start offset and length or start and end offsets arguments. I would have to look it up (or wait for the IDE to help me), but I do know that C# and Java disagree about it.

Until recently, an ignoring a brief foray into Limbo, I've been a PHP only/focused programmer. I've been working with python more in the past year as I've been doing more work with data processing and statistical analysis for which PHP really doesn't have the tools.

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?

because PHP provides practically NO means for async I/O whereas the other languages do.

One of the reasons for this is because PHP was designed to quickly handle single HTTP requests. The scaling is ment to be done on the app-server side and that single request that your script is serving at a given time will take as long as it will take anyways.

So you don't really need the async I/O (in theory).

Python and Javascript (and to some degree ruby) rely on their own web servers implemented in their own language, in many cases with no or bad (GIL) concurrency at which point it gets more interesting to move into an event based model where it becomes imperative that operations don't block.

There async I/O becomes important.

So: PHP: concurrency by firing off another apache/fastcgi process or thread. Don't worry about blocking on I/O.

node.js and some python/ruby frameworks: concurrency by using an event based system. Because one operation blocks the whole server, they need to be quick. async I/O becomes important.

Of course the evented model has huge advantages too: You worry much less about races, you get huge performance with a simple architecture and you can potentially handle much more concurrency (because each thread/process consumes resources that your one evented process does only once).

Both paradigms are interesting, but having first-class functions certainly makes an evented model more convenient to work with.

Async I/O is important for any time the connection needs to be kept open while processing the request under heavily concurrent conditions; it's less about not blocking on I/O, than it is about avoiding the overhead of context switching in the kernel and the extra resources of keeping a thread / process alive for the duration of the request. I don't see it as less or more important in a PHP context than an event-based model. However, without an automatic CPS transformation (continuation passing style) of the source of your request handling logic - in particular, continuations at the boundary points all I/Os - you do need to write to a pattern which is in effect event-driven.

Curious, what language is web-only… And spending most of the time with PHP does not prevent you from trying all these thing in the remaining time.

PHP is pretty much considered web-only. Sure you can use it on the command line (never seen it myself) and yes you can do Gtk stuff with it but that doesn't change the perception of it even if you can argue differently.

EDIT: I don't hold that view because of the things I mentioned but I am pretty sure a lot of programmers do.

I have been writing command line scripts in PHP for the most part of the past 18 months.

I will have to agree with you that PHP is perceived as a web language. Hopefully with more articles like these that perception will change.

I have also been writing PHP command-line scripts, or rather maintaining them.

They are a bad idea, in general. PHP is designed for a very specific purpose: Very quickly building web pages in a CGI or mod_php environment and spitting them out. Everything else is an afterthought, and it shows.

For example, if you try to manipulate the filesystem extensively using PHP you will eventually trip over its "stat cache". PHP caches the result of stat() calls, presumably assuming that, hey, it is more important to avoid redundantly calling stat() during the time-sensitive rendering of your web page than it is to actually return correct information about the state of the filesystem. I mean, how often do symlinks change or files get moved during the rendering of a typical web page? And how much web-page-rendering code really depends on being able to read a link, then read the link again after the link has changed on disk? You can afford to ignore that stuff at the language level, if you're PHP.

The result is that you have to learn about the stat cache and remember to call clearstatcache() all the time when manipulating the filesystem in PHP.

That's just one example of why it's better to use Ruby or Perl to write command-line scripts. These languages were designed with command-line scripting in mind. Indeed, this is the flip side of the reason why PHP eventually drove out Perl as a web development language: Perl was originally designed for command-line scripting, and PHP was originally designed for the web. Use tools for their proper purpose.

Use tools for their proper purpose.

Java was originally designed for programming embedded devices. Python was originally designed as a teaching language. One anecdote suggests that Lisp's original designers always intended to add syntax to the language.

Perhaps a decade after a language's invention it's possible to discuss its current suitability and design for specific tasks more than its original design intent.

(I consider PHP's relative ease of deployment over everything else far more explanatory of its ubiquity than any original design intent.)

Good example!

Things like "stat cache" and "memory leaks" are what I watch out for when I write command line scripts in PHP. Also, I do not run my scripts as a daemon and I make sure that they do not run for more than a set maximum execution time.

So yeah, it may not be the most perfect choice but, it beats : having to learn another language when I know what to look out for when I write a command line script in PHP.

Curious, what language is web-only…

JavaScript. Sure, in theory you can use it on the server for other things. Have you seen that happen lately?

Now with node.js, it isn't as clear cut as you make out it to be. It's not there yet, but in the not so distant future, you can use node.js for your scripting needs.

Running on v8, it has an edge in terms of execution speed over other scripting languages. And the javascript syntax and semantics is something most of the developers are familiar with.

If you don't like writing nested closures, you have coffeescript which makes the code pretty, and also brings in some new features viz. list comprehensions, splats, satement modifiers etc.

Considering that nodejs is the hottest hype on the block, yeah, I have.

Wait, is it 2009 again?

I have written a certain amount of Javascript this year to run on Windows machines. This was because a) I needed the scripts to run on Windows, b) I did not wish to have to install another language (say Python) on the machines, c) I really really did not want to do them in VBScript.

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

FYI, JavaScript programmers use asynchronous I/O all the time. That's what the 'A' in AJAX stands for...

When you have a hammer everything looks like a nail.

  We (well. back then it was just me) began doing this back in 2004.
  Fast forward 8 years.
well... uhm... it's still 2010 isn't it?

I'm a programmer. I use machines for math :p

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.

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

The trollish part of my brain compels me to tell you that, while I didn't read what you wrote, you should capitalize the first letter of sentences.

But I did read it and I don't care too much about proper grammar ;-)

I think you unintentionally (or maybe intentionally) make a good point here. Regardless of language, re-writing your entire code base is almost always a bad idea. If you have 100,000 lines of PHP, it's probably going to stay that way. If you were motivated properly, you could start to migrate things over to language 'X' slowly, but even then the benefit may not outweigh the cost.

I think the effort would be better spent refactoring the PHP code over time than migrating to a new language.

Nitpick: "Ruby was in its infancy" - Ruby was created in 1995, and was certainly quite usable in 2004. I think maybe you mean Rails, which was released in July of that year according to wikipedia.

I meant web development with ruby.

In 2004 you still only had cgi/erb for web development. While ruby was really cool, it just wasn't practical for web development.

Well, you had Cerise and IOWA for Ruby Web frameworks then, also Wee, though Wee was not so robust. But IOWA was quite capable of fast, scalable Web sites. For whatever reasons it never got the attention it deserved.

I am interested to learn from experienced PHP developers about certain aspects of PHP program. We are currently maintain a social game which consists of few millions transactions every day (through JSON-RPC, not HTML page rendering), and it appears to be CPU-bounded (we use Redis as db backend). Based on my understanding, Facebook is CPU-bounded too and that's the reason behind their custom HipHop. How many PHP programs out there in wild are CPU-bounded in percentage? Because before I got my hand dirty on PHP few years ago, I heard many times that web applications were usually bounded by network/disk bandwidth rather than CPU.

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

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?

I have no huge grudge against PHP, but I'd also like really to see an answer to this.


As I said: I'm all for adopting new technologies (newer projects than this web application were done in Python 3 and lately node.js).

I'm also reluctant though to introduce more dependencies for the sake of porting perfectly working code to another language I might like more.

It's not just that maintenance will be harder it's also that in some cases our customers (very traditional enterprise. IE6-on-NT4-traditional) provide the server for this to run on and I can't present them with a huge list of services to install and monitor.

Well. Maybe I could, but I my conscience can't deal with persenting them with that list just so that I potentially have more fun while programming.

One of the things I'm currently looking into though is Websockets for a specific component of the app and in that case, I SO clearly see a huge advantage in Node.js that I will certainly go node if we decide that the shortcomings in the way we are currently solving that problem warrant the change in the architecture.

Which brings me to the same conclusion as my initial post:

Rewrite for additional functionality or fixed issues: Yeah. Rewrite for the sake of having it rewritten: I'd rather not.

If I was talking to you about a job, and I knew this ahead of time, I'd be a lot more likely to consider it even though I'm a python guy.

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

"So before you jump on that bandwagon thinking nothing interesting could possibly be done with PHP"

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 this context I'd like to quote Peter Norvig talking directly here on HN just a few days ago (in this case about Lisp vs Python):

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.


Is it good software thanks to PHP, or in spite of PHP?

It's good software in spite of the difficulty of creating such a system in any language. It's good software in spite of the inherent difficulties in creating software. It's good software in spite of computers.

Because rewriting it in a different language automatically makes it better software..? I don't think the language really matters.

When I first wanted to build a website, I wanted to use C, because that was the language I knew best at the time. I'm glad I decided against idea as time went on.

Heh. I have written precisely one CGI. It's in C. It also does precisely what I needed it to do.

PHP really just isn't that bad. It's quirky but it's also quite capable.

I have no doubts that complicated things can be done in PHP. Complicated things can and were being done in Assembler, too.

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.

I am a Ruby on Rails programmer from the early days. It is my platform of choice. And yet, I still have massive respect for PHP. For me, it's the next best option.

I worked in PHP for five years before I worked in Rails, and I think PHP is a great language for web development.

"I think Rails is a more modern platform. I think PHP is not the ideal choice. But I think PHP is a great platform."

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 don't think something like Cake is a good comparison for Rails, and it's honestly not how I think of PHP. Developing in PHP is making a collection of functions and custom made classes hacked together, in my mind. I know there are frameworks, but if you're going to use a fancy framework, you'd might as well use Rails.

I wouldn't develop in Ruby without Rails, but I wouldn't develop in PHP with a framework.

I don't like rails. When I do web development, I do it in PHP, and I avoid PHP rails-like frameworks as well. I prefer more control and most of projects don't fit into a nice box for rails.

In this day and age the only real reasons to use php is because you're either stuck with it and changing the code base makes no sense since you already have a product built, because you're new and don't know any better, or because you've been doing it for such a long time that you're so used to it you don't see the languages faults anymore.

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.

Well, I experienced a reverse ewww when I was interviewing at Amazon for an Imdb job. As soon as I mentioned that my previous employer used PHP, I had a very short and quite frank answer: Oh, what for? PHP is such a bad language. So bad, that nobody should use it.

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.

The trend I've noticed n recent years is that the PHP developer has to defend himself when talking about language choice, much like someone who decides to use .NET.

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.

My bank supports billions of dollars of transactions per day. But they use COBOL, so I will never work there.

These quotes from PHP's creator are very enlightening:


Can someone fix the link? It's pointing to the front page for the blog, the blog post is here: http://www.mailchimp.com/blog/ewww-you-use-php/

We always hear about Facebook using PHP as a justification for it.

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 used to be a PHP programmer, and now I'm a Ruby programmer. A lot of great things have been built on PHP, I just don't like coding with it. To the folks who build great things on PHP, more power to them.

You've got the right attitude. You just say you don't like it and move on. Different strokes for different folks.

No point in being condescending about someone else's choice of language.

I work as a developer at a stock exchange. My department wrote and maintains several business apps in PHP, including a report generation framework and several realtime clinet/server apps.

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

As someone who's written tons of Java/J2EE etc... and who's been writing PHP for several years, I don't get all the PHP bashing. I've seen tons of garbage code in Java, and in PHP. And I've seen amazing things done with both. It's a poor carpenter that blames his tools. And yes, for many tasks I opt for PHP, because it is fast for both implementation and performance. It's fun and it works really well, as long as you know what you are doing. How's that different from Java, Python, Ruby etc...? One more thing, if you want to judge a language based on how much trouble you can into, what about C? Or what about the threading and memory leak issues you can run into in Java? I mean, all of these languages have massive pitfalls and none of them can effectively stop a bad programmer from doing bad things.

"So before you jump on that bandwagon thinking nothing interesting could possibly be done with PHP, think of us (or Facebook)."

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.

"Email marketing" + "I thought you were cool" = cognitive dissonance

PHP is fast and just about everybody "knows" it (which is a curse as much as a gift). But as someone who made a living writing PHP and made the jump to another language:

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 "cool factor" of a language is inversely proportional to its popularity.

This would be a reasonable defense of PHP if it didn't genuinely lack any sort of intelligent design. More sophisticated programmers hate PHP because it was thrown together like a Mad Max car.

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.

Just like with everything else...

human progress was never a result of religious fanaticism. sticking to one language because it is the "one true language" is a lot of crap.

"Get out of languages, platforms that's the important thing" - Zed Shaw said something like that a while ago

As opposed to its peers (eg. Ruby, Python), the original PHP was not a programming language but just a collection of tools for HTML preprocessing. Although the current PHP has nothing to do with the original one, and PHP 5.3 actually has pretty nice feature set with namespaces (finally!) and anonymous functions, its "non-academic" roots still show off as general ugliness. That's why I wouldn't recommend PHP to anyone as their first programming language (been there, done that, nowadays a Pythonista).

PHP devs are the silent majority.

Can an admin update the link to: http://www.mailchimp.com/blog/ewww-you-use-php/

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

I picked up PHP because it was like C (which I use since I was born) with training wheels and some quirks.

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.

I have been contracting for a company that has an in-house version of this tool. We are able to push about 10 million emails a day, including processing bounces, click, unsubs, etc, with a fairly straightforward set of python scripts. Its not about the custom logic, its about choosing the right basic building blocks.

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)

Everyone has to make his/her choice of technology and MailChimp has chosen PHP. That's perfectly okay.

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.

I grew up coding in PHP and still love it to this day, so I agree with the basic premises of this article.

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

PHP is a pretty decent lazy language, it just could give rise to bad habits. It also has a few odd irregularities in the naming of functions/argument order. It's just a massive arsenal of functions for everything. For example if people want to manipulate a string or array, newbies will often not pay any attention to how often it gets iterated through redundantly. They just use a bunch of functions that do what they want magically.

I have to say, I code in .NET during the day and have been considering ruby / python for my own projects because the hosting costs are a lot less. I used to do a lot of PHP and I keep thinking I should just stick with that.

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.

ASP.NET has always been the cleaner, nicer-to-use alternative to PHP. If you're already good at .NET i see zero advantage to saving the few dollars here and there that PHP would bring.

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.

Why F#?

Fair point, well made

I don't know, PHP used to be a security nightmare (or rather, it would encourage bad security flaws - I assume it is possible to write reasonably secure PHP web apps). Has that improved much? Yes, getting a site up and running is fast. Making it secure might be a lot less simple.

You can write secure apps in PHP. What I find unforgivable about PHP is that most of the code examples you will find on the web or in books is outdated and insecure. For example, a newbie looking for how to make a DB connection is much more likely to stumble on the mysql_* functions than on PDO.

I consistently read about ruby & python web apps are deployment issues


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

Deployment issues? Are we back in 2008? Don't tell me that Ruby doesn't scale or that developing in Python on a Mac is impossible because of the default version that ships with OSX.

Did I mention anything about either of those? Firstly, entire companies have been created specifically for ruby / rails hosting.

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

"Did I mention anything about either of those?"

Yes you did ("the only thing I consistently read about ruby & python web apps are deployment issues"). That was the reason I used them as my examples.

On your second point, I never assumed anything. I used two examples of common things that where said a few years ago about both languages. It had nothing to do with what you use, more power to you if you use windows7 and .net, it had to do with the fact both where misconceptions that where later proved to be non issues.

I didn't mean to be patronizing or anything, I guess what I really wanted to say is that if you keep reading that Ruby and Python have all this massive issues, you're probably reading articles from 2008 ;)

I don't understand the "PHP is fast" comments. Whenever I've had major scaling problems with PHP or anything else it's been due to IO rather than a fundamental issue with whatever language I was using.

The things I did to fix the performance problems are generally language agnostic. Improved database architecture, search indexer configuration, clustering, memcache, etc.

Yeah, PHP is slow. It's just that the speed of your language doesn't really matter. What is, in my opinion, an advantage with PHP (but not exclusive to it) is the whole share-nothing design philosophy and mod_php.

Speaking specifically of mailchimp, I interviewed with the a few years ago. They are a seriously cool company. If you ever get a chance to talk to Chad, ask him to tell you the story of DDoSing Mechanical Turk. Ignore the language they use, mailchimp is an amazing analytics company.

Does your customer care which programming language you use? The true test is if the application that was developed meets the requirements of the customer/consumer. I don't develop for other developers; I develop for customers that want the app to work.

> thirty million emails sent by tens of thousands of users every day

Damn! Are these all spammers?

I can say without doubt that it is the most sophisticated framework for this environment that I’ve heard of except for perhaps what Facebook uses.

He hasn't heard of Google? :-P

Uh, does Google use PHP? I think that's what he's referring to.

Define "this environment". I took it to mean handling large amounts of mail, in which case the gmail team has one of the most sophisticated frameworks, period.

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.

I think this is the money quote in the article

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

moozeek -

It's 2010 - link the post, not the blog

For posterity, the link to the post: http://www.mailchimp.com/blog/ewww-you-use-php/

Edit: never mind, http://news.ycombinator.com/item?id=1819021 already posted it.

Oh well, you built your own framework. That changes everything!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact