Hating on PHP almost feels like racism. All the arguments are biased or false. I always get sad after clicking on PHP articles on HN.
> All the arguments are biased or false. All of them?
At the time of writing, 100%
PHP in 2022
181–190 of 318 posts
Re: PHP in 2022
#182I learned to use php when I was like 14. I’m 27 now and still derive such joy when making my own little projects that will never see the light of day. I try to be humble as far as just being a php trash coder, but I don’t feel too ashamed honestly, as it is the most mainstream thing really. I will always be grateful to php for being accessible and yeah, I guess easy. I don’t know why php is the only one I really stuc…
In a world where everything is fast becoming a JavaScript front end with “some” backend and with the improvements PHP has seen in recent years I don’t see why you’d consider yourself a “lowly” php developer. I’m mainly a C# guy myself as far as the backend goes, but I don’t view PHP as being bad in 2022. I think people who do are stuck in the past to be perfectly honest. It’s sort of like disliking JavaScript because…
I think unambiguously janky design choices like this[1] in PHP's early history is what's given it such a bad reputation, while it might be a decent language now such a reputation is hard to shake. I'll be honest the only time I'd reach for PHP over a comparable language with a less chequered history like Python is if I was dealing with a project that was already closely tied up in the PHP ecosystem.
[1] https://www.i-programmer.info/news/98-languages/6758-the-rea...
Re: PHP in 2022
#183Earlier quoted context omitted.
There is a garbage collection: https://www.php.net/manual/en/features.gc.php > This section explains the merits of the new Garbage Collection (also known as GC) mechanism that is part of PHP 5.3. > First of all, the whole reason for implementing the garbage collection mechanism is to reduce memory usage by cleaning up circular-referenced variables as soon as the prerequisites are fulfilled. In PHP's implementation, t…
PHP's garbage collector is ARC, unlike any other dynamic language that I know of. ARC is more performant but can introduce memory leaks via circular references, which is probably not a big problem for short-lived scripts anyway.
Python uses ARC plus a tracing GC for dealing with cycles, same as PHP: https://devguide.python.org/garbage_collector/
Perl uses ARC with no tracing GC, so you have to handle cycles yourself: https://www.perlmonks.org/?node_id=1173079
TCL uses ARC, and apparently doesn't need a tracing GC because it is impossible to create cycles in it: https://wiki.tcl-lang.org/page/Garbage+collection
Re: PHP in 2022
#184Re: PHP in 2022
#185Earlier quoted context omitted.
> PHP is C-like and written in C so the hate is funny to me. You didn't realize how many people hate C? (Like any other popular language, yes)
I've being used PHP since it was Personal Home Page (3.x or something). The reason I moved away from it, is it is language make up. Some point around 4 it try to become Java OO style (ok ES6 is trying to do that too). The main reason moving away from it is because would like to have language that has function as a first class citizen, and JS seems to fit the bill. Once I found the joy of developing with proper closur…
PHP supports first class functions though?
Re: PHP in 2022
#186Earlier quoted context omitted.
The big guys, who know what they're doing use PHP because it makes devops stupid simple. Throw it on the server, its ready. That's always been PHP's killer feature.
Is it? Last time I used PHP (around 5.x-7.x) it was exactly the other way around. For production you needed php-fpm, nginx, opcode cache... it was a nightmare compared with go or even java. Is it better now?
The opcode cache is built in now. A webserver and php-fpm are still a good idea.
Re: PHP in 2022
#187I started my career in PHP ~15 years ago trying to do OOP in PHP 4.x. That was "fun". In the meantime I switched to other stacks but I've been keeping a distant eye on how PHP was evolving and I still am involved with PHP projects to a certain degree, though rarely at code level. I really appreciate the effort put into fixing most of the things I hated about the language, though at times it felt like the language and…
Share-nothing architecture, good, stable ecosystem build around Composer, Laravel and Symfony and as you said a lot of devs. Otherwise, I think differences in syntax etc. are rather subjective and everyone has their preferences. For example, I really like PHP "arrays" because it removes cognitive load of choosing between different data structures. When writing business rules 90% of time I don't really care about opti…
I can agree with the share-nothing architecture as a good selling point that keeps things simple but there are use cases where this is actually a limitation.
Parts of the community seem to want to go over that limitation so things like Swoole and Roadrunner were developed. I guess it's interesting to have both options available even though much of the ecosystem won't readily function in both contexts.
While the ecosystem seems a bit weaker that what I would expect considering the number of developers (comparing to Java, Ruby, Python) I don't have a strong opinion on package management. I feel like all major platforms have gotten into pretty good shape on this front. Like you mentioned, if I start a new Python project I can just choose Poetry and avoid most of the drama.
Re: PHP in 2022
#188I learned to use php when I was like 14. I’m 27 now and still derive such joy when making my own little projects that will never see the light of day. I try to be humble as far as just being a php trash coder, but I don’t feel too ashamed honestly, as it is the most mainstream thing really. I will always be grateful to php for being accessible and yeah, I guess easy. I don’t know why php is the only one I really stuc…
I'm one of those web devs that tries everything under the sun, and I also happen to have worked for a lot of companies (more than a dozen already, I'm on my 40s).
Laravel is such a *joy*. I've never had this feeling of using something so easy and productive. I've been recently building a side project with LiveWire and oh-my-god. I really wish I had discovered it before. From the templating system (you get components out of the box! no more "includes" if you don't want to) to the validations, to the queues system... everything is so well integrated and so easy to use.
For the last decade I've worked mostly with Django and SPAs, I'm not going back to that any time soon. Django templates are extremely limited for nowadays requirements, and SPAs are 1000x more complex to build and maintain so in my opinion they're not worth the price/effort. I think Livewire, Hotwire, Unpoly, Htmx, etc are what 90% of web apps need.
Re: PHP in 2022
#189Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. That, and also the fact that it ma…
> Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. I don't see that as its biggest killer feature. In fact most projects built on PHP using a framework won't use the feature, as every request will be routed through a front controller. This has been true for at least a decade. I think the killer feature of PHP…
Could you elaborate on the shared-nothing architecture?
Re: PHP in 2022
#190>>Packagist, now with over 3 million registered versions and more than 300.000 packages I see PHP continues to import all of the problem of npm into the PHP community, I moved away from php about the time packagist started to gain ground.
Packagist actually gets a lots of things right that NPM gets wrong: 1. NPM has a global namespace that was shoe-horned into an organization thing later. Packagist has been namespaced since day one. Using a namespace avoids almost all of typo-squatting issues etc. 2. NPM hosts the code at its end. This means you could review some code on GitHub and it might not match the code that you get. Packagist fetches the code f…
> The PHP community also prefers medium sized packages, so you don't get a thousand dependencies accidentally.
I think it was Laravel or Lumen? I tried that one once and was kinda amazed it pulled like 100 packages. In PHP ecosystem, I think that's considered a lot (to be fair, this is few years back). I've worked on fairly large projects (mostly Symfony + Doctrine and PHPUnit) and don't recall seeing so many dependencies.
Now compare this to initialization of any common JS framework starter.