3 ms·
The first time I used python I was amazed. I just wrote my code as normal (indented, thank you very much) and could ignore semicolons and curly braces, and th
by Kim_Bruning 3y ago
The first time I used python I was amazed.
I just wrote my code as normal (indented, thank you very much) and could ignore semicolons and curly braces, and the code just ran.
I was done in half the time!
This seems like a regression by people who are bad at indenting their code. ;-)
(see also: https://pypi.org/project/goto-statement/ https://pypi.org/project/goto-statement/ )
- bsza 3y agoWhy do I need to be good at indenting when it can be 100% automated assuming the language has braces? I’m a programmer, not a typesetter from 1520.
- NotMichaelBay 3y agoIndenting is not hard, and programmers should be good at it, provided they care about clean code. I like that Python forces indentation rules because it means I'll never have to read code that has confusing/improper indentation. ESLint has an indent rule to enable it for JavaScript.
- manishsharan 3y agoCopying and Pasting code around is really cumbersome with indenting. Refactoring code is harder. Or maybe it's just me.
- otabdeveloper4 3y agoa) All sorts of shitty code and text formatters will ignore or clobber whitespace. b) When reformatting code like for a in x: f(a) if something: g() you're liable to make a typo and commit a grave logic error.
- jerpint 3y agoWhy would curly braces stop you from making the same logic error?
- jen20 3y agoThey don’t. They stop it being an accident though - except in languages like C where braces are optional for single line blocks which can lead to similarly poor outcomes. Whitespace sensitivity is the top of Python’s pretty exhaustive list of flaws.
- yunwal 3y agoBraces definitely do not stop accidents of this type, in my experience. All it takes is refactoring some code where you can’t feasibly count the number of open braces/parentheses (HCL tends to get like this), and misplacing a brace somewhere.
- jen20 3y ago> where you can’t feasibly count the number of open braces/parentheses (HCL tends to get like this) HCL is fine for this. Editors highlight matching braces, typically, and the parser will typically fail if they are mismatched.
- yunwal 3y ago> Editors highlight matching braces Until it doesn’t fit on the page anymore so you can’t see the highlight > parser will typically fail if they are mismatched. The concern is that your braces are technically matched, but not in the intended way, which happens a lot. Probably more than tab errors in python in my experience
- jen20 3y agoCan you give an example of HCL which is ambiguous under these conditions?
- Kim_Bruning 3y agoOf course, on the other hand, you can just as easily misread this example if you don't notice the incorrect formatting. for (let a of x) { f(a); if (something) { g(); } } If you're a programmer who looks primarily at indentation for their syntax cues, it's the parens that can lead you into traps. So there's arguments either way. Now that I'm used to it, I do feel that indentation errors (or at least an indentation/paren mismatch) should probably be a syntax error either way. Possibly people who argue for belts and suspenders might be on to something?
- rstuart4133 3y agoI've had a team of programmers come to me and ask why some C code wasn't working after spending some time looking at it. It was a very badly formatted piece of code and yes, they were looking at the indenting rather than the braces. This was decades ago, before the rise of modern IDE's which might make such errors obvious. To me, that was a definitive proof that while people may prefer braces over white space the majority of those same people read code, they are using indentation to guide their mental parse tree - not the braces. One obvious reason for doing that is they may not even be able to see the braces in the editor window. It also seems obvious that the compliers should parse the same way humans do. It makes life so much simpler when we both see the same thing, so the code the compiler is emitting matches the semantic tree we are building in our heads. Which means if your goal is correct, readable code python got it right, and just about every other language gets it wrong. The article notwithstanding, there is not a lot of wriggle on that point.
- xigoi 3y agoWhy are you using shitty tools?
- gkbrk 3y agoEven without any editor features from the last 20 years (like auto-adding and auto-closing braces), typing semicolons and curly braces should not end up taking a significant portion of time.
- Kim_Bruning 3y agoTyping doesn't take a significant portion of a programmer's time anyway. Automation on that half of the work is only so useful. Checking the code on your screen against your internal mental model does take varying amounts of time. It depends on language syntax and how your mind works. Different programmers internally think in different ways, it turns out. In my case I found that I tend to look at the indentation primarily, and then I check parentheses and semicolons against the indentation. (So in my case python lets me skip an entire step.)
- illiac786 3y agoIt used to depend on your keyboard layout I will say. But nowadays it's autocompleted anyway.
- Shorel 3y agoI am used to the curly brackets, and my keyboard muscle memory is used to the curly brackets. I put the cursor over a curly bracket, press CTRL-M, the cursor navigates to the other curly bracket. My eyes also parse code much faster when it is both indented and with proper brackets. Python just makes more difficult some common tasks like commenting out a try/catch block without having to reindent all the code inside. Not a win IMO. In fact, Python presumes it is easier to use, while in reality, it is not.