29 ms·

Not surprisingly (as the OP), I disagree. Good names help people understand concepts; bad names confuse. Choosing good names is not merely aesthetics, it's brin

Not surprisingly (as the OP), I disagree. Good names help people understand concepts; bad names confuse. Choosing good names is not merely aesthetics, it's bringing clarity, meaning, and culture. That said, in this particular case, I think Russ could have chosen a better example. Neither "acquire" nor "take_ownership" are terrible. But when you're a language designer (like Russ), the names you choose shape people's code and their thinking for the next 10, 20, even 50 years. When you're a library designer (many of us are), it might only be a few years, but still. I think as code reviewers we should take this as seriously as the context demands: for internal names and local variables, it's not too important. For public API names, very important. For language changes, extremely important. Some good quotes from Bob Nystrom, author of "Crafting Interpreters": "Names are the structure we impose on the formless sea of bits that is computing." http://journal.stuffwithstuff.com/2016/06/16/long-names-are-long/ http://journal.stuffwithstuff.com/2016/06/16/long-names-are-... "For me, thinking about names is inseparable from the process of design. To name something is to define it." http://journal.stuffwithstuff.com/2009/06/05/naming-things-in-code/ http://journal.stuffwithstuff.com/2009/06/05/naming-things-i...

spicyusername 3y ago
I don't disagree that things like function naming are important. I understand that it's important to think critically about the philosophical North stars of your work. This is precisely what it means to be an "expert". I appreciate the work you're doing adding your voice to the discussion. That being said, it doesn't change the fact that, for me, it's tiring working in a profession where nothing is "real". There is never going to be an end to these kinds of discussions, because everything is abstract, relative, and ever-changing. Unlike many other professions grounded in the limitations of physical reality: carpentry, civil engineering, hair cutting, etc, Software Engineering is a house of cards of artificial abstractions. The tools and architectural patterns are mostly free from physical constraint, so they can change at will, and they do. What is "good" is highly dependent on context, and in our case that context is fluid, changing along every dimension all the time, making it very hard to establish a shared understanding of any given problem. This translates into a work culture where there is always room for debate about what to do, since there is almost never an objective best next step. And debate we do.
- benhoyt 3y ago
  > Unlike many other professions grounded in the limitations of physical reality: carpentry, civil engineering, hair cutting, etc, Software Engineering is a house of cards of artificial abstractions. The tools and architectural patterns are mostly free from physical constraint, so they can change at will, and they do. Interesting comment, thanks. It certainly puts your original comment in perspective, and I respect that position. I suppose this is related to the position that "computer science is more art than science".

spicyusername 3y ago

I don't disagree that things like function naming are important. I understand that it's important to think critically about the philosophical North stars of your work. This is precisely what it means to be an "expert". I appreciate the work you're doing adding your voice to the discussion. That being said, it doesn't change the fact that, for me, it's tiring working in a profession where nothing is "real". There is never going to be an end to these kinds of discussions, because everything is abstract, relative, and ever-changing. Unlike many other professions grounded in the limitations of physical reality: carpentry, civil engineering, hair cutting, etc, Software Engineering is a house of cards of artificial abstractions. The tools and architectural patterns are mostly free from physical constraint, so they can change at will, and they do. What is "good" is highly dependent on context, and in our case that context is fluid, changing along every dimension all the time, making it very hard to establish a shared understanding of any given problem. This translates into a work culture where there is always room for debate about what to do, since there is almost never an objective best next step. And debate we do.

benhoyt 3y ago
> Unlike many other professions grounded in the limitations of physical reality: carpentry, civil engineering, hair cutting, etc, Software Engineering is a house of cards of artificial abstractions. The tools and architectural patterns are mostly free from physical constraint, so they can change at will, and they do. Interesting comment, thanks. It certainly puts your original comment in perspective, and I respect that position. I suppose this is related to the position that "computer science is more art than science".