Comment by pizlonator
3 hours ago
Damn well trying to enforce an "obviously no bugs" rule in a language runtime would mean zero progress in language runtimes.
We certainly wouldn't have gotten to where we are with runtime and compiler quality and performance if we had damn well tried to enforce such a rule
IMO the very minimum requirement should be that you've demonstrated effort to reduce unnecessary complexity of the problem. Sure, some problems are complex enough that there might not exist an obvious solution, yet usually after a while once you're familiar with some topic the existing solutions do start to appear obvious. If they're not I'd argue we're doing something very very wrong
Adding concurrency to JavaScript definitely falls in the "complex enough" category
So does basically any feature or optimization in a JS runtime
I think it's also worth distinguishing _problem complexity_ and _solution complexity_. The problem might be really really hard (and it very obviously is in the case of adding multi-threading to JavaScript). But it does not mean that the solution has to be hard to understand. It doesn't mean that any average PHP developer (I can say that, I started with PHP) should be able to verify the correctness of the patch, but for a person who is well familiar with the area there shouldn't exist areas they can't understand.
Look at the description of your own Fil-C: it focuses on clarity of explanation of how it works, and it actually does make sense (and, hopefully, works well enough too). Compare that with the pull request sent here. I'll wait
3 replies →