Comment by troad
6 hours ago
Haha, I knew you'd bring up Go. I even considered pre-emptively dropping Rust and Zig as counterexamples. I think most people who favour static typing consider the duck-typed interfaces of Go to be a mistake. Personally, I consider all of Go to be a mistake.
> these type system features were added by multiple experienced language designers for a reason
Oooh, an appeal to authority, where that authority isn't even named. I'll have you know a famous queen told me you're wrong on this, also for "a reason".
> TypeScript has several runtime-safe advanced validators based on its type system (most well-known being Zod), capable of enforcing types similar to what I provided.
Right, so TS typing is so amazing it requires runtime parser libraries from NPM, and Haskell is less sophisticated because it's not stringly typed.
You realise the entire, complete, exhaustive runtime schema for your zero-first non-empty integer array example looks like this in Haskell, right?
sch (0:_) = True
sch _ = False
That's a complete function that somehow manages to work without pulling in NPM dependencies. The best JavaScript minds of our generation remain baffled.
> The Person/Wine example is a pointless strawman
> I didn't give practical examples to save space, obviously, it was just to disambiguate what I meant.
So when you use illustrative examples, it is to "disambiguate what you meant" (huh?), and when I do it, they're "pointless strawmen". A little hypocritical, no?
> a bit ignorant
Honestly, I don't think you know what you're talking about at all. You clearly hadn't even read my comment when you started replying with Python and TS examples... that were already in my comment.
It also really sounds like you're using string literals to type input without properly parsing it, which is just a terrible idea. Haskell's type system is designed precisely to protect you from this sort of mistake. [0] No, you're not always going to get what you expect. No, your JS program will never let you know that's the case. No, a sane type system does not require mainlining runtime parser libraries from the biohazardous oceans of NPM. A schema in Haskell is going to be significantly shorter and sounder than anything in Zod, and you don't need a library for it.
As I said above, TS' type system makes sense for a type system bolted onto a dynamic language post facto. TS needs to more tightly link (even mildly conflate) values and types, since it needs to do a lot of clever narrowing to figure out what mad ball of JS it is dealing with at any given time. Haskell does not operate under any such constraint.
> I don't see a productive continuation to this discussion.
Phew. Timesaver.
Of course the irony of all this is that I use TS daily, and Haskell quite rarely.
[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Yeah, you're just continuing to take whatever was written argumentatively/maliciously as predicted.
Does not seem like this:
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
> Personally, I consider all of Go to be a mistake.
You also consider Scala and OCaml to be mistakes? Because all of what I've mentioned also works in a very similar way in Scala.
> an appeal to authority
No, I didn't appeal to authority. It's the opposite - it's statistics. Multiple experienced language designers don't add features later for nothing. For a similar process, see eg. closures getting added to every mainstream language.
> complete, exhaustive runtime schema
Again, I wasn't talking about runtime schemas, but types. I only mentioned runtime as a counterpoint to the false statement that TypeScript doesn't enforce this. Only reducing this to runtime checking is a fallacy, again.
> A little hypocritical, no?
No, they aren't comparable since I wasn't using the examples as supports for an argument of whether X is better than Y. Strawmen involve argumentation.
> read my comment... examples... that were already in my comment
I read it in detail, the problem is you didn't really read my comment in detail, which illustrated both the subtyping and structural typing aspects (albeit trivially, yes), which yours didn't.
> You're also fairly clearly using string literals to type input without properly parsing it
Okay then, the arrogance of this is pretty astounding... You seem to know what I'm doing better than I am!
To be clear, I'm not doing any of that. And I've written Haskell way before I wrote any TypeScript.
I believe I was promised a respite from this.
Everything I said to you prior to my last message was fairly gentle. I'm not sure what response you were expecting to what you wrote at that point, which was to accuse me of disingenuous strawman arguments and ignorance. Perhaps you yourself would have benefited from a rule refresher?
> You seem to know what I'm doing better than I am
Apparently so! Trust me, it gives me no pleasure, and I'd rather I didn't.
> Again, I wasn't talking about runtime schemas, but types. I only mentioned runtime as a counterpoint to the false statement that TypeScript doesn't enforce this. Only reducing this to runtime checking is a fallacy, again.
My dear friend, this is almost completely incoherent.
I wish to strictly type myself as a function at this point, whereby your messages are my input, and void is my output. Zod, activate!
I would say, with a striped-shirt and not a glove in my hand, that the person you were fighting with gets the score, and wins by technicality. I suggest you take the bench first and review your comments and reflect with a wet towel on your head.