5 ms·

> What possible advantage is there to be gained from any other choice? You're thinking like a single individual. Almost all programming that happens in the rea

> What possible advantage is there to be gained from any other choice? You're thinking like a single individual. Almost all programming that happens in the real world is in teams, and most of that probably within companies. Teams and especially companies often benefit from strict standards that keep everyone on the same page and make it harder to screw things up.

dllthomas 4y ago
Those standards don't have to live between the individual and every single execution, though.
zozbot234 4y ago
Even a single individual has to team up with his past and future selves.
lisper 4y ago
> Teams and especially companies often benefit from strict standards that keep everyone on the same page and make it harder to screw things up. Sure, but those standards don't have to be enforced by the language design. They can be enforced, for example, by policy, e.g. "Don't push anything that produces warnings to the master branch". That still allows you to, for example, test parts of an uncompleted program, which can vastly improve productivity. Not being able to test-run a partially completed program can increase your development cycle by orders of magnitude.
- subarctic 4y ago
  Well, sure, they don't have to be. As a team you can come to an agreement on policies, and if you have the time, you can set up linting or configure your tools to make sure that they are enforced in CI. We use Rust and TypeScript at work, and for the latter we've made some effort to make it as strict as possible, and even added some eslint rules to enforce things more. But it sure is nice when the language itself does that by default for you, so you don't have to advocate for lint rules or tsconfig options and spend time setting them up. Plus, if it's built into the language, it effectively means that even people outside your organization are following the same policies as you. All that being said, your point is a valid one. It's a tradeoff and depending on what you're used to, you'll feel the pain from one approach or the other more strongly.
- masklinn 4y ago
  > 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
- lazide 4y ago
  The issue with enforcement by policy is it puts the onus of checking things on whoever is enforcing the policy. Which is usually either no-one, or an already busy/overloaded team lead or (even worse) manager. Every software engineering organization I’ve been at either wanted, or put in place, automated policy enforcement because otherwise it either never happened (and hence there were constant problems), or everyone hated doing it because it felt like a waste of their time (with it’s own constant source of problems). it’s best for everyone if a problem is identified and called out as close in time to when it’s created as possible, and as clearly as possible. Ideally before it can be part of any product, or be depended on by other work that would need to be refactored. Which automated tools can do cheaply. If it is in the compiler, even better! Doing it manually delays the feedback cycle, AND burns people decision energy, which is almost always the thing everyone is in the shortest supply of anyway.
  - lisper 4y ago
    > it’s best for everyone if a problem is identified and called out as close in time to when it’s created as possible, and as clearly as possible. Sure. But it does not follow that it is beneficial for your language to forbid you from testing some code you wrote over here until you fix a completely unrelated problem over there, indeed until you fix every single problem that the compiler can find. > Doing it manually delays the feedback cycle I'm not talking about "doing it manually", I'm talking about the compiler issuing warnings instead of errors.
    - lazide 4y ago
      If you can check in those problems, and make them problems for everyone else - it absolutely is an issue! If the policy is ‘you can generate “warnings” all your want locally, but you can’t check them in’ then sure. The issue of course is folks want to check things in as soon as they ‘work’ in their basic use case, even if it means bypassing a bypassable alert. So it means enforcing it at check-in time, in a non bypassable way (usually), which just means folks have a lot of ‘hidden’ cleanup to do before submitting, while they have their code ‘working’, which is always a drag.
- TulliusCicero 4y ago
  > They can be enforced, for example, by policy, e.g. "Don't push anything that produces warnings to the master branch". I laughed out loud when I read this. Funny thing is, this would work where I'm at now, Google, because Google actually has an enormous number of presubmit checks that require all KINDS of things out of your code, it's practically crazy how many checks it runs. Since there's already so much setup for these checks, yeah adding one more would be fine (and it already does this for type annotations for dynamically typed languages like Javascript). But most places aren't Google, and it's way more realistic to prevent this kind of problem by just having a language that'll enforce it automatically, then you never have to think about it, or have a policy debate, or always make sure during code review to look for that thing, etc. If I'm putting out some small open source library where I might get an occasional pull request, I'd much rather have the language automatically enforce correct typing than have to remember to look for it myself every time (and then possibly miss something if I screw up).
- shepherdjerred 4y ago
  > Don't push anything that produces warnings to the master branch I have never worked on a project that has actually followed such advice.
- TulliusCicero 4y ago
  > Not being able to test-run a partially completed program can increase your development cycle by orders of magnitude. This sounds insane to me. Do you really think needing to specify types up front saves you that much time? Multiple orders of magnitude means you're talking a 100x speedup at minimum.
  - JonChesterfield 4y ago
    Could be right. Make a change in one place to see how it behaves, code elsewhere that wouldn't be executed for your test input now doesn't compile - do you get to learn from that experiment now, or do you have to go and placate the compiler temporarily first. For example, making unused function arguments a fatal error would be an easy place to increase iteration time.
- kaba0 4y ago
  Initially I disagreed with you, but I do see value in what you propose, but I would implement it the other way around — add an option to the compiler that turns type check errors into warnings only, say dev mode. Then the following arguments are moot, as CICD will run it in the “sane default” setting.

dllthomas 4y ago

Those standards don't have to live between the individual and every single execution, though.

zozbot234 4y ago

Even a single individual has to team up with his past and future selves.

lisper 4y ago

> Teams and especially companies often benefit from strict standards that keep everyone on the same page and make it harder to screw things up. Sure, but those standards don't have to be enforced by the language design. They can be enforced, for example, by policy, e.g. "Don't push anything that produces warnings to the master branch". That still allows you to, for example, test parts of an uncompleted program, which can vastly improve productivity. Not being able to test-run a partially completed program can increase your development cycle by orders of magnitude.

subarctic 4y ago
Well, sure, they don't have to be. As a team you can come to an agreement on policies, and if you have the time, you can set up linting or configure your tools to make sure that they are enforced in CI. We use Rust and TypeScript at work, and for the latter we've made some effort to make it as strict as possible, and even added some eslint rules to enforce things more. But it sure is nice when the language itself does that by default for you, so you don't have to advocate for lint rules or tsconfig options and spend time setting them up. Plus, if it's built into the language, it effectively means that even people outside your organization are following the same policies as you. All that being said, your point is a valid one. It's a tradeoff and depending on what you're used to, you'll feel the pain from one approach or the other more strongly.
masklinn 4y ago
> 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
lazide 4y ago
The issue with enforcement by policy is it puts the onus of checking things on whoever is enforcing the policy. Which is usually either no-one, or an already busy/overloaded team lead or (even worse) manager. Every software engineering organization I’ve been at either wanted, or put in place, automated policy enforcement because otherwise it either never happened (and hence there were constant problems), or everyone hated doing it because it felt like a waste of their time (with it’s own constant source of problems). it’s best for everyone if a problem is identified and called out as close in time to when it’s created as possible, and as clearly as possible. Ideally before it can be part of any product, or be depended on by other work that would need to be refactored. Which automated tools can do cheaply. If it is in the compiler, even better! Doing it manually delays the feedback cycle, AND burns people decision energy, which is almost always the thing everyone is in the shortest supply of anyway.
- lisper 4y ago
  > it’s best for everyone if a problem is identified and called out as close in time to when it’s created as possible, and as clearly as possible. Sure. But it does not follow that it is beneficial for your language to forbid you from testing some code you wrote over here until you fix a completely unrelated problem over there, indeed until you fix every single problem that the compiler can find. > Doing it manually delays the feedback cycle I'm not talking about "doing it manually", I'm talking about the compiler issuing warnings instead of errors.
  - lazide 4y ago
    If you can check in those problems, and make them problems for everyone else - it absolutely is an issue! If the policy is ‘you can generate “warnings” all your want locally, but you can’t check them in’ then sure. The issue of course is folks want to check things in as soon as they ‘work’ in their basic use case, even if it means bypassing a bypassable alert. So it means enforcing it at check-in time, in a non bypassable way (usually), which just means folks have a lot of ‘hidden’ cleanup to do before submitting, while they have their code ‘working’, which is always a drag.
TulliusCicero 4y ago
> They can be enforced, for example, by policy, e.g. "Don't push anything that produces warnings to the master branch". I laughed out loud when I read this. Funny thing is, this would work where I'm at now, Google, because Google actually has an enormous number of presubmit checks that require all KINDS of things out of your code, it's practically crazy how many checks it runs. Since there's already so much setup for these checks, yeah adding one more would be fine (and it already does this for type annotations for dynamically typed languages like Javascript). But most places aren't Google, and it's way more realistic to prevent this kind of problem by just having a language that'll enforce it automatically, then you never have to think about it, or have a policy debate, or always make sure during code review to look for that thing, etc. If I'm putting out some small open source library where I might get an occasional pull request, I'd much rather have the language automatically enforce correct typing than have to remember to look for it myself every time (and then possibly miss something if I screw up).
shepherdjerred 4y ago
> Don't push anything that produces warnings to the master branch I have never worked on a project that has actually followed such advice.
TulliusCicero 4y ago
> Not being able to test-run a partially completed program can increase your development cycle by orders of magnitude. This sounds insane to me. Do you really think needing to specify types up front saves you that much time? Multiple orders of magnitude means you're talking a 100x speedup at minimum.
- JonChesterfield 4y ago
  Could be right. Make a change in one place to see how it behaves, code elsewhere that wouldn't be executed for your test input now doesn't compile - do you get to learn from that experiment now, or do you have to go and placate the compiler temporarily first. For example, making unused function arguments a fatal error would be an easy place to increase iteration time.
kaba0 4y ago
Initially I disagreed with you, but I do see value in what you propose, but I would implement it the other way around — add an option to the compiler that turns type check errors into warnings only, say dev mode. Then the following arguments are moot, as CICD will run it in the “sane default” setting.