I haven't kept up on what the latest and greatest things are in this area, but last time I checked Shedskin seemed the most mature and had a relatively small set of restrictions (in most cases, converting Python to a statically-compiled language involves either giving up some of Python's dynamicness to make it "fit" into the more static language or adding some sort of layer on top of the static language to support more dynamic functionality - Python is strongly but dynamically typed).
Anyway, py2c and Nuitka both seem to be in the same space as Shedskin but I haven't used either.
Cython bills itself as an "optimizing static compiler" for Python, although I think it's geared more towards writing Python extensions in C as opposed to trying to convert your entire program away from Python (i.e. it's a good fit if you're writing in Python but want to statically compile some performance critical parts of your app in C, or if you are calling some C library and don't want to use ctypes or cffi).
I believe that for awhile rpython (from the pypy project) optionally targeted the LLVM; not sure if that ever went anywhere.
The above are just the ones I've heard about; don't know if there are others.
Agree to disagree on what he's implying - the context was talking about C and Python and mentioning that he's no familiar with hardware that runs Python natively. If he wasn't implying that C on other hand does run natively, then the comment seems to have no meaning.
And yes, there/are/ versions of Python that compile to native code, but most people use the interpreter flavors as they give the most flexibility or have the fewest restrictions. Similarly, there are interpreted versions of C, but most people use the compiled flavor.
JIT-compiled languages sometimes in fact exceed statically-compiled languages as far as performance goes, but in general don't yet.
My point(s)? To recap: hardware doesn't run C natively. Python is not a language-of-the-day or some passing fad. The fact that the main version of Python is written in C is mostly irrelevant (as in, I'm still not sure why it was mentioned and it does not mean Python is not useful or not worth learning). Raw performance of a language is rarely as important as developer productivity, and languages like Python regularly yield higher developer productivity than lower level languages like C. More and more people moved to C from assembly as the benefits exceeded the costs more and more, but assembly of course didn't go away. More and more people move to higher level languages like Python from C as the benefits exceed the costs more and more, but C of course won't go away. The trend will likely continue, with lower level languages becoming more and more niche because progressively powerful and higher level languages will continue to provide benefits that outweigh the costs, while the lower level languages will not warrant as much use because of the relatively lower productivity.
I wasn't replying to the OP, nor (AFAICT) were any Python developers claiming C is inherently flawed. I was responding to the "Python is just Perl for the hipsters" nonsense as well as the weird statement that implied hardware ran C natively.
*Some* versions of Python are written in C, but not all of them. In fact, the version you're referring to is officially known as CPython to differentiate it from the others.
Claiming that hardware can run C natively is quite a reach. Your definition of what it means to run a language natively is so broad that it encompasses a large number of programming languages (if not all of them). Even before abstractions like LLVM were introduced, going from C to hardware involved translating to assembly and then machine language - multiple steps.
And "language-of-the-day"... really? Python is over 20 years old. I think it's beyond the passing fad stage.
Finally, it's not about getting rid of C, but people use higher level languages like Python over C for the same reason we generally stopped using assembly in favor of C back in the day - the costs vs benefits made it worth it in many cases. C's a good language in many ways and I still use it where it's the right fit, but these days it's realistic to get anywhere between 2x and 10x the productivity by using a higher level language than C. And if the cost is very little in practical terms, it's hard to justify not using a higher level language for many projects. Just like assembly, C probably won't go away anytime soon, if ever. But just like with assembly, these days there are many, many, many scenarios in which the cost vs the benefit isn't worth it.
Sorry, I'm struggling to understand the point you're trying to make, as well as correcting the implication that there's generally available hardware that runs C natively.
The fact that Python was originally written in C is an argument for not using Python? I don't get it.
Oh c'mon, "No company uses python outside of scientific use" is wildly incorrect.
I started using Python about 15 years ago and, at the time, Python was obscure and it took some convincing to get others to use it for any "real" (i.e. customer-facing) projects. But it's so widely used now that I haven't had to make that argument for at least a decade, and I've used it at many different (and successful) companies.
I work for a Fortune 100 company currently and we primarily use Python for our whole sytem. Not by mandate - it's just a really great language in so many areas. Our whole web stack is written in Python and we handle hundreds of millions of transactions each month (yes, there are companies doing more, that's not my point, just trying to convey that it's not some toy web app or something).
And for large scale web apps, pypy+gevent packs a nice one-two punch. We've even started using Python on Android (via Kivy) lately, but at this stage it/is/ just for toy apps - for now.
No language is perfect for everything, but Python is really great in a lot of scenarios. Honestly, at this point PHP qualifies for the title of "odd language" than Python does. The fact that so many companies still use PHP is a historical artifact more than anything.
read the stuff again. overeating will lead to obesity in most cases, where there isn't some disease/condition preventing the fat accumulation, in which case the person isn't really overeating anyways.
But, you could think it from the other way - without overeating it's __impossible__ to become obese..
Unfortunately, this is well-documented as not being the case. Our "common sense" screams that it's true, but it's not, and so we really have a hard time letting go of it.:) You can start reading about it by Googling "obesity malnutrition paradox" (some of the links will take you to malnutrition via overeating, I'm not talking about those, but there are oodles of resources about obesity in populations where there are nowhere near enough calories to reach what is considered the minimum recommended daily intake). What's particularly compelling is that the same scenario is documented in many different peoples/societies in many different time periods - so it's incredibly well-established that obesity can and does occur without excessive caloric intake. Also, there are an abundance of studies that refute the notion that overeating *causes* obesity - there is a correlation, yes, but there isn't solid scientific evidence to support a causal relationship in the way you indicate (although there is a good bit of evidence that shows a causal relationship in the other direction - obesity leading to overeating).
statistics back this up (counting out exotic diseases, elephantinism or whatever). besides, it's a proven method for losing weight: eat less, do more - or inversely a proven method for getting fat: eat more and do less.
Actually, no, there is a strong tie between eating less / doing more and feeling hungry, but not between eating less / doing more and losing weight and keeping it off for any interesting length of time. A really interesting link though is that the rise of the "eat less / do more" philosophy (as a way to control weight) more or less exactly correlates with the obesity epidemic - not saying it caused obesity, but that those ideas as a means of weight control replaced earlier, more correct ideas, and that transition in thinking also marks the rise in obesity. Similarly, there is strong evidence that the introduction of the food pyramid with a high carbohydrate base has been particularly disastrous. Prior to both of these philosophies, it was fairly well-accepted that carbohydrate intake and obesity had a causal relationship, but these fell out of fashion... and obesity rates took off.
(and it doesn't really work like a river that it takes what it needs, it takes what it can and figures out where to put it later).
This too isn't quite right, unless you for some reason don't poop and pee. A really obvious example is most types of fiber - for the most part fiber passes right through your system (which, incidentally, is why e.g. a diabetic can for the most part ignore fiber when counting carbs to predict glycemic impact of a meal - the vast majority of the fiber isn't metabolized into sugars and just passes on through). Maybe that's what you meant by "takes what it can", but just because a calorie is introduced into the body, it doesn't somehow force the body to hang onto it - the body is quite adept at giving off what it doesn't think it needs (hint for what follows below: the problem isn't that the body doesn't know what to do with excess calories, but that it is being quite directly told to hang on to too many calories). Further, all calories aren't created equal - simple sugars, especially those already in liquid form, get sucked up by your body much more easily than the calories that are in the small, digestible portion of fiber.
Perhaps the misconception is because it's easy to assume that e.g. eating a fatty or high calorie food means more fat will end up on your body. That's not exactly how it works though - your body contains fat t
I used to think the same thing as you, but it turns out that "common sense" is wrong in this area, as are many dieticians (who too often also just rely on common sense). And history (at least in the form of rigorous scientific studies) does/not/ agree with you.
Overeating and obesity are correlated, but get this: some of the most current scientific studies show that, if anything, overeating is actually an *effect* of obesity and not a cause. What makes us fat? If you want to point to one thing and focus on it, it's carbohydrates. In a nutshell: carbs lead to insulin increases in the bloodstream, insulin tells fat tissue to remove energy from the bloodstream and store it as fat. Guess what happens when too much energy is removed (and stored as fat) such that there's not enough for normal body functions? Yep! You feel hungry, so you eat more.
In general, a reduction in carbs leads to a reduction in obesity, although the degree of the effect varies by body type and genetics and how much damage has been done from years of high carb eating. Also generally speaking, when people see a weight loss reduction from exercising, being on a "reality" TV show, or starting some fad diet, any lasting effects are likely to be highly correlated with a reduction (intentional or not) in carb intake.
There are numerous books on this subject and, sadly, the link between carbs and obesity has been recognized for over a hundred years. Unfortunately it fell out of fashion due to a combination of geopolitics and the health/exercise craze, among other things.
Don't get me wrong: I love to exercise. And I hate the victim mentality and am a huge believer in personal responsibility. But there is quite a large body of evidence that shows that the "eat less! be more active!" mentality is completely wrong. As in, those are generally great bits of advice (and have many helpful effects), but they neither prevent nor solve obesity.
For an accessible, entry level work on the subject, see "Why We Get Fat" by Gary Taubes, although he's the first to point out that the key principles he talks about have been understood for over a century.
The individual/members/ of the LDS church probably constituted a big chunk of the contributions to Prop 8, but that's very, very different than the LDS church as an institution directly contributing funds as you stated it - the assertion that Prop 8 passed because "the Catholic Church and the Mormon Church spent untold millions of dollars campaigning for it" is incorrect.
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.
Most people/use/ both in typical modern languages of course; but in terms of conveying the structure of the code to a person reading it, the whitespace is more significant (that's the point of the suggested experiment - to give you first-hand knowledge of the relative importance of each, independent of the other).
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/why/ the problem could occur in the first place, and not be instantly obvious after the fact? This isn't rhetorical: I'm genuinely asking you to think through what is going on in a programmer's thought process
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/and modified/ en route - a byte-for-byte transfer of the code doesn't introduce any errors, it's only cases where you are assuming it's acceptable for modifications to occur. Again, yeah, it could occur, but there are so many ways for it to not occur - any modern website showing code is careful to preserve whitespace using a 'pre' tag if nothing else - regardless of language. Ditto for mail readers and a block with a fixed width font. But then there are plenty of other ways for sending code around that doesn't permit the code to be modified, be it a file attachment, a revision tag in a VCS, etc.
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.:) 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). The one that matters in the end is the one your tool chain is looking for (the braces), yet in terms of understanding the code by the humans working on it, the whitespace is *most definitely* stronger. That's why coding standards typically make mention of it, that's why IDEs are so good at reformatting code, that's why poorly formatted code is so frowned upon - information is conveyed by the indentation, and if it's out of sync with the "official" block delimiters, the formatting of the code is misleading.
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/can/ occur? It's because from the human's perspective, the indentation carries more weight in conveying the block structure of the program. If this isn't intuitively clear to you (which I bet it is), Google for the usability studies that have been done on this subject. This is of course confirmed by my other suggestion of taking a C program
That's the strongest I can say it without somebody coming up with an obscure counter-example and declaring checkmate.:) In my experience, these problems just don't happen, but asserting an extreme is an invitation for somebody to come along and gleefully pounce on it.
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/wasn't/ just me: not only are there gobs and gobs of people using these types of languages without constantly falling into these pitfalls, I have also witnessed firsthand the same thing across several companies, many projects (of all levels of scale and complexity), and many developers (of all ranges of experience with the language). So while I do readily understand how these problems could happen in theory, I think it's significant that after all this time I've rarely if ever seen them. That combined with the perception that those who most often cite them are those who haven't actually used a language like Python for any large project or significant amount of time does make me question how realistic these problems are in practice.
[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/needed/ and/or helpful - this whole thread is due to people dismissing Python because of significant whitespace, either implicitly or explicitly stating that that is a flaw in the language's design.
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/except for/ the tool chain. The code is quite readable without the braces as long as indentation is maintained, while the opposite is definitely not the case. Further, it is not unheard of for braces to accidentally be omitted while indentation is maintained, resulting in a bug (not arguing that it is a common bug, just citing it as another example of what actually matters to the humans).
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/directly/ change the *implied* meaning of the code to someone who is reading it or changing it. That may not matter to you, but IMO that's a pretty big deal as most code is almost certainly read (by humans) a lot more than it is written.
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?
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.
"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.:) In my experience, these problems just don't happen, but asserting an extreme is an invitation for somebody to come along and gleefully pounce on it.
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/is/ relied upon - by humans who read, write, debug, and refactor the code. That's the rub. I'm sure you've seen the classic errors in C like:
while (condition);
doSomething();
I'm not suggesting that these types of bugs happen all the time, but do you understand/why/ they can be easy to miss?
(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 thro
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/in theory/. In practice they rarely, if ever, occur. Seriously, I've been using Python for well over a decade with many different teams of developers in several different companies, and the problems that curly braces help protect against just don't really happen all that often. Big companies, small companies, big projects, small projects, new Python users, Python experts, large teams, small teams, etc., etc.: every significant variation in situation that I can think of, and not only have these types of problems never been regularly occurring, they have in fact been so rare that I have trouble coming up with specific instances in which they/did/ 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/am/ familiar with other languages. I've used both types we're discussing for many years, which is why I can from experience observe that these things just don't really happen that often. At my company, for example, we each regularly develop in C#, Java, C, C++, Objective-C, Scala, Javascript, and Python. We use four-spaces-no-tabs in all languages not because of some standard that is enforced, but just because it looks nice and nobody used tabs anyway. We have the full gamut of experience levels of people using Python, and at this company we have experienced these theoretical problems with Python exactly zero times. I'm not saying they couldn't happen. Maybe we're just phenomenally lucky, or maybe these problems don't happen as frequently as detractors of significant whitespace imply.:)
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
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/all/ modern programming languages (otherwise it wouldn't be so universally used and often required by e.g. a company's coding standards). The difference is that in most languages a schism exists because the whitespace is significant to the human but not the computer.
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?
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/because/ they are the winners that they don't whine).
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/you/.
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.
Try this: take a well-formatted C or Java program and remove all the curly braces, and try to objectively quantify how much this affects your ability to determine the program's structure. Now, take the same program and leave the curly braces but remove all the indentation and again make your best guess about how much this affects your ability to determine the program's structure.
Now ask yourself two questions: 1) Which of the two (indentation or curly braces) is the much stronger indicator of program structure to a human? 2) Which of the two is the much stronger indicator of program structure to the computer?
(hint: if you're completely honest, you'll almost certainly come up with different answers for #1 and #2:) )
Doesn't it seem just a little weird that the primary indicator of program structure to the human isn't the one that actually matters from the computer's perspective? I'm not saying it's this massive problem, but at the same time it seems odd to fault a language like Python for taking the main block structure indicator from modern languages and have both the human and the computer rely on it. No redundancy, and no chance for two competing block structure indicators to ever be out of sync.
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.
Slashdot Mirror
I haven't kept up on what the latest and greatest things are in this area, but last time I checked Shedskin seemed the most mature and had a relatively small set of restrictions (in most cases, converting Python to a statically-compiled language involves either giving up some of Python's dynamicness to make it "fit" into the more static language or adding some sort of layer on top of the static language to support more dynamic functionality - Python is strongly but dynamically typed).
Anyway, py2c and Nuitka both seem to be in the same space as Shedskin but I haven't used either.
Cython bills itself as an "optimizing static compiler" for Python, although I think it's geared more towards writing Python extensions in C as opposed to trying to convert your entire program away from Python (i.e. it's a good fit if you're writing in Python but want to statically compile some performance critical parts of your app in C, or if you are calling some C library and don't want to use ctypes or cffi).
I believe that for awhile rpython (from the pypy project) optionally targeted the LLVM; not sure if that ever went anywhere.
The above are just the ones I've heard about; don't know if there are others.
Agree to disagree on what he's implying - the context was talking about C and Python and mentioning that he's no familiar with hardware that runs Python natively. If he wasn't implying that C on other hand does run natively, then the comment seems to have no meaning.
And yes, there /are/ versions of Python that compile to native code, but most people use the interpreter flavors as they give the most flexibility or have the fewest restrictions. Similarly, there are interpreted versions of C, but most people use the compiled flavor.
JIT-compiled languages sometimes in fact exceed statically-compiled languages as far as performance goes, but in general don't yet.
My point(s)? To recap: hardware doesn't run C natively. Python is not a language-of-the-day or some passing fad. The fact that the main version of Python is written in C is mostly irrelevant (as in, I'm still not sure why it was mentioned and it does not mean Python is not useful or not worth learning). Raw performance of a language is rarely as important as developer productivity, and languages like Python regularly yield higher developer productivity than lower level languages like C. More and more people moved to C from assembly as the benefits exceeded the costs more and more, but assembly of course didn't go away. More and more people move to higher level languages like Python from C as the benefits exceed the costs more and more, but C of course won't go away. The trend will likely continue, with lower level languages becoming more and more niche because progressively powerful and higher level languages will continue to provide benefits that outweigh the costs, while the lower level languages will not warrant as much use because of the relatively lower productivity.
I wasn't replying to the OP, nor (AFAICT) were any Python developers claiming C is inherently flawed. I was responding to the "Python is just Perl for the hipsters" nonsense as well as the weird statement that implied hardware ran C natively.
*Some* versions of Python are written in C, but not all of them. In fact, the version you're referring to is officially known as CPython to differentiate it from the others.
Claiming that hardware can run C natively is quite a reach. Your definition of what it means to run a language natively is so broad that it encompasses a large number of programming languages (if not all of them). Even before abstractions like LLVM were introduced, going from C to hardware involved translating to assembly and then machine language - multiple steps.
And "language-of-the-day"... really? Python is over 20 years old. I think it's beyond the passing fad stage.
Finally, it's not about getting rid of C, but people use higher level languages like Python over C for the same reason we generally stopped using assembly in favor of C back in the day - the costs vs benefits made it worth it in many cases. C's a good language in many ways and I still use it where it's the right fit, but these days it's realistic to get anywhere between 2x and 10x the productivity by using a higher level language than C. And if the cost is very little in practical terms, it's hard to justify not using a higher level language for many projects. Just like assembly, C probably won't go away anytime soon, if ever. But just like with assembly, these days there are many, many, many scenarios in which the cost vs the benefit isn't worth it.
Sorry, I'm struggling to understand the point you're trying to make, as well as correcting the implication that there's generally available hardware that runs C natively.
The fact that Python was originally written in C is an argument for not using Python? I don't get it.
Oh c'mon, "No company uses python outside of scientific use" is wildly incorrect.
I started using Python about 15 years ago and, at the time, Python was obscure and it took some convincing to get others to use it for any "real" (i.e. customer-facing) projects. But it's so widely used now that I haven't had to make that argument for at least a decade, and I've used it at many different (and successful) companies.
I work for a Fortune 100 company currently and we primarily use Python for our whole sytem. Not by mandate - it's just a really great language in so many areas. Our whole web stack is written in Python and we handle hundreds of millions of transactions each month (yes, there are companies doing more, that's not my point, just trying to convey that it's not some toy web app or something).
And for large scale web apps, pypy+gevent packs a nice one-two punch. We've even started using Python on Android (via Kivy) lately, but at this stage it /is/ just for toy apps - for now.
No language is perfect for everything, but Python is really great in a lot of scenarios. Honestly, at this point PHP qualifies for the title of "odd language" than Python does. The fact that so many companies still use PHP is a historical artifact more than anything.
Most hardware doesn't run C natively either. ;-)
read the stuff again. overeating will lead to obesity in most cases, where there isn't some disease/condition preventing the fat accumulation, in which case the person isn't really overeating anyways.
But, you could think it from the other way - without overeating it's __impossible__ to become obese. .
Unfortunately, this is well-documented as not being the case. Our "common sense" screams that it's true, but it's not, and so we really have a hard time letting go of it. :) You can start reading about it by Googling "obesity malnutrition paradox" (some of the links will take you to malnutrition via overeating, I'm not talking about those, but there are oodles of resources about obesity in populations where there are nowhere near enough calories to reach what is considered the minimum recommended daily intake). What's particularly compelling is that the same scenario is documented in many different peoples/societies in many different time periods - so it's incredibly well-established that obesity can and does occur without excessive caloric intake. Also, there are an abundance of studies that refute the notion that overeating *causes* obesity - there is a correlation, yes, but there isn't solid scientific evidence to support a causal relationship in the way you indicate (although there is a good bit of evidence that shows a causal relationship in the other direction - obesity leading to overeating).
statistics back this up (counting out exotic diseases, elephantinism or whatever). besides, it's a proven method for losing weight: eat less, do more - or inversely a proven method for getting fat: eat more and do less.
Actually, no, there is a strong tie between eating less / doing more and feeling hungry, but not between eating less / doing more and losing weight and keeping it off for any interesting length of time. A really interesting link though is that the rise of the "eat less / do more" philosophy (as a way to control weight) more or less exactly correlates with the obesity epidemic - not saying it caused obesity, but that those ideas as a means of weight control replaced earlier, more correct ideas, and that transition in thinking also marks the rise in obesity. Similarly, there is strong evidence that the introduction of the food pyramid with a high carbohydrate base has been particularly disastrous. Prior to both of these philosophies, it was fairly well-accepted that carbohydrate intake and obesity had a causal relationship, but these fell out of fashion... and obesity rates took off.
(and it doesn't really work like a river that it takes what it needs, it takes what it can and figures out where to put it later).
This too isn't quite right, unless you for some reason don't poop and pee. A really obvious example is most types of fiber - for the most part fiber passes right through your system (which, incidentally, is why e.g. a diabetic can for the most part ignore fiber when counting carbs to predict glycemic impact of a meal - the vast majority of the fiber isn't metabolized into sugars and just passes on through). Maybe that's what you meant by "takes what it can", but just because a calorie is introduced into the body, it doesn't somehow force the body to hang onto it - the body is quite adept at giving off what it doesn't think it needs (hint for what follows below: the problem isn't that the body doesn't know what to do with excess calories, but that it is being quite directly told to hang on to too many calories). Further, all calories aren't created equal - simple sugars, especially those already in liquid form, get sucked up by your body much more easily than the calories that are in the small, digestible portion of fiber.
Perhaps the misconception is because it's easy to assume that e.g. eating a fatty or high calorie food means more fat will end up on your body. That's not exactly how it works though - your body contains fat t
I used to think the same thing as you, but it turns out that "common sense" is wrong in this area, as are many dieticians (who too often also just rely on common sense). And history (at least in the form of rigorous scientific studies) does /not/ agree with you.
Overeating and obesity are correlated, but get this: some of the most current scientific studies show that, if anything, overeating is actually an *effect* of obesity and not a cause. What makes us fat? If you want to point to one thing and focus on it, it's carbohydrates. In a nutshell: carbs lead to insulin increases in the bloodstream, insulin tells fat tissue to remove energy from the bloodstream and store it as fat. Guess what happens when too much energy is removed (and stored as fat) such that there's not enough for normal body functions? Yep! You feel hungry, so you eat more.
In general, a reduction in carbs leads to a reduction in obesity, although the degree of the effect varies by body type and genetics and how much damage has been done from years of high carb eating. Also generally speaking, when people see a weight loss reduction from exercising, being on a "reality" TV show, or starting some fad diet, any lasting effects are likely to be highly correlated with a reduction (intentional or not) in carb intake.
There are numerous books on this subject and, sadly, the link between carbs and obesity has been recognized for over a hundred years. Unfortunately it fell out of fashion due to a combination of geopolitics and the health/exercise craze, among other things.
Don't get me wrong: I love to exercise. And I hate the victim mentality and am a huge believer in personal responsibility. But there is quite a large body of evidence that shows that the "eat less! be more active!" mentality is completely wrong. As in, those are generally great bits of advice (and have many helpful effects), but they neither prevent nor solve obesity.
For an accessible, entry level work on the subject, see "Why We Get Fat" by Gary Taubes, although he's the first to point out that the key principles he talks about have been understood for over a century.
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 /members/ of the LDS church probably constituted a big chunk of the contributions to Prop 8, but that's very, very different than the LDS church as an institution directly contributing funds as you stated it - the assertion that Prop 8 passed because "the Catholic Church and the Mormon Church spent untold millions of dollars campaigning for it" is incorrect.
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 /use/ both in typical modern languages of course; but in terms of conveying the structure of the code to a person reading it, the whitespace is more significant (that's the point of the suggested experiment - to give you first-hand knowledge of the relative importance of each, independent of the other).
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 /why/ the problem could occur in the first place, and not be instantly obvious after the fact? This isn't rhetorical: I'm genuinely asking you to think through what is going on in a programmer's thought process
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 /and modified/ en route - a byte-for-byte transfer of the code doesn't introduce any errors, it's only cases where you are assuming it's acceptable for modifications to occur. Again, yeah, it could occur, but there are so many ways for it to not occur - any modern website showing code is careful to preserve whitespace using a 'pre' tag if nothing else - regardless of language. Ditto for mail readers and a block with a fixed width font. But then there are plenty of other ways for sending code around that doesn't permit the code to be modified, be it a file attachment, a revision tag in a VCS, etc.
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. :) 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). The one that matters in the end is the one your tool chain is looking for (the braces), yet in terms of understanding the code by the humans working on it, the whitespace is *most definitely* stronger. That's why coding standards typically make mention of it, that's why IDEs are so good at reformatting code, that's why poorly formatted code is so frowned upon - information is conveyed by the indentation, and if it's out of sync with the "official" block delimiters, the formatting of the code is misleading.
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 /can/ occur? It's because from the human's perspective, the indentation carries more weight in conveying the block structure of the program. If this isn't intuitively clear to you (which I bet it is), Google for the usability studies that have been done on this subject. This is of course confirmed by my other suggestion of taking a C program
That's the strongest I can say it without somebody coming up with an obscure counter-example and declaring checkmate. :) In my experience, these problems just don't happen, but asserting an extreme is an invitation for somebody to come along and gleefully pounce on it.
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 /wasn't/ just me: not only are there gobs and gobs of people using these types of languages without constantly falling into these pitfalls, I have also witnessed firsthand the same thing across several companies, many projects (of all levels of scale and complexity), and many developers (of all ranges of experience with the language). So while I do readily understand how these problems could happen in theory, I think it's significant that after all this time I've rarely if ever seen them. That combined with the perception that those who most often cite them are those who haven't actually used a language like Python for any large project or significant amount of time does make me question how realistic these problems are in practice.
[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 /needed/ and/or helpful - this whole thread is due to people dismissing Python because of significant whitespace, either implicitly or explicitly stating that that is a flaw in the language's design.
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 /except for/ the tool chain. The code is quite readable without the braces as long as indentation is maintained, while the opposite is definitely not the case. Further, it is not unheard of for braces to accidentally be omitted while indentation is maintained, resulting in a bug (not arguing that it is a common bug, just citing it as another example of what actually matters to the humans).
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 /directly/ change the *implied* meaning of the code to someone who is reading it or changing it. That may not matter to you, but IMO that's a pretty big deal as most code is almost certainly read (by humans) a lot more than it is written.
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. :) In my experience, these problems just don't happen, but asserting an extreme is an invitation for somebody to come along and gleefully pounce on it.
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 /is/ relied upon - by humans who read, write, debug, and refactor the code. That's the rub. I'm sure you've seen the classic errors in C like:
while (condition);
doSomething();
I'm not suggesting that these types of bugs happen all the time, but do you understand /why/ they can be easy to miss?
(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 thro
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 /in theory/. In practice they rarely, if ever, occur. Seriously, I've been using Python for well over a decade with many different teams of developers in several different companies, and the problems that curly braces help protect against just don't really happen all that often. Big companies, small companies, big projects, small projects, new Python users, Python experts, large teams, small teams, etc., etc.: every significant variation in situation that I can think of, and not only have these types of problems never been regularly occurring, they have in fact been so rare that I have trouble coming up with specific instances in which they /did/ 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 /am/ familiar with other languages. I've used both types we're discussing for many years, which is why I can from experience observe that these things just don't really happen that often. At my company, for example, we each regularly develop in C#, Java, C, C++, Objective-C, Scala, Javascript, and Python. We use four-spaces-no-tabs in all languages not because of some standard that is enforced, but just because it looks nice and nobody used tabs anyway. We have the full gamut of experience levels of people using Python, and at this company we have experienced these theoretical problems with Python exactly zero times. I'm not saying they couldn't happen. Maybe we're just phenomenally lucky, or maybe these problems don't happen as frequently as detractors of significant whitespace imply. :)
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
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 /all/ modern programming languages (otherwise it wouldn't be so universally used and often required by e.g. a company's coding standards). The difference is that in most languages a schism exists because the whitespace is significant to the human but not the computer.
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 /because/ they are the winners that they don't whine).
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 /you/.
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
Try this: take a well-formatted C or Java program and remove all the curly braces, and try to objectively quantify how much this affects your ability to determine the program's structure. Now, take the same program and leave the curly braces but remove all the indentation and again make your best guess about how much this affects your ability to determine the program's structure.
Now ask yourself two questions:
1) Which of the two (indentation or curly braces) is the much stronger indicator of program structure to a human?
2) Which of the two is the much stronger indicator of program structure to the computer?
(hint: if you're completely honest, you'll almost certainly come up with different answers for #1 and #2 :) )
Doesn't it seem just a little weird that the primary indicator of program structure to the human isn't the one that actually matters from the computer's perspective? I'm not saying it's this massive problem, but at the same time it seems odd to fault a language like Python for taking the main block structure indicator from modern languages and have both the human and the computer rely on it. No redundancy, and no chance for two competing block structure indicators to ever be out of sync.
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.