See, for example, http://www.mormonnewsroom.org/article/church-clarifies-proposition-8-filing-corrects-erroneous-news-reports which states that in-kind donations were under $200k (not millions) and that the church gave *no* cash donations.
The individual
As others have pointed out, however, Card's even gone beyond that. He actively uses his money to lobby for discriminatory marriage laws and anti-sodomy laws. If that's not crossing a line, I don't know what is.
Really? You can't think of anything more extreme than him lawfully donating money to causes he supports?
I don't agree with Card's extreme views, but you're basically saying it's ok for people to have an opinion but that it's not ok for them to engage in any sort of advocacy for that opinion. People lobby for and fund causes you and I disagree with all the time. We don't have to like those causes, but it's hardly crossing any lines - it's a part of our society, and you trying to shut that down would be an example of intolerance. Just let him do his thing and either ignore him, or engage in counter-advocacy of your own.
Prop 8 in California passed because the Catholic Church and the Mormon Church spent untold millions of dollars campaigning for it.
Minor correction: the Mormon church didn't spend money in support of Prop 8 (this is a matter of public record).
Wish I had some mod points right now - thanks for taking the time to explain this!
Most people
It's not "wrong" that both are used, but this whole sub-thread is in response to the implication that Python is somehow broken because it doesn't have the braces. But what Python has done is neither bad nor all that crazy of an idea: not only does it work extremely well in practice, it avoids the oddity of the tools looking at one structure indicator and the humans using it too but (subconsciously or not) actually relying fairly heavily on another.
Again, I don't think it's a big deal that other languages have been designed that way, but Python is certainly not poorly designed because it didn't opt to follow suit.
(hint: if you're completely honest, you'll almost certainly come up with different answers for #1 and #2
You must free your mind even more, grasshopper.
I don't see why #2 would be different from #1.
Try the experiment I suggested and then you'll see.
What makes you (reader) think a byte is "stronger" than another for a parser ?
Nothing, because I don't think that. Try the experiment, and re-read my posts.
I find the mindstate about spaces being "weak" chars annoying.
Er... okie dokie. I'm not suggesting that spaces are weak characters, so if that's the conclusion you've reached I encourage you to re-read my post, as well as those in the related sub-thread.
I still encourage you to try the experiment for yourself, but here's the answers to the earlier two questions:
1) indentation - many people would recognize this intuitively, but if you don't, the experiment I suggested makes it very clear. You can also confirm it by glancing at code from a distance, looking at how you write pseudocode, or try writing code without indentation for a few hours. If you're feeling especially masochistic, download a non-trivial module from an OSS project, remove all indentation and blank lines, and then read through it to become familiar with how the code works.
2) braces - obviously, because that's how the syntax of the language has been defined
If we were to quantify the "weight" of each block indicator to humans vs computers, it's probably something like:
- for humans: indentation=95+%, braces=5% or less (again, if the value you come up with is substantially different, then you really ought to try some of the above experiments to see for yourself. Seriously, take a few minutes and give it a whirl.)
- for computers: indentation=0%, braces=100% (by definition, per the language syntax)
Now, take a step back, put on your language designer hat, and think through the implications of this.
So is the contention that code needs to be sent through unreliable media a lot?
No, contention is that this can happen at all, and there's likely no way to reconstruct the code afterwards. You were talking about implicit blocks as evolution of languages, but this evolution makes unhealthy assumptions about every media and every program only doing verbatim transfers. This is far from reality.
I was talking of programmers doing less busywork just to satisfy the language as the evolution of languages. As far as verbatim transfers, to me it seems strange that a language designer would spend any time at all trying to worry about the case where code might be copied through some medium that can't be relied upon. Not saying it can't be a problem, just that it seems to be far outside the realm of what a language designer should care about.
But regardless of which way you end up on this, I have to emphasize that this is more or less a theoretical problem: we send code from all sorts of languages through these example media and never run into problems: be it showing code snippets on a web page or emailing chunks of code back and forth for quick review or brainstorming. We never mandate any rules or best practices about how this should be done, and yet from your description of things it seems like we should frequently be "burned" by this, but we aren't. Are we just really lucky?
The problem with a language like C is that there are two indicators of block structure - the official one (the braces), and the unofficial one (the whitespace).
There's _one_ indicator of block structure in C et al. - braces.
*Sigh*, no. I encourage you to look past the strict definition of what the tool is consuming and look at it from a language design perspective. Like I've already said before, from the tool chain's perspective, there is just one indicator. I'm not in any way disputing that. Yes, it really is the block structure indicator that matters (to the tools). But what matters to the humans? If you answer 'braces', then why is consistent indentation so widespread and important?
You could blindly assume there's no indentation at all in all your C files and just set up your workflow to automatically reindent it to your liking when you open it.
Not in practice, as this would destroy your revision control - you make a one line change to a file and the commit diff ends up being nearly the whole file just because your coworker with a different scheme was the one who edited that file previously.
But still, this too is missing the point. Even if your editor and my editor decide to display the C code differently, the differences would be in things like the horizontal distance in each level or whether or not the opening curly brace is on its own line or not. The block structure of the program would not realistically be different in my editor than yours. Things that didn't really have anything to do with the program's structure might be displayed differently, yes, but not the structure of the program itself. Why? Because the structure of the program isn't changing, and that formatting conveys to you the structure (far more than the braces do), so of course it's going to be the same materially in both cases.
As noted earlier, that's why bugs like this can occur:
while (condition);
doSomething();
And that's why bugs like this are easily caught simply by hitting the same "reformat" key without needing a static analysis tool.
Forget how to catch/correct the problem. I'm asking you to think through
doesn't it seem a little strange that the strongest indicator of block structure to a human is different than the one that actually matters?
No, for reasons I stated in last post's PS. Robust model is preferable to perceived lower redundancy in presentation. In fact, you could write a plugin for any IDE that'd strip braces from your C and replace them with indentation, or, conversely, would let you write Python with braces, seamlessly changing it on save - model's the same, "IfStmt(condexpr, truestmt, falsestmt)" etc., it's just the question of presentation. Python's reliance on whitespace is bad design decision because it believes in perfection - that no one trims whitespace, every editor is aware of Python and programmers are perfect beings and don't misindent. All of this is just false. Good design shouldn't make so much assumptions and trip over imperfections of real world.
The model/presentation analogy is a bit of a stretch, but I'll run with it: the reason significant whitespace works so well in Python is that there is no difference between model and presentation. How the person reading and writing the code organizes the structure of the code is exactly how the tool sees it too. There is no chance for the two parties to be out of sync.
Final thought exercise: if I assume for a moment that you're right, that it
Further, I've watched a lot of people start using Python with a pretty big range of attitudes, from openly hostile to prematurely enamored and everything in between. After each person has used it for a few months, I have never (not even once) heard of someone complain about that darn significant whitespace anymore. Before they used it, yes, I'd hear the complaints. But after a "real" project or two, it has *never* come up. Why might that be the case? What's even more interesting perhaps is that if you look specifically at the subset of these people who end up disliking Python (but have used it on real projects for a few months) and listen to their reasons why, even *they* have never mentioned the significant whitespace. Not once! They have first hand experience and can articulate some really valid points about drawbacks with the language, and yet they don't cite the whitespace thing. Why might that be?
Finally, if people have been on a Python-only project for awhile and then jump onto a C or Java project, I *do* routinely hear them half-jokingly make comments like, "d'oh, I keep forgetting the braces". Or others will remark how the braces seem superfluous, a waste of time. What is interesting to me is that I have observed this with pretty much *everyone*, be they veteran programmers or relative newbies. What would be a good explanation for why this happens, and why would they so universally remark that it seems odd for braces to be needed?
Well, that's what I keep repeating - whatever someone does to indentation of brace-delimited code, you can easily make it readable. It's just a matter of presentation.
If someone sends you a snippet of code and somewhere along the road indentation gets stripped by inconsiderate software (don't tell me it never happened to you), as long as it didn't break the block markers, you can just hit "reformat" in your code editor and start reading and understanding it. In Python's case indentation is block markers, so if it's longer than 3-5 lines, you can just hit "reply" and ask your respondent to send it again and stop using dated software. I'd say it's pretty clear which one helps understanding and readability there.
IOW, explicit markers = original author can write how he pleases, software inbetween can do how it pleases, reader can get it presented how he pleases, implicit markers = all three stages have to be aware of restrictions. At least, reader can change indentation from 3 spaces to 4.
So is the contention that code needs to be sent through unreliable media a lot?. The issue is not really one of explicit vs implicit block delimiters (in both Python and e.g. C the delimiters are quite explicit and part of the syntax), so we're talking about cases where you're allowing the code to be transferred
So even if I concede the point that sometimes code has to be sent through an unreliable medium (which I don't do, Python or not), that in itself seems like a pretty tenuous argument in favor of delimiters be part of the language. Surely there is a more compelling reason than this, no?
PS: "read (by humans)" is quite a pertinent note, especially for interpreted languages. Your code may be read (by humans) hundreds times a month, but it (or its bytecode form) will be read by computers thousands and millions times a day. I think it's clear possibility of which one misunderstanding you should be minimized. Especially if, as I keep saying, unambiguous for one means he can present it to other's eye in any form.
You're misunderstanding my point: your argument above is precisely what I'm saying.
As noted earlier, that's why bugs like this can occur:
while (condition);
doSomething();
Do I think these bugs occur a lot? Nope. Do you understand why they
As you have asserted over and over, the tool chain only cares about the braces, and that's exactly my point: in terms of code readability and maintainability, doesn't it seem a little strange that the strongest indicator of block structure to a human is different than the one that actually matters? At best it seems odd for the redundancy, and at worst it's a source of bugs. But really it doesn't matter either way since I'm not advocating changing C or Java or any other language. I do maintain, however, that significant whitespace is a pretty reasonable language design decision for the above reasons.
The fact that people who use these languages regularly are not constantly dealing with these theoretical problems that could occur with significant whitespace doesn't mean you need to like or use such languages, but it does pretty strongly indicate that that design decision is far from wacky, nor is it a significantly liability in practice.
That's the strongest I can say it without somebody coming up with an obscure counter-example and declaring checkmate.
Err, same to you. You're just brushing me off with "But it didn't happen to me!"
To an extent perhaps, but I also tried to articulate that it
[snipped lots of things to same effect] The curly braces can help indicate block structure, but they are secondary to the whitespace to the people writing the code, reading the code, troubleshooting the code, and modifying the code. [snipped]
Ahem. Your definition of primary and secondary are quite strange.
Braces do not "help indicate block structure", they define block structure. That's it.
Ah, but we're arguing two different things. I think you're saying, "curly braces define block structure because the language is defined that way". I'm not disagreeing with that - languages like C, Java, etc. *are* defined that way of course. This discussion is around whether or not it's actually
So, I'm taking a step back from any particular language and looking at what value the curly braces actually add, and observing that in terms of code readability, they are less significant than the whitespace to all parties involved
All of this is not some attempt to abolish braces in those languages that have defined them as necessary, but to merely dispute the suggestion that significant whitespace is some crazy idea. You don't have to like significant whitespace or use it, but there's pretty compelling evidence that it's at least sensical. And to many of those that have used it a lot, it's quite preferable.
Unless you're writing your code on paper, you can ask your editor to present that defined block structure in any way you're comfortable with, or you can do it yourself in any way you're comfortable with. You can freely indent (or don't indent) it in any way, and it won't change the meaning of your code at all!
To whom? While it's true that the compiler will still generate the same output from the whitespace-less input, the maintainability of the code is drastically impacted, and "incorrect" whitespace can
Adding "/some/ readability"'s not the point of braces. Letting readability not affect semantics is. Didn't your mama teach you about importance of decoupling model from presentation?
LOL
Maybe some languages do. But if I were to guess, it's probably a couple of things:
- design - it's a pretty fundamental decision in a language's design, and has implications that kind of ripple through everything. Both the language/tool maintainers as well as the users need to be able to reason about how things behave, and having both and not violating the principle of least surprise (among others) might be tricky, I dunno. There's a sweet spot between firm decisions around the "right" way to do things in a language and having a language be flexible enough to do things many different ways; I suspect that doing both would make it hard to remain in that sweet spot.
- resources - it's reasonable to assume that most language designers/implementors have finite resources, so they'd probably prefer to spend them on making new language features or libraries, improving performance, etc. than implementing and maintaing the complexity associated with supporting both.
- philosophy - a language designer probably has an opinion about the general benefits of one vs the other and therefore probably has less interest in whatever that "other" is. It has been shown that both types of languages can be used to build large, complex, reliable systems, so neither has inherent, complete, and overwhelming advantages over the other.
Just guesses though.
"Doesn't happen very much" isn't quite comforting for something that introduces a new possible way to break your code.
That's the strongest I can say it without somebody coming up with an obscure counter-example and declaring checkmate.
There are plenty of ways to break code via sloppiness. Your experience may differ, but for me significant whitespace causes problems about as often as code breaking because somebody changed it all to upper case or ran it through Google Translator.
Even when copying and pasting code (from e.g. an email or a web page to my editor), I can't remember the last time I had a whitespace problem, but more often I've had problems with e.g. the quote character becoming the quote character a word processor uses.
Even though I don't cross paths with Python very often I saw both syntax errors of this kind and semantic errors - copy-paste programming isn't a good idea, but when a validation function's all copy-pasted blocks to the effect of "if not validate_stuff():\n\t#may be do some stuff\n\treturn False", it's just waiting for some of those returns get miss out a tab. Which happened. Good thing it wasn't return True, which would be worse.
Don't think I saw many of these errors with braces-based code. And don't think it was less readable, thanks to indentation still being permitted, just not being relied upon.
But whitespace
while (condition);
doSomething();
I'm not suggesting that these types of bugs happen all the time, but do you understand
(otherwise it wouldn't be so universally used and often required by e.g. a company's coding standards)
Coding standars also usually require comments with concise and correct explanation of every class, method and function in understandable English, without slang and profanities.
Don't see anyone declaring it "significant" and building it into a language.
That's missing the point.
It's telling that that consistent whitespace is such an important factor in code readability that many companies/projects formalize it as part of their coding standards, that's all.
The difference is that in most languages a schism exists because the whitespace is significant to the human but not the computer.
You're programming a computer. Of course things that are significant to computer should be of priority. If you're trying to explain something to someone, do you prioritize "it sounds better to me", or "there's less probability of misunderstanding"?
First of all, the above two aren't opposites. In fact, the more the two converge, the better.
But the underlying principle is that everything you require the programmer to do has a cost, and if the cost doesn't provide sufficient benefit, then it might be good to change it. If you look at the evolution of programming languages, real progress has been made in making languages more expressive and requiring less arbitrary effort on the programmer's part.
The fact of the matter is that programming languages always require something of the programmer that is outside of the domain of whatever problem the programmer is trying to solve. To the extent that you can recognize and eliminate those effectively, that's a good thing. For example, in older C programs you had to declare variables at the start of your function, even if you didn't use them until later. Was that to help the programmer? Some people argued that it helped them think through what they'd need, but in reality it was because it made writing the compiler tools easier. Relaxing that requirement was a good thing.
Remember when Java didn't have autoboxing of primitive types? Not the end of the world, and yet having the programmer care about that detail had really nothing to do with the problem at hand, but it was work being done to satisfy the language and the tools.
There are countless examples of this: work the programmer has to do, not because it really is related to the task at hand per se, but an artifact of the tools and language. Some are more significant than others, but regardless of the magnitude they are a cost, they do add complexity, and they distract from building bigger and bigger things. So as computers get faster and more powerful, we often exchange that new power for making languages and tools that allow for higher forms of expression but also languages and tools that require less busywork by the programmer.
I "get" that you're not a fan of significant whitespace, but those who like it see it as just another example of this sort of evolution of languages that is ongoing. The curly braces can help indicate block structure, but they are secondary to the whitespace to the people writing the code, reading the code, troubleshooting the code, and modifying the code. You could argue that the curly braces also add
Again, if you want a language where curlies are required, that's fine, but hopefully you can at least see that what Python does is both sensical and pragmatic.
Sorry, but pragmatic is not the right word.
Oh, it most definitely is! Look at all the counterarguments in this thread, including yours below: these are all very realistic problems that could occur
So, going back to my earlier suggestion that whitespace is significant to humans in pretty much all modern computer languages, if you use a language like Python for awhile, most people I've worked with (including those who have come to Python with pretty strong bias against it) end up realizing it's actually just fine. You don't run into problems, you aren't constantly at risk of a big mess or anything. It works great. Do that for awhile and then go use e.g. C or Java, and it seems odd to need to use the curly braces. Why? Because you recognize that they aren't the most significant indicator of block structure (to you, the person writing the code or to all the people reading the code). Net result is that the curly braces don't feel all that pragmatic: they add little or no value so why use them?
The indentation-is-block-structure assumes people make sane editing choices, don't redefine the size of a TAB, and don't disagree about indentation level.
That's just not how the average programmer works, unfortunately.
Hehe, I'm tempted to make some quip about what constitutes an average programmer, but again all I can do is observe that these things just don't happen all that often. You hire a new guy and he asks, "tabs or spaces?" and we say "spaces. Most people use 4" and that's it. It's never ever ever an issue. And honestly, it seems like 4-spaces-instead-of-tabs is a pretty common default anyway (regardless of language), such that a lot of times this conversation doesn't even happen.
I myself have lost a lot of time on this. When you're familiar with other languages, it's an odd feeling when you realize a small indentation fsckup forces you to start over from the beginning.
I
On the other hand, it's just one blemish on an otherwise good language, and not a reason to reject it.
You're entitled to your opinion of course, but I hope you can recognize that many people feel that not only is it not a blemish that you just have to deal with, but a compelling feature and one of the reasons it's a really good language. Further, I hope you can accept that there are a lot of people who feel this way not due to some preconceived notion they are holding to, nor due to a lack of experience with other languages, but that their opinion is based on both having used Python as well as other languages for a long time - i.e. their opinion is based on first-hand experience.
You might be an exception, but it often seems that people who dismiss a language like Python due to significant whitespace are people who haven't really tried it for any significant project or length of time. My initial reaction to Python was "meh". Then for one reason or another I used it on a few projects, then a few more, and so on, until it became my language of choice when the scenario permits it. Along the way I found that many of the theoretical objections to Python are not well-founded, and that its departures from the Java/C family of languages (things including significant whitespace) are often beneficial, well-thought out, and really nice from a programmer's perspective, such that when you go back to those other languages, you really miss them.
Here's the thing - I can restore destroyed indentation from braces in a single keypress/click in any editor. I can't restore program structure from destroyed indentation without careful reading through and manual reindenting.
There's not many ways you can accidentally destroy braces (and yeah, I've cursed at websites swallowing < many times), but there's a lot of ways you accidentally destroy indentation - starting with same websites that swallow your less-thans and going through other Python-insensitive software to careless copypasting and reindenting.
Definitely could happen in theory, but it just doesn't tend to happen in practice very much, for the same reasons that the whitespace is used in the first place: it conveys useful information, so people take steps to preserve that information, regardless of the language being used.
Thank you, but I'll take unambiguous and less prone to accidental failure (though taking some more time in some cases) option every time.
More power to you: I'm not in any way trying to argue that people with your perspective should give up what they have selected as their preference. I do, though, object to the earlier comments (from you or some other AC) that imply that languages with significant whitespace are somehow lacking or broken or wrong.
My assertion is that whitespace is significant in pretty much
PS: By the way, there is significant whitespace in C. Inside of quotes. In Python you get both significant whitespace (in quotes and at starts of lines) and insignificant (in comments and as separator). Overloading semantics much?
Haha.
Ok, thanks. I was trying to understand if this was actually relevant to Python or to this sub-topic of whining.
Circling back: how should one proceed without whining? A few thoughts:
1) How effective is whining exactly? Probably not all that much, especially vs e.g. organizing like-minded people/companies into a more powerful group and articulating why a change in policy would be a good thing for all parties involved. Whining is so weak compared to doing something about a problem. Whining is not something that the winners do (but it's not
2) The xbox example isn't actually a good one. By that I mean, it's not startups vs big companies. A startup that is genuinely serious about developing for that platform can most certainly get ahold of dev kits and publish native apps. It's pretty easy, at least in the US. Also, there are much larger factors than C# vs native when it comes to Live Indie vs Live Arcade - the companies doing the latter are investing far more resources and are held to much higher and stricter standards, not to mention much higher expectations being placed on their output.
3) When your business faces an obstacle and you overcome it, you often find that you want that obstacle to remain in place as it could be an obstacle for your competition. It's easy to think you want a level playing field, but the opposite is almost always the case - you want every advantage possible but you want it for
4) I think the GP is right in that whining is what people do instead of overcoming challenges. Using the xbox example again, someone who is completely put off by the C# vs native thing, to the point that they feel it's the insurmountable challenge, would probably not be able to succeed anyway - there are much larger challenges they'd have to face on the road to success, so such a minor one up front is probably a filter to weed out those who would later fail on a bigger and more real challenge. In a way, it's a blessing in disguise as it helps divert those people down some other path where they have better odds of success.
I just use % for e.g. matching parentheses, but see e.g.:
http://stackoverflow.com/questions/896145/more-efficient-movements-editing-python-files-in-vim
"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_
