Surprise is also based on convention.
What could be surprising to you might be just a stroll in the park for others.
In Japan people would be surprised to see others wearing shoes in a house while it's perfectly normal for people of other countries.
Reading the manual is something to prevent surprises and only takes one sentence to explain. I'd go for that any day of the week!
> ... a well designed system wouldn’t do this. ...
A well designed system would be able to explain their decisions and document that somewhere. Perhaps in the manual.
A well-documented system would explain all decisions. A well-designed system would enable the user to learn a small set of principles and apply them in adjacent areas successfully without reference to documementation.
As you say, I am used to checking the docs in Linux. It’s the convention that no convention shall be assumed. Is that good design?
I have a feeling you were waiting to say that for a while. :D
Glad to make your day. You are welcome.
Ultimately we all end up reading the manual. I'd still prefer if I didn't have to remember how a certain C stdlib function works vs. what seems intuitive.
But that's a lost cause with a lot of people. They'll happily point out how "intuitive" differs among different groups of people and all that, merrily missing the point on purpose.
Oh well. At least I found out without locking my self out of my servers.
> Ultimately we all end up reading the manual. I'd still prefer if I didn't have to remember how a certain C stdlib function works vs. what seems intuitive.
Intuitive is highly subjective, it might be intuitive to you, but not for others, and vice versa, and it is part of the job to read the "manual instruction".
> But that's a lost cause with a lot of people. They'll happily point out how "intuitive" differs among different groups of people and all that, merrily missing the point on purpose
What is your point? Are you arguing against documentation? You told me you are not averse to reading the documentation, yet you are complaining about it and bringing "intuition" into this. I am confused. Could you clarify your point?
That documentation is not sacred texts so yes I am arguing against it.
My point is that intuitive is as not as subjective as you make it out to be. Which is partially reinforced by a lot of software where "last one wins" is the policy. This example here sticks out like a sore thumb.
No point pursuing however because you seem hellbent on defending tradition which is something that tires and bores me.
Every time I say RTFM (like in the case of strtok), I get down-voted. Some tools really cannot be dumbed down, and they should not. I do not know why people have an aversion to reading documentation. It is bad.
In the case of strtok, I am not going to implement my own if strtok does what I want it to do, and behaves how I know it does. Why would I?! Sometimes what I need is strtok, sometimes strsep, sometimes I may use strtok_r.
My understanding is that "first one whens" is intended for security. Global config is read first, and then local (per-user) configs are read later. Because the earlier config wins, the per-user configs can't override the global policy.
See, not so intuitive, and you would have known this by reading the documentation.
> To me "first one wins" might be intuitive TO YOU, but to me "last one wins" is.
What I mean is that "first one wins" might be intuitive to you, but to me "last one wins" is, and apparently I was wrong, but I would have known at least, because I do read documentation.
It does make sense, indeed, that "first one wins", though.
> Why would "last one wins" be dumbing down the tool, exactly?
I did not refer to that as dumbing down the tool. That said, if you are unsure whether it is first or last one wins, read the documentation. There is no objective intuition here. To me "first one wins" might be intuitive TO YOU, but to me "last one wins" is.
> You're doing a big assumption that people are averse to reading documentation.
Some people definitely are, and they openly tell you that on here, too.
If you look further into my comments where I discuss "strtok", you will see it for yourself.
> You are likely downvoted because you prefer to make your opponents look irrational so you can easily defeat them.
I got down-voted because I claimed strtok is straightforward to use once you have read the documentation. I do not see how I am making them look irrational either (nor is it my intention). I am just trying to encourage people to read the documentation.
One thing a lot of traditionalists like yourself miss (sometimes I think it's on purpose) is that we have limited time.
Modern programming is not like 30 years ago. We have literal hundreds, if not thousands, of bits and pieces to assemble. I couldn't care less what some lone cowboy thought "strtok" should do decades ago. And how genius it seemed to him.
Apropos, why use "strtok" at all in this case, btw? Fine, the function might make perfect sense. The tool's behavior does not.
...But, well, he did made me care ultimately, right? But it's not welcome and now I think less of that person.
But again -- those were different times. To me if you don't do what seems intuitive (and yes I am replying to your comment here after the other and yes I am aware we'll never agree on what's intuitive), defined also broadly as "what many other programs do" then you are just John Wayne-ing your way into my hatred.
Nevermind though. I knew some UNIX cowboys of old. I don't miss them one bit. The way this tool behaves smells very strongly of them.
We have always had limited time, and it is your problem (and not the tool's fault) if you do not read the manual pages or documentation. You do realize you can search, right?
I do not know about you, but I write documentation for my programs, both a manual page, and comments in the source code. If you do this as well, then why would you do that? What if someone blames your tool just because they did not read the documentation?
> I couldn't care less what some lone cowboy thought "strtok" should do decades ago. And how genius it seemed to him.
If you do not know how strtok behaves, that is your problem, it is well-documented. If you do not want to read its manual page, just roll your own for all I care.
Is this php5 or a more recent version? That is hugely relevant when it comes to pho and something I should have mentioned in my original post (no idea if this specific thing would work in pho5, but there are other weird things)
No, the article says that the suppliers send data to a central service, which then tells them the optimal price, this service bases this price based on data sent by all other suppliers, and presumably gives all suppliers the same price.
That seems reasonable. I understand Worker and Worklet are established concepts in the domain, though, so better to use those names than invent new terminology.
