Preferring implicit code is optimization for the first person writing the code while making it harder to understand, debug, and update.
When code is written only once and most of the cost comes afterward, that seems like an impossible choice to defend.
Why optimize for keystrokes? How much do keystrokes really cost you? Why optimize for conciseness, if it comes at the expense of readability?
I've maintained some PHP code bases with tons of implicitness (magic methods in ORMs and strings dictating object behavior, mostly) and some that had no implicitness. Guess which were more expensive for the client and painful for me?
Another example: I've recently been working on a C#/.NET code base, and I was wondering where the HTTP request is converted into a C# object (in this case, a JSON to object deserialization).
Guess where I had to go to figure it out? Google. And it wasn't easy to Google. I couldn't follow the code because of the layers of magic and configuration that controlled my code, rather than actual code. It was a huge waste of time and makes the code base completely opaque sometimes. It's a ball of yarn, and you don't know where it begins or where it ends.
Why is my code behaving strangely? Is it because I wrote it to do something a certain way? No, it's because this random config file (that I didn't know existed) is dictating behavior instead of the code itself.
I can't imagine how anyone working on large code bases with other people would want to do this. Yes, implicitness is more fun and beautiful at the beginning, but it becomes a nightmare after a short time for anyone other than the original coder.
> 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.
> 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.
> > 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".
> 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.
> When code is written only once and most of the cost comes afterward, that seems like an impossible choice to defend.
> I can't imagine how anyone working on large code bases with other people would want to do this. Yes, implicitness is more fun and beautiful at the beginning, but it becomes a nightmare after a short time for anyone other than the original coder.
Good points, it seems like the arguments for implicitness may have been stronger in the past, when programming languages were less developed. Think of RollerCoaster Tycoon being written almost entirely in assembly in '99 by a single programmer. You'd have plenty of incentive for implicit standards. When you have modern languages with well optimized abstractions, all that implicitness ends up losing out. But if you compare the total amount of work that went into, say, Rust, with the cost of a single dude just building an awesome game, you see that explicitness only wins when it gets to cheat and use way more resources. So yes, explicitness is always better in the limit, but when resources are more constrained, implicitness is so nimble it will just crush the competition.
I'd interpret to mean that borrow checking for example can to be explicitly demanded in rust code, whereas in assembly a lot of the safety is manually assured and often enough only implicitly in the code.
> > Think of RollerCoaster Tycoon being written almost entirely in assembly in '99 by a single programmer. You'd have plenty of incentive for implicit standards
On the other hand you could say that it's the rust compiler source that is rather explicit about the mechanics and the game code would be explicit only by extension.
When code is written only once and most of the cost comes afterward, that seems like an impossible choice to defend.
Why optimize for keystrokes? How much do keystrokes really cost you? Why optimize for conciseness, if it comes at the expense of readability?
I've maintained some PHP code bases with tons of implicitness (magic methods in ORMs and strings dictating object behavior, mostly) and some that had no implicitness. Guess which were more expensive for the client and painful for me?
Another example: I've recently been working on a C#/.NET code base, and I was wondering where the HTTP request is converted into a C# object (in this case, a JSON to object deserialization).
Guess where I had to go to figure it out? Google. And it wasn't easy to Google. I couldn't follow the code because of the layers of magic and configuration that controlled my code, rather than actual code. It was a huge waste of time and makes the code base completely opaque sometimes. It's a ball of yarn, and you don't know where it begins or where it ends.
Why is my code behaving strangely? Is it because I wrote it to do something a certain way? No, it's because this random config file (that I didn't know existed) is dictating behavior instead of the code itself.
I can't imagine how anyone working on large code bases with other people would want to do this. Yes, implicitness is more fun and beautiful at the beginning, but it becomes a nightmare after a short time for anyone other than the original coder.