3 ms·

> Works if you consider the reader is what you use to do the reading. You have a source you want to read, so you get a reader that can do that. This strains or

by jonahx 3y ago

> Works if you consider the reader is what you use to do the reading. You have a source you want to read, so you get a reader that can do that. This strains ordinary language imo: Say you have a "log" which implements the Reader interface. When I call "log.read()" surely we are reading from the log, no? The log itself isn't the reader. This matches everyday usage. Perhaps your argument is that you can envisage the "log" object as an abstract "reader" of the bytes on disk, or something like that -- so the mental model is not a "log being read from" but instead "bytes on disk, an object able to read them (the Reader), and the code using that object to do the reading". In this worldview one never does anything oneself, but always uses a tool to do that thing -- the "-er" tool. I dislike this as it introduces an unnecessary layer of abstraction, but I grant it resolves the issue consistently. Also in this conception now I have a variable named "log" which does not represent the log but "a reader of the log". So you have to either ignore that inconsistency or name the variable "logReader", which introduces extra verboseness everywhere. The other resolution is simply to say this is a programming language, not ordinary language, and we decided that having a consistent, mnemonic way to name one method interfaces was more important than respecting natural language analogies. So f it, we're using "-er" to mean "-able". I would be curious to know what the actual conversation was during the development of Go.

taeric 3y ago
But odds are high your code isn't reading from any device. It is literally using a "reader of ___" to get the data read into a buffer that your code will process. So, still seems to work for me.
- 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.
        3y ago
deleted 3y ago
[deleted]

by jonahx 3y ago

taeric 3y ago

But odds are high your code isn't reading from any device. It is literally using a "reader of ___" to get the data read into a buffer that your code will process. So, still seems to work for me.

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.
      - 3y ago

deleted 3y ago

[deleted]