If only Walmart remained, in the worst case, I would expect prices to rise to monopoly levels -- of course, limited by the ability for anyone to set up local distribution. In other words, prices would rise to the levels we had before Walmart came on the scene. Why should I avoid Walmart because of the vague worst-case possibility of them having no effect? And in reality, Walmart actually DOES have real competition from the likes of Target, so this worst-case is very unlikely.
And your claim about forcing suppliers to lower prices and so on may be true (but if so would give Walmart another opening for competition -- another store could steal their suppliers by treating them better), but has already been addressed -- lower prices are a benefit even if the goods are produced outside of the local area. Mercantilism has been long since refuted: there's no real advantage in paying more money under the hope of boosting your own country's economy rather than another country's. The money you waste is simply a lost opportunity.
I agree with all your points, but I'd like to add that automatically running test drivers are better than print statements in a few ways:
1. They provide regression testing for free -- no need to ask a later programmer to figure out what your print statements mean. 2. They document the interfaces of your program. 3. They encourage loose coupling between modules. 4. They can't possibly affect the execution of your production code (since they're not executed in the normal line of operation).
I'm not saying that they're always better than print statements or a debugger, but I do find the advantages compelling over print statements in all recent cases, and over debuggers when the problem doesn't involve legacy code. Debuggers still make a great learning tool, but once I understand the problem I try to reproduce it in a test.
The difference is that the employees are also customers.
An excellent point. It makes sense that, as you say, if the employees lose their jobs, they won't be able to purchase things from companies, thus stagnating the economy.
But there's more to this story. Employees are customers; and customers are the ultimate authority. When the company spends less on its product, there are more resources left over in the economy to be spent on more urgently felt needs. Less money needs to be spent on the company's product, and more is allocated to meeting other needs.
If enough companies outsourced (I'm stealing your phrase), we wouldn't be in a recession -- we'd have unprecedentedly low costs for everyone, and higher competition. Some people would lose their current jobs, but there's more money out there than there was before -- less is being tied up in the same old companies.
The same thing tends to happen with off-shoring of labor, but that's a bad thing for the economy because it reduces costs by eliminating workers.
You're right that the same thing happens, but you're wrong that "it's different this time". It's the same thing, and it has good results. By reducing costs, the company is able to expand (and in the long run, survive), thus providing the things people want without asking the people to give up things they want more, which is the only reason the company exists in the first place.
The employees of the company are in the same situation as the company itself -- they're selling something that people just aren't willing to buy at the prices they need to ask in order to be profitable. The company's selling (for example) software, the employees are selling labor specific to that software.
If I had to guess, I'd say that Walmart is going to pocket any extra profits they come into as a result of this.
This scheme is nothing new; Walmart is enormously succesful precisely because of their cutting-edge inventory management systems, and they have _always_ passed the savings on to their customers. The direct, immediate connection between them saving money and their customers seeing lower prices and better stock management is why there are so many WalMarts. It's the key to their success.
It's kind of interesting to study -- they have an incredibly low profit margin compared to other stores in their industry, and that low profit margin has made them one of the biggest companies in the U.S.
One of my favorite things about RPN is that the stack is an actual object that you can inspect. You can see intermediate values in a way that always makes sense, and if you want to calculate something completely different you can always do that, and after you drop the result your original work will be right back where you left it.
So there's no need for a distinct "memory" functionality. The stack handles everything.
I thought the point of the artical was not that people are risking our privacy by using it, but that the existance of this service may compromise the status of email as being private.
Correct, that's what I saw too. I think the poster you're replying to saw it as well; his point was that email already isn't private.
I agree with him. Email's not at all private; anyone with reasonable resources (in other words, precisely the sort of person you SHOULD worry about violating your privacy) can already read your email almost at will. It's routed in plain text, after all, with no real limits on the number of times it gets copied.
Gmail changes nothing about the privacy of email -- in fact, Google could conceivably already HAVE a massive searchable database of most email sent since they became big enough to afford the storage. (They almost certainly don't, BTW, but they COULD.)
I strongly recommend you read Google's Gmail FAQ rather than asking Slashdot users:-). They answer this question VERY clearly.
They're going to pay for the space by putting AdSense ads next to some emails, based on the user's emails. Just like how they pay for the Google search.
It's possible that the result will be more valuable than the search ads for them, since they'll have more information based on which to target the ads, so advertisers will have a higher response rate.
What is "VERY forthcoming"? Will the Gmail pages have warnings about email being read by Google in large fonts in very prominent locations in a user's eyespace?
Gosh, I hope not!
Nope; what they do is discuss in their FAQ, prior to any user questions on the subject, exactly what they plan to do to your messages. This is in contradistinction to Hotmail, which does not discuss at ALL what they will do to your messages, and whose service agreement includes a blanket license to use, perform, and so on ANYTHING in your email (essentially a complete license under copyright law). Google is very forthcoming, meaning that they take the initiative to state precisely what they're going to do.
It's just... bitterly sad that such honorable conduct should be met by such strong resistance. Look, Google is doing only what the other webmail providers do, and MUST do in order to survive. The difference is that Google tells us BEFORE they start! This would not have been a controversy if Google hadn't made it SO easy to find out what they're doing.
More likely it will be stated in some privacy policy in some place where many users eyes will not naturally fall.
Again, this is REALLY pathetic. The entire controversy is CAUSED by Google discussing this privacy issue openly and accessibly.
1. If Google gets away with this there will be imitators ( some not upfront ) making it harder for people who DON'T want their personal read to get away from that sort of thing.
Hotmail already exists. NEXT!
2. Its not just Gmail user's email that gets read, its the email from anyone who sends email to a Gmail address
First, it's not "getting read"; it's at most getting scanned. No human ever sees it.
Second, it's not being used for any magical marketting aggregation (or at least that's not what this controversy is about -- it's possible, but no more so than it's possible for ANY large enough ISP). It's being used ONLY to deliver ads to the single customer to whom it's being sent! In other words, the only person who will be affected by Google's scanning of that message will be the person for whom the message is intended.
With that said, though, I would think that Google would do well to investigate the concept of only scanning outgoing email for the purpose of establishing advetisements. That way, Google could accurately claim to deliver ads targetted to YOU, not to the people from whom you happen to receive email.
If I have to correspond with a Gmail user it will be ONE email from a disposable address explaining #2 and that I will not converse with them at a Gmail address
Isn't it odd that you could HAVE disposable addresses? The fact is that the only thing that makes those even faintly private and affordable is companies who do what Google wants to do, only generally with less honesty.
And really, if you're worried about Google, your only way out is to run your own server and encrypt everything.
If you give them your private information, they HAVE it. If you don't want that, don't give it to them. Whether they "have rights" to your information is irrelevant once they have it.
This means, of course, that anything you consider private information must NOT be sent out over the Internet in plain text. If you don't do this, then refusing to use Google Email only makes sense -- in fact, even THINKING of using Google email doesn't make sense.
I'm going to use Gmail, because I'm only going to use it for stuff that's not private, in the sense that I'm not worried about whose hands it might fall into. Of course, that's ALL my non-work email currently. I can imagine someday wanting GPG or PGP set up, and on that day I'll use something other than Gmail.
The "peer-to-peer" claim refers to the fact that lookups, data traffic, encryption, and routing is all accomplished without any reference to central servers. Skype therefore should not be vulnerable to typical network scaling issues -- it could support a HUGE number of users, since the users themselves provide all the network capacity.
Typical VOIP, on the other hand, is centrally served; at least the routing (and sometimes all of the traffic) is done by a central server. That central service has to get VERY big VERY quickly.
Someone else who replied to you claimed that P2P means that you can only call other Skype users. Although this may be true (I don't know), it doesn't have to remain so -- I'm sure Skype will be very willing to make money selling the right to use their access points to let you dial into landlines (and licensing their tech to other companies wanting to do the same).
This is a HUGE use of P2P technology, fully as clever as BitTorrent.
The saving "deleted" mail is part of Google's filesystem, not part of its advertising policy. It's also technically required for any redundant distributed system -- it's not possible to delete things immediately without incurring HUGE overhead.
However, if it were part of its advertising policy, I'm curious -- why would you care?
But nobody's giving up privacy -- we're talking about a company that publicly states that it does what every mail server has to do as a matter of course.
Yes, they parse your email. That's part of SMTP (HELO, mcfly). They store it; that's part of webmail. They go through it; that's part of syntax highlighting. They index it; that's part of search capability. They may not wipe it out when you delete it; that's part of the cost of a distributed system.
Google isn't the only one that does ANY of this; all of the others do as well, including your ISP and _certainly_ including the big webmail providers (because they ALSO throw in advertising). The difference is that Google tells you EXACTLY what they're doing.
This is honesty, plain and simple. They should be rewarded for it.
I think you're only partially right, and that Google will have the information needed to find the core set of "spam" that it can safely delete without angering (or inconveniencing) its users. Furthermore, it'll do so because doing otherwise will both cost it more money in spam storage, but will also cut down on email reading time for its users, directly saving Google money _and_ making many people devoted fans.
I suspect that Google will use tools like the graph analysis discussed in a recent Slashdot story in addition to typical Bayesian analysis. There are ways around all that, and Google will keep on their toes -- once the spammers start really/using/ their zombie networks antispam will become HARD, but Google can muster enough power to outzombie a typical worm without even involving any user's machines, and Google can ask its users to install and run clients if it needs to (after all, Google's experimenting with grid computing in its Googlebar already!).
Of course, even if you're "only" partially right, you're still right:-). There probably WILL be people who really do want to get all the spam. There are plenty of other reasons to run your own mail server or to continue using your ISP's email, but this would be one of them.
Afraid that the things I and others do in public will become public information? (They already are, whether or not someone's indexing them.) Afraid that email will become publicly available? (It already is, to your host and to any server that happens to pass your messages on.) Afraid of being served customized ads? (Okay, but at least be honest what you're telling us to be afraid of -- because I'm NOT afraid of that!)
Come on, tell us WHAT we're supposed to be frightened of.
Well, that wasn't really the comparison. I was equating the question "how do I get from here to there without a goto" to your statement "you can't change coding styles just by changing tab size". Both demonstrate a certain stubborn adherence to past practices when faced with new techniques.
That's not true.
The problem here is that you're telling me that using tabs is the new advanced wave of computer science, and I'm being obsolete to think of opposing it. You've got it exactly backwards. ALL the old code uses tabs; tabs were the primary means of indentation, mainly because they take less disk space. So _your_ solution is firmly in "the old way" camp, and mine is the up-and-coming "new way".
And this STILL has nothing to do with our debate. It's _entirely_ beside the point. The fact that your is old and mine is new doesn't mean anything.
Again, if you wish to debate this, you'll have to do better than make analogies and/or appeal to age. Even a valid analogy (which this is not) wouldn't be evidence, much less proof.
Ok, how is this... I like smaller tab size (2 or even 1) better for deeply-nested code, and larger tab size (say 4) for shallow code. Neither tab size is optimal in all cases. When dealing with my own code, which uses only tabs, I can change the tab size dynamically based on the code I'm looking at.
Deeply nested code is going to have a lot of continuation lines, which are going to be the most indentation-dependant things you'll see. Changing the indentation may mess other things up; it WILL mess up continuation lines.
You'll also find that as you change depths, your line lengths will become more obviously non-optimal since they were written with much less horizontal room than you're using to read (unless the original developer didn't care about line lengths, in which case you'll just be lucky if his code is readable).
And finally, of course, the better solution is to realise that what you're doing is a shoddy replacement for re-indenting the code -- nothing WRONG with what you're doing, but it'll never be as effective as doing the job properly.
Well, I'm no Python language lawyer, so I may need to concede that point. But I still find it distasteful to be so liberal with indentation in a language where indentation is syntactically significant. Pick the wrong number of spaces, and you might change the semantics of your code!
You sound fearful -- I suspect you've never used Python. Go ahead, there's nothing to be afraid of -- Python's very smart about indentation. The only rules you have to follow are:
1. Make sure every line in a block lines up with the other lines *in that block* at any tabsize. (The parser will complain if you get it wrong and refuse to execute the file, so don't worry about it.) 2. Don't EVER put a space before a tab. (You can turn on an option to make the compiler complain, but it's pretty much a waste of time, because most programmer have an instinctive fear of this kind of silliness.)
Reccommended: Use only tabs OR only spaces.
As long as you stick to the first two rules, everything will work out. Stick to the third rule, and other people will be able to edit your code without worrying about it.
The code I typed doesn't even care about indentation -- stuff inside parentheses ignores indentation.
Strange that ecode didn't work for you. Hmm.
Christ, he had better not press spaces until they visually line up in the font he happens to be using at the time. That's the most abhorrent practice you have suggested so far.
Why? I honestly have no idea why you don't like that.
Keep in mind that any editor that claims to support proportional fonts had better have special support for spaces and tabs used as indentation!
I like how you're referencing "Goto Considered Harmful," so I think I'll quote from its nemesis:
We will perhaps eventually be writing only small modules which are identified by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language.
--Donald E. Knuth, "Structured Programming with goto Statements", Computing Surveys, Vol 6 No 4, Dec. 1974
Seriously, your comparison of using spaces to unstructured programming is at best beside the point; the only similarity between the two practices is that you personally don't like either one. BUT, I like how you present your point, and I think I see what you're saying. I'm going to take the following paragraph as the REAL point you were making, and ignore the guilt-by-association:-). (Don't worry, I'm smiling when I'm saying all that stuff -- I'm enjoying the conversation.) Likewise, if you write your program text with variable tabs in mind in the first place, then you can change the layout of the code cleanly just by adjusting tab size. And that's all there is to it!:-) Again, this is a coding conventions question, not simply a question of whether or not to use tabs. In order to gain a vaguely alleged advantage to a hypothetical reader, you have to throw out a _lot_ of possibilities for using code structure to convey information about your code. Now, if you could provide me with an advantage more concrete than "I might not like your indentation level," I might find that to be a more interesting tradeoff. But as things stand, the only time I've felt the need to change someone's indentation is when their code was messed up by *my* editor settings not matching theirs.
Yes, my example used C types -- what of it? Remove the text "void *" and that's valid Python code. Contrary to what you said, my statement applies precisely to any language. Well, at least any language whose lines appear next to each other:-). The Slashdot HTML to preserve Python indentation is "ecode".:-)
Another thing to keep in mind: I do know at least one programmer who prefers proportional fonts. Why shouldn't he use them? An excellent question. There are a lot of advantages to using proportional fonts -- I've tried it, and it's really easy to get used to. So long, that is, as your editor can handle treating the leading spaces and tabs both correctly and consistently:-).
But let me answer your question more completely, as it deserves. When writing code using proportional fonts, the programmer will still tend to group lines together in a way that communicates any parallelism in the lines; he won't count letters to line them up, rather he'll press space (or tab) until they line up. Just like he did back when he used a fixed-width font.
Have you ever done this? I don't think it's as easy as you say it is.
Use search and replace to change code indentation? Yes. Only with tab-based code, though -- I've never found screwed-up space-based code (because most really old code is tab-based, not because space-based code can't get screwed up). The idea is the same, though; and the search expression is a complex regexp. (I never said it was easy.)
I've already demonstrated that this is simply false -- changing tab size is NOT sufficient to change coding standards in many cases.
You demonstrated it on C code. As I said, I'll plead no contest on that count.
I never mentioned C code in that context. I don't know what you're talking about. Changing tabs size is simply NOT sufficient to change coding standards, and that's all there is to it! There's no language dependancy in that statement of ANY kind, nor in the proof; even the example I gave was legal Python (or C).
But in a language where indentation is syntactically significant, I think your view is harder to defend.
Why? I'm really confused now -- that doesn't make any sense to me. In a language where indentation is syntactically significant -- the only significant current one in Python (Prothon isn't any different) -- indentation means exactly the same thing _semantically_ as it does in every other modern language. The only difference is that the Python compiler *checks* the indentation.
So how could "syntactic significance" of indentation change anything about my argument?
Anyway, I'll tell you what would be cool. I'd like to specify tab stops in the code, with a special comment or something, and have the editor obey them.
vi does this with a special form at the beginning line of a file. I don't know emacs, but it probably does that too. I've seen people paste "tab bogosity meters" at the beginning of code, looking somewhat like this:
too small [ * ] too big (tabs) ^
The first line is laid out with spaces; the second line starts with a few tabs, and the instructions for the bogosity meter says that if the carat doesn't line up within the brackets, adjust your tab size.
Cute. Anyhow...
The best solution, of course, is to use spaces instead of tabs; spaces are indentation instructions that _every_ editor and printer recognises to mean the same thing. (Abuses such as proportional fonts excepted.)
Probably not, but thank you very much for taking the time; it's an enjoyable discussion for some odd reason;-).
but I think if you have a language that uses indentation as a syntactical feature, then it makes sense that there be one designated "indentation character", and that you can tell the indentation level simply by counting the occurrences of this character.
I agree 100%. In fact, so do the official guidelines for Python.
http://www.python.org/peps/pep-0008.html
Although they state that using spaces is preferred, you can see from the rule and rationale that using tabs consistently is good for that purpose.
Using tabs exclusively also has the benefit that anyone can choose the indentation level they like the best, and the code will still look right.
I've already demonstrated that this is simply false -- changing tab size is NOT sufficient to change coding standards in many cases. The exceptions exist, but I've never found one, even in the days when I used tabs-only (and would religiously convert spaced code to tabbed code). Really -- have you? I mean, have you ever actually changed someone's tab size because you were unhappy with it, or have you ever done the opposite, change your tab size to match the original author's tabs because you realized that his code didn't read right otherwise? (I've done the latter!)
Your mindset is to make the code look the way you want it to by forcing the issue with spaces.
No. Think about it -- I *can't* force the issue. If you want to make my code look different, you can do ANYTHING to it; search and replace will do what tab redefinition can't. Thus, my use of spaces doesn't "force the issue".
YOUR mindset, on the other hand, is that _you_ can make my code look more to your taste simply by changing the tab level. My point is that you can't, either, unless my coding convention randomly happened to be indentation-agnostic.
The tabs-only approach, in an indentation-based language, lets you make the code look the way you want by adjusting your editor settings, and allows other users to do the same without changing the code.
Again, have you ever done this? Have you seen the results? Not only do little things like line alignment get messed up, but also big things like continued lines get torched.
The problem isn't tabs versus spaces; the problem is that tabs are entirely unique in the programmer's character set. They're the only characters whose size changes in different places. If it was only tabs versus spaces tabs would win every time (because they take less storage). But it's not -- you also have to compare tabs to all the other characters they're next to.
But what if I don't want your parameters to line up with the end of the function name?
That's my point -- your gripe isn't with my tabsize, it's with my coding style. Changing my tabsize will only make my coding style inconsistent (in most cases).
First, are you REALLY keeping track of other people's bugs? I don't see why you'd expect to get real numbers on bug cause frequency unless you conducted a real survey.
Second, my #1 source for this bug was hardware engineers (I used to work for a chip design company). They tend to be sloppy about indentation on their own, so they *trust* other people's indentation.
Finally, I wouldn't expect a huge number of released bugs to be caused by this. It's a consmetic mistake with (usually) obvious consequences.
My point wasn't that C is fatally flawed; I was claiming only that Python ISN'T flawed. My point about this one is that C's choice is actually worse than Python's by any human standard. (Computer text manipulation, on the other hand, is definitely harder in Python, although still nothing like impossible.)
But if you set them to anything other than what I wrote them as, my lines won't line up anymore. For example, consider the classic C
int MyFunc(
void *source,
void *dest
)
Now, whatever you may think about my choice of coding standards, I definitely intended the parameters to line up with the end of the function name. There's no way to do that with changable tabs.
Indentation depth is only a tiny part of coding standards, and it interacts with the rest. Pretending you can change it without affecting the rest isn't really logical; getting offended at someone's choice for it isn't either.
Sure, that's bad C style to write that, and I don't think I'm suggesting C is perfect.
Nor am I suggesting that Python is perfect, or even that C is inadequate.
But I can count { easier than counting white space.
But you don't HAVE to count white space; all you have to do is look and see that the text lines up. You DO have to count brackets, unless you just trust the indentation; and do I have to stress the risk in that?
I can't argue with your experience; all I can do is trust that what you say is correct (it would be odd of me to claim that it's not). You can't argue with my experience either; I _have_ seen numerous bugs caused by this specific misunderstanding. Calling my claims ridiculous will take more than citing your own personal experience.
Many editors DO outdent do_that, but many editors get OTHER things wrong, and I've fought with editors enough to understand someone fighting them in that.
And BTW, tens of thousands of lines isn't very much code, even if you meant 99 thousand. Certainly no basis for a judgement like that.
C has its warts, but the brackets aren't one of them.
I have no problem with that statement:-). I don't want to sound like I'm nitpicking C's brackets; they work perfectly well (although making the brackets optional was less defensible, and both Ada and Oberon chose good alternatives in that respect).
What I take exception to isn't any part of C; it's the claim that Python's choice of indentation is worse than C's choice of brackets. Both are vulnerable to certain problems; furthermore, C's block structure is MORE, not less, vulnerable to invisibility than Python's.
Both of your complaints are about your editor/text manipulator, not about Python. The first one is actually reasonable, since you DO have to go to a bit more effort to make your tools respect the whitespace; but the second reason I find odd, because you state it as a general rule, but I haven't used an editor in a LONG time that doesn't handle Python indentation correctly.
Even editors that don't recognise Python syntax can indent correctly most of the time, so long as you have indentation continuation (i.e. whenever you start a new line you get the same indentation as the line you'd just been on). The two exceptions are when you're starting a block (in which case detecting the : at the end of the line gives an unambiguous sign) or ending a block (in which case you have to backspace once, hardly a special challenge).
Slashdot Mirror
If only Walmart remained, in the worst case, I would expect prices to rise to monopoly levels -- of course, limited by the ability for anyone to set up local distribution. In other words, prices would rise to the levels we had before Walmart came on the scene. Why should I avoid Walmart because of the vague worst-case possibility of them having no effect? And in reality, Walmart actually DOES have real competition from the likes of Target, so this worst-case is very unlikely.
And your claim about forcing suppliers to lower prices and so on may be true (but if so would give Walmart another opening for competition -- another store could steal their suppliers by treating them better), but has already been addressed -- lower prices are a benefit even if the goods are produced outside of the local area. Mercantilism has been long since refuted: there's no real advantage in paying more money under the hope of boosting your own country's economy rather than another country's. The money you waste is simply a lost opportunity.
-Billy
I agree with all your points, but I'd like to add that automatically running test drivers are better than print statements in a few ways:
1. They provide regression testing for free -- no need to ask a later programmer to figure out what your print statements mean.
2. They document the interfaces of your program.
3. They encourage loose coupling between modules.
4. They can't possibly affect the execution of your production code (since they're not executed in the normal line of operation).
I'm not saying that they're always better than print statements or a debugger, but I do find the advantages compelling over print statements in all recent cases, and over debuggers when the problem doesn't involve legacy code. Debuggers still make a great learning tool, but once I understand the problem I try to reproduce it in a test.
-Billy
The difference is that the employees are also customers.
An excellent point. It makes sense that, as you say, if the employees lose their jobs, they won't be able to purchase things from companies, thus stagnating the economy.
But there's more to this story. Employees are customers; and customers are the ultimate authority. When the company spends less on its product, there are more resources left over in the economy to be spent on more urgently felt needs. Less money needs to be spent on the company's product, and more is allocated to meeting other needs.
If enough companies outsourced (I'm stealing your phrase), we wouldn't be in a recession -- we'd have unprecedentedly low costs for everyone, and higher competition. Some people would lose their current jobs, but there's more money out there than there was before -- less is being tied up in the same old companies.
-Billy
I agree with your post, except:
The same thing tends to happen with off-shoring of labor, but that's a bad thing for the economy because it reduces costs by eliminating workers.
You're right that the same thing happens, but you're wrong that "it's different this time". It's the same thing, and it has good results. By reducing costs, the company is able to expand (and in the long run, survive), thus providing the things people want without asking the people to give up things they want more, which is the only reason the company exists in the first place.
The employees of the company are in the same situation as the company itself -- they're selling something that people just aren't willing to buy at the prices they need to ask in order to be profitable. The company's selling (for example) software, the employees are selling labor specific to that software.
-Billy
If I had to guess, I'd say that Walmart is going to pocket any extra profits they come into as a result of this.
This scheme is nothing new; Walmart is enormously succesful precisely because of their cutting-edge inventory management systems, and they have _always_ passed the savings on to their customers. The direct, immediate connection between them saving money and their customers seeing lower prices and better stock management is why there are so many WalMarts. It's the key to their success.
It's kind of interesting to study -- they have an incredibly low profit margin compared to other stores in their industry, and that low profit margin has made them one of the biggest companies in the U.S.
-Billy
One of my favorite things about RPN is that the stack is an actual object that you can inspect. You can see intermediate values in a way that always makes sense, and if you want to calculate something completely different you can always do that, and after you drop the result your original work will be right back where you left it.
So there's no need for a distinct "memory" functionality. The stack handles everything.
-Billy
I thought the point of the artical was not that people are risking our privacy by using it, but that the existance of this service may compromise the status of email as being private.
Correct, that's what I saw too. I think the poster you're replying to saw it as well; his point was that email already isn't private.
I agree with him. Email's not at all private; anyone with reasonable resources (in other words, precisely the sort of person you SHOULD worry about violating your privacy) can already read your email almost at will. It's routed in plain text, after all, with no real limits on the number of times it gets copied.
Gmail changes nothing about the privacy of email -- in fact, Google could conceivably already HAVE a massive searchable database of most email sent since they became big enough to afford the storage. (They almost certainly don't, BTW, but they COULD.)
-Billy
I strongly recommend you read Google's Gmail FAQ rather than asking Slashdot users :-). They answer this question VERY clearly.
They're going to pay for the space by putting AdSense ads next to some emails, based on the user's emails. Just like how they pay for the Google search.
It's possible that the result will be more valuable than the search ads for them, since they'll have more information based on which to target the ads, so advertisers will have a higher response rate.
-Billy
What is "VERY forthcoming"? Will the Gmail pages have warnings about email being read by Google in large fonts in very prominent locations in a user's eyespace?
... bitterly sad that such honorable conduct should be met by such strong resistance. Look, Google is doing only what the other webmail providers do, and MUST do in order to survive. The difference is that Google tells us BEFORE they start! This would not have been a controversy if Google hadn't made it SO easy to find out what they're doing.
Gosh, I hope not!
Nope; what they do is discuss in their FAQ, prior to any user questions on the subject, exactly what they plan to do to your messages. This is in contradistinction to Hotmail, which does not discuss at ALL what they will do to your messages, and whose service agreement includes a blanket license to use, perform, and so on ANYTHING in your email (essentially a complete license under copyright law). Google is very forthcoming, meaning that they take the initiative to state precisely what they're going to do.
It's just
More likely it will be stated in some privacy policy in some place where many users eyes will not naturally fall.
Again, this is REALLY pathetic. The entire controversy is CAUSED by Google discussing this privacy issue openly and accessibly.
1. If Google gets away with this there will be imitators ( some not upfront ) making it harder for people who DON'T want their personal read to get away from that sort of thing.
Hotmail already exists. NEXT!
2. Its not just Gmail user's email that gets read, its the email from anyone who sends email to a Gmail address
First, it's not "getting read"; it's at most getting scanned. No human ever sees it.
Second, it's not being used for any magical marketting aggregation (or at least that's not what this controversy is about -- it's possible, but no more so than it's possible for ANY large enough ISP). It's being used ONLY to deliver ads to the single customer to whom it's being sent! In other words, the only person who will be affected by Google's scanning of that message will be the person for whom the message is intended.
With that said, though, I would think that Google would do well to investigate the concept of only scanning outgoing email for the purpose of establishing advetisements. That way, Google could accurately claim to deliver ads targetted to YOU, not to the people from whom you happen to receive email.
If I have to correspond with a Gmail user it will be ONE email from a disposable address explaining #2 and that I will not converse with them at a Gmail address
Isn't it odd that you could HAVE disposable addresses? The fact is that the only thing that makes those even faintly private and affordable is companies who do what Google wants to do, only generally with less honesty.
And really, if you're worried about Google, your only way out is to run your own server and encrypt everything.
-Billy
If you give them your private information, they HAVE it. If you don't want that, don't give it to them. Whether they "have rights" to your information is irrelevant once they have it.
This means, of course, that anything you consider private information must NOT be sent out over the Internet in plain text. If you don't do this, then refusing to use Google Email only makes sense -- in fact, even THINKING of using Google email doesn't make sense.
I'm going to use Gmail, because I'm only going to use it for stuff that's not private, in the sense that I'm not worried about whose hands it might fall into. Of course, that's ALL my non-work email currently. I can imagine someday wanting GPG or PGP set up, and on that day I'll use something other than Gmail.
-Billy
The "peer-to-peer" claim refers to the fact that lookups, data traffic, encryption, and routing is all accomplished without any reference to central servers. Skype therefore should not be vulnerable to typical network scaling issues -- it could support a HUGE number of users, since the users themselves provide all the network capacity.
Typical VOIP, on the other hand, is centrally served; at least the routing (and sometimes all of the traffic) is done by a central server. That central service has to get VERY big VERY quickly.
Someone else who replied to you claimed that P2P means that you can only call other Skype users. Although this may be true (I don't know), it doesn't have to remain so -- I'm sure Skype will be very willing to make money selling the right to use their access points to let you dial into landlines (and licensing their tech to other companies wanting to do the same).
This is a HUGE use of P2P technology, fully as clever as BitTorrent.
-Billy
The saving "deleted" mail is part of Google's filesystem, not part of its advertising policy. It's also technically required for any redundant distributed system -- it's not possible to delete things immediately without incurring HUGE overhead.
However, if it were part of its advertising policy, I'm curious -- why would you care?
-Billy
But nobody's giving up privacy -- we're talking about a company that publicly states that it does what every mail server has to do as a matter of course.
Yes, they parse your email. That's part of SMTP (HELO, mcfly). They store it; that's part of webmail. They go through it; that's part of syntax highlighting. They index it; that's part of search capability. They may not wipe it out when you delete it; that's part of the cost of a distributed system.
Google isn't the only one that does ANY of this; all of the others do as well, including your ISP and _certainly_ including the big webmail providers (because they ALSO throw in advertising). The difference is that Google tells you EXACTLY what they're doing.
This is honesty, plain and simple. They should be rewarded for it.
-Billy
I think you're only partially right, and that Google will have the information needed to find the core set of "spam" that it can safely delete without angering (or inconveniencing) its users. Furthermore, it'll do so because doing otherwise will both cost it more money in spam storage, but will also cut down on email reading time for its users, directly saving Google money _and_ making many people devoted fans.
/using/ their zombie networks antispam will become HARD, but Google can muster enough power to outzombie a typical worm without even involving any user's machines, and Google can ask its users to install and run clients if it needs to (after all, Google's experimenting with grid computing in its Googlebar already!).
:-). There probably WILL be people who really do want to get all the spam. There are plenty of other reasons to run your own mail server or to continue using your ISP's email, but this would be one of them.
I suspect that Google will use tools like the graph analysis discussed in a recent Slashdot story in addition to typical Bayesian analysis. There are ways around all that, and Google will keep on their toes -- once the spammers start really
Of course, even if you're "only" partially right, you're still right
-Billy
Be afraid OF WHAT?
Afraid that the things I and others do in public will become public information? (They already are, whether or not someone's indexing them.) Afraid that email will become publicly available? (It already is, to your host and to any server that happens to pass your messages on.) Afraid of being served customized ads? (Okay, but at least be honest what you're telling us to be afraid of -- because I'm NOT afraid of that!)
Come on, tell us WHAT we're supposed to be frightened of.
-Billy
Well, that wasn't really the comparison. I was equating the question "how do I get from here to there without a goto" to your statement "you can't change coding styles just by changing tab size". Both demonstrate a certain stubborn adherence to past practices when faced with new techniques.
That's not true.
The problem here is that you're telling me that using tabs is the new advanced wave of computer science, and I'm being obsolete to think of opposing it. You've got it exactly backwards. ALL the old code uses tabs; tabs were the primary means of indentation, mainly because they take less disk space. So _your_ solution is firmly in "the old way" camp, and mine is the up-and-coming "new way".
And this STILL has nothing to do with our debate. It's _entirely_ beside the point. The fact that your is old and mine is new doesn't mean anything.
Again, if you wish to debate this, you'll have to do better than make analogies and/or appeal to age. Even a valid analogy (which this is not) wouldn't be evidence, much less proof.
Ok, how is this... I like smaller tab size (2 or even 1) better for deeply-nested code, and larger tab size (say 4) for shallow code. Neither tab size is optimal in all cases. When dealing with my own code, which uses only tabs, I can change the tab size dynamically based on the code I'm looking at.
Deeply nested code is going to have a lot of continuation lines, which are going to be the most indentation-dependant things you'll see. Changing the indentation may mess other things up; it WILL mess up continuation lines.
You'll also find that as you change depths, your line lengths will become more obviously non-optimal since they were written with much less horizontal room than you're using to read (unless the original developer didn't care about line lengths, in which case you'll just be lucky if his code is readable).
And finally, of course, the better solution is to realise that what you're doing is a shoddy replacement for re-indenting the code -- nothing WRONG with what you're doing, but it'll never be as effective as doing the job properly.
Well, I'm no Python language lawyer, so I may need to concede that point. But I still find it distasteful to be so liberal with indentation in a language where indentation is syntactically significant. Pick the wrong number of spaces, and you might change the semantics of your code!
You sound fearful -- I suspect you've never used Python. Go ahead, there's nothing to be afraid of -- Python's very smart about indentation. The only rules you have to follow are:
1. Make sure every line in a block lines up with the other lines *in that block* at any tabsize. (The parser will complain if you get it wrong and refuse to execute the file, so don't worry about it.)
2. Don't EVER put a space before a tab. (You can turn on an option to make the compiler complain, but it's pretty much a waste of time, because most programmer have an instinctive fear of this kind of silliness.)
Reccommended: Use only tabs OR only spaces.
As long as you stick to the first two rules, everything will work out. Stick to the third rule, and other people will be able to edit your code without worrying about it.
The code I typed doesn't even care about indentation -- stuff inside parentheses ignores indentation.
Strange that ecode didn't work for you. Hmm.
Christ, he had better not press spaces until they visually line up in the font he happens to be using at the time. That's the most abhorrent practice you have suggested so far.
Why? I honestly have no idea why you don't like that.
Keep in mind that any editor that claims to support proportional fonts had better have special support for spaces and tabs used as indentation!
-Billy
Seriously, your comparison of using spaces to unstructured programming is at best beside the point; the only similarity between the two practices is that you personally don't like either one. BUT, I like how you present your point, and I think I see what you're saying. I'm going to take the following paragraph as the REAL point you were making, and ignore the guilt-by-association
Likewise, if you write your program text with variable tabs in mind in the first place, then you can change the layout of the code cleanly just by adjusting tab size. And that's all there is to it!
Again, this is a coding conventions question, not simply a question of whether or not to use tabs. In order to gain a vaguely alleged advantage to a hypothetical reader, you have to throw out a _lot_ of possibilities for using code structure to convey information about your code.
Now, if you could provide me with an advantage more concrete than "I might not like your indentation level," I might find that to be a more interesting tradeoff. But as things stand, the only time I've felt the need to change someone's indentation is when their code was messed up by *my* editor settings not matching theirs.
Yes, my example used C types -- what of it? Remove the text "void *" and that's valid Python code. Contrary to what you said, my statement applies precisely to any language. Well, at least any language whose lines appear next to each other
The Slashdot HTML to preserve Python indentation is "ecode".
Another thing to keep in mind: I do know at least one programmer who prefers proportional fonts. Why shouldn't he use them?
An excellent question. There are a lot of advantages to using proportional fonts -- I've tried it, and it's really easy to get used to. So long, that is, as your editor can handle treating the leading spaces and tabs both correctly and consistently
But let me answer your question more completely, as it deserves.
When writing code using proportional fonts, the programmer will still tend to group lines together in a way that communicates any parallelism in the lines; he won't count letters to line them up, rather he'll press space (or tab) until they line up. Just like he did back when he used a fixed-width font.
-Billy
Use search and replace to change code indentation? Yes. Only with tab-based code, though -- I've never found screwed-up space-based code (because most really old code is tab-based, not because space-based code can't get screwed up). The idea is the same, though; and the search expression is a complex regexp. (I never said it was easy.)
You demonstrated it on C code. As I said, I'll plead no contest on that count.
I never mentioned C code in that context. I don't know what you're talking about. Changing tabs size is simply NOT sufficient to change coding standards, and that's all there is to it! There's no language dependancy in that statement of ANY kind, nor in the proof; even the example I gave was legal Python (or C).
But in a language where indentation is syntactically significant, I think your view is harder to defend.
Why? I'm really confused now -- that doesn't make any sense to me. In a language where indentation is syntactically significant -- the only significant current one in Python (Prothon isn't any different) -- indentation means exactly the same thing _semantically_ as it does in every other modern language. The only difference is that the Python compiler *checks* the indentation.
So how could "syntactic significance" of indentation change anything about my argument?
Anyway, I'll tell you what would be cool. I'd like to specify tab stops in the code, with a special comment or something, and have the editor obey them.
vi does this with a special form at the beginning line of a file. I don't know emacs, but it probably does that too. I've seen people paste "tab bogosity meters" at the beginning of code, looking somewhat like this:The first line is laid out with spaces; the second line starts with a few tabs, and the instructions for the bogosity meter says that if the carat doesn't line up within the brackets, adjust your tab size.
Cute. Anyhow...
The best solution, of course, is to use spaces instead of tabs; spaces are indentation instructions that _every_ editor and printer recognises to mean the same thing. (Abuses such as proportional fonts excepted.)
-Billy
Ok, I doubt we'll ever agree,
;-).
Probably not, but thank you very much for taking the time; it's an enjoyable discussion for some odd reason
but I think if you have a language that uses indentation as a syntactical feature, then it makes sense that there be one designated "indentation character", and that you can tell the indentation level simply by counting the occurrences of this character.
I agree 100%. In fact, so do the official guidelines for Python.
http://www.python.org/peps/pep-0008.html
Although they state that using spaces is preferred, you can see from the rule and rationale that using tabs consistently is good for that purpose.
Using tabs exclusively also has the benefit that anyone can choose the indentation level they like the best, and the code will still look right.
I've already demonstrated that this is simply false -- changing tab size is NOT sufficient to change coding standards in many cases. The exceptions exist, but I've never found one, even in the days when I used tabs-only (and would religiously convert spaced code to tabbed code). Really -- have you? I mean, have you ever actually changed someone's tab size because you were unhappy with it, or have you ever done the opposite, change your tab size to match the original author's tabs because you realized that his code didn't read right otherwise? (I've done the latter!)
Your mindset is to make the code look the way you want it to by forcing the issue with spaces.
No. Think about it -- I *can't* force the issue. If you want to make my code look different, you can do ANYTHING to it; search and replace will do what tab redefinition can't. Thus, my use of spaces doesn't "force the issue".
YOUR mindset, on the other hand, is that _you_ can make my code look more to your taste simply by changing the tab level. My point is that you can't, either, unless my coding convention randomly happened to be indentation-agnostic.
The tabs-only approach, in an indentation-based language, lets you make the code look the way you want by adjusting your editor settings, and allows other users to do the same without changing the code.
Again, have you ever done this? Have you seen the results? Not only do little things like line alignment get messed up, but also big things like continued lines get torched.
The problem isn't tabs versus spaces; the problem is that tabs are entirely unique in the programmer's character set. They're the only characters whose size changes in different places. If it was only tabs versus spaces tabs would win every time (because they take less storage). But it's not -- you also have to compare tabs to all the other characters they're next to.
-Billy
But what if I don't want your parameters to line up with the end of the function name?
That's my point -- your gripe isn't with my tabsize, it's with my coding style. Changing my tabsize will only make my coding style inconsistent (in most cases).
-Billy
First, are you REALLY keeping track of other people's bugs? I don't see why you'd expect to get real numbers on bug cause frequency unless you conducted a real survey.
Second, my #1 source for this bug was hardware engineers (I used to work for a chip design company). They tend to be sloppy about indentation on their own, so they *trust* other people's indentation.
Finally, I wouldn't expect a huge number of released bugs to be caused by this. It's a consmetic mistake with (usually) obvious consequences.
My point wasn't that C is fatally flawed; I was claiming only that Python ISN'T flawed. My point about this one is that C's choice is actually worse than Python's by any human standard. (Computer text manipulation, on the other hand, is definitely harder in Python, although still nothing like impossible.)
-Billy
Indentation depth is only a tiny part of coding standards, and it interacts with the rest. Pretending you can change it without affecting the rest isn't really logical; getting offended at someone's choice for it isn't either.
-Billy
Sure, that's bad C style to write that, and I don't think I'm suggesting C is perfect.
Nor am I suggesting that Python is perfect, or even that C is inadequate.
But I can count { easier than counting white space.
But you don't HAVE to count white space; all you have to do is look and see that the text lines up. You DO have to count brackets, unless you just trust the indentation; and do I have to stress the risk in that?
-Billy
I can't argue with your experience; all I can do is trust that what you say is correct (it would be odd of me to claim that it's not). You can't argue with my experience either; I _have_ seen numerous bugs caused by this specific misunderstanding. Calling my claims ridiculous will take more than citing your own personal experience.
:-). I don't want to sound like I'm nitpicking C's brackets; they work perfectly well (although making the brackets optional was less defensible, and both Ada and Oberon chose good alternatives in that respect).
Many editors DO outdent do_that, but many editors get OTHER things wrong, and I've fought with editors enough to understand someone fighting them in that.
And BTW, tens of thousands of lines isn't very much code, even if you meant 99 thousand. Certainly no basis for a judgement like that.
C has its warts, but the brackets aren't one of them.
I have no problem with that statement
What I take exception to isn't any part of C; it's the claim that Python's choice of indentation is worse than C's choice of brackets. Both are vulnerable to certain problems; furthermore, C's block structure is MORE, not less, vulnerable to invisibility than Python's.
-Billy
Both of your complaints are about your editor/text manipulator, not about Python. The first one is actually reasonable, since you DO have to go to a bit more effort to make your tools respect the whitespace; but the second reason I find odd, because you state it as a general rule, but I haven't used an editor in a LONG time that doesn't handle Python indentation correctly.
Even editors that don't recognise Python syntax can indent correctly most of the time, so long as you have indentation continuation (i.e. whenever you start a new line you get the same indentation as the line you'd just been on). The two exceptions are when you're starting a block (in which case detecting the : at the end of the line gives an unambiguous sign) or ending a block (in which case you have to backspace once, hardly a special challenge).
-Billy