5 ms·
I thought one of the basic lessons we learned from the last 70 years of programming language design is that it's a bad idea to make semantics depend on lexical
by DaveInTucson 7y ago
I thought one of the basic lessons we learned from the last 70 years of programming language design is that it's a bad idea to make semantics depend on lexical structure.
I'm really surprised people like Rob Pike and Ken Thompson would design a language where the visibility of an identifier depends on the case of its identifier.
- sim_card_map 7y agoInteresting. Do you have links? Or maybe a short summary why this is bad?
- apta 7y agoIt becomes very annoying and tedious to refactor when you need to change visibility. Suddenly, a single line change (e.g. changing private to public) needs an IDE to refactor it and make sure it gets all instances (which is quite ironic given that golang proponents generally shun IDEs). Now depending on how many instances changed, you would need to split up your diff for readability, or clutter your diff with needless changes.
- DaveInTucson 7y agoThe linked article discusses this in the first point: * Changing the visibility of a variable requires changing its name, everywhere it's used. * It also cuts contrary to some very long-standing traditions, like using all caps for global constant names, using title case for class names, and starting with lower case for most everything else.
- lacker 7y agoIf you work for a while at a larger company that enforces a style guide, it starts to make total sense. If your company's style guide already insists that identifiers should be named with some convention that matches their visibility, then by making that part of the language, you are simplifying the system. I would not be surprised if specifically the Google C++ style guide influenced this decision.