1. 28

  2. 7

    Ohh I remember working in Haskell and being extremely frustrated that libraries wouldn’t use longer generic type names. Free documentation opportunity, wasted! There’s easy stuff and common shortcuts, but sometimes I just get lost in the noise

    1. 1

      Often in Haskell the idea is to reduce the scope of what you need to keep in your head at any given time. Often the types themselves are the most important details. For example when looking at a function with two args you can often reduce the scope to the input types and the output types. Knowing the outer context about where the inputs come from is actually a burden in this situation and can lead to misunderstandings. We only care about the implementation of this little function. Clear your mind of all other thoughts ;)

      To keep the implementation free and clear of meaning collisions we use very simple names.

      Also sometimes it can get so general and category or type theory heavy that there are no good names!

      But I agree sometimes it’s a bit too much.

    2. 5

      I agree lifetimes should have more descriptive names, but I wish the examples in this post learned the lessons from variable naming around pervasive abbreviations also not being great. Why abbreviate author to auth to save 2 characters? Why not call it 'author and 'provider? This is not much typing, probably has autocomplete support, and requires less guessing. if it is a provisioner or provider, author, authentication, authorization, …

      1. 3

        This example is a bit contrived and may not be considered sufficiently useful in terms of the additional explanatory value of the longer name, but helps to illustrate the idea that names can be longer.

        That’s some good pedagogy, calling out that this specific example is purely about syntax

        1. 1

          Hm… I have mixed feelings here. There are libraries I have used that have names for the lifetimes, and in certain situations I agree it makes it more useful, but I think its a pretty niche use-case.

          Since lifetimes are akin to generic types (where we generally use single letters like T and U) I think it makes sense in most cases to keep lifetimes as single letters. Otherwise it risks just adding noise for no real reason.

          Of course, nothing in software is black and white, and there are situations for single-character and for full names. It is certainly good to be aware of the options.

          1. 2

            Yeah, I try not to prescriptively state that one thing is better or worse when I’m writing for Possible Rust. There are lots of reasons to make one choice or the other, and they include considerations outside the software like the knowledge and experience of the team. Sticking to describing what’s “possible” (hence the name of the site) is a safer strategy for sharing useful knowledge.

            1. 1

              Right on! I think the post is good at showing the options available. I was just adding my personal commentary on the topic to see what others might think.

              Sorry if it seems like I’m disagreeing with the post! Although to your point, there isn’t really anything to disagree with because you’ve just stated the available option.

              1. 2

                No worry at all! I was trying to provide a bit of context for my own thinking around the purpose of the site and the posts. You’re right that the framing makes disagreeing with the stances the site takes difficult (because I try not to take stances usually), but I find the conversations around the posts often end up in the lovely world of exploring trade-offs, edge cases, and situational case studies. That’s what I’m looking for!