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

251–260 of 285 posts

Re: PHP in 2023

#251

Post by makeitdouble »

jbboehr wrote: post #248
makeitdouble wrote: post #247

Earlier quoted context omitted.

Yes, except it has to be set on the _caller_ side. I kinda see why, after all it’s the caller who will deal with the TypeError. But assuming we’re not setting types for all our functions, when I do for a specific one, I want to enforce that strictness on the _callee_ side (“for this function, it really matters that the parameters are correct”), and not have to go check if every single caller files properly has the st…

> Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system There was this RFC[0] but it seems to have fizzled. > And it still doesn’t work for native functions. The page states: 'Function calls from within internal functions will not be affected by the strict_types declaration' (emphasis mine). Outside of array…

> native functions

Thanks

> That sounds awful. Why not install a nice static analyzer like phpstan or psalm and never think about it again?

It is completely unelegant, but works decently in practice (fits the subject perfectly…). We’re extensively using phpstan, especially as it’s the best way to expose in array types.

Phpstan still has blind spots, including the ability to disable it on the caller side (in particular, as far as I know you can’t disable specific errors inline, so if you have to do it for one parameter for instance, it applies to all parameters), and the option to overwrite a variable type just for phpstan. Those comes from developer error, but that’s exactly what we want to protect the system from.

Actually checking at runtime that a value is of the right type is more secure.

Re: PHP in 2023

#252

Post by buttocks »

francislavoie wrote: post #234
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.

Maybe not, but Wordpress is arguably one of the main applications that has kept PHP relevant over the years. They could reach out a hand.

Re: PHP in 2023

#253

Post by cbsjjxhcc »

esskay wrote: post #21
bluetomcat wrote: post #11

Earlier quoted context omitted.

As of PHP 5, it lost its way and started imitating the Java OO model with a worse botched-on syntax. PHP 4 used to be a compact "hypertext preprocessor" with many built-in groups of functions, enabling you to process forms, talk to databases or process images without much code.

How has PHP lost its way? It grew up from a poorly thought out hacky scripting language to a major programming language. All the nasty code you could write in PHP 4 or 5 is still possible, but everyone will look at your code and laugh.

Poorly thought out?

Only the language that runs most of the internet and invented the term tight development loop.

All the modern crap has just moved us further away from this.

Re: PHP in 2023

#254

Post by cbsjjxhcc »

ianhawes wrote: post #180
cbsjjxhcc wrote: post #38

Earlier quoted context omitted.

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.

You're just wrong. PSRs are widely accepted and all serious frameworks and PHP libraries implement them as needed. I haven't seen a PHP package in quite a long time that didn't implement PSR-4.

Except the largest framework doesn't. And the majority of libraries don't.

Re: PHP in 2023

#255

Post by cbsjjxhcc »

esskay wrote: post #231
cbsjjxhcc wrote: post #38

Earlier quoted context omitted.

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.

Composer is trash, semver sucks and I'd tell PSR to go jump but it'd get stuck in a class file somewhere.

Re: PHP in 2023

#256

Post by dmitriid »

chippiewill wrote: post #128
dmitriid wrote: post #93

Earlier quoted context omitted.

mysql_connect has been heavily discouraged for at least 15 years now.

PHP 4.1 came out with mysqli in 2001. So you could argue that mysql_ functions have been bad practice for over 20.

This made me realize how ild I am :)

Weren't the 90s just 10 years ago?

Re: PHP in 2023

#257

Post by omnimus »

skrowl wrote: post #187
awestroke wrote: post #146

I started my career with PHP. Created my own apps, created client websites etc. Full of footguns, but I didn't know any better. Once I learned more languages, I never used PHP again. I actually started to feel like I'd been fooled into using PHP. Now the small PHP community keeps trying to justify their language choice with articles like these and comments like the ones on this submission. They claim it's a no braine…

PHP devs hate to admit that the only reason PHP is still relevant at all today is because of WordPress. If WordPress moved to a modern language tomorrow, PHP would cease to exist afterwards.

You probably dont make content sites. The reason PHP is still relevant today is because no other language has CMSes as good as those from PHP. And i dont mean WP or Drupal.

Craft, Kirby, Twill, October, Grav, Statamic, Bolt, Processwire… All of those projects have big active ecosystems around them and are used for serious projects. Most other languages dont have a single CMS. There is no CMS in Go or Elixir. Javascript have some but they are super immature and mostly hype. Python has some super ugly ones based around Django.

Now people may look down on these PHP cmses but many web projects like ecommerce grow as extensions of CMS. And most of these CMSes are suited to this because they are nice web framework with customizable admin area. So it often doesnt make sense not use PHP.

Re: PHP in 2023

#258

Post by iLoveOncall »

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?

The fact that WordPress doesn't run on PHP 8.x is honestly the least of WordPress' problems.

There are MANY reasons to cast shade on WordPress, it's an absolute pile of garbage from top to bottom.

I recently developed a WordPress plugin as a personal project for my blog and it just puts in light how bad this software is, from non-existant documentation (on 10 years old functions?) to practices that were already not recommended in PHP 5.

WordPress as a product is great, but WordPress as a technological piece is absolute garbage, made by grossly incompetent developers.

Re: PHP in 2023

#259

Post by iLoveOncall »

lordgroff wrote: post #153
azangru wrote: post #140

Earlier quoted context omitted.

Php's inconsistencies in regards to needle vs haystack make me weep. Javascript doesn't have anything remotely like that.

I hope you realize that "fixing" these types of early mistakes is almost impossible for PHP, a language which tries hard not to break things, especially something that's going to be used everywhere. But if this is such a deal-breaker and your IDE is dumb as a stump and can't remind you nothing prevents you from wrapping the stdlib or using something like psl to do it for you.

I think fixing as in "removing and replacing" is indeed impossible, but defining a new convention and making alternative names for the same function would work fine.

Let's say the new convention is that functions are named str_*(), then keep strpos(), but create a new one called str_pos() that is the same, and mark the old one as deprecated (but don't remove it).

I am sure there are edge cases where both str_* and str* exist already and do different things, but we can figure something out.

Re: PHP in 2023

#260

Post by jimmaswell »

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…

I loved the straightforwardness of just having a nice simple HTML page with some sprinkled in. Now everything has to be done through a million layers of indirection. Which is fine when it's necessary, but I still like to write my own pages as simple unstructured PHP.
Post reply on HN