> The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out.
Sure, empirical knowledge isn't the only knowledge there is, but this is what your proposal sounds like:
"Hi $TECHLEAD, I think we should use TypeScript because it's good documentation, and because it helps me think about the system."
My response would be: "that sounds like changing our whole development toolchain, which would be a lot of work and carries a lot of risk; what if we wrote some documentation instead?"
In A Philosophy of Software Design, John Ousterhout writes that (paraphrasing) because code is always an imperfect representation of a model, comments are required in order to fill in the gap. This rings true to me, and I'm skeptical that any type system--much less a mainstream one--could overcome what seems like a fundamental limitation of information. I'm more receptive to documentation: comments, code docs, arch docs, etc.
---
> so suggesting data driven decision making such as benchmarking because you don't trust Big-O
The reason people benchmark is because Big-O notation is incomplete: it doesn't describe n. You can't describe the performance of a system with Big-O alone. Maybe I'm digging into a poor example here, but I don't think it really fits in our discussion.
> quantifying typescript's benefits instead of actually thinking about them is a cop out
This is a little dismissive; I'm actually a person who likes types and misses them when I don't have them. I often move between languages (or the same language typed and untyped like Python or JS/TS). Consequently I have some experience across lots of different verification/validation/constraint/testing systems. My general take is that what your type system doesn't provide your tests can compensate for, and since you (should) have tests anyway, a type system's benefits are diminished. Further, tests can check things type systems can't, and can be traced to requirements. For example:
int add(int a, int b) {
return a - b;
}
A type system can tell you a lot about this function: its domain/range, overflow/underflow risks, etc. What it can't do is tell you that the function has the wrong name.
Dynamic language communities have known about stuff like this for a long time. Indeed a lot of people are fans of TDD precisely for the reason you mention: tests are tools that help you think and reason about a code base. Types are not a silver bullet, there are always trade offs, software engineering is the agony of never really being sure but having to ship anyway.