4 ms·

His point remains. If someone is so uncomfortable in all other languages that they have to pick a bad tool for the job, then they are probably not a good devel

His point remains. If someone is so uncomfortable in all other languages that they have to pick a bad tool for the job, then they are probably not a good developer. Obviously, we can't always pick or even know the absolute 'best' tool, but good grief there are a lot of better choices than typescript for cli tools.

Hermitian909 3y ago
Even if they know better suited languages, do they know the same better suited languages? I'm in a TS shop, 95% of our code is TS. I would assume that almost everyone we've hired knows at least one compiled language but that language might be C++, Go, or Java. The only way to write a CLI tool that anyone at the company can edit is to write it in TS and so, indeed, >90% of the CLI tools we write are in TS. Works fine.
- randomdata 3y ago
  > The only way to write a CLI tool that anyone at the company can edit is to write it in TS The only way? If you know C++, Java, or Go, even Typescript for that matter, they are all almost exactly the same. There is a little nuance with respect to setting up a project idiomatically, but once that groundwork is laid anyone can come along as they're simply going to copy the structure and style of what is already there anyway.
  - Hermitian909 3y ago
    > There is a little nuance with respect to setting up a project idiomatically, but once that groundwork is laid anyone can come along as they're simply going to copy the structure and style of what is already there anyway. You might think so! Having seen this tried in multiple 100+ engineering orgs, I think empirical evidence is against you. CLI tools can get surprisingly complicated (or use a surprisingly complicated set of language features). Many engineers will simply give up if a solution is not obvious in the first 5 minutes. The end result is you have a lot of team A asking team B for a minor feature or fix to team B's CLI tool, or worse, team A just writes a hacky workaround to the broken-ness in the CLI tool. Most people just don't care enough to put in the kind of effort for anything but the easy path.

Hermitian909 3y ago

Even if they know better suited languages, do they know the same better suited languages? I'm in a TS shop, 95% of our code is TS. I would assume that almost everyone we've hired knows at least one compiled language but that language might be C++, Go, or Java. The only way to write a CLI tool that anyone at the company can edit is to write it in TS and so, indeed, >90% of the CLI tools we write are in TS. Works fine.

randomdata 3y ago
> The only way to write a CLI tool that anyone at the company can edit is to write it in TS The only way? If you know C++, Java, or Go, even Typescript for that matter, they are all almost exactly the same. There is a little nuance with respect to setting up a project idiomatically, but once that groundwork is laid anyone can come along as they're simply going to copy the structure and style of what is already there anyway.
- Hermitian909 3y ago
  > There is a little nuance with respect to setting up a project idiomatically, but once that groundwork is laid anyone can come along as they're simply going to copy the structure and style of what is already there anyway. You might think so! Having seen this tried in multiple 100+ engineering orgs, I think empirical evidence is against you. CLI tools can get surprisingly complicated (or use a surprisingly complicated set of language features). Many engineers will simply give up if a solution is not obvious in the first 5 minutes. The end result is you have a lot of team A asking team B for a minor feature or fix to team B's CLI tool, or worse, team A just writes a hacky workaround to the broken-ness in the CLI tool. Most people just don't care enough to put in the kind of effort for anything but the easy path.