I would pretend that a reasonable argument is the following: brackets, curly or normal, are handled pretty constantly by every editor or text-display system.mcsven wrote:That said, is there anything other than arguments from authority on this issue? The reasoning you have presented so far has been mostly assertions about legibility and ease of debugging, yet these are surely countered simply by saying that I think the opposite. We're not much further forward.
Spaces and tabs are not. Best example is this one:
Code: Select all
<- no space ( normal )
<- two spaces { curly }
<- four spaces [ square ]
<- no space ( normal )
<- two spaces { curly }
<- four spaces [ square ]
Indeed HTML is not displaying spaces correctly. It does however display all brackets consistently. And do not get me started on tab, that is sometimes N spaces (usually 3 or 4) and sometimes it's own character.
So why is this an issue? Because of code re-use. Even one person may have a file with indentation at 2 spaces and another with 3 spaces that he won't be able to combine into one with a simple copy-paste.
And what about taking examples from the web? Copy-pasting to and from an email? Sharing and re-using community code? This is made much more difficult by using inconsistent, invisible characters than by using consistent and visible brackets.
Now of course I can live with anything as I am already impressed by what Josh is giving us as toys. But I guess he makes our online-community life a bit less easy with this design choice... As opposed to saying any number of space and tab is considered "one space" (so indentation can be used for human readability ) and a special visible unique character like a parenthesis for scoping.