4 ms·

Why the downvote?

• tkxxx7 10y ago
  I didn't downvote, but I'd guess it's because you didn't answer the parent's question exactly, which was asking the OP's rationale for their opinion (not the rationale for the addition to the language). Your comment still provides valuable context so it seems unfair to me.
• junke 10y ago
  I didn't downvote either. I would have like to read a more convincing answer, but this always come down to "Rob Pike says so". I found an old thread about this btw: https://news.ycombinator.com/item?id=5201461 https://news.ycombinator.com/item?id=5201461.
  • ngrilly 10y ago
    It's not because "Rob Pike says so". It just happens that I agree with him on this matter, which is why I mentioned his answer :-) Thanks for the link, including tptacek comments, which are very convincing.
    • junke 10y ago
      > As a result, a lot of packages do The Simplest Thing That Could Possibly Work and just expose simple functions. The result is usually refreshingly clear. That's what I do too, but I don't change names. I use "export" declarations for packages, which are completely orthogonal to what the symbol represents. Less naming problems. The capitalization thing would be in the "Meh" category for me, that's all.
      • ngrilly 10y ago
        Interesting! In which language?
        • junke 10y ago
          Common Lisp (packages and symbols are first class). There are some gotchas at first but then they feel quite natural. You write your code in one place and manage visibility elsewhere. This allows for example to make a symbol exported in different packages, or take separate code and provide a unified facade package. But most of the time you just need to define the public interface of your code and this is quite easy.