3 ms·

> Unused imports flagged as an error is great for production code, but infuriating during developing, when you need to work with a lot of tentative code, the mo

> Unused imports flagged as an error is great for production code, but infuriating during developing, when you need to work with a lot of tentative code, the most basic of which involves printing. This sentence has baked into it a context which is not universal. Namely that "during developing" you are "work[ing] with a lot of tentative code". That's simply not how I, nor many others, develop. Even on the very first sketch of a program, I'm writing complete, valid types and functions. I code all of the error paths completely as I encounter them. For very large first drafts, I'll often stub methods or types, but I never leave the program in an invalid state and "try it out". (Tangentially, for what I suspect are similar reasons, I never quite understood why anyone would care so much about REPLs.) All of the tentativity, so to speak, has been expressed and explored in my head and on paper beforehand. Go is a language that rewards, perhaps even demands, this style of development. If that's not how you operate, Go will feel like it's fighting you. But that's not a universal critique of the language, that's a very specific critique of your specific operating context.

lobster_johnson 11y ago
I'm pretty sure you are in the minority — REPLs are provably immensely popular, for example (I've never heard anyone criticize their usefulness). Sometimes I write code like you do. At other times I'm "feeling out" a solution and want the language to not fight my half-baked, messy (but syntactically valid!) program. At other times I'm writing a quick and dirty script I will use today and never after; it doesn't need to be pretty, only functional. But Go wants your code to always be fully realized and clean, which just doesn't mesh with reality. We don't need "universal critiques". Everyone has a style, and a good, mainstream programming language needs to be receptive to those styles.
- sagichmal 11y ago
  > Go wants your code to always be fully realized and clean, which just doesn't mesh with reality. It certainly meshes with my reality.
  - lobster_johnson 11y ago
    Sure. Great. However, there are other realities outside yours.
    - sagichmal 11y ago
      ...yes, of course. Acknowledging the diverse set of realities is the point of my original comment :)
      - lobster_johnson 11y ago
        ...But the fact that it is diverse is the exact problem that Go doesn't address.
        sagichmal 11y ago
        A language isn't obliged to serve all realities equally. Quite the opposite: a language, a framework, a system -- a product -- should carve out a set of contexts that it's explicitly targeting, and fiercely guard those boundaries. Otherwise, you get terrible products that are nothing more than the lesser sum of their features, like JIRA, or Scala.
        lobster_johnson 11y ago
        This is about basic ergonomy, though.

lobster_johnson 11y ago

I'm pretty sure you are in the minority — REPLs are provably immensely popular, for example (I've never heard anyone criticize their usefulness). Sometimes I write code like you do. At other times I'm "feeling out" a solution and want the language to not fight my half-baked, messy (but syntactically valid!) program. At other times I'm writing a quick and dirty script I will use today and never after; it doesn't need to be pretty, only functional. But Go wants your code to always be fully realized and clean, which just doesn't mesh with reality. We don't need "universal critiques". Everyone has a style, and a good, mainstream programming language needs to be receptive to those styles.

sagichmal 11y ago
> Go wants your code to always be fully realized and clean, which just doesn't mesh with reality. It certainly meshes with my reality.
- lobster_johnson 11y ago
  Sure. Great. However, there are other realities outside yours.
  - sagichmal 11y ago
    ...yes, of course. Acknowledging the diverse set of realities is the point of my original comment :)
    - lobster_johnson 11y ago
      ...But the fact that it is diverse is the exact problem that Go doesn't address.
      - sagichmal 11y ago
        A language isn't obliged to serve all realities equally. Quite the opposite: a language, a framework, a system -- a product -- should carve out a set of contexts that it's explicitly targeting, and fiercely guard those boundaries. Otherwise, you get terrible products that are nothing more than the lesser sum of their features, like JIRA, or Scala.
        lobster_johnson 11y ago
        This is about basic ergonomy, though.