On Tue, Jan 4, 2022 at 1:27 AM Marco Pivetta <ocram...@gmail.com> wrote:
> > I know you're picking on details here, but believe me, I'm serious when > I'm saying "use matlab". > > In fact, I did work on financial products where (from Java PHP and Python) > we used the MATLAB Compiler to create binaries and dynamic libraries, which > would then do the heavy lifting around the financial models that were in > use. > > "Use an external tool that already exists to accomplish this task" is not, in my view, a legitimate reason to reject a feature from the language on its own. I see it as a relevant additional detail justifying a rejection, given that the rejection is for other reasons. That is, it's more of a justification for "this is why the rejection isn't that bad" than it is "this is *why* it should be rejected". You can literally use this argument to reject *any* feature, which means that it's application is entirely arbitrary. Let me phrase this another way: if I came later with a different RFC that has a main use case of mathematics, would you reject that as well on the basis that mathematics *should not* be well done in PHP? I'm not asking rhetorically, I'm legitimately wanting an answer to this question. Do I need to find and demonstrate non-mathematics use cases on future RFCs in order to have them seriously considered? Mathematics is not niche. I simply disagree on that. And it sort of seems that you do as well, since *immediately* before saying mathematics was niche you also said that spreadsheets run the world. If this RFC is rejected, as seems likely at this point barring some changed minds, I can certainly accept that. Several of the yes votes so far on this RFC also told me they would likely vote no out-of-hand when I first discussed this RFC back in August, but I was able to listen to their concerns, continue improving the RFC, and also present my arguments for why it is an important and impactful feature to them. They provided me with concrete objections that I could consider and see if there was a way for me to address and incorporate into the feature design, and it made the RFC better. But virtually all of the no votes so far declined to participate in any of the three threads that I had soliciting feedback, in the chat discussions over the last 5 months, or even in this thread. I have one actionable bit of feedback so far from Nikita, suggesting that the RFC would be improved with different syntax. I am at a total loss at this point as to how to proceed with other contributions I would like to make to PHP in the future, as the only conclusion I can draw right now is that math improvements simply aren't important or even wanted. Can I expect this for other math related RFCs, or is this dogmatic about operator overload specifically? I have no clue, and at the very least, I would like to learn that. Jordan
