[wycats]

> 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.

[smt88]

> nobody thinks about what it means anymore, it just "seems true"

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.

[michaelcampbell]

> > 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".

Indeed. It seems just another way to not understand "everything is hard to read until one learns to read it".

[smt88]

> It seems just another way to not understand "everything is hard to read until one learns to read it".

So everything is equally difficult to read and understand? There are articles that say "great software is like Shakespeare" and others that say "great software is like Hemmingway". Which one of those authors is easier to read and understand, as someone who speaks English natively?

As someone who has inherited just two code bases, I know first-hand that there can be massive differences in how easy something is to read and understand. One of my companies had a code base that non-technical people could read and even send PRs for. Another of the code bases took months of ramp-up time.