> I mean do plumbers have an advent of plumbing where they try and unblock shit filled toilets for fun?
Yes, plumbers and other types of craftspeople and technicians do also have these little fun competitions. Why shouldn't they?
I think the reason some of us programmers do these things, is likely because many (myself included) entered the field as enthusiasts and hobbyists in the first place.
Boom and bust hype cycles have always been a feature of capitalism, especially for advanced technology. Perhaps the only way to know the limit is to overshoot.
Not just the economy. We usually deal with these busts and crisis collectively through the public sector as well.
There's also a hidden opportunity cost in regards to hype cycles. So much energy, attention and money flows into the hype, while other businesses or entire sectors get overlooked and underappreciated.
Parse_url isn't standards compliant, often fails with relative url's and most importantly only parses urls, not uris (with the exception of file://). I also find it's syntax clunkier than the new uri(), but that's just personal preference.
The pipe operator is indeed just syntactical sugar (and the article links to another article specifically about it which does cover the case of temporary variables), but with the coming partial function application feature it (in my opinion) will make easier to read/reason chains of code than temporary variables or nested function calls.
parse_url() also had no generate_url() counterpart - sure, it could (sometimes) split a URL into its components, but there was no safe way to modify those components and glue them back into a string. The new URI class solves that.
Typical users of this likely don't care the slightest about whether anyone considers it an anti-pattern, because you use those in order to write utility scripts. And those who care would use tooling to detect issues like that anyways.
Yeah, doing things wrong happens quite often. Especially for the meta-character injection issue. Personally I think language designers should deprecate and remove backticks and other shell-executing features from all languages.
Many of the newer features have this problem. Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
Meanwhile it seemingly abandoned features and unique selling points, like the in-built templating, associative arrays with value semantics and the fact that it integrates well with C or the simple fact that it can be used to write web server scripts very easily. To me, many of these cool features have been largely ignored or even moved away from.
>Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
The problem is that the php project is maintained by (mostly) unsponsored contributors. There’s not a giant corporation behind it. Each of these new features are designed by a couple people (per rfc) and then discussed and voted by other contributors. The match keyword, for example, is consider as the future scope of this rfc which is still being worked on: https://wiki.php.net/rfc/pattern-matching
Also, a lot of these half baked features are designed to be implemented in steps because of what I said in my other paragraph and to increase the odds of being accepted (it’s well known that it’s hard to get an rfc accepted and a lot of good ones haven’t been able to pass the voting phase).
When you consider this, it’s amazing that we get so much from so little.
PHP has introduced breaking changes, deprecations etc. in a somewhat rapid fashion.
PHP doesn't prioritize stability, but language features and cleanup. It's an impressive technical endeavor that has its merits, but comes with a tradeoff.
Within the last 10 years, the language itself broke twice. And that's not counting the ecosystem on top of it. Common frameworks, libraries etc. tend to break relatively often as well.
There are languages that are _much_ more stable and reliable than that.
That has not been my experience and I have a project that started in 2017 with PHP 7.1 & Symfony 3.3 and is now at PHP 8.4 & Symfony 7.3 with plenty of dependencies.
Not everything will always update flawlessly but with Composer and a popular framework with planned depreciations and releases the ecosystem tends to sync fairly well.
It's broader, it's about users data. For example, you can store my address so you can send the item I ordered to me. You can't, without permission, use that to send me marketing stuff.
We had a do-not-track header that has been deprecated. Simply enforcing the header legally and having it on by default would suffice and it would be much easier to test, because it's not bespoke from the client side of things.
reply