Code Verbosity

The (Zen of Python)[https://peps.python.org/pep-0020/] states that “Special cases aren't special enough to break the rules.” It also states that “Explicit is better than implicit.” In my personal code I have no problem with the following:
x: Int = 5
y: StringLiteral = "Howdy Howdy!"
var z : String = str(x) + " " + y
print(z)
x: Int = 5
y: StringLiteral = "Howdy Howdy!"
var z : String = str(x) + " " + y
print(z)
Many believe that if the type can be inferred, there’s no need to write it. The main exception in this is when it’s a union like var x: Int | None = None, then you add the type declaration. I believe that it’s simpler to just have the type declaration everywhere so that there’s no “special cases” to “break the rules”. Again, “Explicit is better than implicit.” The main argument I see against this is the line “Simple is better than complex.” Often the claim is made that more type annotations adds complexity but I personally disagree though YMMV. It doesn’t necessarily make it more readable but IMO it doesn’t detract from it either. What are your thoughts? Any experiences that I should consider?
17 Replies
bunny
bunny4mo ago
@Three chickens in the green bag , this debate is really common in the Go community due to that language's similar ease in implicit typing. I find that adding the explicit type declarations is a bit more verbose, but it can be really helpful in debugging type tom-foolery. Like when I think I'm making a List (to use the Mojo term) but I'm actually making a ListLiteral. Just declaring the type often tidies up little unexpected moments of compiler fussiness. OTOH, I cannot think of a single time I would have done the x style verbose assignment for something as clear as what z does:
var x: Bool = True
var z = True
var x: Bool = True
var z = True
Not much room for mistyping in simple Bools. 🙂
Three chickens in the green bag
True, but should it be considered a rule that initialization should always have a type and no special case is special enough to break the rules? Not actually enforced by the compiler as a rule but just a rule of thumb so to speak
bunny
bunny4mo ago
I have to search the googles to confirm my rusty memory, but I seem to recall some debate about having gofmt (Go's "black", to use a Python comparison) auto-add types and/or remove "unnecessary" ones. Or maybe it wasn't a formal discussion as a RFP or anything, but just a side chatter in Go circles. The general consensus on the subject within Go was something like:
This is too hot of a potato for us to touch. Just go with your team's style-sheet. If they don't have one, wing it.
😄 I realize I'm not giving any authoratative answer. But I think that was the result within Go circles: there just isn't a universal answer on that one. And within Python, I think it sort of fell the same way. Like you can add type notations all over the place, but it is uncommon. I find that I add more type notations than most, but not 100% of the time. But that's me, and I'm nowhere on the level of other peeps here. Including you. 😉
Mohamed Mabrouk
Mohamed Mabrouk4mo ago
One of the nicest approaches is by Rust's rust-analyzer where the inferred types is explicitly shown and you can either confirm, override or just leave as type hints. If the same behaviour can replicated by mojo LSP, that would great
Three chickens in the green bag
I don’t have my computer with me so excuse the poor editing of my Google search but I can’t help but be reminded of Java who has explicit types everywhere and also CPP which requires type annotations everywhere. I don’t thing they should be compiler mandatory when “unnecessary” but I do like more verbose code
No description
No description
Mohamed Mabrouk
Mohamed Mabrouk4mo ago
I think the rust's approach fits quite well to mojo. It is not mandatory to annotate if the type can be inferred, you see your types while you are writing code, and you can intervene at any points. Instead of having to check the types once you inadvertly shoot yourself in the foot if the compiler inferred another type that you didn't want.
Three chickens in the green bag
Agreed. Don’t force it, but if you want to you can be as verbose as you want.
Mohamed Mabrouk
Mohamed Mabrouk4mo ago
and It is pretty annoying in Java that you have to annotate evvverything
Three chickens in the green bag
Maybe, but the verboseness leaves no questions asked
bunny
bunny4mo ago
Gotta agree with that! I really like how rust-analyzer adds in the type notations as a greyed-out "here's what the compiler thinks you mean" hint. Really awesome feature that I'd love to see in the Mojo extension, too.
Melody Daniel
Melody Daniel4mo ago
Inlay hints. I believe it's part of LSP now
Mohamed Mabrouk
Mohamed Mabrouk4mo ago
Mojo's LSP?
Melody Daniel
Melody Daniel4mo ago
Language server protocol It was originally a specialized feature when Rust-analyser added it worked only for Rust I think Mojo LSP will get it eventually
Heyitsmeguys
Heyitsmeguys4mo ago
Virtual text makes everybody happy 🙂
Heyitsmeguys
Heyitsmeguys4mo ago
Java and C++ added type inference through var and auto because developers didn't want to deal with that.
Want results from more Discord servers?
Add your server