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

PHP in 2023

stitcher.io

Post reply on HN
Print view View original

231–240 of 285 posts

Re: PHP in 2023

#231

Post by esskay »

cbsjjxhcc wrote: post #38
esskay wrote: post #20

Earlier quoted context omitted.

If you're inherited a legacy project thats a mess then the chances are it was written by some ass who's not following the languages generally accepted PSR standards. Proper PHP code is extremely easy to dive into and maintain. The benefit and downside of the PSR standards is they are optional. Sadly some think they know better and opt to roll their own convoluted 'standards' that just end up creating hell for the nex…

PSR isn't generally accepted. It's a bunch of nobody know-it-alls that decided everyone needs to write java in PHP. No thank you.

If you actually think that you dont know the language very well. It's baked into Composer, all the major frameworks fully use it as to almost every major opensource project that isn't prevented from doing so by legacy code.

And honestly if you're a PHP dev intentionally avoiding the widely adopted standards and know someone else is going to have to maintain your code then shame on you.

Re: PHP in 2023

#232

Post by jensensbutton »

zeptonix wrote: post #36

I used to work way back in the day on PHP too, but even though I'm sure this will be downvoted, it's really sad people still take it seriously as a language in 2023. There's nothing remotely elegant about it. It's not expressive or programmatically succinct in the way Ruby is. It's not beautifully well thought-out the way Python is. It's not fast and modern in the way Rust is. It's not elegant or composable or client…

It's more productive as Ruby and Python and much faster than either? Is that not reason enough for some to choose it? I'd argue that of the PHP, Python, and Ruby it is Ruby that should die. It's the same use case as Python, but harder to read and just as slow.

Re: PHP in 2023

#233

Post by francislavoie »

jdpedrie wrote: post #155

I learned programming with PHP back in the mid-2000s, and worked professionally with it until about two years ago. I haven't touched it since 7.4 or so, except to help some friends with WordPress sites and such. It might be me getting old and grumpy, but PHP seemed to peak in terms of usability and syntax around 7.2. Lots of the new type syntax in the article is... inscrutable to me. I'm all for strong typing in gene…

Maintaining a legacy project might as well be a different language entirely than building a fresh project with modern PHP. I've been doing both, maintaining and modernizing a 17 year old PHP codebase, while building fresh apps with Laravel. And I would say the language is certainly not the limiting factor, but rather prior decisions causing debt.

Re: PHP in 2023

#234

Post by francislavoie »

buttocks wrote: post #171

The shade cast on Wordpress at the end is the article is a little disappointing. Ok, they’re behind on versions but for many years there was not much progress in PHP. Now PHP is flying and dependent projects are not keeping up. What can the PHP team do to help facilitate?

It's not the PHP internals team's responsibility to prop up a private company (Automattic, who owns WordPress) who are lagging behind on maintaining their product and ecosystem. They're already strapped for resources as it is.

Re: PHP in 2023

#235

Post by culebron21 »

My main issue with this report is that it gives all figures without any context:

- $500K in the foundation. Is this a lot or not, compared to other foundations? Is this more or less than the previous year/last decade?

- 6 developers. Again, what does this figure mean?

- "many users still use old versions" -- again, at which % should the community be worried?

The only meaningful info I found was the chart showing that after 7.0, its popularity stopped falling (though, the chart should have been rendered as stacked to see the full sum of downloads).

Regarding the language, I guess people get their job done with it, but the code in the presentation makes an impression that it's the same hassle as back in 2010 (v 5.3) when I quit using it. (Used it since 1999.)

Re: PHP in 2023

#236

Post by shkkmo »

koonsolo wrote: post #227
shkkmo wrote: post #205

Earlier quoted context omitted.

Many of those questions have answers that point out you are comparing two very different things. Some of them are explicitly comparing Laravel and React, which makes a bit more sense. The rest seem to be AI generated trash. The easiest way to explain it is that you could reasonably use react within a PHP project. I wouldn't use the term "idiot" but rather "ignorant". A good article that answers the PHP vs React quest…

For reference, I'm working with both React and PHP. And yes, for example WordPress uses React components. I'm a 42 year old software architect. But hey, maybe I've been ignorant all this time. React vs PHP is a decision you can make, because... the intention of both is to output HTML. edit: > The easiest way to explain it is that you could reasonably use react within a PHP project. I can use C within a Python project…

> React vs PHP is a decision you can make, because... the intention of both is to output HTML.

Often PHP is used when no HTML rendering happens at all (Apis, scheduled jobs etc.)

> I can use C within a Python project. Does that mean I can't compare the two? One is compiled while the other is interpreted, so maybe you can't compare those?

Those are at least both programming languages. Several major python libraries are written in C (or other compiled language) so a pure python project is probably fairly rare. Someone asking for "Python vs C" is probably more in need of an explanation of what the broad categories mean and tend to be used for than a point by point breakdown of specific language features and ergonomics.

In this specific instance, the complaint was that PHP, a server side language, doesn't offer client side rendering built in. This a point that should be brought up comparing JavaScript to PHP, not React.

Re: PHP in 2023

#237

Post by paulryanrogers »

oblio wrote: post #105
makeitdouble wrote: post #88

Earlier quoted context omitted.

I'm on PHP 8 and I feel the same as parent. Sure, there's been a lot of progress since the PHP 5 days, but the core of the language has been left mostly untouched by design, and we haven't seen the kind of drastic moves like JS moving to ES6 syntax. It's a matter of taste, so there's no absolutr truth. I hate PHP's function and property access syntax differenciation and wildly prefer ruby's approach or instance. And…

Maybe PHP can add a "stricter" mode that gets rid of all the cruft? Enable it per-file, allow it to simmer for 10 years, remove legacy support in PHP 12.

It already has one

Re: PHP in 2023

#238

Post by 0x073 »

krapp wrote: post #57
iLoveOncall wrote: post #7

Earlier quoted context omitted.

What's the point? You can use types in the vast majority of places in PHP and it works well, so I don't really see the point of that instead of contributing to the native typing system.

Javascript already set the precedent. If you don't like the way a language works, it's preferable to have a proxy language that does work the way you want that compiles to it, rather than accept the language for what it is and learn to work with it.

Javascript can't be compared with PHP, javascript is the only scripting language that all browsers understand except wasm. And there are multiple interpreters that may work different or have not all features avail.

PHP is used on servers that can run many different languages. Additional there is only one php interpreter that is widely used (yes there was hhvm and some others ), that means you can rely on all features of this version.

Re: PHP in 2023

#239

Post by bakugo »

pocketsand wrote: post #211
bakugo wrote: post #189

Earlier quoted context omitted.

> Can you give me a few real life examples where you got bit by the "magic" conventions or ran into any serious issue from not explicitly setting properties on your models? I shouldn't need "real life examples" to explain why using objects with magic dynamic properties instead of declaring the properties on the class is stupid. If I can't look at a model class and know what properties and methods it has, why is it ev…

You can look at a Laravel (Eloquent) model and easily see what methods it has. Nothing is hidden -- at least no more than any ORM that inherits from another class which gives it functionality. As for properties -- yes, they're not explicitly described but mapped to the database schema. Other ORMs, like that in Ruby on Rails, also do not explicitly set model properties and just map to database columns. People have bee…

The only benefit you've mentioned is writing less code. Which just proves my original point about Laravel being for people who want to get things done as fast as possible with the minimum effort possible, regardless of how much sense it makes.

>Consider Django. There, you explicitly define properties, but link them to the type of database column they'll use. Then, you can generate a migration based upon the model, and then run that migration. I really like that pattern. Removes tedium of writing migrations, preserves ability to modify the migrations, and makes things explicit.

This is exactly what Symfony with Doctrine does, and it's the correct way to do it. The benefits vastly outweigh the "drawback" of having to write slightly more code.

Re: PHP in 2023

#240

Post by pocketsand »

ceejayoz wrote: post #213
pocketsand wrote: post #211

Earlier quoted context omitted.

You can look at a Laravel (Eloquent) model and easily see what methods it has. Nothing is hidden -- at least no more than any ORM that inherits from another class which gives it functionality. As for properties -- yes, they're not explicitly described but mapped to the database schema. Other ORMs, like that in Ruby on Rails, also do not explicitly set model properties and just map to database columns. People have bee…

> Symfony is a great piece of software. So is Laravel. And to be clear, Laravel is a piece of Symfony software , and a good example of what you can do with Symfony packages and a bit of opinion. There are 13 Symfony dependencies in https://github.com/laravel/framework/blob/9.x/composer.json alone, and many of the Laravel packages listed in there also depend on them; the Laravel Request class extends Symfony\Component…

Technology companies routinely use/license technology from other companies in their products. If, for example, Apple relies upon Samsung for displays and memory in their laptops, it does not follow that you're actually buying a Samsung laptop.

In any event, Laravel has never been shy about its debt to Symfony.

Post reply on HN