3 ms·

> Sure, but those standards don't have to be enforced by the language design. They can be enforced, for example, by policy Yes, policy debates are amazing, so

> Sure, but those standards don't have to be enforced by the language design. They can be enforced, for example, by policy Yes, policy debates are amazing, so fun, so productive. And nothing funnier than having to discover completely new and incompatible policy when changing company, or trying to change policy. That's one of the few good things I have to say about Go, they considered policy debates and went "fuck that". I think they went too far and wrong in lots of ways, but on that front I can't fault the heart, even if I hate the language.

lisper 4y ago
I don't see any reason that policy debates should be any more problematic than language debates.
- mcherm 4y ago
  Language debates are over once a substantial amount of the code has been written. Policy debates continue eternally.
  - spankalee 4y ago
    This is silly. There are tools that enforce the types of policy we're talking here very well. In a TypeScript codebase you would not let CI pass if the TypeScript build fails. Locally you can still run the output. There's not much room for debate and I've never seen a TypeScript project that both has CI and allowed failing builds to be merged. I've also never heard of someone proposing that PRs failing to build should be allowed to be merged.
  - hbrn 4y ago
    Not every team has eternal policy debates. Eternal debates indicate a deeper problem with the engineering culture. I'd rather have that problem become visible so that I could address it, than keep it hidden under a pile of irreversible decisions.
- peterashford 4y ago
  I do. Policy is up for debate. If your codebase is in <x> the debate is over
lliamander 4y ago
> Yes, policy debates are amazing, so fun, so productive. Who says there's going to be a debate? The commit hooks and/or CI pipeline should prevent you from merging code that doesn't pass typecheck. It's still enforced by tooling, just at a different place in the process.
- lazide 4y ago
  Which lets folks get deeper into trouble before running into a wall.
  - lliamander 4y ago
    Well, you're going to want those checks regardless because, if we really want to be pessimistic, developers can commit code without running the compiler locally anyway. The question is really, before you commit/push your code, and you just want to run the code, do you really need to be prevented from running the code just because it didn't pass typecheck? I'm inclined to say no.
    - lazide 4y ago
      It’s not being pessimistic, it happens all the time, which is why CI/CD is a thing. It’s also why if it’s a compiled language, I’d personally want to know if it’s definitely not going to be working if I go to check it in right away. If I wanted something that could kinda work, I’d just use a scripting language?

lisper 4y ago

I don't see any reason that policy debates should be any more problematic than language debates.

mcherm 4y ago
Language debates are over once a substantial amount of the code has been written. Policy debates continue eternally.
- spankalee 4y ago
  This is silly. There are tools that enforce the types of policy we're talking here very well. In a TypeScript codebase you would not let CI pass if the TypeScript build fails. Locally you can still run the output. There's not much room for debate and I've never seen a TypeScript project that both has CI and allowed failing builds to be merged. I've also never heard of someone proposing that PRs failing to build should be allowed to be merged.
- hbrn 4y ago
  Not every team has eternal policy debates. Eternal debates indicate a deeper problem with the engineering culture. I'd rather have that problem become visible so that I could address it, than keep it hidden under a pile of irreversible decisions.
peterashford 4y ago
I do. Policy is up for debate. If your codebase is in <x> the debate is over

lliamander 4y ago

> Yes, policy debates are amazing, so fun, so productive. Who says there's going to be a debate? The commit hooks and/or CI pipeline should prevent you from merging code that doesn't pass typecheck. It's still enforced by tooling, just at a different place in the process.

lazide 4y ago
Which lets folks get deeper into trouble before running into a wall.
- lliamander 4y ago
  Well, you're going to want those checks regardless because, if we really want to be pessimistic, developers can commit code without running the compiler locally anyway. The question is really, before you commit/push your code, and you just want to run the code, do you really need to be prevented from running the code just because it didn't pass typecheck? I'm inclined to say no.
  - lazide 4y ago
    It’s not being pessimistic, it happens all the time, which is why CI/CD is a thing. It’s also why if it’s a compiled language, I’d personally want to know if it’s definitely not going to be working if I go to check it in right away. If I wanted something that could kinda work, I’d just use a scripting language?