Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taking PHP Seriously [pdf]

raw.github.com

Post reply on HN
Print view View original

61–70 of 155 posts

Re: Taking PHP Seriously [pdf]

#61

Post by leokun »

LeafStorm wrote: post #27
leokun wrote: post #23

Earlier quoted context omitted.

In what ways is PHP less hassle than Python? I don't understand this argument.

Deployment, for one. sudo apt-get install Apache and PHP, then edit the Apache config to say, "use this directory." I love Django and Flask to pieces, but deploying a Python app is like building a hovercraft compared to PHP.

I have no problems deploying a django app with gunicorn. It's a simple command line statement, and deployment is always an intricate thing, unless you don't have to worry about ssl certs and secrets and keys, and managing access, admin pages, etc etc.

Re: Taking PHP Seriously [pdf]

#62

Post by gfodor »

I feel like the reason you don't see a web app development model that takes from the best ideas from both PHP model and the Rails/Django model is because by the time you've been exposed deeply enough to both of these approaches to truly understand the benefits and flaws of each you are way too cynical and burnt out on the idea of tooling around building "the next big web framework." Instead, after watching trends come and go, you just take whatever you can get for free and go out and solve real problems with it.

Re: Taking PHP Seriously [pdf]

#63

Post by wanderr »

jtreminio wrote: post #45
wanderr wrote: post #41

Earlier quoted context omitted.

Hmm, how so? In general it seems to make testing things easier since nothing is carrying around state; a static method with the same parameters is going to run exactly the same way every time no matter where or when it's called.

You are unable to properly mock static methods. So, for example, if you have a AuthorizeNet class that has a static method ::submit(), if you test the code then every single time you run it you're pinging Authorize.net's servers, which opens you up to a world of hurt. Properly mocking methods allows you to get rid of this unknown and say, "The submit() method will return an array of this specified data" without Autho…

Perhaps I'm missing something, what about static methods prevents you from having a mock AuthorizeNet class implementing the same interface but with a submit() method that just returns fake data? Perhaps there is something specific to the testing framework you use that makes this clunky?

As far as static properties go, if you're mucking with those you're back into the world of storing state, which OO is more suitable for, but the whole point is to avoid doing that wherever possible. :) What I was getting at before is that we really use a mixture of both real OO and procedural with class-namespaces-static-methods wherever each thing makes sense, but given the nature of what most backend PHP is trying to accomplish, the latter ends up being the majority.

Re: Taking PHP Seriously [pdf]

#64

Post by jtreminio »

wanderr wrote: post #63
jtreminio wrote: post #45

Earlier quoted context omitted.

You are unable to properly mock static methods. So, for example, if you have a AuthorizeNet class that has a static method ::submit(), if you test the code then every single time you run it you're pinging Authorize.net's servers, which opens you up to a world of hurt. Properly mocking methods allows you to get rid of this unknown and say, "The submit() method will return an array of this specified data" without Autho…

Perhaps I'm missing something, what about static methods prevents you from having a mock AuthorizeNet class implementing the same interface but with a submit() method that just returns fake data? Perhaps there is something specific to the testing framework you use that makes this clunky? As far as static properties go, if you're mucking with those you're back into the world of storing state, which OO is more suitable…

I am completely against create actual files to make mocks.

I use PHPUnit, the de facto standard for testing php code.

To create a proper mock in it, you use getMockBuilder()

Re: Taking PHP Seriously [pdf]

#65

Post by samuellevy »

Before this turns into a recanting of the points in the "PHP is a double-clawed hammer" post again, I would like to remind people that PHP still has a place in the business world that nno other language has stepped up to fill.

http://blog.samuellevy.com/post/41-php-is-the-right-tool-for...

Please stop complaining about how horrible PHP is if you don't use it or have. intentions to replace it.

Re: Taking PHP Seriously [pdf]

#66

Post by samuellevy »

Before this turns into a recanting of the points in the "PHP is a double-clawed hammer" post again, I would like to remind people that PHP still has a place in the business world that nno other language has stepped up to fill.

http://blog.samuellevy.com/post/41-php-is-the-right-tool-for...

Please stop complaining about how horrible PHP is if you don't use it or have. intentions to replace it.

Re: Taking PHP Seriously [pdf]

#67

Post by jdjb »

badclient wrote: post #35

Most of the criticism of php seems to contrast it with a language plus a framework. If you really want to compare, compare php with ruby or python, not Django or RoR. As for php encouraging shitty programming, a good bit of that is that so many more people program in php because its easier to get started with. This does not mean that just because php attracts shitty programmers that it doesn't have more or many aweso…

The linked article explicitly states that the author has found (albeit anecdotally) that good engineers are very very productive in PHP. I've found this myself as long as you don't go writing code that sits in PHP's "hmm, what'll happen if I do this..." area.

Re: Taking PHP Seriously [pdf]

#68

Post by skore »

harshreality wrote: post #14
vinight wrote: post #3

obligatory X is better than php flames on the way.. php just works.. end of story

$productid = "0x4zz5"; print $productid + 4; If printing "8" is your idea of a working interpretation of that code, then PHP is the language for you. If not, then PHP doesn't work. End of story.

I've been coding PHP for almost 8 years now. The number of times that I have come across anything even close to that example is precisely zero.

Re: Taking PHP Seriously [pdf]

#69

Post by justinhj »

jasonlotito wrote: post #42
memla wrote: post #17

Earlier quoted context omitted.

Things like this and some interesting developments from Facebook concerning them are mentioned in the presentation, so it would be nice if people would actually discuss that. Just a suggestion.

It's PHP. Unfortunately, enough developer got bit by the fact that PHP doesn't prevent you from shooting yourself in the foot, and shot themselves in the foot. So, you'd probably be pretty ornery too when other people had more discipline to use the language without shooting their foot and were also employing it successfully. You'd probably want to make assumptions, and word hard to belittle them. Insult them. And the…

PHP may have a bunch of ways to shoot yourself in the foot, but you get a new foot back right away. IMHO the oddities in PHP rarely hit you, and when they do you'll pick it up right away in PHPUnit, fix it, and walk away.

Re: Taking PHP Seriously [pdf]

#70

Post by xkiwi »

dkhenry wrote: post #44

At this point we almost need to stop saying facebook programs in PHP. I know this was defending PHP, but look at what is happening. Facebook ( big engineering firm, lots of developers and resources ) could not get php to work for them short of rewriting the core (HPHP ) and then adding on features to the language that most other languages have determined are useful enough to be baked into the language. Here is my TL;…

Another hard example: A start up wants the cutting edge tech so they use hphp. The company ran out of money before it finish complied.
Post reply on HN