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

Taking PHP Seriously

slack.engineering

Post reply on HN
Print view View original

181–190 of 673 posts

Re: Taking PHP Seriously

#181

Post by davidw »

williamgb wrote: post #176
davidw wrote: post #112

Earlier quoted context omitted.

"Grok" is good. Perhaps it's that it sounds less pretentious, somehow?

Interesting! I have somehow developed the opposite opinion. The phrase "to reason" is plain English and uncomplicated. Grok, by comparison, is arcane and to the uninitiated is semantically opaque. The latter strikes me as a more suitable vehicle for demonstrating pretension.

Fair enough. I never claimed my dislike of "reasoning about" things was rational! 'Grok' definitely has a context, that likely does not include talking to non-hacker types like clients, board members, or whatever.

Re: Taking PHP Seriously

#182

Post by bpicolo »

greenhatman wrote: post #34
swalsh wrote: post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

Love this comment. I'm a PHP dev. I do care about my code though. I think you can write niceish code, even with a shitty language.

PHP always reminds me of the Dijkstra quote:

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

Re: Taking PHP Seriously

#183

Post by ux-app »

brian-armstrong wrote: post #152
chris_wot wrote: post #138

Earlier quoted context omitted.

Perhaps. But that rather begs the question. PHP has horrible bits, but in fact from what I've observed in the last year or so is that whilst it has in the past been fairly horrible, much of what made it awful can be entirely avoided. If you aren't following the PHP Framework Interop Group ( http://www.php-fig.org ) then you really should. I'd hazard that most of the warts in PHP can now be avoided pretty much altoget…

An easier way to avoid those warts would be to pick a different language

and miss out on all the awesome aspects of the language/environment?

Re: Taking PHP Seriously

#184

Post by bkanber »

Nullabillity wrote: post #31
Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT. You can get the same reasoning benefits in pretty much any language by just not using any global variables. Yes, you're still running a framework/server with internal state, but with PHP you've got the same "issue" with Apache/Nginx.

> very wasteful

Define "very". Because for me it's more like "a few hundred microseconds per request".

Re: Taking PHP Seriously

#185

Post by berntb »

weberc2 wrote: post #100
berntb wrote: post #63

Earlier quoted context omitted.

It didn't really, AFAIK (not a PHP guy, but old) it got traction because it was easier to get started with than the alternatives. That said, all environments will be one of three: 1 Have warts. 2 Not be used. 3 Be in denial and claim to be perfect. The GP had a point, perfection is the enemy of good. Something delivered is better than nothing.

What do you consider its cohort to be? PHP was the first language on my radar that didn't depend on CGI.

Uh, the early versions of PHP was written in Perl running under mod_perl, which was not CGI.

Also, e.g. fastcgi was around the same time frame.

(In order not to end up in a flame war regarding the first point I checked wikipedia -- see second paragraph of the intro here. :-) https://en.wikipedia.org/wiki/Mod_perl )

Re: Taking PHP Seriously

#186

Post by bkanber »

grok2 wrote: post #27
Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

Performance/scaling?

PHP is perhaps one of the easiest technologies to scale horizontally, because of its statelessness.

Re: Taking PHP Seriously

#187

Post by bpicolo »

leeoniya wrote: post #179
anarazel wrote: post #114

Earlier quoted context omitted.

Sure. But that doesn't really address the problem, just makes it smaller. You still need to reinstantiate a lot of runtime state.

I can't tell you how much more "runtime state" exists in PHP than in say Java. In both cases you need to initialize some sort of security-aware context. Once you've eliminated parsing, disk i/o and compilation phases. You should be on pretty even ground of bytecode vs bytecode. Java has a Hotspot JIT, so it will probably win there. I think a JIT is coming to PHP as well since the architectural rework that went into P…

There's more too it than that though, yeah? Say you use a service that uses oauth2 authentication. You need to do a request to pull in a oauth token. If you lose all state between requests, you waste time re-fetching tokens.

In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality

Re: Taking PHP Seriously

#188

Post by asimuvPR »

colechristensen wrote: post #86
asimuvPR wrote: post #32

Earlier quoted context omitted.

I've been in the game long enough to realize how true this is. Good point. It will certainly make people here defend their sacred choices.

Not everything can or should be well engineered. People that always chase this are worshipping false gods. Does anyone have experience working on something that at one point actually met with the high ideals a certain mindset strives for?

I've worked on enough projects to have covered both sides of the equation. The pristine codebase that belonged on a museum yet took way too much time to ship a feature. The other side of the coin with the codebase that somehow worked (no one knew how) and brought in millions because people would keep piling stuff on top of it. Have also worked with a codebase that started off awfully and was cleaned up enough to reduce the amount of time lost on stupid bugs and and thus increased how effective the team was delivering new features (with a direct financial improvement as a result because sales picked up significantly). It all boils down to finding a balance. Sadly, people confuse technical perfection with a product that works.

Re: Taking PHP Seriously

#190

Post by igravious »

wyager wrote: post #153
chris_wot wrote: post #138

Earlier quoted context omitted.

Perhaps. But that rather begs the question. PHP has horrible bits, but in fact from what I've observed in the last year or so is that whilst it has in the past been fairly horrible, much of what made it awful can be entirely avoided. If you aren't following the PHP Framework Interop Group ( http://www.php-fig.org ) then you really should. I'd hazard that most of the warts in PHP can now be avoided pretty much altoget…

It's not just about the obvious "warts"; it's about the fact that PHP is not a well-designed language on the first place. A wart-free pig is still a pig.

That's a bit harsh on pigs.
Post reply on HN