Potentially unpopular opinion: if you haven't studied type theory, you should not be designing programming languages, because you don't know the span of the design space. Sure, you can hack something together, but you won't know what it's missing or what you got wrong.
-
-
Replying to @perrymetzger
Slightly disagree: if your language has a typesystem (and it probably should, or else you should just be hacking Lisp), then *someone* in your team should be a typesystem specialist. Not every language designer needs be.
1 reply 0 retweets 3 likes -
Replying to @Ngnghm
I suspect that if a language has more than a couple of people designing it, it's probably too big to keep in your head, and that's probably bad. See C++ as an exemplar of what not to do. (That said, you do want feedback from a large number of users.)
1 reply 0 retweets 2 likes -
Replying to @perrymetzger
A modern typesystem is enough work for more than one person: complexity and termination of checking or inference, row types, parametricity, co and contra variance, subtyping, inheritance, fixed points, dependencies, linearity, ownership, temporal or epistemic modalities...
1 reply 0 retweets 4 likes
As obviously the field becomes too big for one person to complete, yet any endeavor must be started by just one person, obviously don't wait to know everything before you start. Instead, surround yourself with complementary talents, and know to delegate.
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.
Read my blog!