[parent predicts flamewar, starts one with:]
> Their reasoning is along the lines of, "I don't need a type system because I'm a professional and don't make mistakes."
Nah. Where did you get that? That's so horribly wrong, it's not even funny.
Types are one tool in the toolbox to describe a system. It is not the most powerful or expressive one. It just happens to be available at compile-time.
It catches trivial bugs, acts as documentation, helps the compiler with memory allocation.
It also is static. And that's where the weaknesses begin. A whole class of problems that benefit from domain definitions being available at runtime are clumsy to write in languages that force types on you. Not impossible, of course, but clumsy. (i.e. place-oriented programming)
To your point:
Everyone makes mistakes. The way to catch them and to prevent them in the future is not by having types. It's by writing tests.
Tests > Types > no types at all
Did you miss the part where they said "... at runtime are clumsy to write in languages that force types on you.."
That may most likely put "types + tests" at the bottom of their food-chain. And speaking of TS, since it compiles down to JS in production, it can be considered a very basic type of testing, or an advanced type of linting.
> That may most likely put "types + tests" at the bottom of their food-chain.
That is totally illogical.
If types are better than nothing, and tests are better than nothing, then how could both tests and types together be worse than nothing?
> Did you miss the part where they said "... at runtime are clumsy to write in languages that force types on you.."
No, I didn't miss it. I just disagree with it. Interpreting values at runtime is called "parsing". The parsing step exists regardless of whether the program is written in a static language or a dynamic language.
> If types are better than nothing, and tests are better than nothing, then how could both tests and types together be worse than nothing?
Ok, move it to the left by one, my point still stands: considering his goals and experience, types + tests will most likely be almost at the bottom of their food chain.
> No, I didn't miss it. I just disagree with it. Interpreting values at runtime is called "parsing".
Actually, you completely misunderstood it. It has nothing to do with parsing. Its all about design patterns, functional + dynamic language design patterns to be more specific.
1. I disagree. Perhaps this[0] will help you understand the bits you are missing.
2. I do not understand why you are so hostile. To try and understand, I went through some of your comment history, and I can see it's not just me you are hostile towards. Furthermore, you appear to have a poor understanding of how JavaScript works. For the former reason, at least until your anger issues are addressed, I don't find it constructive to continue discussion with you.
I have not yet looked at your comment history, but just looking at your comments a few lines up, that's what I've found. And the first two are your comment to someone else. Ever heard of projection? That is what you are suffering from if you cannot see that you are just as hostile as I am.
Personally, I respond in kind, so I am very much aware of when I'm being hostile. And unlike you, I never resort to cheap personal insults about the understanding or abilities of the people I engage with. That's just beneath me, my friend.
Nah. Where did you get that? That's so horribly wrong, it's not even funny.
Types are one tool in the toolbox to describe a system. It is not the most powerful or expressive one. It just happens to be available at compile-time. It catches trivial bugs, acts as documentation, helps the compiler with memory allocation.
It also is static. And that's where the weaknesses begin. A whole class of problems that benefit from domain definitions being available at runtime are clumsy to write in languages that force types on you. Not impossible, of course, but clumsy. (i.e. place-oriented programming)
To your point:
Everyone makes mistakes. The way to catch them and to prevent them in the future is not by having types. It's by writing tests. Tests > Types > no types at all