> What thing that violates a type check would be "perfectly fine to do"?
Here is an example limitation of typescript's type system that I routinely run into while developing real code [1].
I look at it like this. If you consider all possible programs, some are invalid, some are valid, and some are valid and useful. A type system's job is to reject as many invalid programs as possible while accepting as many valid programs as possible and trying to optimize for useful valid programs. Due to the halting problem this is impossible to do perfectly, so any given type system will likely accept some invalid programs and reject some useful valid programs. If the type system happens to reject your useful valid program, you'll likely have a bad day :)
Sometimes the type system is forcing you to think in terms of what it is that you are passing around. In this case, getEmails() isn't expecting a group of students or a group of faculty, but rather a group of people that can be emailed. You can introduce an interface of that type and have it inherited by both Student and Faculty and use that in the method for clarity and type-safety without over-relying on union types: https://www.typescriptlang.org/play?ssl=1&ssc=1&pln=38&pc=30...
I appreciate the effort you’ve both put in to concrete examples. I think yours gets to a point that I haven’t often seen stated. You’ve named your interface Person, but perhaps even Emailable could serve the purpose. The problem is that you had to name it. Naming well is hard, and I believe strong type systems often create a need for more names. It’s a cost I don’t often see considered in the tradeoff.
I’m not much of a clojure fan myself, but I think the observation is that by relaxing that last constraint of static typing (and given the other appropriate tools), that while you can’t solve The Expression Problem itself, it’s a bit easier to solve the real world problem that happened to manifest itself as the expression problem in your code.
By the way, I was also enticed by multi-methods in this area, but I ultimately don’t think multiple dispatch is necessary.
Yes, absolutely, but doing so would be moving the goalpost right out of the stadium. The expression problem isn't supposed to describe a challenge for people implementing line-of-business applications. It's a problem for programming language researchers.
I agree, I managed to make it through a PhD in physics and I never had a problem. Neither do I recall any of my class mates having a problem with hand written notation.
tslint, while quite useful last year, still had (and has) known bugs with unused variables, missing/incorrect type assertions, and other annoyances.
Most new versions of TypeScript expand on their `strict` rules, and just enabling `strict` in your tsconfig, as well as using prettier, is arguably a more robust superset of seatbelts than tslint offered. I deleted tslint from all my TS projects several months ago and don't miss it at all.
I honestly used to browse the web without an adblocker and bounce from the site if it was too bad. About a year ago I ended up getting so fed up with not being able to visit pretty much any site that I installed one. I’m totally fine with being served ads, and recognize that it will even come with some not so friendly user tracking. Surely it must be possible to both serve me your content and ads at the same time. My only explanation is that it is pure laziness on all sides. The content maker gets paid if they display ads, the ad network gets paid if they fill ad slots, and the advertiser somehow sells more product (this I’m more skeptical of). So no one in that chain ever bothers to think of the end user.
