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

PHP – The Right Way

phptherightway.com

Post reply on HN
Print view View original

281–290 of 349 posts

Re: PHP – The Right Way

#281

Post by apocalyptic0n3 »

throwaway_r211 wrote: post #173
kilburn wrote: post #167

Earlier quoted context omitted.

I was curious about this rant since I'm maintaning a number of PHP projects and I haven't had any issues with "count". In the Changelog section of the "count" docs at https://www.php.net/manual/en/function.count.php we find: > 7.2.0 - count() will now yield a warning on invalid countable types passed to the value parameter. So in 7.2.0 they started raising a warning in cases where the application was doing a stupid t…

> In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Breaking changes (at runtime no less) are the worst way to improve any language. They should have created a new count method if they wanted to change behavior in a breaking way. Forcing millions of developers to comb through their code just because some designer doesn't like the way someo…

Perhaps ironically, this attitude towards backwards compatibility is a big part of what held PHP back for so many years and part of the reason why PHP 6 was abandoned during development and PHP 7 used none/almost none of that work.

Instead of introducing a warning and informing the community that a feature was going to change or be removed in an upcoming major update, for years PHP just added new functions. You ended up with `mysql` and then `mysqli`. You ended up with the `mb_*` functions. And in order for developers to properly interface with all of these duplicate functions that may or may not be installed on your system, you ended up with jQuery-like libraries that would wrap certain portions of the PHP language and try to make them easier to work with. The comments on this (and most PHP posts on HN in general) are pretty crappy in large part because of decisions like this. It's also why the language basically died for like half a decade in the late 00s.

It's an absurd way for a language to evolve. At some point, you MUST fix the issues break backwards compatibility. You put out documentation and upgrade guides instructing developers on what needs to be done to facilitate the change. And as developers, we accept that we need to make sure we check that documentation before upgrading and in exchange, we get a better experience for developing new applications in the future.

Re: PHP – The Right Way

#282

Post by trwhite »

gocartStatue wrote: post #235
trwhite wrote: post #82

Earlier quoted context omitted.

Mocked as in made fun of? Personally (in 7 years as a PHP dev) I've not found this. There was one company I interviewed at where the lead engineer thought facades were dumb, but then couldn't explain why he needed to rebuild the entire backend in Node. Perspective.

Yes, made fun of. Philosophy of Laravel crowd seems to be similar to "the rails way", which means a lot of framework-specific solutions, disregard for TDD etc. Well, static service locators disguised as "facades" are a bad design. Rebuilding entire backend in Node for that reason alone is dumb. Laravel features a PSR-compliant DI container and supports dependency injection with autowiring, you can very well write a n…

You can of course take a TDD approach with Laravel. I think I know what you're getting at, but I do find the Laravel has a lot out of the box now that I would otherwise have to write from scratch. I suppose the Spatie packages (for example) fill some of those gaps. I hadn't heard of Laminas before

Re: PHP – The Right Way

#283

Post by inoop »

9dev wrote: post #274
inoop wrote: post #262

Earlier quoted context omitted.

> did not change within the minor revision boundary I'm confused, are you saying it's fine to change core language semantics as long as it's across major version boundaries? How the hell is that better? No other reasonable language does this.

That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. That applies to Go too, for example (talking of reasonable languages...). That PHP ever allowed count()-ing uncountable things is effectively a bug in the standard library. What happened is that a depreciation was put into place, and in the next major version that depreciation was converted to an error. Just how it…

> That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes.

this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code?

I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the old ones. Nobody would use their stuff. But somehow the PHP community thinks this is perfectly normal.

It just boggles the mind.

Re: PHP – The Right Way

#284

Post by 9dev »

cies wrote: post #184
Ronsenshi wrote: post #143

Earlier quoted context omitted.

I'm not the OP, but I have plenty of comparative experience working with Python and JS on the backend (node) and I find PHP to be a very decent option compared to those two. PHP has an amazing infrastructure of third-party libraries/packages around it, particularly if you're using PHP for web development. In comparison, Python simply does not have the same quality of framework for web like Symfony or Laravel. Django…

So compared to JS and $DYNAMICALLY_TYPED_LANG, PHP is "decent these days". These languages all suffer from very similar problems. Compare to C#/MVC.net, Kotlin/whatever, Go, Rust to get something noteworthy.

Happily!

- PHP gets you all the way from typeless prototype code to prove an idea, to expressive, runtime-enforced type checks that you can run in production.

- PHP doesn't require static compilation, but can be configured to compile to efficient Opcodes on the first run, making it competitive with Java/Kotlin/whatever speed-wise.

- PHP handles HTTP requests statelessly, starting with a blank slate in extremely short boostrap time. This pretty much eliminates memory leaks for common work loads. This execution model is very simple to reason about, and the major edge, I would argue.

- PHP has an exhaustive ecosystem with a great package manager. All code is namespaced, fetched directly from the source repository (eliminating several security concerns), and usually of high quality. Common frameworks are mature, solidly built, and feature-rich.

- PHP can also be used for other workloads outside of web applications: I've built a realtime message processing system handling thousands of messages per second, spread out across a dynamically scaling number of worker threads. It still happily processes messages as far as I know, and if you've ever received a business communication via messaging apps, chances are it was sent by my system.

All of these things make PHP an excellent choice for a wide range of projects, even compared to statically compiled languages, which you seem so keen to compare a dynamically interpreted language to.

Re: PHP – The Right Way

#285

Post by gocartStatue »

trwhite wrote: post #282
gocartStatue wrote: post #235

Earlier quoted context omitted.

Yes, made fun of. Philosophy of Laravel crowd seems to be similar to "the rails way", which means a lot of framework-specific solutions, disregard for TDD etc. Well, static service locators disguised as "facades" are a bad design. Rebuilding entire backend in Node for that reason alone is dumb. Laravel features a PSR-compliant DI container and supports dependency injection with autowiring, you can very well write a n…

You can of course take a TDD approach with Laravel. I think I know what you're getting at, but I do find the Laravel has a lot out of the box now that I would otherwise have to write from scratch. I suppose the Spatie packages (for example) fill some of those gaps. I hadn't heard of Laminas before

Laminas is Zend rebranding :)

Re: PHP – The Right Way

#286

Post by hnfong »

apocalyptic0n3 wrote: post #281
throwaway_r211 wrote: post #173

Earlier quoted context omitted.

> In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Breaking changes (at runtime no less) are the worst way to improve any language. They should have created a new count method if they wanted to change behavior in a breaking way. Forcing millions of developers to comb through their code just because some designer doesn't like the way someo…

Perhaps ironically, this attitude towards backwards compatibility is a big part of what held PHP back for so many years and part of the reason why PHP 6 was abandoned during development and PHP 7 used none/almost none of that work. Instead of introducing a warning and informing the community that a feature was going to change or be removed in an upcoming major update, for years PHP just added new functions. You ended…

> And as developers, we accept that we need to make sure we check that documentation before upgrading

Not everyone does. I think I've read a couple times how people commented that Python2->3 was the worst decision made by Guido. (I'm personally grateful that Py3 makes unicode default and more sane than Py2)

With every compatibility breaking release, you run the risk of splitting the language into two. Perl suffered that fate (though not only for that reason), and Python almost did (Py2 is still used in so many places 14 years after Py3 was released in 2008).

Re: PHP – The Right Way

#287

Post by dotancohen »

inoop wrote: post #275
dotancohen wrote: post #270

Earlier quoted context omitted.

If you're conversing with someone who believes that the JVM is a resource hog, then you are likely conversing with someone with decades of experience. I would phrase my opposing viewpoint in a more respectable manner, as you might have a lot to learn from someone like that.

> If you're conversing with someone who believes that the JVM is a resource hog, then you are likely conversing with someone with decades of experience As someone who has actually read the JVM specifications many times, has actively worked on a JVM implementation, and has a pretty good grasp on virtual machine design, I beg to differ. But hey, I'll take the bait, what makes you think the JVM is a 'resource hog'?

I no longer think that the JVM is a resource hog. In fact I implied that it was an archaic mindset by suggesting that someone who thinks so has been decades in the industry.

That said, many Java applications themselves are resource hogs. Even my preferred IDE, the Jetbrains suite which I love, are resource hogs. Perhaps I'm simply not configuring it properly, but arguably I wouldn't ask an end user to tune JVM parameters any more than I would ask a car buyer today to set his timing or tune his mixture.

Re: PHP – The Right Way

#288

Post by mkdirp »

inoop wrote: post #283
9dev wrote: post #274

Earlier quoted context omitted.

That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. That applies to Go too, for example (talking of reasonable languages...). That PHP ever allowed count()-ing uncountable things is effectively a bug in the standard library. What happened is that a depreciation was put into place, and in the next major version that depreciation was converted to an error. Just how it…

> That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the o…

> this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code?

Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve.

For the longest PHP was really great with backwards compatibility, refused to address issues in the name of backwards compatibility. So it became the butt of the jokes it is today.

As you can imagine, I'm on the other end. Providing backwards compatibility is kept for a relatively long time, I don't think it's unreasonable to break changes with a good system (i.e. major version upgrades). In such cases, I welcome it.

Re: PHP – The Right Way

#289

Post by 9dev »

inoop wrote: post #283
9dev wrote: post #274

Earlier quoted context omitted.

That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. That applies to Go too, for example (talking of reasonable languages...). That PHP ever allowed count()-ing uncountable things is effectively a bug in the standard library. What happened is that a depreciation was put into place, and in the next major version that depreciation was converted to an error. Just how it…

> That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the o…

> [...] where each major version upgrade breaks their code?

> [...] randomly change their APIs every couple of months [...]

This is just FUD. Breaking changes are announced long-term via deprecations, so they don't catch you out of the blue. Every major release of the runtime has three years of support, so nobody "randomly" changes their API every couple of months.

I find Google to be a funny example, by the way - picking that one company axing another project or API every other day.

Re: PHP – The Right Way

#290

Post by tehbeard »

inoop wrote: post #283
9dev wrote: post #274

Earlier quoted context omitted.

That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. That applies to Go too, for example (talking of reasonable languages...). That PHP ever allowed count()-ing uncountable things is effectively a bug in the standard library. What happened is that a depreciation was put into place, and in the next major version that depreciation was converted to an error. Just how it…

> That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the o…

Because, suprisingly, Noone is forcing you to update immediately!

Hell, there's still a lot of 5.x deployments out there that work just fine. I even manage one or two (both of them being very old, legacy installations in enterprises. In both cases I'm making slow and steady progress to getting them up to 7.x or 8.x so that we can benefit from engine improvements etc).

> Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code

That. Is. The. Entire. Point. Of. Major. Versions.

A big red warning and culutral understanding of "stuff we said would be gone, that we gave you a year+ of notice on, is now gone, go read the migration notes if you've been sleeping under a rock."

You act like this is happening monthly? 8.0 came out in Nov 2020... , 7.0 was Dec 2015.

> I just don't understand why people accept this from their tools.

Actually our tooling is pretty nice. Between psalm, phpcs and rector, we have tooling that can forwarn of deprecations in use, and most of the time fix them automatically.

Should you always use PHP? No. But the debate on the nuances as to when to not use it doesn't tend to go well with those who just throw everything out the pram acting like PHP developers are insane because it's not a haskell/rust docker project.

Post reply on HN