5 ms·

Typically you are reading from a file, or the network. someFile.read(dest) network.read(dest) I'm reading from a file or network in both cases. You c

by jonahx 3y ago

Typically you are reading from a file, or the network. someFile.read(dest) network.read(dest) I'm reading from a file or network in both cases. You can say you're using "the reader" to read, but as I said it a) introduces an unnecessary concept, b) is not how we naturally talk, and c) does not fit with the variable names (unless you want append "Reader" to all of them, which I think is ugly and bloated.) It's not the worst thing in the world, and I understand the benefits of the choice, but still it slightly grates on me.

taeric 3y ago
You are using some other code capable of reading from the file, though. Your code can do no such thing. Consider now you send a physical letter to me? You use a mail carrier. You have my address, but sending is through the carrier. Same for calls, you use a service provider to make the call.
- jonahx 3y ago
  > Consider now you send a physical letter to me? You use a mail carrier. You have my address, but sending is through the carrier. Same for calls, you use a service provider to make the call. We perform some actions with tools, but not all. Do you use a tool to run? To read a book? You simply run, or read. My issue is that Go forces every situation into the tool paradigm. If I have an object representing a file that I can read from, I am reading from that file. I am not using anything to read from it. So either the object can no longer represent the file directly (but instead a tool used to read it), or the file can keep representing the file but the language is off because the file is now also a "Reader" (in the Go sense) of the file. > You are using some other code capable of reading from the file, though. We are talking about how to conceptually name pieces of our code to match our natural concepts and language. That is, the conversation we're having is one about modeling, so this move seems illegal to me. The "other code implementing reader" is not part of the model. It would be like arguing, in regular life, that "you can't say that you read a book, because really it is your brain doing the reading".
  - taeric 3y ago
    But you are playing into it? If you are the one running, you are a runner. If you used someone else to run a letter to the whatever, they were the runner. It can fail if you are writing the physical contact point to the hardware, but very few of us do that. We use code that does that. Do I use a tool to read? I have reading glasses. And an ebook reader. And I've delegated some reading to others. Life is complicated. Language no less so.
    - jonahx 3y ago
      > And an ebook reader Your ebook reader it the thing being read, not the thing that reads. Glasses for reading are also called readers, and they are the tool helping you read. Here, to your point, we see "language being complicated" -- the same convention being used for opposite things. But this is a tangential point leading us astray. I thought about this some more in the shower, and I think I can distill my objection more clearly. Methods on objects act on those objects. That is: object.do() is equivalent, in English, to performing the action "do" on "object". To take a random example from Effective Go: d, err := f.Stat() if err != nil { f.Close() return err } We "Stat()" the file (get statistics about it) and we "Close()" the file. This pattern is well-established in both Go and nearly every language with objects. Instance methods are actions performed on their object. Now of course "File" also implements "Reader". Yet when I "f.Read()" the situation is exactly the same as in "Stat" and "Close". I am reading the file. So where is the "Reader" now? Well the Reader is also the file. In the conceptual model, there is no other object around. The file is both the Reader and the object of reading. And that's my problem. The "reader as tool" is inconsistent with "methods act on objects". In the tool model you've been arguing for, I would have to write something like: reader.read(file) The redundancy of that aside, this is not typically what you see with Go code (though you sometimes do). You are more likely to see stuff like "f.Read()" As I said, you can argue that Go's "File" object is not meant to represent a file, but instead an abstract tool: a thing which can Read and Stat and Close files. But that's not what the documentation says: "File represents an open file descriptor." That is, in the intended conceptual model, the "f" in "f.Read()" is a file. And we are reading it. And that is at odds with it being a "Reader" -- a thing that reads.

by jonahx 3y ago

taeric 3y ago

You are using some other code capable of reading from the file, though. Your code can do no such thing. Consider now you send a physical letter to me? You use a mail carrier. You have my address, but sending is through the carrier. Same for calls, you use a service provider to make the call.

jonahx 3y ago
> Consider now you send a physical letter to me? You use a mail carrier. You have my address, but sending is through the carrier. Same for calls, you use a service provider to make the call. We perform some actions with tools, but not all. Do you use a tool to run? To read a book? You simply run, or read. My issue is that Go forces every situation into the tool paradigm. If I have an object representing a file that I can read from, I am reading from that file. I am not using anything to read from it. So either the object can no longer represent the file directly (but instead a tool used to read it), or the file can keep representing the file but the language is off because the file is now also a "Reader" (in the Go sense) of the file. > You are using some other code capable of reading from the file, though. We are talking about how to conceptually name pieces of our code to match our natural concepts and language. That is, the conversation we're having is one about modeling, so this move seems illegal to me. The "other code implementing reader" is not part of the model. It would be like arguing, in regular life, that "you can't say that you read a book, because really it is your brain doing the reading".
- taeric 3y ago
  But you are playing into it? If you are the one running, you are a runner. If you used someone else to run a letter to the whatever, they were the runner. It can fail if you are writing the physical contact point to the hardware, but very few of us do that. We use code that does that. Do I use a tool to read? I have reading glasses. And an ebook reader. And I've delegated some reading to others. Life is complicated. Language no less so.
  - jonahx 3y ago
    > And an ebook reader Your ebook reader it the thing being read, not the thing that reads. Glasses for reading are also called readers, and they are the tool helping you read. Here, to your point, we see "language being complicated" -- the same convention being used for opposite things. But this is a tangential point leading us astray. I thought about this some more in the shower, and I think I can distill my objection more clearly. Methods on objects act on those objects. That is: object.do() is equivalent, in English, to performing the action "do" on "object". To take a random example from Effective Go: d, err := f.Stat() if err != nil { f.Close() return err } We "Stat()" the file (get statistics about it) and we "Close()" the file. This pattern is well-established in both Go and nearly every language with objects. Instance methods are actions performed on their object. Now of course "File" also implements "Reader". Yet when I "f.Read()" the situation is exactly the same as in "Stat" and "Close". I am reading the file. So where is the "Reader" now? Well the Reader is also the file. In the conceptual model, there is no other object around. The file is both the Reader and the object of reading. And that's my problem. The "reader as tool" is inconsistent with "methods act on objects". In the tool model you've been arguing for, I would have to write something like: reader.read(file) The redundancy of that aside, this is not typically what you see with Go code (though you sometimes do). You are more likely to see stuff like "f.Read()" As I said, you can argue that Go's "File" object is not meant to represent a file, but instead an abstract tool: a thing which can Read and Stat and Close files. But that's not what the documentation says: "File represents an open file descriptor." That is, in the intended conceptual model, the "f" in "f.Read()" is a file. And we are reading it. And that is at odds with it being a "Reader" -- a thing that reads.