Live data from Hacker News

Taking PHP Seriously

slack.engineering

231–240 of 673 posts

Re: Taking PHP Seriously

#231
post #4
post #2

I've had to do some PHP work recently, on a fairly old school PHP codebase for a high traffic website, after spending most oy my career working in Java and C# (and I still do most of my work in those languages). I've read a lot of PHP hate over the years, but I've found working with it in practice to be decidedly...not bad. Perhaps the codebase I inherited is better than most. But I've had to make some fairly major u…

The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C. The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3]). But PHP7 is both fast and productive with many modern first-class features. You can in fact write excellent code without much effort that will handily outperform Py…

> The devs are ultra-conservative and stubborn to cause BC even at major version bumps

Well, breaking backwards-compatibility comes at a cost. Avoiding another PHP 4/5 or Python 2/3 situation is the goal. It doesn't mean nothing gets changed: PHP 7 has a long list of backwards-compatibility breaks.

Re: Taking PHP Seriously

#232
> Inconsistency around reference, value semantics.

I ran into this problem today with some code by a programmer who should have known better. The problem is not with PHP, it's with programmers who learn one version and then don't keep up and change as the language evolves and improves (ain't nobody got time for that.) One guy I work with is still programming PHP like it's year 2000. It's maddening. PHP7 is a very nice language. People decided JavaScript was cool after "The Good Parts" came out. The same is true for PHP. If you learned PHP3 in high school and are still banging out code like you did then, you're the problem, not the language.

Re: Taking PHP Seriously

#233
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…

To clarify, I didn't say that no GC would be needed, just that it can be much less robust, use quicker algorithms, and in many cases is simpler to actually implement.

Re: Taking PHP Seriously

#234

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…

I worked on a large-scale (30m+ users, tons of concurrent sessions and high request rates) site + online service + native client setup in PHP for years.

This was never actually an asset. Startup times were huge, lack of shared state meant extra requests to database servers (and to memcache instances to avoid database round trips) to get the same data per-request. Each request got longer and a given page or api call might issue many duplicate requests in a short period of time.

Plus since PHP doesn't have viable threading or async (definitely didn't at the time) each memcache or sql request had to be synchronous, resulting in even more wasted time. At the very least memcache had good support for batch operations so we could manually batch our queries.

Overall though this is not an asset. It's only the 'best' part of PHP if you don't want to think about writing good software that manages shared state.

To be fair, many applications don't actually benefit from being good code, so PHP is probably a good fit for those.

Re: Taking PHP Seriously

#235
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.

"Reason about" is pretentious, and "grok" is jargon. I think the way to say it in plain, everyday English is "understand."

Re: Taking PHP Seriously

#236
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"?

Re: Taking PHP Seriously

#237

Earlier quoted context omitted.

You should definitely try vscode. I've found it to be the easiest to set up step debugger for PHP and it's not a heavy ide like intellij

Step by step with the ability to execute arbitrary expressions in the middle of it? That's the important bit. What VSCode extensions are useful here?

Official docs are a good starting point:

https://code.visualstudio.com/Docs/languages/php#customizati...

Re: Taking PHP Seriously

#238
There have been huge improvements made with PHP over the past few years. PHP 7 is great and I would choose it over Hack. Modern PHP using autoloading (Packagist & Composer) and an MVC structure allows for rapid development. With frameworks such as Laravel, you can get something up quickly or just pull in Packagist libraries you need if you don't want the bloat of a framework.

I recently finished up a fairly complex web app that uses PHP 7 for the back-end. Took me under 2 weeks to develop partly because I was able to leverage a lot of stable and well supported libraries through Packagist. It brought in over $4k its first month. Not bad for 2 weeks worth of work. It would have been hard to accomplish the same thing that quickly leveraging Node or Python (I use both) at lease for this app.

Re: Taking PHP Seriously

#239

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/

There was a time I thought Toyotas were beautiful cars and American cars were crap. Then some years later I had two occasions to rent a car. The first time I got a Toyota. Absolute crap. The transmission couldn't stay in the same gear with even slight inclines. The next time I rented a Chevy Malibu. An absolute dream. Loved that car. I learned a lesson to not let my prejudices prevent me from taking another look.

Re: Taking PHP Seriously

#240
post #192

Earlier quoted context omitted.

> On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it. If you read the thread, no one could actually recall having ever seen code that relies on the current behavior. It has been discouraged in the docs for years . The stop-gap proposal was to have PHP7 deprecate it with a warning rather than silently changing the behavior. Then change the behavior in a future ver…

I'd rather they don't change it. I like my code to not stop working (python3, perl 6) when upgrading. Also it's not a bug, more like a design oversight that doesn't cause any problem if you rtfm

> doesn't cause any problem if you rtfm

unfortunately, that's PHP's mantra for unexpected/inconsistent behavior (of which there is a plethora)

Post reply on HN