How exactly do we require those companies to get permission, especially when our own government has an interest in this sort of behavior, and to some degree, in having other companies do the dirty work for them?
The problem is that people have not yet awoken to the idea that old notions of privacy no longer apply. Until the majority of people realize that the game has changed, there will not be any meaningful regulation (why would anyone vote for it, if they do not perceive a problem that needs to be solved), nor will people switch to systems with stronger privacy guarantees.
if you don't want it to get in a database, DON'T PUT IT ON THE FREAKING INTERNET
If only it were that simple. How do you stop other people from posting it on some website somewhere, potentially without your knowledge? What about all those people who use Facebook and think that their privacy settings are equivalent to not posting information online, or that what the post on Facebook is only accessible to people they "friend?" Just saying, "Well you posted it online so it is your own fault," is not really an answer to the question.
(For the record, I do not use any social networking websites, I do not blog, and so forth. I still have to deal with everyone around me who does, though.)
I think the bigger fail is the amount of Javascript PeekYou makes use of -- including from Facebook and Google. I wonder if just searching for your name on PeekYou could potentially add more data to those companies' databases...
I think the real issue here is that we need to rethink our notions of "privacy." It used to be that having a normal social life meant that outside of your social circle, you had a measure of privacy -- someone would have to actually be part of your social circle to learn about you. That is no longer true, but we still have not quite caught up with that new reality.
It is a bit unnerving to think of "opting out" of something that I never consented to in any form. I am going to guess that most people are not even aware of these companies.
Yes, I know, "Don't post data about yourself online!" That is not really the answer when most people think that Facebook is the way to be social. I do not have a Facebook profile, and I stay off of other social networking websites too; I am not going to pretend for a moment, though, that I am even close to representative of the norm. It is easy to make fun of all those "fools" out there who are undermining their own privacy, but in the end, that is not going to solve the problem, and eventually even people who want to have privacy will find that it is not possible to do so.
In fact, when I saw that bug in one of my students' programs, I did check the standard -- I was about to report it as a bug in the compiler itself.
The standards may be a bit permissive in not declaring this to be illegal but the only parties dropping the ball are the ones in charge of specific compiler projects and/or ignorant users who fail to understand both this basic aspect and how to properly configure their compiler of choice.
Not everyone is an expert. Why is it obvious that "-Wall -Werror" should be passed to the compiler, especially for people who have never used g++ before? My students were in their second year as undergrads, and in their first year they saw Java and Scheme, two languages where it is not necessary to ask your compiler to be stricter than the language standard just to avoid seemingly obvious issues.
Thus explaining why other languages do not have this problem? What, do their compilers decide the halting problem? In the general case, the semantic analyzer should detect that (1) control flow reaches the end of a function that is supposed to return a value or object and (2) stop with an error, because that is not something that should happen.
Well, More Effective C++ lists the following three things (Effective C++ has more, but I loaned out my copy):
Overloading operator&&, operator||, or operator, (regarding operator, -- I have seen a single case where this was overloaded in a constructive and useful manner, the Boost Lambda Expression Library)
Propagating exceptions out of a destructors (can result in a crash)
Exception specifications (Meyers says to use them "judiciously")
Another one that comes to mind is overloading a function to take either an int or a pointer (because if you pass 0 as a null pointer, what happens? This might have been in Effective C++).
My apologies, I seem to have missed the definition of "undefined behavior." Still, the fact that a function can be declared to return a non-void type but reach the end of its body without a return statement is pretty bad...
what's wrong with COBOL for when it was widely used (rather than comparing it to the languages of today)?
Nothing was wrong with using COBOL back then, but COBOL remains in use today -- quite a lot of COBOL code is running right now. It is not being used because COBOL is a great language or because COBOL is the best solution in the situations where it is still used. It is in use because the cost of switching is still too high.
I'm not arguing that C++ is perfect, but most of its flaws are either sufficiently minor, or easy to work around.
Some flaws are minor, sure, and I would not begrudge any language a couple of minor flaws -- nothing is perfect. C++ has flaws, however, that are not at all minor. Control flow can reach the end of a non-void function, for example -- a situation which can cause a program to crash (this is a leftover from C, where such a situation could only cause corrupted data). If an exception is thrown while the stack is being unwound as part of the handling of another exception (e.g. an exception might propagate outside of a destructor), the program immediately aborts. The standard library has things like auto_ptr (fixed in C++0x, thankfully), return codes instead of exceptions (but only sometimes; in some cases, though, you need to ask for exceptions to be thrown instead, but in other cases it is part of the standard), allocators as template parameters (I hear this will be fixed too), etc.
Yes, some flaws are minor, like the weird syntax for overloading prefix operators, but there are other, more serious problems with C++.
Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function."
Undefined behavior does not mean that a compiler is supposed to stop with an error. In fact, it means that the compiler should accept the code, but that the standard does not mandate any particular behavior in the code that is generated.
This is not equivalent to saying that a function which declares a non-void return type must have at least one return statement.
It means that the code should compile but that the standard does not specify what exactly the program will do. This is something that is supposed to be reserved for situations where there is no good way to define what should happen, usually because factors that are beyond the scope of the standard can influence the behavior of the program. A good example is modifying a static string -- C++ is not intended for development only on platforms where such behavior is not allowed, nor is it intended for development only on platforms where such behavior is allowed, and there is no good way to define what the compiler should do when it sees such code (in fact, it is very easy for such a situation to arise without the compiler being able to detect it at all, if you pass pointers around a lot).
In this case, though, there is a proper definition: a function that is declared to return something should have a return statement, and nothing else makes sense.
Or, look at the standard, which is what I did when I first saw this bizarre bug, and yes, the standard says nothing about that code failing to compile (the standard defines errors, not warnings, although at the default warning level, g++ doesn't even warn about that one).
Actually, if you look at the standard, it is not defined. The standard says what a return statement does, and it was what a function declaration should mean, but it says nothing about functions that have a non-void return type being required to have a return statement in the function body. The fact that Visual C++ won't compile that code means that (1) Visual C++ implements a language that is not exactly C++ and (2) Visual C++ corrects an error in the C++ standard. On the other hand, g++ does not try to correct errors in the standard; in fact, on at least one occasion, they have relied on omissions to justify changes to their implementation of the STL (specifically, they changed the implicit include structure, which is not defined in the standard, and which caused a lot of code to break; the right way to do things in C++ is to explicitly include all headers and never rely on implicit includes, but there are certain common implicit include structures that people have come to rely on, like fstream implicitly including iostream).
C++ is popular for the same reason Windows is popular (and in fact, Windows' popularity probably fuels a lot of the popularity of C++): it is widely deployed, people know it, and there is a lot of legacy code that depends on it. Popularity does not make a language good, and I think we have enough examples: COBOL, FORTRAN, C++, etc. C++ has a number of glaring omissions from the standard, and worse yet, things in the standard that are now idiomatically avoided (see Effective C++ and Effective STL if you are interested -- auto_ptr certainly comes to mind). There are some really great languages out there, which just don't have the same non-technical advantages that C++ enjoys, and therefore never became popular among mainstream programmers.
I would certainly call that a "real project." Really, C and C++ are pretty terrible programming languages, with C++ being a bit worse than C, and I say that as someone who also started programming in middle school using C++.
C++ was my first language too, and until I started teaching it to other people, it was my favorite. Then I saw all the things that make no sense in C++, which never tripped me up because I happened to have been using the language for so long. I also noticed that a lot of idioms and design patterns that I used to think were really cool hacks were just ways to avoid serious design flaws in the language itself.
What really killed C++ for me was when a student created a situation like this:
std::string somefunction(){}
The fact that such a thing can compile is a glaring error. A function that declares a return type should have a return statement in it, and that should be beyond question. In C, failing to actually return will cause you to have corrupt data; in C++, it can cause a crash, when a temporary object that was never created is destroyed (and happens to have a virtual destructor, which is common).
It is true, there is no on right language, but on the flip side, there certainly are languages that should be avoided if possible, and I would say that C++ is one of them. I understand that there is a lot of legacy code and that using C++ is often unavoidable, and I have found myself in that situation, but if I were starting a new project with a fresh codebase, C++ would be pretty far down the list of languages that I would consider.
This, by the way, is one way you might construct the real numbers
FTFY. There are other ways of constructing real numbers from rational numbers. You can even avoid constructing real numbers entirely, and just use an axiomatic approach (this is what is done in Aposotol's calculus text). As it turns out, 0.999... = 1 is true regardless of how you approach the real numbers.
True, but it has also been my experience that only a handful of those pictures are really interesting and worth sharing. Back before Facebook, when more people were willing to send emails, I remember people snapping dozens of pictures but only sending a handful, presumably those that they thought looked best.
I should probably have phrased it "Anything that competes with Windows," since the tactic I was referring to was the one that they have been using for a decade now to discourage people from using other operating systems. They are now recycling this attack for an office suite that competes with MS Office, which for the past decade they have been able to basically assume is immune to attack. I guess they believe that era is over, and I would not be too surprised by that -- OOo has been able to satisfy the needs of a large number of MS Office users for some time now.
0.999... is not a "decimal expansion" of some number, but rather it denotes a sequence of numbers: 0.999, 0.9999, 0.99999,....
Talk about having difficulty understanding the concept. 0.9999... is not a sequence, it is a series:
9/10 + 9/100 + 9/1000 + 9/10000 +...
Which anyone who paid attention in middle school will recognize as a geometric series (well, actually, it is a multiple of a geometric series).
The fact that "the real numbers can be defined as equivalence classes of Cauchy sequences of rational numbers"...
...is not relevant to this discussion. The real numbers can be defined axiomatically; you can show that a formulation using equivalence classes of Cauchy sequences is equivalent to the axiomatic definition, or you can use Dedekind cuts, etc. In the end, you wind up with the same theorems regarding series, and 0.999... will mean the same thing -- a series. If you construct the real numbers using Cauchy sequences, you need to be careful about what you mean by "+" -- 0.999, for example, is 9/10 + 9/100 + 9/1000 using addition of rational numbers, but when you construct the real numbers, you are defining addition differently (since you can add two Cauchy sequences). Why get into that much depth, though, when we have a good definition of what decimal expansions are: series.
Also, one should not just casually accept the ideas of infinite series and sequences, because counter-intuitive things DO happen with them.
There is nothing counter-intuitive in this case, it is just a geometric series. More generally, decimal expansions are special cases of infinite series, and there is a well developed theory on infinite series.
It is interesting that you should bring up email and IM. I have a number of friends who are somewhat annoyed by the fact that I am not on Facebook and that they have to actually communicate with me using email/IM. For example, a friend posted some pictures of her at an event...and then seemed annoyed by the very concept of emailing those pictures to me, instead of just having me log in to Facebook and look at them. On a number of occasions, people have refused to send me an email at all, demanding that I just sign up for Facebook and look at their pictures there.
Personally, I think it is a little scary that Facebook itself is the dominant communications platform for so many people. No interoperability, no respect for privacy, and plenty of rules about what you can or cannot say or do (and you can forget writing a script or even attempting to automate something that Facebook's developers do not want you automating).
Slashdot Mirror
How exactly do we require those companies to get permission, especially when our own government has an interest in this sort of behavior, and to some degree, in having other companies do the dirty work for them?
The problem is that people have not yet awoken to the idea that old notions of privacy no longer apply. Until the majority of people realize that the game has changed, there will not be any meaningful regulation (why would anyone vote for it, if they do not perceive a problem that needs to be solved), nor will people switch to systems with stronger privacy guarantees.
if you don't want it to get in a database, DON'T PUT IT ON THE FREAKING INTERNET
If only it were that simple. How do you stop other people from posting it on some website somewhere, potentially without your knowledge? What about all those people who use Facebook and think that their privacy settings are equivalent to not posting information online, or that what the post on Facebook is only accessible to people they "friend?" Just saying, "Well you posted it online so it is your own fault," is not really an answer to the question.
(For the record, I do not use any social networking websites, I do not blog, and so forth. I still have to deal with everyone around me who does, though.)
I think the bigger fail is the amount of Javascript PeekYou makes use of -- including from Facebook and Google. I wonder if just searching for your name on PeekYou could potentially add more data to those companies' databases...
I think the real issue here is that we need to rethink our notions of "privacy." It used to be that having a normal social life meant that outside of your social circle, you had a measure of privacy -- someone would have to actually be part of your social circle to learn about you. That is no longer true, but we still have not quite caught up with that new reality.
It is a bit unnerving to think of "opting out" of something that I never consented to in any form. I am going to guess that most people are not even aware of these companies.
Yes, I know, "Don't post data about yourself online!" That is not really the answer when most people think that Facebook is the way to be social. I do not have a Facebook profile, and I stay off of other social networking websites too; I am not going to pretend for a moment, though, that I am even close to representative of the norm. It is easy to make fun of all those "fools" out there who are undermining their own privacy, but in the end, that is not going to solve the problem, and eventually even people who want to have privacy will find that it is not possible to do so.
The standards may be a bit permissive in not declaring this to be illegal but the only parties dropping the ball are the ones in charge of specific compiler projects and/or ignorant users who fail to understand both this basic aspect and how to properly configure their compiler of choice.
Not everyone is an expert. Why is it obvious that "-Wall -Werror" should be passed to the compiler, especially for people who have never used g++ before? My students were in their second year as undergrads, and in their first year they saw Java and Scheme, two languages where it is not necessary to ask your compiler to be stricter than the language standard just to avoid seemingly obvious issues.
Thus explaining why other languages do not have this problem? What, do their compilers decide the halting problem? In the general case, the semantic analyzer should detect that (1) control flow reaches the end of a function that is supposed to return a value or object and (2) stop with an error, because that is not something that should happen.
Another one that comes to mind is overloading a function to take either an int or a pointer (because if you pass 0 as a null pointer, what happens? This might have been in Effective C++).
auto_ptr comes to mind...
My apologies, I seem to have missed the definition of "undefined behavior." Still, the fact that a function can be declared to return a non-void type but reach the end of its body without a return statement is pretty bad...
what's wrong with COBOL for when it was widely used (rather than comparing it to the languages of today)?
Nothing was wrong with using COBOL back then, but COBOL remains in use today -- quite a lot of COBOL code is running right now. It is not being used because COBOL is a great language or because COBOL is the best solution in the situations where it is still used. It is in use because the cost of switching is still too high.
I'm not arguing that C++ is perfect, but most of its flaws are either sufficiently minor, or easy to work around.
Some flaws are minor, sure, and I would not begrudge any language a couple of minor flaws -- nothing is perfect. C++ has flaws, however, that are not at all minor. Control flow can reach the end of a non-void function, for example -- a situation which can cause a program to crash (this is a leftover from C, where such a situation could only cause corrupted data). If an exception is thrown while the stack is being unwound as part of the handling of another exception (e.g. an exception might propagate outside of a destructor), the program immediately aborts. The standard library has things like auto_ptr (fixed in C++0x, thankfully), return codes instead of exceptions (but only sometimes; in some cases, though, you need to ask for exceptions to be thrown instead, but in other cases it is part of the standard), allocators as template parameters (I hear this will be fixed too), etc.
Yes, some flaws are minor, like the weird syntax for overloading prefix operators, but there are other, more serious problems with C++.
Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function."
It means that the code should compile but that the standard does not specify what exactly the program will do. This is something that is supposed to be reserved for situations where there is no good way to define what should happen, usually because factors that are beyond the scope of the standard can influence the behavior of the program. A good example is modifying a static string -- C++ is not intended for development only on platforms where such behavior is not allowed, nor is it intended for development only on platforms where such behavior is allowed, and there is no good way to define what the compiler should do when it sees such code (in fact, it is very easy for such a situation to arise without the compiler being able to detect it at all, if you pass pointers around a lot).
In this case, though, there is a proper definition: a function that is declared to return something should have a return statement, and nothing else makes sense.
% cat blah.cpp
#include <string>
std::string func(){}
% g++ blah.cpp -c
%
Or, look at the standard, which is what I did when I first saw this bizarre bug, and yes, the standard says nothing about that code failing to compile (the standard defines errors, not warnings, although at the default warning level, g++ doesn't even warn about that one).
Actually, if you look at the standard, it is not defined. The standard says what a return statement does, and it was what a function declaration should mean, but it says nothing about functions that have a non-void return type being required to have a return statement in the function body. The fact that Visual C++ won't compile that code means that (1) Visual C++ implements a language that is not exactly C++ and (2) Visual C++ corrects an error in the C++ standard. On the other hand, g++ does not try to correct errors in the standard; in fact, on at least one occasion, they have relied on omissions to justify changes to their implementation of the STL (specifically, they changed the implicit include structure, which is not defined in the standard, and which caused a lot of code to break; the right way to do things in C++ is to explicitly include all headers and never rely on implicit includes, but there are certain common implicit include structures that people have come to rely on, like fstream implicitly including iostream).
C++ is popular for the same reason Windows is popular (and in fact, Windows' popularity probably fuels a lot of the popularity of C++): it is widely deployed, people know it, and there is a lot of legacy code that depends on it. Popularity does not make a language good, and I think we have enough examples: COBOL, FORTRAN, C++, etc. C++ has a number of glaring omissions from the standard, and worse yet, things in the standard that are now idiomatically avoided (see Effective C++ and Effective STL if you are interested -- auto_ptr certainly comes to mind). There are some really great languages out there, which just don't have the same non-technical advantages that C++ enjoys, and therefore never became popular among mainstream programmers.
I think that *real* projects use either C or C++
Well, there is this:
http://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool
I would certainly call that a "real project." Really, C and C++ are pretty terrible programming languages, with C++ being a bit worse than C, and I say that as someone who also started programming in middle school using C++.
What really killed C++ for me was when a student created a situation like this:
The fact that such a thing can compile is a glaring error. A function that declares a return type should have a return statement in it, and that should be beyond question. In C, failing to actually return will cause you to have corrupt data; in C++, it can cause a crash, when a temporary object that was never created is destroyed (and happens to have a virtual destructor, which is common).
It is true, there is no on right language, but on the flip side, there certainly are languages that should be avoided if possible, and I would say that C++ is one of them. I understand that there is a lot of legacy code and that using C++ is often unavoidable, and I have found myself in that situation, but if I were starting a new project with a fresh codebase, C++ would be pretty far down the list of languages that I would consider.
This, by the way, is one way you might construct the real numbers
FTFY. There are other ways of constructing real numbers from rational numbers. You can even avoid constructing real numbers entirely, and just use an axiomatic approach (this is what is done in Aposotol's calculus text). As it turns out, 0.999... = 1 is true regardless of how you approach the real numbers.
True, but it has also been my experience that only a handful of those pictures are really interesting and worth sharing. Back before Facebook, when more people were willing to send emails, I remember people snapping dozens of pictures but only sending a handful, presumably those that they thought looked best.
Now if only judges and juries could be convinced that is a likely scenario, maybe we could finally move past all the nonsense.
I should probably have phrased it "Anything that competes with Windows," since the tactic I was referring to was the one that they have been using for a decade now to discourage people from using other operating systems. They are now recycling this attack for an office suite that competes with MS Office, which for the past decade they have been able to basically assume is immune to attack. I guess they believe that era is over, and I would not be too surprised by that -- OOo has been able to satisfy the needs of a large number of MS Office users for some time now.
0.999... is not a "decimal expansion" of some number, but rather it denotes a sequence of numbers: 0.999, 0.9999, 0.99999, ....
Talk about having difficulty understanding the concept. 0.9999... is not a sequence, it is a series:
...
9/10 + 9/100 + 9/1000 + 9/10000 +
Which anyone who paid attention in middle school will recognize as a geometric series (well, actually, it is a multiple of a geometric series).
The fact that "the real numbers can be defined as equivalence classes of Cauchy sequences of rational numbers"...
Also, one should not just casually accept the ideas of infinite series and sequences, because counter-intuitive things DO happen with them.
There is nothing counter-intuitive in this case, it is just a geometric series. More generally, decimal expansions are special cases of infinite series, and there is a well developed theory on infinite series.
It is interesting that you should bring up email and IM. I have a number of friends who are somewhat annoyed by the fact that I am not on Facebook and that they have to actually communicate with me using email/IM. For example, a friend posted some pictures of her at an event...and then seemed annoyed by the very concept of emailing those pictures to me, instead of just having me log in to Facebook and look at them. On a number of occasions, people have refused to send me an email at all, demanding that I just sign up for Facebook and look at their pictures there.
Personally, I think it is a little scary that Facebook itself is the dominant communications platform for so many people. No interoperability, no respect for privacy, and plenty of rules about what you can or cannot say or do (and you can forget writing a script or even attempting to automate something that Facebook's developers do not want you automating).