Even 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.
Typing 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.)
I'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.
They 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.
Braces 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.
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
Indenting 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.
I was bitten so many times by un-indented code, thanks to copy / paste that took me hours for figure out what was the actual problem.
I wish Python had closing...how do we call them, tags(?), clauses?
Anyway, here's an example of what I mean:
Before:
def IsPalindrome(s) -> bool:
for i in range(len(s)):
if s[i] != s[len(s)-1-i]:
return False
return True
print("Is Anna a palindrome?", IsPalindrome('ANNa'.lower()))
after:
def IsPalindrome(s) -> bool
for i in range(len(s))
if s[i] != s[len(s)-1-i]
return False
endif
endfor
return True
enddef
print("Is Anna a palindrome?", IsPalindrome('ANNa'.lower()))
There is nothing wrong with properly indenting code. The lack of {} makes python very ugly when things no longer fit on one line. Because Python has an opinion about whitespace there are certain ways one can break a line an other ways one cannot. The result looks very ugly. Maybe the old way of using a backslash was not the worst, but linters nowadays don't like that anymore. Also having : also does not make things look better. Python must be one of the most ugly looking languages out there.
You might be already aware of this, but besides using the backslash, the other way you can allow an expression to span multiple lines in Python is to enclose it in brackets. I find this to be pretty unobtrusive. Often your line break will already be within a pair of brackets anyway.
I don't get it either. I mostly use C#, but I somehow manage to properly indent it anyway. Whenever I use python, I don't have any issues with indentation.
To me this discussion always sounds a bit like people complaining they can't find any brown underwear.
In Python, whitespace is explicit, so actually, the bug you just posted hadn't happened if they used Python. Indeed, in your link, the braces are implicit too.
Properly indenting code is fine. Now try modifying that code, like removing an if statement inside somewhat nested code and trying to ensure that everything still has the same meaning as before. With Python, you can never be sure you did it right.
Because everyone (and all their editors) on every project have to handle indentation identically or as soon as someone makes an edit, things won't run.
The purpose of parenthesis is too let the language know when the condition ends, and the statement begins. In a language with mandatory curly braces, the brace does that job already.
Can we also have multi line lambdas? It will make loops in trees of components (html, UI etc) easier. Generating html in Python will look much better than:
```
with lib.html():
with lib.body():
with lib.ul():
for i in items:
with lib.li():
lib.add(i)
```
Not sure it's really that unpopular. I personally find braces harder to read. Perhaps they are more explicit, but it just adds clutter. Compared to C and Java (even well formatted) I'd rather read someone else's Python code any day.
People who don't like significant whitespace are just people who don't use a proper text editor / IDE. A lot of them think you have to manually insert the whitespace. It's the same with people who complain about parentheses in lisp.
I don't think I've ever craved braces in Python. I've had a few bugs due to indentation but that happens with braced languages too. If this is your preference just careful that Bython is supported into the future that you expect to use it.
Algol 60 and Pascal had 'BEGIN ... END' to handle multiple statements in a block, but Ada and Wirth's successors, Modula-2 and Oberon, removed them except to denote where code begins in a PROCEDURE. It is much cleaner.
Poorly contrived example in Oberon:
IF n > 1 THEN
n := n * n;
RETURN 0
ELSE
RETURN 1
END
Surely you don’t mean tab and vertical tab, so you must be talking about tab and… space? How would a language with no spaces look like? How do you separate tokens?
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/ )