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…
PHP in 2019
301–310 of 489 posts
Re: PHP in 2019
#302I'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
Re: PHP in 2019
#303Earlier 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.
Re: PHP in 2019
#304Earlier 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…
Re: PHP in 2019
#305I 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.
Re: PHP in 2019
#306Earlier 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 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
#307I 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.
Re: PHP in 2019
#308I'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…
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.
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
#310I'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…
https://stackoverflow.com/questions/18144782/performance-of-...