6 ms·
Ken, iant and I have beards thank you :) Rob, gri, Russ and Kai are sadly lacking.
by agl 17y ago
Ken, iant and I have beards thank you :) Rob, gri, Russ and Kai are sadly lacking.
- nailer 17y agoAny chance you could please ditch the brace requirement? You're already marking up the code for humans using indentation, don't repeat yourself by having the compiler use a different parsing mechanism (and make developers mark up seperately for their colleagues and the compiler).
- praptak 17y ago> Any chance you could please ditch the brace requirement? Wearing braces is optional. It's only the beards that are mandatory.
- jacquesm 17y agoLet's please not ditch the brace requirement.
- nailer 17y agoCould you provide either some supporting arguments or a response to the parent post?
- jacquesm 17y agoSure. The 'indentation is enough' argument ignores that braces offer redundancy and are unambiguous. They're like guard rails on the highway, they make totally explicit what is going on. The 'but you're writing for other humans to read' argument imho is not 100% the truth, you're writing for both the computer and other humans to read. Humans like the indentation, the braces make it explicit. The computer doesn't care about the indentation, it just looks at the brackets. Drop a bracket and you get an error, drop a couple of spaces and your program will happily continue to work, only not in the way you intended. it's funny how even in languages that don't use 'begin/end' markers (such as python) there are extraneous characters, such as the () pair when calling a function (surely there are ways to do without that ?), or when making a list or a dictionary. Some things come in pairs, and the beginnings and endings of blocks are such things. In Pascal it was BEGIN and END, which seemed overly verbose, in C it was { and }, which seems about as minimal as you can go before you become invisible, and when you get invisible you lose something. Try cutting and pasting some python examples from online fora and see how well it works without. And try figuring out from a python program that has been created on a box with alternate tab settings what it's intended function was (yes, I know there are tools for that situation). Begin and end block have meaning, they are 'there', and even if you don't strictly speaking need them they cost next to nothing and make me feel a lot more like things are spelled out to mean exactly what I'm reading. I should probably start collecting python examples in the wild on the web where the indentation is clearly messed up so the code no longer works the way it is intended, this is a lot more common than you'd want. It is also very frustrating when learning a language. So, please keep those braces.
- nailer 17y agoRedundancy is an argument against braces, not in favor. 'They're like guard rails on the highway, they make totally explicit what is going on.' Using this logic, perhaps you should add some ASCII art to your source to denote blocks a third time? This is also a common practice. Do you feel the same about duck typing? 'The 'but you're writing for other humans to read' argument imho is not 100% the truth, you're writing for both the computer and other humans to read.' Yes, that's true the computer also parses the code. You still haven't provided an argument why using seperate blocking formats is required. 'they cost next to nothing and make me feel a lot more like things are spelled out to mean exactly what I'm reading.' The cost is evident: there are many cases of indentation not matching braces and vice versa, and the inconsistency between these causing confusion between the language and the humans trying to debug issues. Tell me you've never looked for an unmatched brace in code you can otherwise parse?
- pohl 17y agoRedundancy is an argument against braces, not in favor. I disagree. I know that the word "redundant" sometimes carries a negative connotation, but the truth is that it is a mere property whose value depends upon the context and associated tradeoffs. Spacecraft have redundant systems, but those systems are far from superfluous. Human languages have built in redundancies. Generally they are there for ensuring communication still happens in a noisy environment. My music CDs have redundancy in the encoding, and thankfully at that: after years of accumulating scratches I could still rip them without loss of quality. Redundancy was a positive here too. Redundancy is a tradeoff, not an automatic downside.
- nailer 17y agoAgreed about context, but let's be clear: spacecraft and music CDs have redundancy to prevent loss. What loss are you preventing by requiring blocks be delimited twice? Have you considered that inconsistencies due to repetition are frequently themselves cites as a cause of data loss? Ever had code that looks good to you but doesn't parse because a machine is expecting an extra bracket?
- maw 17y agoMy main gripe with Python is that it's impossible for autoindenters to work correctly. Consider this code: if x == foo: # do things if y == bar: # do something # do other stuff <-- at what indent level should this line live? # get on with life You and I know what that means given its indentation, but an autoindenter can't know what to do with the fifth line. It gets worse when you're moving blocks of code into different indent levels. Now, it's true that in this simple case, you could rewrite the snippet starting with: if x == foo and y == bar: # ... # get on with life but when blocks get long, this becomes less practical. And your autoindenter still doesn't know when to stop indenting and get on with life. As a result, in my Python code, I use otherwise gratuitous pass statements all over the place–ugly, but it does the trick. if x == foo: # do things if y == bar: # do something pass # do other stuff <-- at what indent level should this line live? pass # get on with life My hypothetical ideal language (the one that's not lispy in outward appearance, anyway) would use braces but would also not run if any inconsistencies of indentation are found. This would be allowed: if x == foo { # stuff # more stuff } But this would not: if x == foo { # stuff # more stuff <-- BAM! }
- wsprague 17y agoThe only thing I HATE about Python is the mandatory indentation. The problems with it are: 1. It mixes format with logic. Don't we all know this is one of the greatest evils one can commit? 2. Indentation is a bitch to parse compared with braces. Violates occam's razor of software of engineering -- simpler is better. Unnecessary complexity is the second greatest evil in software engineering. 3. Indentation is neither symmetrical nor logically unique. Therefore you can't delete all the formatting from a python program and expect a formatter to get it right. With symmetric braces a formatter always knows exactly what logical level it should be on by counting the number of closed braces; not possible with python's goofy system. 4. All that tiresome debate and worry over tabs versus spaces. 5. One can't really say "braces are redundant not indents" or "indents are redundant not braces". Redudency is commutative. I would say braces are for computers, indents are from human; it is simple to go from braces to indents but not so in the other direction. Just a note -- I will always pick Python over any other scripting language. I just think the indentation is a serious mistake; there are so few other bad choices it tends to irk me that much more.
- nailer 17y agoIndentation is logic. Repeating logic is one of the greatest evils one can commit. http://en.wikipedia.org/wiki/Dont_repeat_yourself http://en.wikipedia.org/wiki/Dont_repeat_yourself Re: parsing, read each line, if the indent is greater than the current indentlevel, add line to a new block, else, add line to existing block. Tabs were considered harmful before Python, they're still considered harmful now. You could add braces to Python quite easily, I think this has already been done in jest a few times...
- bugmenot 17y agoDRY: I only type braces, the editor does the indenting for me. And it's resistant to mistakes during cut/paste - refactoring of code.