I'm heading over to bsky.app/profile/ericli…, hope to see you there!
English
Eric Lippert
2.7K posts
Eric Lippert
@ericlippert
Eric Lippert is a programming language designer; prior work includes the C#, Hack, JavaScript and Bean Machine compilers. Blog at https://t.co/LoIRH9LwbX.
Seattle เข้าร่วม Ocak 2011
476 กำลังติดตาม18.7K ผู้ติดตาม
@codelumpn @panopticoncntrl That said, the design team is very aware that overload resolution is too complex for users to understand. Most treat it as a black box that does the right thing most of the time and is puzzling when it does not. Which is perhaps not ideal, but there won't be an ideal design.
English
@codelumpn @panopticoncntrl Design is a failure when it doesn't meet the needs of users, not when it complicates the job for implementers. I am proud of the work we did in both design and implementation here.
English
Apropos of nothing, if anyone is looking for a job working with languages/compilers and you have some experience, let me know, I might have something coming...
Paul Vick@panopticoncntrl
@ThatVBGuy @ericlippert @headinthebox (Another novel issue which I am currently living through is that parser generators are also so powerful now that they enable folks to write spaghetti grammars full of ambiguities which allows them to almost (almost!) ship without understanding what their grammar actually does.)
English
@ericlippert This is such a good point!!
I've got a talk about readability coming up, is it okay if I screenshot your post and include it?
English
🚀 Want to Grow Faster as a Developer? Improve Your Code Readability Today 🚀
If you’ve ever opened an old piece of code and felt a wave of panic trying to understand what you were thinking, you’re not alone.
English
@AndrewStellman That's why organizations such as the Jet Propulsion Lab run static analysis tools on all their code and fix all the bugs reported *even if the report is a false positive*.
English
@AndrewStellman Moreover: though the *compiler* doesn't care about readability, static analysis tools do. If your code is correct but so unreadable that a static analysis heuristic is fooled into reporting a false positive, then humans will also likely be unable to understand it.
English
@codelumpn @panopticoncntrl I also left a debug-only "Dump" method to make the report human-readable. Debugging mistakes in overload resolution and its error reporting got MUCH easier when I could just ask the debugger for a human-readable summary of the analysis. I highly recommend that technique!
English
@codelumpn @panopticoncntrl If you look at
github.com/dotnet/roslyn/…
you can see all the possible ways a method can fail to be best, and in
github.com/dotnet/roslyn/…
method ReportDiagnostics we have the heuristic for turning an analysis into an error message. I left LOTS of comments!
English
@codelumpn @panopticoncntrl The way I implemented this was: for all the attempts at inference and all the candidates for overload resolution involving lambdas, we track the errors that *would* have been reported had the types of the parameters been known, and then see if there's a common error.
English
@codelumpn @panopticoncntrl My point here is that we do NOT want to say "inference failed" or "overload resolution failed", even though those things are true, because they're not *actionable*. What we want to do is point the user at the thing that needs to change: you made a typo in the lambda body.
English