5 ms·
You can't just cherrypick examples and say this is typical. Even worse, you (GP) can't say this is typical without providing any examples when the most obvious
by Jabbles 4y ago
You can't just cherrypick examples and say this is typical.
Even worse, you (GP) can't say this is typical without providing any examples when the most obviously relevant analogy (precendence in Go) does not support your statement.
- eis 4y agoYou are misunderstanding his point even though masklinn explained it. It's not about the specific point of operator precedence. It is about designing something that has internally sound logic but is very unexpected by a typical new user. And he provided the example of time package patterns in Go which imho fits very well. Yea it makes sense but I'm sure there are hordes of users that think "why doesn't this work like in virtually every other language?". It's probably good to not take the "typical" too literally and more as a "Rob Pike has done a few designs in the past that have this quality".
- mseepgood 4y ago> "why doesn't this work like in virtually every other language? What's the point in creating something new if you simply repeat what already exists?
- coldtea 4y agoDoing it better in other aspects (e.g. 100% same design but faster or safer, etc.)? Refactoring? Making a FOSS version? Learning? Doing it in Rust because it's fashionable? Competition with an existing player in the same market? And lots of other reasons besides...
- indymike 4y agoThe op was commenting Rob Pike's body of work and Ivy's operator precedence certainly does fit this description to a tee.
- coldtea 4y agoIt's not about the particular intepreter or specific precedence design, it's about the tendecies described: what kind of stuff he often appears to like and/or produce. Now, you might disagree with that, but at least disagree with what I tried to say, not what I didn't mean :)