Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP in 2022

stitcher.io

Post reply on HN
Print view View original

261–270 of 318 posts

Re: PHP in 2022

#261

Post by vdo »

kodemager wrote: post #138
vdo wrote: post #74

I 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…

Yes, sorry, I don't mean to make out php as this scrappy underdog or that we are under constant attack or anything... I see it more like, ummm, a pumpkin spice latte of languages, something viewed as a lesser choice because or in spite of its popularity? There are all these other amazing options, why pick this? Of course, with programming languages, you have many objective criteria where a coffee drink is totally subjective. Languages are also a huge investment time-wise instead of being able to try different flavors each day. Not a perfect analogy, but maybe you still see a little what I was going for as far as lighthearted stigma. PHP is and has been doing so well for so long, but I couldn't argue a huge case for it personally besides... it was there. It clicked at the time. I grew up with it.

I am balancing my love for it with the public perception I have seen over the years (fortunately I think much of the vitriol has waned sorta), in terms of how bashful I feel whenever discussing anything coding-related as to not overstate what I know/do. Most people, I think, grow out of php, so I see myself as a bad stereotype in still using it. But it has done a lot for me in terms of confidence building, being able to make things, the creative process of turning nothing into something, even though admittedly if I'd picked a different language I could likely say the same. But as far as staying with it, I feel like I look lazy for it, it just does what I want it to do. I am grateful for it. I hope this made sense.

Re: PHP in 2022

#262

Post by tored »

cntainer wrote: post #187
Isinlor wrote: post #59

Earlier quoted context omitted.

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 ecosy…

Essentially you have 3 types of web backends

1) CGI and similar share-nothing architecture like PHP, unaware of process model, threaded or processes, everything starts from zero. Any state needs to be handle outside of the runtime. Stateless thus a good conceptual fit for stateless protocol like REST.

2) Threaded frameworks like Java Spring or Python frameworks, the framework forks for you, but the architecture is leaky, you can share data between threads intentionally or unintentionally. Benefits from things like connection pools to be used between requests. Can be easier when need to handle a single mutex of a resource compared to 1), e.g only one job instance should run simultaneously. However most of the time you write code as if it was share-nothing, because fewer complications (no need to worry about locks, concurrent collections etc) and reduces risks of introducing any hard to debug and expensive mutex.

3) Single threaded event driven architecture, no need to worry about race condition thus you can keep global state within the application between requests, no locks or anything but with a big caveat, as soon as you start running your application as multiprocess, like cluster, that global state can no longer be used for data sharing, only for caches like database connection, thus the best way of writing application code is to write it as share nothing to avoid any state related bugs.

BUT single threaded event driven architecture also has a huge drawback, you can essentially freeze the entire application by programmer error or introduce hard to detect mini freezes because it is single threaded.

Proposition: the larger the single threaded event driven application becomes the higher the chance of freezing your application.

I think this is why nodejs shepherds you to write micro services and conversely PHP shepherds you to build monoliths because you don't care about the process model when writing PHP.

Conclusion: You should almost always design your code as share nothing. The only benefit of picking either of 1), 2) or 3) is for performance considerations outside of team expertise and community. 2) and 3) can have better performance than 1) due things like to connection pooling but 3) is bad choice in respect to longlivity because of the monolith mismatch. 1) is easier to reason about because the process model is irrelevant thus increasing longlivity.

Re: PHP in 2022

#263

Post by marcosdumay »

The_Colonel wrote: post #193
marcosdumay wrote: post #178

Earlier quoted context omitted.

If you only know "don't use ==, use ===", you will just fall for the next unityped trap. If you know why you shouldn't use `==`, you know enough so that even if you don't go for `===`, using `==` safely is the least of your problems.

> for the next unityped trap Many languages are unityped and carry the same problems, yet they are hyped rather than bashed (e.g. Python, Ruby). > If you know why you shouldn't use `==`, you know enough so that even if you don't go for `===`, using `==` safely is the least of your problems. You have some weird false dichotomy going on. I'm personally in the state "I remember why == is bad (type coercion ...)" but I d…

Your two examples are not unityped, and most unityped languages are unityped all the way down and as a consequence do not have the same problems.

Re: PHP in 2022

#264

Post by amarshall »

dncornholio wrote: post #122
awestroke wrote: post #118

Earlier quoted context omitted.

I feel it's the opposite. Always a lot of people defending PHP in these threads, no criticism allowed. Gives a very misleading picture of the industry - in reality, PHP is not a loved language, it's below Powershell and just over C in the latest ranking[0] with 40% love / 60% dread. [0]: https://insights.stackoverflow.com/survey/2021#technology-mo...

This only adds fuel to my argument. Yeah let's post a results on how people FEEL about a language. How is that objective? I could argue 100% of the 40% of the people actually uses PHP and 100% of the 60% people don't even use it.

You can argue that, but it's not what the question was about. The survey question is:

> Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year? (If you both worked with the language and want to continue to do so, please check both boxes in that row.)

Of course nothing requires survey participants to be honest or to actually totally read and comprehend the question.

Re: PHP in 2022

#265

Post by fart32 »

captn3m0 wrote: post #226
fart32 wrote: post #190

Earlier quoted context omitted.

> 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 depende…

checked for a fresh laravel install: 110 packages, 40 of those are development dependencies. Of the 70, only 38 are non (symfony/laravel) dependencies. The PHP ecosystem tends to use packages-for-interfaces, so that ups the count somewhat.

Yes, I saw similar numbers (just not in empty projects, but I'm not familiar with Laravel/Lumen - there might have been a good reason for it).

The point is that Composer packages are far from being that granular, we have less dependencies by literally order of magnitude.

Re: PHP in 2022

#266

Post by DerArzt »

heurisko wrote: post #222
chefandy wrote: post #157

Earlier quoted context omitted.

I think that says more about your particular mental model of programming than about programming in general. In the couple of decades I’ve been coding, I’ve seen good use of both dynamically/weakly-typed and strongly typed languages. Sure— thinking you’re going to save time writing more complex applications by avoiding boilerplate is flatly wrong. However, if boilerplate would be a double-digit percentage of your code…

> I think that says more about your particular mental model of programming than about programming in general. Well, I originally started programming only using dynamic types. Then I moved to typed languages, and I could avoid whole categories of errors. I don't see it as dogma, I think typed languages are just qualitatively better at creating software. I also think this is starting to become industry experience, as e…

I started on the other end (my first language was C89) and I am with you on types. Just being able to read a plaintext file and know what type every variable and parameter is just makes reading the code easier to me. My primary language is python at the moment, and I don't think I could continue without the type annotations that you can add in coupled with mypy (a static type checker that you can run on the cli as part of a build).

Every time I see a regular Map with nested maps, I get a little annoyed.

Re: PHP in 2022

#267

Post by lelanthran »

cntainer wrote: post #21

I 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…

> Why would I choose PHP when starting a greenfield project?

Ease? I have not professionally used php since php4, and last set it up in php5.x.

Last night I wanted to send some data to an http server, a small payload of json, that would be saved into a DB and queried later. Took me all of 5m to realise that my php test script that receives the file can be copied over to my el-cheapo webhost account unchanged and work fine.

No extra "database" modules to download, then install on a host I've no shell access to, sending email worked out the box, etc.

Php reduces the friction. I remember trying to use Python for something (with Django, I think) in 2011 and it was absolute hell to get deployed onto my webhost; fingers burned, I won't touch it again.

Php is basically batteries included, and works everywhere. I'm sure the Python, Node or Ruby alternatives are elegant, and neat, etc ... but if I wanted that, it means the project is expected to be large-ish, and for anything more than a few thousand lines of code I'm switching to a compiled language.

Re: PHP in 2022

#268

Post by kyleee »

moonchrome wrote: post #221
kodemager wrote: post #138

Earlier quoted context omitted.

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 people who do are stuck in the past to be perfectly honest. I've recently tried to help out a friend who got stuck with a half-finished PHP project and a deadline to deliver, I have not touched PHP in 10 years and it still has the stench of a bad language from the get go - "modules" requiring VM config, "include" files ... what is this 90s ? PHP might have had a huge patchwork competent people did to keep t…

well to be fair, any user is quite capable of building a pile of shit using any language, and if you were mucking with include statements manually it sounds like that's likely what was going on

Re: PHP in 2022

#269

Post by progmetaldev »

vdo wrote: post #74

I 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 my experience, a lot of the hate that PHP gets is unjustified. I can only speak from personal experience, but most people I know that complain about PHP were just burnt out from dealing with other developers' code. Having such a low barrier to entry created many novice and hobbyist PHP developers to hit the market, and start producing terrible code due to not fully understanding software development practices. I know I never had an issue with PHP, and could get work done very quickly, but once I had to start working through other's spaghetti code it burnt me out and I moved on to other languages with a bit higher barrier to entry.

Re: PHP in 2022

#270

Post by tored »

PHP in 2022 has much going for it, the only dark clouds on the horizon is the increasing framework oligarchy within the PHP community, which may reduce innovation and foster a "one size fits all" culture.
Post reply on HN