Live data from Hacker News

PHP in 2019

stitcher.io

301–310 of 489 posts

Re: PHP in 2019

#301

I'm working in a vanilla PHP codebase right now, and I see all sides - the fractal design fails and the surprising improvements to the language. I've just read up on the architecture of Laravel, and given the public opinion of it, must be a very nice framework. What strikes me most about PHP is the fundamental request/response execution model. Your execution context begins when a request is received and ends when we…

This execution model is just good old CGI scripts [0].

[0]: https://en.wikipedia.org/wiki/Common_Gateway_Interface

Re: PHP in 2019

#302
post #282

I've been using PHP semi-regularly since the late 90s. It's been empowering and infuriating. The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards. For whatever reason, I often feel clu…

Laravel has Collection class that wraps arrays - as such you can do `(new Collection([your array]))->filter(function(){})` or `(new Collection([your array]))->map(function(){})`. It also adds other helper methods. I guess Symfony has something similar Reference: https://laravel.com/docs/5.8/collections

Or collect([your array]). I love Laravel collections.

Re: PHP in 2019

#303
post #18
post #15

Earlier quoted context omitted.

> Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy. It's also use abysmal amounts for RAM for some reason. I managed to use Chrome headless for my app with only 512MB, but not Composer.

How long ago was that? There were some issues if you had xdebug enabled, but AFAIK that has been fixed.

I've had fun issues recently where Composer crashed after hoovering up 1.5 GB of memory. (Composer sets that limit by itself on startup, I didn't arbitrarily choose that number.) XDebug was off. I fixed it by telling Composer to use unlimited memory.

Re: PHP in 2019

#304

Earlier quoted context omitted.

What's wrong with Laravel or Symfony?

Laravel and Symphony, in particular, have the terrible code smell of elongated toolchains, that are specific to the frameworks. > php artisan serve # laravel > symphony server:start # symphony Same poor thinking that NodeJS introduced, albeit less offensively integrated. If you need additional toolchains, you're not using PHP per se, but another meta-language. There's literally no good reason to do this other than to…

Never met a Laravel developer who actually uses php artisan serve. Sounds like you're fighting windmills.

Re: PHP in 2019

#305

I think the easiest thing to forget is what made PHP popular was how easy it was to get started writing software that worked good enough. The barrier to entry was incredibly low. It caused a lot of bad code & gave PHP a bad reputation but a lot of good was also made from it. PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant valu…

> PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses. Unfortunately it also provided a lot of careers to developers who never got to the "make it" stage.

I think it's a bit harsh and elitist to label this with "unfortunately"; for developers like the ones you mention, often their goal or aspiration is not to work in a FAANG or silicon valley startup; they want to make a decent living as a developer in their city and this provides that career for them. Many of those companies aren't trying to be the next unicorn, they're just small dev teams trying to maintain a web site for their business.

Re: PHP in 2019

#306

Earlier quoted context omitted.

Have you ever tried building, deploying and maintaining Java? There is more to a language than the syntax

I have. And honestly, with modern, professional PHP development, most of us are not just FTP'ing PHP code to our shared host to deploy. So realistically, we are dealing with some of that deployment complexity regardless. The modern Java ecosystem has tooling like Maven and Gradle. IDE support and static analysis in Java is more advanced as well. As I said above, the additions are fantastic and I think they have absol…

I agree that once you get a certain size of application, you effectively reduce the complexity of deployment to a small portion of the overall work. In those cases, something like Java is probably appropriate. In fact, most companies leave Ruby/PHP for Java service once they mature.

I was more referring to your statement of using Java over PHP. PHP's syntax may be approaching something like Java, but the differences between the languages are still so vast, that they are only similar in syntax.

Re: PHP in 2019

#307

I think the easiest thing to forget is what made PHP popular was how easy it was to get started writing software that worked good enough. The barrier to entry was incredibly low. It caused a lot of bad code & gave PHP a bad reputation but a lot of good was also made from it. PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant valu…

> PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses. Unfortunately it also provided a lot of careers to developers who never got to the "make it" stage.

Why on earth is that unfortunate? Seems like a positive thing to me, even if some people don't make it to the pinnacle of their craft so what? If someone has gainful employment and meaning in their life I see that as a net positive.

Re: PHP in 2019

#308

I've been using PHP semi-regularly since the late 90s. It's been empowering and infuriating. The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards. For whatever reason, I often feel clu…

I hear this complaint a lot but I find those argument orders completely intuitive.

You filter (1) an array with (2) a function. You map (1) a function over (2) an array. You reduce (1) an array with (2) a function.

It follows exactly what I'm thinking when I type it. To reverse the orders would be, what? "Mapping an array with a function?" "Filter a function on an array?"

Re: PHP in 2019

#309

"While async and await are not available yet, lots of improvements to the language itself have been made over the past years" It's 2019 guys. Please.

If you are looking for speed tacking an event loop on an interpreted scripting language is trying to dig a hole with a rake.

Its why the demand for such functionality was almost wholly absent from Python, PHP, etc for so long. Asyncio is a throughput boon even in a single core environment, which dates its practicality back to the 90s - and it was found there, in pretty much every graphics stack and COM. C apis have used what is fundamentally a promise since the 80s,

But if you are in a situation where you want those kinds of performance characteristics where you have work to do during blocking operations you probably don't want to be writing that code in an interpreted language to begin with.

Last week I was optimizing some performance critical Python but when considering my options I just ported the whole thing to Boost / C++ and got an ~80x speedup over the whole loop.

Theres only a narrow range of problems actually best solved with interpreted asyncio, pretty much only in the space where introducing a build system and doing language binding isn't worth it but the gains from being non-blocking are. They exist, and its definitely not a bad thing to have async support in your interpreted language, but it definitely isn't mission critical in the slightest.

Re: PHP in 2019

#310

I've been using PHP semi-regularly since the late 90s. It's been empowering and infuriating. The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards. For whatever reason, I often feel clu…

From a performance perspective, you likely want to do those with `foreach` anyway in PHP. Especially when the array function is fed a closure. I know it is not as interesting as using those functions, but because of PHP internals, `foreach` is almost always preferred.

https://stackoverflow.com/questions/18144782/performance-of-...

Post reply on HN