| > Preferring implicit code is optimization for the first person writing the code while making it harder to understand, debug, and update. I feel that this argument has been repeated so often that it's almost understood axiomatically: nobody thinks about what it means anymore, it just "seems true". I posted Aaron Turon's (of the Rust core team) article that touches on these topics elsewhere in the thread (https://news.ycombinator.com/item?id=14280908), but this topic desperately needs a better definition of "implicitness". Virtually nobody thinks that C programming is "too implicit" because it's "optimizing for the writer over the reader," and similarly, garbage collection is an extremely implicit mechanism that is widely accepted, including by some of the strongest EIBTI proponents. On the other hand, as a strong proponent of abstraction and implicitness in many contexts, I was extremely supportive of (and helped champion) Rust's explicit error handling through the Result type. I like Aaron's "reasoning footprint" rubric because it gives us a way to debate this topic without "implicit" defined in the eye of the beholder. Importantly, it allows us, as a community, to broadly accept changes like garbage collection and control-flow constructs without repeatedly rehashing the same old bumper-sticker debates that mar every generation of programming. |
I think about what it means constantly because every single day, I spend hours digging through documentation about the .NET framework instead of just following a call stack or reading code. It's excruciating.
Do I know exactly where to draw a hard, absolute line between "too implicit" and "too explicit"? No. But I definitely feel the pain of "too implicit" when it's happening to me.