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

261–270 of 673 posts

Re: Taking PHP Seriously

#261

Post by combatentropy »

PHP is wonderful as a thin layer of glue between your database and the web browser. It's when you write a thick middle layer that PHP gets unwieldy.

Business logic: Don't write it in PHP. Write it in PostgreSQL.

Authentication: Don't write it in PHP. Use Apache 2.4's mod_auth_form. Replace hundreds of lines of PHP code with a few lines of Apache config. When it gets to your PHP script, all that's left to do is read $_SERVER['REMOTE_USER'].

Authorization: Don't write it in PHP. Use one of Apache's modules (LDAP, DB, or even file) or if possible make your users all very restricted database users and use database permissions more.

Don't need a database? Then why not handle it all on client-side JavaScript?

I'll admit that my advice fits well with CRUD web apps. If you're doing something else, PHP may be gross.

But really, my goal in programming (don't always reach it) is for PHP to just make a simple database call and wrap the result in HTML. If you're doing 123 == '123foo', can you move that up into the database or down into the browser? If you're writing elaborate class hierarchies in PHP, I think you're doing too much in PHP. I write a few functions, if needed, but mostly move all data processing to the database or browser.

Re: Taking PHP Seriously

#262

Post by codedokode »

anarazel wrote: post #18
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…

This is my least favorite part. As soon as your program gets more complicated the amount of repeated parsing, compilation and setup you need to do for every request causes massive speed and structural issues.

You can add a ReactPHP based HTTP server to your app to avoid reinitializing, but you'll have to deal with memory leaks between requests and process management yourself.

Re: Taking PHP Seriously

#263

Post by steveklabnik »

codedokode wrote: post #243
wyager wrote: post #221

Earlier quoted context omitted.

Rust and Haskell are both extremely well designed. Most of the "top languages" by percentage usage are 20+ years old, so I can't fault them that much for being badly designed, but we should definitely stop using them.

Rust looks very complicated to me because there are "lifetimes" and you need to think where to put those single quotes properly. Not a language for a beginner. Haskell doesn't support OOP if I remember correctly. And it is complicated too.

Due to lifetime elision, you rarely need to explicitly write lifetimes. I participated in the last Ludum Dare game competition, my game never used an explicit lifetime.

That said, it is true that Rust has tricky parts. The domain is inherently complex.

Re: Taking PHP Seriously

#264

Post by chiefalchemist »

hueving wrote: post #96
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…

This sounds like to me you are mistaking the popularity of PHP with the proficiency of the developers. PHP has been around a long time and is used by lots of people. Even if PHP projects only have a 1% success rate and haskell projects have a 20% success rate, guess which one will have more "successful projects".

I think the point is, PHP won't kill you. It might be bad. But it is not in and of itself deadly.

Re: Taking PHP Seriously

#265

Post by aikah »

bkanber wrote: post #186
grok2 wrote: post #27

Earlier quoted context omitted.

Performance/scaling?

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

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

PHP is no more stateless than any other language out there. Statelessness is a design choice, not something PHP gives you for free. If your app write things on the local disk or use the default PHP session handler then it is not scalable by default. In order to write code that scales you need to make it scalable, it's not something automatic and certainly not special to PHP.

Re: Taking PHP Seriously

#266

Post by qwertyuiop924 »

codedokode wrote: post #236
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…

I don't like the term "garbage language". People use to praise languages like Ruby or Python which don't even have private fields or type hinting the PHP has. Ruby libraries use approaches like monkey-patching classes in other modules. And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?

Javascript actually has less problems than PHP. It also has proper lambdas, true lexical scope, and a shockingly good (if slightly confusing) OO system.

There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.

Re: Taking PHP Seriously

#267

Post by TazeTSchnitzel »

mrmagooey wrote: post #218

I'm surprised no one has posted this fairly thorough criticism of PHP from a few years ago https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

It's a useful reminder that how ever far PHP has come, it still has a long way to go. Most of what's in that post still applies today, though a few things have been dealt with.

Re: Taking PHP Seriously

#268

Post by pre »

oridecon wrote: post #148

Sorry to sound so dramatic but I don't know how to put this in better words: After reading this thread, is there even a proper way to measure how good a language is (trade-offs, benefits down the road)? Having done web stuff in PHP and Python I think both are terrible. So, how would a programmer trying to avoid his own biases and anecdotes find what tools are right for each job? Maybe I didn't "liked" PHP and Python…

> is there even a proper way to measure how good a language is?

Nope.

I mean.

They're all Turning Complete (except for the ones that deliberately aren't), and they're often good at expressing different types of problems.

So depends what you're trying to do.

Trouble is, it so often turns out you didn't really know what you were trying to do till you were nearly done doing it and then you're stuck with what you picked.

PHP is pretty good for building website prototypes, and can now handle the scale as they grow too really.

But "Good" depends on what you're trying to do, and what tools you already are running anyway.

Is there a way to measure how good a spanner is compared to a hammer?

Re: Taking PHP Seriously

#269

Post by TazeTSchnitzel »

astrodust wrote: post #194
krapp wrote: post #177

Earlier quoted context omitted.

PHP isn't at much of a disadvantage - it has its own native JSON encode and decode functions. Granted, actually using javascript is better but it's not as if you have to import a library or write your own JSON parser.

It's not the decoding and encoding stuff, every language has that, but the difference in accessing the data. $data['key']['value'][0] is a lot messier than data.key.value[0]. Ruby has ways of mitigating this, but you pay a performance penalty.

There's also $data->key->value[0], which is the default. But yes, dots are shorter.

Re: Taking PHP Seriously

#270

Post by codedokode »

weberc2 wrote: post #217
tyingq wrote: post #193

Earlier quoted context omitted.

>>PHP's "new process per request" is a solution to a problem that PHP created for itself True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out. PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process. Combined with the now bundled opcache, the re-work per request is limited to the developer's own…

> True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out. The OP's question wasn't scoped to the mid-90s. > PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process. Like I said, the same holds true even for an OS thread. Anyway, if it's not a new OS process, then some sort of GC is needed, contrary…

I don't think so. You either keep state between requests and therefore get problems like memory leaks (which often happen in large Ruby or NodeJS apps written by not very experienced developers) or you keep no state and have to do initialization on every request.
Post reply on HN