Hacker News Reader

Comment by madeofpalk | Hacker News Reader

> it allows you to convince it you know what you're doing and, really, this will be fine in reality even if the types don't really agree

I disagree here. Typescript allows you to lie about your code, and that's only a ticking time bomb that will work until it doesn't. The workaround might work in the current state of your application, but over time if things/people change, it makes it much more difficult to reason about things.

Because typescript allows interfaces to have additional properties, five levels up the call stack someone will pass in an object that has extra properties for whatever reason, and then the assumptions we once made about the code fall out and you ship an unknown bug.

View on HN

The only way I can think of off the top of my head where this would be an issue is when calling JSON.stringify on the object, or a similar function that operates on all available keys. But for the most part, why would you write a function like that if you only wanted to operate on certain keys?

Of course, you'd run into the same issue in regular Javascript by expecting a base class and receiving a child class of that base.

It's amazing how in practice it's not really a big deal.

I've worked on many dynamically types systems and have no problems thinking in terms of compile time, run time, and macro expansion if you're so lucky, but some people just want the computer to say yes.

Oh and miss specification of the system will happen in all. Even when computer says yes.

This is purely anecdotal.

I could just as easily argue with equivalent experience the exact opposite.

So what? Someone choosing to act based on their experience is what being experienced IS. We all do it. I do it. You do it. The grandparent comment is very conveniently particularly worded: “until it doesn’t”, with at times orders of magnitude of differences in the likelihood of “until” happening.

If you’re acting like a type system suddenly means that you aren’t making trade-offs, that’s a huge sign of incompetence in my eyes. And if you AREN’T acting like this, what precisely is the issue here?

Not everything needs to be an argument. The parent commenter is quite rightfully pointing out some nuance, not necessarily arguing that Your Preferred Way To Do Things is wrong.

> The grandparent comment is very conveniently particularly worded: “until it doesn’t”

Those words do not appear in the comment that I replied to.

The argument that I'm challenging is this opening line:

> It's amazing how in practice it's not really a big deal.

I'm not discarding their experience, but from my own experience I would argue the opposite — in practice it really is a big deal.

That's fine. You can not like/believe in static types - I'm not here to debate that (even if i did start accidentally advocating for it).

What I don't understand is why you would chose to use Typescript, and then opt out of the only/main benefit it actually has. At that point you're just writing dynamically typed Javascript with more keyboard presses.

Why do type system discussions bring out this type of academic-tier absolutism? You can get immense value out of TS even if you hit eject every so often, just like you get immense value out of Rust’s memory safety even if you write unsafe code, just like you get immense value out of 2FA even if you tick “remember me for 30 days”. Arguing that you shouldn’t use TS if you override it sometimes is throwing 100 babies out with the bathwater. Extending this to claiming that someone “doesn’t believe in static types” is needlessly argumentative and presumptuous. Anyone that makes this sort of absolute argument, I’d argue either hasn’t used TS enough, is using it in an environment where resources can be burned working around and abstracting the cases where it isn’t expressive enough, or has an overly permissive configuration.

Reply on news.ycombinator.com