Conversation

maybe a hot take, but I think this "get it right before i let you run it" approach is straight up bad UX design and it's a shame new languages like Rust haven't rejected it. tell me where I've made mistakes but still let me run my code goddammit
Quote Tweet
I like this article a lot. I can distinctly remember when I first started realizing that working through compile errors and designing the types for my program *was* programming and that fixing those errors was meaningful, important progress. twitter.com/healeycodes/st…
Show this thread
3
11
Dart used to work this way and does so much less now, which I think was the right choice. It's too hard to fit in a tweet, but allowing running erroneous code forces a lot of tradeoffs in the language and can make the downstream UX a lot worse. ...
1
15
It's a good idea, but like a lot of things in languages, it may not be worth the overall cost to users, or the opportunity cost of other features you could support instead.
1
3
very curious, if you have anything I could read that goes into the downsides and tradeoffs I'd very much appreciate it
1
2
Nothing written down, unfortunately. Maybe if I find the time some day. The short answer is that if a program can run with compile errors, that means it must have defined semantics in the presence of those errors, which in turn limits what other language features you can have.
1
4
Replying to and
I'm assuming that Dart had some sort of dynamically typed semantics that it would fall back to on errors? If it were a bit simpler, like I describe in twitter.com/brendanzab/sta, would you still have an issue with it?
Quote Tweet
Replying to @stephenjohnlimb and @eviedots
Yeah, the elaborator would generate something like a 'ReportedIssue' node when a problem is encountered. This crashes the program if it is run, which would allow you to still experiment with the program while it's in a partially correct state.