|
|
|
|
|
|
by vidarh
4152 days ago
|
|
|
Significant indentation is enough for me to avoid Python. It just doesn't have enough to offer vs. the available alternatives without significant indentation. It's much easier to read indentation than unindented/badly indented pairs of brackets, but you're setting up a strawman - it's not either or - and then you tear down the strawman yourself by pointing out we match the indentation anyway. My code generally is properly indented and has start/end markers (though I mostly write Ruby, so rarely brackets), but what makes me stay away from significant indentation is that in the 30+ years I've been coding, I've never gone long without coming across situations where indentation has broken "in transit" e.g. with cut and paste between systems in annoying ways, or someone loading the code into an editor that butchers the indentation with tabs using "non-standard" tab settings. When that happens, I'd rather "get the wrong impression" than have the code be broken. That's one reason I want redundancy. My tools can trivially and automatically fix the result of breaking indentation when the indentation can be derived from the code. Additionally, I want the visual redundancy, much like I find it far more comfortable to read syntax highlighted code even though it conveys no additional information. |
|
|
The way things are in bracketed languages, humans and computers read different things, and you just have to hope that they always match up. Sometimes they don't, and the human and computer will have a misunderstanding. To make it a real linguistic redundancy, like in Spanish, the compiler should read both and issue a warning if the indentation is incorrect or misleading. As it is, you and the computer are actually speaking different languages.