Live data from Hacker News

A look at modern PHP

lwn.net

571–580 of 610 posts

Re: A look at modern PHP

#571
post #569

Earlier quoted context omitted.

idk, seems like a very narrow area to get fixated on (deployment/local development)? I do think Django is less complicated than Spring. You don't have the whole dependency injection lifecycle thing to grasp which isn't easy for someone who never seen it before. Django and PHP are closer in spirit than Spring, also due to dynamic types.

I agree that Spring has a steeper learning curve than Django, but I disagree that Django is more similar to modern PHP frameworks than Spring. Django isn't MVC, it's an entirely different architecture. Symfony framework is heavily inspired by Spring [1], and modern frameworks like Laravel heavily influenced by it and extensively use its libraries. >You don't have the whole dependency injection lifecycle thing to gras…

Ah, that's new! had no idea PHP copied this concept from java. Rails completely avoids dependency injection. You know what, if the php community starts to heavily type annotate and use a framework like Symfony, I start to fail to see the point of using that and not java.

Re: A look at modern PHP

#572
post #416

Earlier quoted context omitted.

The really nice thing of Symfony framework is database schema mapping and migrations, which have compatibility with numerous database systems and provides abstraction layer [0], that among many options of interfaces have quite handy YAML-formatted schema mapping [1]. Nothing extraordinary these days but it is really stable and simple to use. [0]: https://symfony.com/doc/current/doctrine.html [1]: https://www.doctrine…

Do you ever profile doctrine? I found its overhead to be 10x the actual time of my average query. Most of the time is spent hydrating. I wonder how people can put up with such a level of performance reduction and still claim they are using decent tools.

Of course! I believe almost all PHP devs noticed, they have terrible slowdown by Doctrine and used XDebug to check where is the problem. I am not PHP dev anymore and I hope it has improved a lot since my last adventure with this ORM but I'd still advocate to not use it on client-facing interface - you can use Doctrine only for database management (CLI), while for web interface use raw PDO or equivalent (Eloquent). You can also use cache or transform page into static-site. Sky is the limit.

Re: A look at modern PHP

#573
post #416

Earlier quoted context omitted.

Do you ever profile doctrine? I found its overhead to be 10x the actual time of my average query. Most of the time is spent hydrating. I wonder how people can put up with such a level of performance reduction and still claim they are using decent tools.

Oh doctrine, those were the days... I spent a couple years working on a project that was eventually rewritten in rails because there was a memory leak that required restarting the server ever night via cron.

Yeah, PHP scripts in CRON, especially those using some relational database were my nemesis that time too. The nice thing, which in PHP 5.5 was introduced is generators, that almost completely resolved the problem with memory leakage in such scripts IMHO.

[0]: https://www.php.net/manual/en/language.generators.overview.p...

Re: A look at modern PHP

#574

Earlier quoted context omitted.

Ya? Can't speak for others but I've worked on many legacy C++ codebases over the years, it has never been a pleasant experience. Even when it's a C++ 17 codebase the same bad practices from C++ 11 and earlier are all present and accounted for. As are the subtle bugs stemming from an inconsistent standard library and C++'s approach to verbose error handling. I'm sure that there's plenty of good C++ code out there, may…

> I can literally copy and paste what you said replacing it with any language and end up being correct. This is the best point in this thread, IMHO. I think it also is due to the fact that PHP is a fairly easy language for a non-coder to pick up little-by-little. One can easily start using it for doing simple things, like injecting dynamic data into a web page. From there one can learn to scale up to full web apps. I…

> I think it also is due to the fact that PHP is a fairly easy language for a non-coder to pick up little-by-little. One can easily start using it for doing simple things, like injecting dynamic data into a web page. From there one can learn to scale up to full web apps.

I personally started using PHP because, at the time, the free hosting servers only had support for it. Otherwise, I could probably have picked python, ruby (or even perl). I wasn't a non-coder, but I think that these languages may be self-taught with the same ease as PHP (well, maybe not perl).

> In my 20 years of writing code (starting with PHP) I have learned the lesson over and over again that while writing code commercially the fact that the language has feature X or that it forces certain patterns means almost nothing. Sure, your developers might feel better about themselves but that is about it.

But, isn't that the whole point of using PHP 7.4 over, say, PHP 3 (besides evaluation speed)? Would you code in PHP 3 today, if PHP had not evolved at all?

Re: A look at modern PHP

#575

Earlier quoted context omitted.

> Probably more than modern statically typed languages. True, but most people considering PHP probably aren't considering statically typed languages. They're probably comparing it to JavaScript, Ruby, and Python. PHP holds it's own surprisingly well in that comparison. It certainly has it's fair share of quirks, but so do the others.

Most statically typed languages have nothing close to rails/laravel nor the ecosystem surrounding them.

Spring and ASP.Net? Come on.

Re: A look at modern PHP

#577

Earlier quoted context omitted.

I think what the comment really means by "request scoped" is that the PHP process is totally torn down after each request. In Java you can mutate global state as its running. You can leak memory until you OOM.

Tbh, that's done in modern PHP frameworks as well. ReactPHP & Co rely on you not using global variables, Symfony's architecture is built for that as well. You don't want to incur the startup cost for every request, because it's very slow. This doesn't matter a lot in single requests of course, but once you're writing APIs that get considerable traffic, you'll want to cut out those 50ms and the load.

I think the php7.4/8 preloading stuff may address some of that sort of use case.

Re: A look at modern PHP

#578

As someone who has programmed PHP professionally for 13+ years (and also JS and Python) I have never run into anyone who can place a solid argument since the PHP 7 + Laravel. -- Let me clarify, PHP is useful with context. For building web apps. Each language has its best-uses. Laravel has the strongest ecosystem and community out of any language/framework combo I've seen. I can literally setup and deploy a laravel ap…

> Do you remember Javascript before Node/React? Or before jQuery/Prototype? It was _trash_. Anyone remember Dynamic Drive DHTML? http://dynamicdrive.com/

Ha! I recall Dynamic Drive.

Re: A look at modern PHP

#579
post #575

Earlier quoted context omitted.

Most statically typed languages have nothing close to rails/laravel nor the ecosystem surrounding them.

Spring and ASP.Net? Come on.

I haven't used Spring, but I had high hopes for ASP.Net (C# is a very well designed language) and found that not only was the ecosystem around it decidedly lacking, and even the core libraries like EntityFramework were much less flexible and well designed than I am used to in the PHP/JavaScript ecosystems. And they didn't seem be that actively maintained either.

PHP usually has a good library for most things. JavaScript usually has 3-5 good choices (but nothing rails-like). .NET often seemed to have nothing, or only proprietary options.

Re: A look at modern PHP

#580
post #157
post #89

Why do these discussions always end up in some black/white dicotomy? Are there situations where PHP is a valid part of a tech stack? Sure. Are there places where, if you could choose, PHP is not a good choice in the stack, Yup. My personal view of it is that it is part of our eco-system and will not go away, how eager some of us may be to have it disappear, so seeing it getting better as a platform should make the wo…

> The thing I dont understand is, if you for some reason do not like to use a specific language or tech, why bother trying to convince others not to use it? Because, if others use it, I have a higher chance of also having to use it. I do not use Java and JS at work because of my like or dislike of these languages; I use them at work because, many years ago, whoever started the project I'm working at chose these langu…

I guess the "poor" in "poor language" is in the eye of the beholder and I get your point. Have you found yourself lucky in convincing the world in not using any language yet?
Post reply on HN