I won’t @ them but limiting expressivity in order to limit cognitive load and keep codebases approachable is a totally legitimate move in language design. I’d even say essential. It’s all about balance, and expressivity _does_ have tradeoffs.https://twitter.com/SeanTAllen/status/1036236006872305665 …
-
-
Replying to @graydon_pub
In the case of generics, the cost of leaving out even simple generics has a high cognitive load cost. I have no problem with taking it slow and conservative; that's a reasonable place for them. But the koans and zealous arguments against generics disrupt the design process.
2 replies 1 retweet 10 likes -
Replying to @wycats
I can't say I agree. The cognitive load of any static typing discipline is in mentally modelling the dynamic (unspecified-by-typing) residue; the residue-model gets simpler the fancier the types get, but nonlinearly. Balance is load of residue vs. load of the types themselves.
2 replies 0 retweets 17 likes -
Replying to @graydon_pub @wycats
To me, the nonlinearity is the key here. Residue is already off the cliff of undecidability, so meaningful chunks are quite hard to take out of it. Whereas simpler type systems impose dramatically-less load than more-complex ones (which themselves often fall off same cliff).
1 reply 0 retweets 2 likes -
Replying to @graydon_pub @wycats
Many users have experienced "my program is simple, but type system is so complex that I can't for the life of me get it to typecheck" which is .. a thing you want to reserve for only the gravest / most-pervasive problems if you want anyone to have the patience to use the thing.
2 replies 1 retweet 11 likes -
Replying to @graydon_pub
Again, of course this is true. But type systems that in practice lean a lot on dynamic casts are playing a shell game with complexity that at least in my experience doesn't result in a type system that is as cognitively as simple as the formal model would imply.
2 replies 0 retweets 0 likes -
Replying to @wycats @graydon_pub
Rust's unsafe model is a good example of such an escape valve that allows the language to avoid an impossibly hard formal safety model. This is a good thing! But it would be less good if most programmers, even beginners, had to use the escape valve a lot to get things done.
1 reply 0 retweets 2 likes -
Replying to @wycats @graydon_pub
And in such a world, keeping the formal model simple would have been a mirage, with practical Rust programs segfaulting all over the place. In this world, languages without a formal safety model would easily be able to argue against even *having* a safety model on these grounds
1 reply 0 retweets 0 likes -
Replying to @wycats @graydon_pub
You're of course right about the non-linear nature of the tradeoff, but also assuming that Go crossed the breakeven point for the vast majority of the cases it's used for. There's good evidence (including the design of Go 2!) that this isn't quite right.
1 reply 0 retweets 1 like -
Replying to @wycats
Agreed. I'm just saying it's not a slam dunk. There's plenty of evidence on the "no, actually, it's gone far enough for the intended balance" argument too. (I also think it's interesting that new compiler-supported polymorphic types and/or non-generic tycons aren't on the list.)
1 reply 0 retweets 2 likes
Yeah, I think it's possible to argue that, but also interesting that it hasn't been sustained for a language that wants to be as general-purpose as Go. Someone might make another go at it, and it'd be interesting again!
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.