1. 5
  1.  

  2. [Comment removed by author]

    1. 3

      You can never truly trust a method called distributefundsequally, because there is no mathematical truth or concept behind it.

      I 100% agree with this statement.

      I’d prefer to say something like “Naming is Documentation.”

      I’ve learned to treat documentation like I treat the news; that it’s made up of statements which may or may not be true, that may help or confuse your view of the world, so take them with some amount of inherent uncertainty.

      1. 1

        I think we’re in agreement on the spirit of what I intended the post to say, but differ on how to say it. Communication is hard.

        I also think that my post intends to address your last sentence there; Badly written methods will have a name that leaves even more uncertainty about what lives within, and the better the naming the less likely that someone should be suspicious of its contents.

        At the end of the day however, if you have behavior inside such a method that doesn’t match up with its name you don’t have a naming problem you have a people problem.

      2. 2

        I think that’s a fair thing to say. Also, yes, the naming is useful to a team. As soon as I read the parent article I immediately reached into my own code base and began to update an interface where the common method was ‘execute’, and I’ve been telling my team that this really means “send a request external to our network”. The generic name was left-over from bottom-up design. I didn’t know what it was doing when I initially wrote it.

        I’m getting to the end of an effort that was to allow for generic integrations between companies and I chose to use this as an experiment to deploy a minimalistic replication log on top of postgres, taking many of the ideas exposed in Martin Kleppmann’s blog and Jay Kreps writing.

        So far I think it’s been successful, but the biggest challenge I’ve been facing is solidifying an useful abstraction. I have a generic way to append actions onto a log and processing that log has it’s own abstraction where we can just hook in one or more commands and have a queue run things for us (that’s where the ‘execute’ method was). The main functions of this were to enable reliable re-processing of events (e.g. re-send a faild API request), and to isolate the processor inside of a monolithic application in order to see the benefits of beginning to break the application up into smaller microservices (hence, getting to fault tolerance and resilience around the log abstraction). I’m finding that these abstractions are not trivial. Go figure.

      3. 1

        I believe that naming is not an abstraction, but rather a pointer to or a description of abstractions.

        If I have a method called distribute_funds_equally, it doesn’t generalize any ideas. It describes a generalization, in particular the generalization of how to distribute funds equally amongst n people (so that they don’t start murdering each other instead).

        However, naming is still very important, because manager.process(foo) explains what is going to happen less so than investors.distribute_funds_equally(money). And even that, does not explain what actually happens, just the end result (which is probably the most important bit of information, you don’t want functions called distribute_funds_equally_from_the_sql_database_to_the_banks_api_according_to_the_text_file_with_all_employees_names_in_it, do you?).

        You could also say that I’m being pedantic here, because what’s the difference between the idea of a monad and it’s name when communicated via some means, such as these words… to which I (unfortunately) have no suitable reply other than: yes, yes I am being pedantic.