Hacker News Reader

For performance, not even Facebook levels. If you're having "scaling" issues that benefit from fast executing code (as opposed to a massive dataset management issue), PHP isn't really that fast at all. So why would you want to throw away CPU cycles when there are expressive languages that have a fast compiled representation, too?

I value dev productivity over performance in most cases, but it's silly to try to make a performance argument for PHP.

Couldn't the same be said of any interpreted language.

> 1. Until you hit facebook levels and have to write your own interpreter.

Facebook levels of load would be a great problem to have. Until then, who cares?

> 2. Sure, but your code will also suck and be hard to maintain.

Doubtful, but this isn't even a good point. Working software is the important deliverable.

> 3. Nonsense. You might as well say that everyone should use C because it was the first language with a TCP socket API.

You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'.

> 4. Nonsense. You can fuck up royally in any language.

He said as much in that point. Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here.

Color me unimpressed.

How can you argue that both "tied to the web" and "frameworks" are benefits, yet keep a straight face?

Frameworks in any language plug the language into the web—that's what they exist to do.

And if you're using the parts of PHP that are tied to the web, then you must not be using a framework, or those would surely be wrapped.

...but those parts of PHP must suck, or you wouldn't need to use a framework!

So then... PHP is good because it solves the problems it causes? I don't get it.

> Facebook levels of load would be a great problem to have. Until then, who cares?

It shows up a lot faster than at Facebook levels of load. Because php throws everything out at the end of every request, you're going to need to buy a lot more servers a lot more often if your app does take off. Or you end up paying zend lots of money for things like caching that are built into nearly every other language.

> Doubtful, but this isn't even a good point. Working software is the important deliverable.

Until you're stymied next year because your current codebase is falling apart.

> You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'.

I'd much rather have a language isn't tied to any particular ideology. Yes, your clients are web-based at the moment, but your database isn't web-based, your mail server isn't web-based, etc. Driving everything by your presentation layer is a terrible, superficial way of looking at problems.

> He said as much in that point. Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here.

The original blog author posted this with an air of php exceptionalism. Other languages equally have no problem handling the issues that this author claims exist.

This blog post, and your response, is a classic example of the php hammer syndrome. Yes, it kind of works, and seems neat at a superficial level, but once you start to use it, you start seeing all of the glaring flaws in the actual delivery of the product. Workarounds become dogma, and everyone suffers as a result.

> Facebook levels of load would be a great problem to have. Until then, who cares?

Good question, why did he bring it up? As others pointed out, it doesn't even make sense: your data store is where you have to scale, not the language itself.

> Doubtful, but this isn't even a good point. Working software is the important deliverable.

Hmm. I thought the goal was working and maintainable software?

> You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'.

No, it makes sense to choose the most powerful language. A language that's "basically tied to the web" means that you can't use it to do other things when your business needs change.

> He said as much in that point.

No, he said that php makes it less easy to screw up, which is simply not true. What if, late at night, I call mysql_escape_string (because, hey, the name makes sense!) instead of mysql_real_escape_string? Type systems make it harder to screw up. Poorly named escape functions, ridiculous type coercion, and a gigantic global namespace do not.

> Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here.

They see me trollin', they hatin'.

Doubtful, but this isn't even a good point. Working software is the important deliverable.

An unmaintainable codebase makes it hard to deliver working software in the future.

So programming in PHP means that your code base will be unmaintainable?

No, deciding not to hire good programmers means that your codebase will be unmaintainable.

Next time, maybe try reading the thread before commenting? Here's the discussion up to this point:

OP: "If the event that my new ventures grow and I need to hire on more programmers I do not need the best and brightest to get the job done."

tych0: "Sure, but your code will also suck and be hard to maintain."

Domenic_S: "Doubtful, but this isn't even a good point. Working software is the important deliverable."

argv_empty: "An unmaintainable codebase makes it hard to deliver working software in the future."

You: "So programming in PHP means that your code base will be unmaintainable?"

I did read the thread, thank you.

"An unmaintainable codebase makes it hard to deliver working software in the future." is a truism that I chose to respond with a question, because I am not of the opinion that Domenic_S was even remotely suggesting that anyone write unmaintainable code.

Domenic_S's argument of "working software is the most important deliverable" isn't really a bad point, regardless of what language you're using. If you have maintainable code that doesn't address the application's requirements, how much does maintainability matter then?

In the real world, there is hierarchy of priorities, and for most, working is at the top of the priority list.

You'll have to talk to tych0 about that. I'm just responding to the idea of setting aside maintainability in order to produce working code.

1. Pretty sure Facebook is the only one hitting Facebook levels. Facebook is an outlier, don't use this as an example to invalidate his entire point.

2. There are great PHP programmers...just because you're writing something in PHP doesn't mean your code sucks. There is a ton of crap PHP code, but not all. Ruby and python also have their fair share of terrible developers and shitty code.

> 1. Until you hit facebook levels and have to write your own interpreter.

Or use the one that Facebook open sourced.

The documentation for PHP is great. But in order to do many useful things in PHP, you really, really need the documentation. FWIW, I don't find other solutions hinging their success on documentation as much as PHP.