Live data from Hacker News

Why PHP won

startuplessonslearned.blogspot.com

11–20 of 61 posts

Re: Why PHP won

#11
Most importantly, back in the day 1998/1999 there was not much around that could match up to the functionality of PHP. Java servlets were not supported widely, Netscape had their serverside javascript wich required you to buy into their servers... Going with PHP was a no-brainer for any small web-shop/startup. With all the web stacks that are available today, it wouldn't have been that clear.

Re: Why PHP won

#12
post #2

Good article. To add a few things: 1. PHP doesn't require routing. It's done for you by Apache to the PHP file at that location. Sure, you can go the way of nice frameworks like Cake and add routing for nicer URLs, but it's not required . PHP has some solution built in. 2. Deployment. The author touched on having to restart when using mod_perl, but it's more than that. In most cases, uploading files is enough. That's…

Agree with your additions completely and would amend your #3 to say that PHP was big on re-use in the small, as well. I've known folks starting out with PHP who cobble a script together by copy-pasting snippets of code from here and there. Inelegant, yes, but when you are working on a small project it was usually effective.

This leads me to one point about PHP's documentation that I was surprised not to see. Their documentation has always (as long as I can remember, at least) had public comments. On many occasions questions I have had or example code I needed was crowdsourced by the public and located in-line below the function reference. I have been surprised other platforms don't make more extensive use of this.

Finally, in response to your "I guess I'm looking for something else." Understand your discontent - I've felt it myself over the past couple years and have found myself toying with Djagno, et. al. This fall I found myself returning to PHP with a mission to create a framework that I could use and not feel shamed to be in PHP. It's still early in development (4 months) but I believe it is looking good and getting exciting. It's called Recess, check it out sometime: http://www.recessframework.org/

Re: Why PHP won

#14
post #6
post #2

Good article. To add a few things: 1. PHP doesn't require routing. It's done for you by Apache to the PHP file at that location. Sure, you can go the way of nice frameworks like Cake and add routing for nicer URLs, but it's not required . PHP has some solution built in. 2. Deployment. The author touched on having to restart when using mod_perl, but it's more than that. In most cases, uploading files is enough. That's…

Item 2 should not really be a problem unless you are using cheap shared hosting. You should test your stuff on your workstation, not on the server. If you do not test on the server, the whole restart apache after you upload something becomes moot. Also, if you happen to change many files, what will users see in your application when half of the site uses new logic and half of it used the previous one? This is a nasty…

I think the point is that PHP grabs people when they're on cheap shared hosting and they continue using it as they build more complicated stuff.

Re: Why PHP won

#15
post #4

You know, after seeing over and over how the supposedly worse ways actually worked better - perhaps it's time to re-decide what is actually good and bad in a language?

It's the old worse is better thing all over again: http://www.jwz.org/doc/worse-is-better.html

Maybe all the "better" languages are a case of misdirected optimization, where the critical resource is developer time?

Re: Why PHP won

#17
To summarize it, I would say PHP is the "get shit done" language. It allows people who are just starting out with programming or people who aren't very technical to focus on what they need to have, rather than on the best way to do something. This is why so many websites (Flickr) and OS pieces of software are in PHP - they focused heavily on what users would be seeing, rather than what developers would be seeing and won out.

Of course, PHP doesn't preclude good design either. Once you have a working product that is excellent on the outside but ugly on the inside, you can start spending more time refactoring your code, or even slowly migrating your system piece-by-piece to another platform.

Re: Why PHP won

#19
post #4

You know, after seeing over and over how the supposedly worse ways actually worked better - perhaps it's time to re-decide what is actually good and bad in a language?

It just depends where you are in terms of experience. It's not that one is good or bad. PHP is easy to understand, and you can jump right into it with no experience. However over time if you have any potential as a serious programmer you will find the pain points and repetitive tasks.

In many ways, experienced programmers and language elitists are a lot like corporations. They are risk-averse. The reason best practices are what they are is to avoid known problems (sort of like bureaucracy). This will make you a better programmer to a certain point, but it's also so easy to overestimate risk. The painful truth is that a 20-year-old hacker figuring out things as he goes may be able to plow through the naive problems he inevitably creates and arrive at a finished, valuable product faster than a seasoned developer who writes uber-maintainable code with a comprehensive test suite and every best practice he can lay his hands on.

Re: Why PHP won

#20

"The platforms that win on the web are those that mirror its fundamental structure, not those that try to morph it into a more traditional "elegant" shape." This reminds me of why C succeeded, because it mirrors Unix so well, that C and Unix succeeded hand in hand. So this part about PHP mirroring the shape of the web made the most sense to me, as someone who doesn't know any PHP.

>C succeeded, because it mirrors Unix so well

Actually, Unix succeeded after it was rewritten in C. (Not counting the very first Unix version which was done in assembler. See http://www.livinginternet.com/i/iw_unix_c.htm )

Post reply on HN