I can’t imagine an argument for why dynamic types would be better for implementing a known problem like that.
I can imagine an argument they might be better for discovering / experimenting in the “business domain” when neither the problem nor solution are clear
Conversation
"Experimentation" is the one argument I hear that sounds like anything but hubris. Personally, I'm starting to find that type driven development is useful in outlining the problem when it's underspecified too.
1
5
As I was typing that I was thinking back to the last time I used a decent type system, which was Flow on the ADL thing at TT - and it really did help me explore the problem. I think maybe the gradual typing escape hatches helped too
1
That's definitely the use case the gradual types people are arguing. I'm still a bit cautious about gradual types, but I suppose as long as you can go `tsc --strict` or smth in production, it's all good.
1
`flow coverage` was a flawed implementation, but a good idea I think
I do also think that many typecheckers aren’t powerful enough and can get in the way.
Not using the “ideal” typchecker would be foolish, but it doesn’t exist yet and what we have varies in distance from that
2
My experience with Rust has been frustrating, but while the type checker has definitely gotten in the way sometimes, the net gains are tremendous.
My experience with Haskell suggests it might be as close to ideal as I can cope with, given that it's never gotten in my way.
1
2
I’ve only ever done Haskell on toy things, last time I did anything I got lost in the numeric tower.
I can chalk that up to learning curve, but learning curve is a problem worth solving.
1
1
What keeps amazing me about Rust is that it has a learning curve nearly as steep as Haskell's, but somehow it doesn't discourage curious JSers and Rubyists and the likes from giving it a go and levelling up. I thing I have to blame the Rust community for just being that lovely.
1
3
Yeah, that’s a vibe I never got from Haskell.
My recent mentions are full of rigorous explanations of why my jokey imprecise tweet isn’t exactly correct according to their dictionary
3
3
Sorry for that - my to replies to your imprecision seemed to have sparked more corrections than really was needed. I'm excited and curious about this stuff and would love help other people to be too, but sometimes I'm not the most successful in my attempts!
1
1
I would be also clear that I don't align myself with Haskell - my crime is probably being somebody who attempts to implement languages and type systems, so I'm abnormally attuned to the difference between 'coercion' and 'inference'.
Replying to
No worries, there were many more worse examples.
Lots seemed to miss that just because the Haskell compiler infers “” and [] as the same, it doesn’t make them lexically equivalent.
Programming is expressing intent to a computer, I’d say no-one who types [] ever means “”
1
And so in the example of comparing two literals, the Haskell example is equally as “wrong” as the JavaScript one, regardless of whether there is a sound type safe explanation for the behaviour.