On 6/21/2016 8:32 PM, Stanislav Malyshev wrote: > What is for you "obviously faulty stuff" for literally thousands of > people is "code that works". I appreciate that there's a number of new > hip randomness tests that mt_rand may not satisfy, and there's new and > exciting number generator that we absolutely must implement because it's > new and exciting, but most users of mt_rand wouldn't really care, and > breaking their code for no reason that we have new and exciting RNG is > not what they would appreciate. >
https://news.ycombinator.com/item?id=9941364 My favorite: > The PHP approach seems to be that any crazy behavior is acceptable as > long as it's documented. There is plenty more of this stuff to be found on the Internet and the only thing I want to show is that it is faulty. It is not broken, yes, but faulty and hard to use right for many people out there. This is usually reason enough to react and try to do better. Why is it faulty? Well, it has many weird edge cases that people need to learn about. Reading the manual is however not something people actually do and this results in constant education being necessary. The question is, why can't we fix that? The answer here seems to be: because of legacy support. You are saying yourself that nobody is upgrading anyways to anything beyond 5.3 so this argument is kind of weak because obviously people have no problem with PHP 7.0, they seem to have a problem with any of the recent PHP versions. On 6/21/2016 8:32 PM, Stanislav Malyshev wrote: > If we're not going to remove it, there's no reason to pollute the logs > with useless messages. If you want to tell people about better > alternatives, there's the manual for that. > Not within 7.x because that would be a serious BC within a non-major version. Of course we would remove rand() in 8.0 in favor of mt_rand() or a better alternative if readily available within the versions of PHP that were releases before 8.0. I proposed to deprecate mt_rand() right away but I had a closer look at the newly available RNGs and non of them seem to be fit for production yet. It is definitely better to wait here and just keep mt_rand() for 7.x. In 8.0 things might change but that's too far in the future to make plans right now. On 6/21/2016 8:32 PM, Stanislav Malyshev wrote: > The users that do not wish to upgrade just won't upgrade. Making them > jump through hoops just to have what they already have makes no sense. > If they don't upgrade, they don't mind it being removed. ;) On 6/21/2016 8:32 PM, Stanislav Malyshev wrote: > This is a meaningless statement. "Cruft" is entirely subjective and > undefined, you essentially are saying "the language should look the way > I like it and contain only the code and syntax I like". That can not > work in a mature language with gigabytes of deployed code out there. > I never said that I want things to be like I want them to be. Stop putting words in my mouth and reflect for a second on your own write ups in which you always claim to know exactly what is best for everyone. I am writing my posts from my perspective and you are writing your posts from your perspective and I tell you a secret: that is how we humans write stuff, from our perspectives. Yes, cruft is a generic term: https://en.wikipedia.org/wiki/Cruft It specifically contains "redundant" which is more than appropriate to the current discussion since we have two random functions that do literally the same but one worse than the other. On 6/21/2016 8:32 PM, Stanislav Malyshev wrote: > "Trying to get rid of" is not going to help people that have code bases > rooting in PHP 4. And that's the majority of deployed code. It would be > enormous expense to convert all that code - and all that expense would > serve absolutely no goal except giving you satisfaction of "there's no > cruft". It is a useless goal and any time spent on reaching it is wasted. > No since most (mt_)rand() calls are broken crypto crap. Just go out and search for yourself like I did. It is pretty much impossible to find any other usage ... Not saying that there are not legitimate usages of any of those functions but they are super rare. On 6/21/2016 8:32 PM, Stanislav Malyshev wrote: > Your company may have tons of money and manpower to rewrite their code > (and, I assume, every library you use and every dependency that library > has) every 2-3 years. Most companies most definitely do not. Our usage > numbers for latest versions are very bad - 5.3 is still the most used > PHP version. We do not need to make upgrading harder. In fact, if we > make it any substantially harder, I don't know who we'll be releasing it > for - 0.01% of PHP user base that would actually run it? > Yes, we have manpower and the libraries we use are being upgraded constantly. Symfony and PHPUnit are pretty reliable in that manner and often ahead of our own libraries (PHP 5.x + 7.x support together is not hard to achieve and also what most of our libraries currently offer; we are not pure PHP 7 but PHP 5.4+). 5.3 is long gone and the fact that 5.4 was actually 6.0 was already discussed very often here. One of the main reasons why upgrades are slow is definitely related to shared hosters who do not upgrade their PHP as well as the Linux distribution systems that is faulty and leads to old packages being installed on many machines. It is hard to judge whether the hidden BCs that are silently being introduced by some RFCs are more harmful than a proper deprecate and remove approach with proper version numbers. I would argue that the last approach is better, at least other programming languages have more success with it (Java). Too much fragmentation is definitely not the goal but we are far away from that right now. Node has a brutal fragmentation with 0.x 1.x 2.x 3.x 4.x and 5.x all being in use at the same time. I really do not know how to address the issue that people are not upgrading. Hidden BCs that are sold as improvements definitely do not help but if controlled BCs do is unanswered in my opinion. Even if you claim otherwise. On 6/21/2016 8:32 PM, Stanislav Malyshev wrote: > Did I misunderstand you or you just claimed nobody wants to code in PHP > because it has var and rand and there's impossible to find a PHP > developer on the market? I am afraid my experience is exactly the > opposite. But if you are worried about this, making it harder to work > with PHP by fragmenting the ecosystem and making people remember which > function does random in which PHP version is not going to help. > No, you simply jumped over a complete sentence: > searching for PHP developers is a hard thing because of all the > various complains that we all know of and are already fed up with. PHP has a bad reputation among the industry especially in Europe/Germany because of "the various complains that we all know of and are already fed up with". This (mt_)rand() situation is just a super tiny part of the whole. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
