2 ms·

Except when you come to a new company and find out they're using the new glory all over the place and insist you do too.

Jtsummers 6y ago
Well, if you join a team you join whatever they're using. Which may not even be C. If you want control, you have to lead the team in the company or run your own company. That's part of being a "company man". You forfeit control over the kinds of things you work on and many decisions about what and how they're made unless you have the right ear or the right level of authority.
- emteycz 6y ago
  And that's why the commenter wants people to not touch C - if C doesn't change then the workplace won't change too.
  - UncleMeat 6y ago
    Or companies will leave C behind.
  - Jtsummers 6y ago
    I mean, you can try and hold back the tide but the world changes. Take control of your section of it if you want control, but you can't stop change. Perhaps try to become as relatively unpopular as Common Lisp so that no new standards are ever made (though the community continues to extend the language environment with things like QuickLisp and Alexandria). Or as truly unpopular as JOVIAL so that there really are no more changes.
    - emteycz 6y ago
      Not everyone has the means to become their own employer. I agree with you about control and I myself am in business for this reason, but suggesting that they should simply use whatever they like doesn't address the problem. Blowing up language is not nice even for me as a businessman - now I have to place special care about who's coding what and how, something I didn't need to do up until now (in case of C).
      - Jtsummers 6y ago
        > Blowing up language is not nice even for me as a businessman - now I have to place special care about who's coding what and how, something I didn't need to do up until now (in case of C). This part is fair, but I've never worked (professionally) in a language that had a BDFL who controlled its extension in a deliberate fashion. It's always been design-by-committee languages. As a consequence, since I began, we've always had coding standards that limited what portions we could use for which projects (usually with options to try out novel parts of the language/standard library with extra reviews). And this is even true with C, though the restrictions weren't as severe (working in embedded, typically mandating no/limited use of malloc/free and no recursion, direct or indirect).

Jtsummers 6y ago

Well, if you join a team you join whatever they're using. Which may not even be C. If you want control, you have to lead the team in the company or run your own company. That's part of being a "company man". You forfeit control over the kinds of things you work on and many decisions about what and how they're made unless you have the right ear or the right level of authority.

emteycz 6y ago
And that's why the commenter wants people to not touch C - if C doesn't change then the workplace won't change too.
- UncleMeat 6y ago
  Or companies will leave C behind.
- Jtsummers 6y ago
  I mean, you can try and hold back the tide but the world changes. Take control of your section of it if you want control, but you can't stop change. Perhaps try to become as relatively unpopular as Common Lisp so that no new standards are ever made (though the community continues to extend the language environment with things like QuickLisp and Alexandria). Or as truly unpopular as JOVIAL so that there really are no more changes.
  - emteycz 6y ago
    Not everyone has the means to become their own employer. I agree with you about control and I myself am in business for this reason, but suggesting that they should simply use whatever they like doesn't address the problem. Blowing up language is not nice even for me as a businessman - now I have to place special care about who's coding what and how, something I didn't need to do up until now (in case of C).
    - Jtsummers 6y ago
      > Blowing up language is not nice even for me as a businessman - now I have to place special care about who's coding what and how, something I didn't need to do up until now (in case of C). This part is fair, but I've never worked (professionally) in a language that had a BDFL who controlled its extension in a deliberate fashion. It's always been design-by-committee languages. As a consequence, since I began, we've always had coding standards that limited what portions we could use for which projects (usually with options to try out novel parts of the language/standard library with extra reviews). And this is even true with C, though the restrictions weren't as severe (working in embedded, typically mandating no/limited use of malloc/free and no recursion, direct or indirect).