3 ms·
I disagree. Compare int num_entries = .. float div = .. float result = num_entries // div vs num_entries: int = .. div: float = .. re
by Nimitz14 8y ago
I disagree. Compare
int num_entries = ..
float div = ..
float result = num_entries // div
vs
num_entries: int = ..
div: float = ..
result: float = num_entries // div
And that's an extremely simple example. I tried out Nim but dropped it because while writing some code with list of lists of different types etc it became completely impossible to parse it quickly.
- faissaloo 8y agoYeah I experienced this with Crystal and really disliked it.
- seanwilson 8y agoI don't see much difference here. It's probably not a big deal when the type annotation is short but if it's something longer reading the short variable name first helps give some context first. When scanning code I think I read the variable name first as well. Type inference should be able to deal with the simple cases anyway.
- dragonwriter 8y agoTypes on the right reads better on those examples (read ":" as "is a(n)" and "=" as "which is").
- dom96 8y agoWhat does types being on the right have anything to do with parsing types representing lists of lists?
- Nimitz14 8y agoParsing as in reading and comprehending.
- lgas 8y agoYour examples are a good argument for types on the right, in my opinion... for the same reason the person you are replying to pointed out.