Sure. Another commenter said as much, and I agree.
It's just a fairly narrow use case, IMHO, where the word applies. And it's basically devoid of information. It's the equivalent to your computer saying "you can't access that file".
What does the computer mean? Read? Write? Execute? What roles or permissions do I need to access it? The moment the file is relevant to me, "can't access" is beyond useless.
Let me pose the question differently: when your computer doesn't let you do something "for security reasons", and you need to do it for your job, what do you do?
Do you say "oh well" and watch porn? Or do find out what access rights you need to do your job? Bonus question: what if it's watching porn that's not possible?
What do you call classified information that you and the person you speak to both have access to?
You're not wrong. That doesn't make the usage much better, though.
Other than "unclassified" is part of the point. Information has to undergo the classification process (is classified) before it can be known that it's unclassified information, ironically. While the article clearly states that "unclassified" is not strictly speaking a classification level, information still has to be classified as "unclassified" in order to be shared.
The other part of the point is that once information is "classified", it really, really, really becomes important what its classification level is. Without that, you can't know who can access it. So "classified" on it's own is practically a useless term outside of this one scenario here of somebody talking to the press.
"Couldn't Google just switch to Qt, which is becoming an industry standard?"
It is? I haven't seen evidence of that. Trolltech/Digia have been working on that for a long time, and have in fact gained significant market share, but I don't see many projects outside of the KDE sphere of influence or very specific embedded platforms adopting Qt. In fact, the popularity of entirely new mobile platforms that did not adopt Qt is a great counter-argument (i.e. iOS, Android, ChromeOS).
Mind you, that's no argument against using Qt - I just don't see evidence of it becoming an industry standard.
The mathematics are sound enough, but that doesn't make BitCoin sound.
After the MtGox situation, I tried to understand what exactly the transaction malleability problem they're blaming is. The best (?) starting point I've found is https://en.bitcoin.it/wiki/Tra..., but while that gives you a high level overview, it also raises more questions. Why are there three distinct issues with BitCoin that share the same name? Why did the BitCoin designers ever think it's a good idea to take a signature over part of a message as verifying the entire message?
Mostly, though, I asked myself what it was they were signing and for what purpose, before going on to the previously stated questions. Several hours later, and I concluded that BitCoin is the single worst documented software system I've seen in a 15 year software engineering career.
Yes, I managed to get the information I wanted. No, it wasn't straightforward. Documentation is distributed amongst this wiki, forum posts (which are then badly copy & pasted into the wiki) and source code. Oh, and external sites like reddit or stackexchange. The wiki is very badly cross-linked, and the terrible naming choices (see above) mean it's not easy to search. Some vital information is effectively hidden from sight in image files, which wikis currently don't tend to index at all. And that's just about the stuff I was interested in at the time.
You should never trust a crypto system whose authors can't explain it cohesively and concisely.
If nothing else, it makes a security audit a nightmare.
That said, of course the BitCoin devs aren't stupid, and they plugged the holes documented in the transaction malleability page as best they could. The wiki still states they exist, incidentally, and since it's the de-facto documentation on BitCoin, it's IMHO fair enough to conclude that the BitCoin specifications are still broken even if the reference implementation is fixed.
None of which should mean that BitCoin itself did worse that MtGox - the latter certainly screwed up royally, and their screwup doesn't mean BitCoin is doomed.
But nothing I've seen of BitCoin so far goes to convince me it's trustworthy.
... that all the work other programmers do in the IDE, I do by hand whilst my mind solves the next problem.
So far I haven't encountered an IDE that lets me habituate these tasks as easily as my plain old text editor does. That means no IDE so far lets me parallelize my efforts in the same way as my text editor. Though I would be the first to admit that habituation is also - but not exclusively - a question of how long one tries.
It's not that IDEs are bad, it's that in my experience they're in the way of my being effective. In part, it's because they rely on the use of a gesture device so heavily - anything that lets me use the keyboard tends to be better for me. Insert obligatory personal/anecdotal evidence warning here.
I think there is an argument to be made that IDEs with fairly complex UIs will resist habituation, and many IDEs fall into that trap. Whether or not that's true should be examined carefully rather than debated aimlessly, though - and even if it's found to be true, then an entirely different question would be whether better habituation *generally* leads people to parallelize tasks, as I described above.
... is considered to be rough at around 150dpi, ok at around 300dpi, good at around 600dpi, and anything at 1200dpi or higher is considered very fine print and is usually reserved for art prints, etc.
Of course, print dots and pixels aren't exactly the same, but comparison is hard - mostly because print dots are not as clearly part of a grid system as pixels are. Comparing print dots and subpixels would make more sense, but is even harder.
So assuming that pixels and print dots are equivalent 3200X1800 on a 13" 16:9 screen would mean the screen has something like a sqrt(3200*3200 + 1800*1800)/13 = 282ppi resolution (simplified maths).
So we're just about moving from "rough" into "ok" territory, by some 30+ year old standards. To me, that's not "good enough", but YMMV.
... is exactly what Mark Shuttleworth has been doing for almost a decade now. If that amount of effort hasn't helped the Ubuntu team initiate some drastic changes in otherwise community-run projects, then I very much understand why he's fed up and wants things to Just Work (TM).
This is irrespective of who did what, and whether they did the right thing, by the way. There's always multiple people at fault in any conflict. I'm talking purely about the desire to stop wasting time and money on something for which there is overwhelming evidence it doesn't work. If I had been in his position, I would have started my own Ubuntu-run competitor projects a lot earlier, but then I'm not a patient man.
The TL;DR version is the rather less spectacular "The problem with diets that are heavy in meat, fat or sugar is not solely that they pack a lot of calories into food; it is that they alter the biochemistry of fat storage and fat expenditure, tilting the body’s system in favour of fat storage."
... I will post it again. This relates to the page views GoSquared measures, NOT to the entire internet.
GoSquared self-describes as "trusted by 30,000 businesses", which is not a small number, but also doesn't really compare to the number of businesses with websites out there. http://www.whois.sc/internet-statistics/ says there are about 150 mio domains (in the most popular gTLDs). Assuming domains is a decent measure for websites (which it isn't, but let's go with that for now), at best GoSquared measures 0.02% of the internet.
That means, we only know that 0.02% of 40% was affected, which is some 0.8% of the total internet.
But wait, we're talking page views, not websites. http://www.worldwidewebsize.com/ estimates 3.76 billion pages (indexed, not existing). If we assume those 3.76 billion pages are spread evenly across those 150 mio domains, we have some 25 pages per domain.
It now depends on the type of businesses GoSquared represents: are they SMEs (often with no more than 1-5 pages on their domain) or large businesses (often with hundreds of pages)? With 30,000 customers, my guess would be that they represent more SMEs than large businesses, meaning the total number of pages they represent is actually less than 30,000 x 25. Which also means the 0.8% percentage of total page views would drop even further.
Lastly, page views does not mean traffic. Traffic is mostly generated from streaming media these days, not pages.
All the numbers to be taken with a grain of salt, of course, but they still seem to be in a better range than the ones GoSquared published. Never trust statistics you didn't forge yourself.
Yes, Android is somewhat fragmented. No, that doesn't play much of a role here.
Android is no more fragmented than e.g. the Desktop, and provides better support for various screen sizes and aspect ratios than most other development environments.
The fragmentation of Android starts to matter once you want to support esoteric features, or use the latest APIs. For UI concerns, Google provides backwards compatibility libraries. For Audio/Video processing, Android's APIs haven't changed since about version 1.5. For what I can see in this case, it shouldn't matter much at all.
None of which means that supporting all these different device configurations is going to be *fast*, and time does have a cost. Development-wise, though, you can reduce the cost best by considering the different screen sizes right from the start. One sadly common mistake I see people repeat over and over is to design for one screen size first, and then try to adapt that design to different screen sizes or aspect ratios. If you go down that path, you're likely going to end up spending more than if you design with an adaptive layout in mind from the start.
"it took him only 30 days to build and launch a basic open source office" and "The suite was released as an alpha version" mean's he's got the 80 (visible) percent done that take 20 percent of the time.
I wish people wouldn't get headlines with this sort of claim. It helps push the entire profession towards cutting corner in order to under bid each other, which does not speak well for the quality of future software.
Speak instead of prototyping. That's much closer to the truth.
... time. And it is a good argument in many cases. Code reviews are great, but they make sense only if you provide good feedback from your review, and the original author has time to revisit their code and make changes according to the feedback. I've seen many work environments were such things were considered too expensive (in terms of time).
I mean, he ends up at reading the subject of every email (check), and scanning through his spam to see if there are false positives (check). My ham volume is about as large as his, and my spam volume is significantly lower (ca. 30%) because I've got a good spam filter.
And how does it relate to the topic that people have faith in some things, but take a scientific approach to trying to understand others? The two are not mutually exclusive. It's not even mutually exclusive that they apply both approaches to the same thing at different times.
Trying to understand science in relation to individual faith is non-sensical; science works at the scope of humanity as a whole. Many individuals being able to double-check many other individual's claims, not one individual proving their own.
Science is not about what individuals believe; it's about what the species as a whole knows. The scopes of faith and science are different; comparing them in this manner is non-sensical.
Let's make it simple why: Science is not what scientific disciplines have found out. Science is a set of methods to further human knowledge.
To confuse the two is to misunderstand science so thoroughly that it pains me.
More precisely, science is a set of tools to guard against our individual fallacies (such as blind faith) contaminating the species' body of knowledge, by enabling each and every person to apply these tools and validate or disprove every piece of knowledge in existence. In other words, it doesn't bloody matter if you, the individual, believe in the tooth fairy when you can prove P != NP. Nor does it matter when you, the individual, don't even know what there is to prove, what the problem is. What matters is that someone else can verify or disprove either your proof of P != NP, or your belief in the tooth fairy. Or both.
To be fair, it's terrifying how people will take on an "expert's opinion" on blind faith. The answer to that problem, though, is to teach scientific process, so that people can make better choices in what to believe. The answer most certainly is not to suggest that science is little more than faith in a different set of beliefs.
Apologies accepted, and my apologies to you. In my experience, trolls wouldn't reply to to this sort of bait, I must have been wrong.
I don't know what sort of point I was supposed to have missed, really, given that I started this sub-thread with an example; if anything - and yes, I'm nitpicking now - everyone else in this sub-thread is missing my point, pretty much by definition.
So let's get back to the point I was trying to make: efficient techniques for parallel programming are all about how you subdivide your data. This is completely language-independent. For a totally high-level approach to subdividing data (mostly) efficiently, look to MapReduce.
What you would do with MapReduce in a simple case on a single multi-core machine would be to divide your data set into N segments, where N is the number of threads you want to run in parallel. Take MapReduce to the level of networked machines, and the concept remains the same, except that you've got M machines to each process a chunk of the overall data (and maybe in addition, on each machine, you further subdivide the data into N segments).
The problem with talking about MapReduce in this context is that at this high level of abstraction, you might as well use OOP, too. It's a good example for illustrating the data partitioning problems that exist around writing parallel code, but not a good example for how OOP might stand in the way of efficient parallel execution.
I figured the best example would be one that takes the subdivision problem to the lowest level, which invariably means breaking down the problem to how efficiently a CPU's cache protocol handles data, based on how it's subdivided in memory. Using C++-ish code as an example made sense, as C++ is a language where you *can* influence the data layout, and where you *can* lay out data in a fashion that's typical to OOP.
As far as I am concerned, OOP is inherently great at a number of things, and at first glance none of them impact parallelism in any way. All of these things - encapsulation, access control, inheritance, etc. - have a side-effect, though, because the very concept requires you to lump data together that's conceptually related, whether or not it's used together (You might feel like rephrasing that as "the very concept IS to lump data together", but that would ignore some OOP features). In that sense, OOP is inherently about preferring some data layout in memory over another, whether you think about it in that way or not.
The downside of this data layout is that it makes it harder to split one set of relevant data off from another, that is, it makes *efficient* subdivision more difficult. Whether or not that's the case of course depends on the problem you're trying to solve; the assumption must be that you want to solve a problem involving one subset of your objects' data members in parallel to another problem involving a disjoint subset of data members.
You're arguing that whether or not data is, in fact, laid out in memory in a "bad" way is dependent on the language or compiler. To the degree where we're speaking about C or C++, that's just not the case - but of course clever enough compilers for other OOP languages might exist. This is something I doubt, though I would love to be proven wrong, with code to read. The reason I doubt it is primarily because it's pretty damn hard without marking your data as "please parallelize", which none of the programming languages I know/use provide a (portable, standardized) mechanism for. Never mind whether they're OOP. Someone mentioned Haskell here; I don't know the language well enough to know whether or not such a mechanism exists.
Look elsewhere in the comments, there's a longer thread where I've commented:)
I'm neither opposed nor in favour of dropping OOP, personally. As far as I am concerned, a good CS graduate must know OOP. A good software engineer must know OOP. But whether or not they *start* with OOP is an entirely different question... because to be good, they also must know a lot of other stuff, which will include other programming paradigms.
What's dumb to me is to drop OOP completely. The principles of OOP can be taught to someone who understands programming in a matter of a few lessons. They won't come out of that being *good* at OOD/OOP, but they'll understand what it is. You can build on that in a sophomore course, much like CMU suggests.
Besides, the "being good" part happens after formal education anyway...
Slashdot Mirror
No, I'm not kidding.
Sure. Another commenter said as much, and I agree.
It's just a fairly narrow use case, IMHO, where the word applies. And it's basically devoid of information. It's the equivalent to your computer saying "you can't access that file".
What does the computer mean? Read? Write? Execute? What roles or permissions do I need to access it? The moment the file is relevant to me, "can't access" is beyond useless.
I should have just written: "classified" and posted http://i0.kym-cdn.com/entries/...
So many things are correct, and yet useless.
Let me pose the question differently: when your computer doesn't let you do something "for security reasons", and you need to do it for your job, what do you do?
Do you say "oh well" and watch porn? Or do find out what access rights you need to do your job? Bonus question: what if it's watching porn that's not possible?
What do you call classified information that you and the person you speak to both have access to?
Why do people read everything in absolutes? Nobody claimed it was made up.
Not disclosing classification level is actually a good use case. I hadn't encountered that.
I'm not encountering the term much, period. It's usually a classification level or another short hand, most often "can't share". YMMV.
You're not wrong. That doesn't make the usage much better, though.
Other than "unclassified" is part of the point. Information has to undergo the classification process (is classified) before it can be known that it's unclassified information, ironically. While the article clearly states that "unclassified" is not strictly speaking a classification level, information still has to be classified as "unclassified" in order to be shared.
The other part of the point is that once information is "classified", it really, really, really becomes important what its classification level is. Without that, you can't know who can access it. So "classified" on it's own is practically a useless term outside of this one scenario here of somebody talking to the press.
Still, it exists as a trope: http://tvtropes.org/pmwiki/pmw...
... how life imitates art?
"Classified" does not mean secret. It merely means that it got assigned a classification level. https://en.wikipedia.org/wiki/...
But films in particular seem to find it using "classified" instead of the actual classification level much cooler. And now people use it for real.
"Couldn't Google just switch to Qt, which is becoming an industry standard?"
It is? I haven't seen evidence of that. Trolltech/Digia have been working on that for a long time, and have in fact gained significant market share, but I don't see many projects outside of the KDE sphere of influence or very specific embedded platforms adopting Qt. In fact, the popularity of entirely new mobile platforms that did not adopt Qt is a great counter-argument (i.e. iOS, Android, ChromeOS).
Mind you, that's no argument against using Qt - I just don't see evidence of it becoming an industry standard.
The mathematics are sound enough, but that doesn't make BitCoin sound.
After the MtGox situation, I tried to understand what exactly the transaction malleability problem they're blaming is. The best (?) starting point I've found is https://en.bitcoin.it/wiki/Tra..., but while that gives you a high level overview, it also raises more questions. Why are there three distinct issues with BitCoin that share the same name? Why did the BitCoin designers ever think it's a good idea to take a signature over part of a message as verifying the entire message?
Mostly, though, I asked myself what it was they were signing and for what purpose, before going on to the previously stated questions. Several hours later, and I concluded that BitCoin is the single worst documented software system I've seen in a 15 year software engineering career.
Yes, I managed to get the information I wanted. No, it wasn't straightforward. Documentation is distributed amongst this wiki, forum posts (which are then badly copy & pasted into the wiki) and source code. Oh, and external sites like reddit or stackexchange. The wiki is very badly cross-linked, and the terrible naming choices (see above) mean it's not easy to search. Some vital information is effectively hidden from sight in image files, which wikis currently don't tend to index at all. And that's just about the stuff I was interested in at the time.
You should never trust a crypto system whose authors can't explain it cohesively and concisely.
If nothing else, it makes a security audit a nightmare.
That said, of course the BitCoin devs aren't stupid, and they plugged the holes documented in the transaction malleability page as best they could. The wiki still states they exist, incidentally, and since it's the de-facto documentation on BitCoin, it's IMHO fair enough to conclude that the BitCoin specifications are still broken even if the reference implementation is fixed.
None of which should mean that BitCoin itself did worse that MtGox - the latter certainly screwed up royally, and their screwup doesn't mean BitCoin is doomed.
But nothing I've seen of BitCoin so far goes to convince me it's trustworthy.
... that all the work other programmers do in the IDE, I do by hand whilst my mind solves the next problem.
So far I haven't encountered an IDE that lets me habituate these tasks as easily as my plain old text editor does. That means no IDE so far lets me parallelize my efforts in the same way as my text editor. Though I would be the first to admit that habituation is also - but not exclusively - a question of how long one tries.
It's not that IDEs are bad, it's that in my experience they're in the way of my being effective. In part, it's because they rely on the use of a gesture device so heavily - anything that lets me use the keyboard tends to be better for me. Insert obligatory personal/anecdotal evidence warning here.
I think there is an argument to be made that IDEs with fairly complex UIs will resist habituation, and many IDEs fall into that trap. Whether or not that's true should be examined carefully rather than debated aimlessly, though - and even if it's found to be true, then an entirely different question would be whether better habituation *generally* leads people to parallelize tasks, as I described above.
... is considered to be rough at around 150dpi, ok at around 300dpi, good at around 600dpi, and anything at 1200dpi or higher is considered very fine print and is usually reserved for art prints, etc.
Of course, print dots and pixels aren't exactly the same, but comparison is hard - mostly because print dots are not as clearly part of a grid system as pixels are. Comparing print dots and subpixels would make more sense, but is even harder.
So assuming that pixels and print dots are equivalent 3200X1800 on a 13" 16:9 screen would mean the screen has something like a sqrt(3200*3200 + 1800*1800)/13 = 282ppi resolution (simplified maths).
So we're just about moving from "rough" into "ok" territory, by some 30+ year old standards. To me, that's not "good enough", but YMMV.
... is exactly what Mark Shuttleworth has been doing for almost a decade now. If that amount of effort hasn't helped the Ubuntu team initiate some drastic changes in otherwise community-run projects, then I very much understand why he's fed up and wants things to Just Work (TM).
This is irrespective of who did what, and whether they did the right thing, by the way. There's always multiple people at fault in any conflict. I'm talking purely about the desire to stop wasting time and money on something for which there is overwhelming evidence it doesn't work. If I had been in his position, I would have started my own Ubuntu-run competitor projects a lot earlier, but then I'm not a patient man.
So more power to him, I say.
The TL;DR version is the rather less spectacular "The problem with diets that are heavy in meat, fat or sugar is not solely that they pack a lot of calories into food; it is that they alter the biochemistry of fat storage and fat expenditure, tilting the body’s system in favour of fat storage."
Yes, we've known that for a while.
... I will post it again. This relates to the page views GoSquared measures, NOT to the entire internet.
GoSquared self-describes as "trusted by 30,000 businesses", which is not a small number, but also doesn't really compare to the number of businesses with websites out there. http://www.whois.sc/internet-statistics/ says there are about 150 mio domains (in the most popular gTLDs). Assuming domains is a decent measure for websites (which it isn't, but let's go with that for now), at best GoSquared measures 0.02% of the internet.
That means, we only know that 0.02% of 40% was affected, which is some 0.8% of the total internet.
But wait, we're talking page views, not websites. http://www.worldwidewebsize.com/ estimates 3.76 billion pages (indexed, not existing). If we assume those 3.76 billion pages are spread evenly across those 150 mio domains, we have some 25 pages per domain.
It now depends on the type of businesses GoSquared represents: are they SMEs (often with no more than 1-5 pages on their domain) or large businesses (often with hundreds of pages)? With 30,000 customers, my guess would be that they represent more SMEs than large businesses, meaning the total number of pages they represent is actually less than 30,000 x 25. Which also means the 0.8% percentage of total page views would drop even further.
Lastly, page views does not mean traffic. Traffic is mostly generated from streaming media these days, not pages.
All the numbers to be taken with a grain of salt, of course, but they still seem to be in a better range than the ones GoSquared published. Never trust statistics you didn't forge yourself.
I notice that I subvocalize my thoughts about what to type next while I'm currently typing. If I have to speak, I can't do that.
Clearly if I had a bad case of RSI like he did, I would give it a shot. Better slow than nothing, right? But right now, I'm quite happy with typing.
Yes, Android is somewhat fragmented. No, that doesn't play much of a role here.
Android is no more fragmented than e.g. the Desktop, and provides better support for various screen sizes and aspect ratios than most other development environments.
The fragmentation of Android starts to matter once you want to support esoteric features, or use the latest APIs. For UI concerns, Google provides backwards compatibility libraries. For Audio/Video processing, Android's APIs haven't changed since about version 1.5. For what I can see in this case, it shouldn't matter much at all.
None of which means that supporting all these different device configurations is going to be *fast*, and time does have a cost. Development-wise, though, you can reduce the cost best by considering the different screen sizes right from the start. One sadly common mistake I see people repeat over and over is to design for one screen size first, and then try to adapt that design to different screen sizes or aspect ratios. If you go down that path, you're likely going to end up spending more than if you design with an adaptive layout in mind from the start.
If you need help with that, let me know :)
"it took him only 30 days to build and launch a basic open source office" and "The suite was released as an alpha version" mean's he's got the 80 (visible) percent done that take 20 percent of the time.
http://en.wikipedia.org/wiki/Pareto_principle
I wish people wouldn't get headlines with this sort of claim. It helps push the entire profession towards cutting corner in order to under bid each other, which does not speak well for the quality of future software.
Speak instead of prototyping. That's much closer to the truth.
You're making the (IMO fallacious) assumption that morality can only be attained through moral teachings.
... time. And it is a good argument in many cases. Code reviews are great, but they make sense only if you provide good feedback from your review, and the original author has time to revisit their code and make changes according to the feedback. I've seen many work environments were such things were considered too expensive (in terms of time).
I mean, he ends up at reading the subject of every email (check), and scanning through his spam to see if there are false positives (check). My ham volume is about as large as his, and my spam volume is significantly lower (ca. 30%) because I've got a good spam filter.
I don't see what the big deal is.
And how does it relate to the topic that people have faith in some things, but take a scientific approach to trying to understand others? The two are not mutually exclusive. It's not even mutually exclusive that they apply both approaches to the same thing at different times.
Trying to understand science in relation to individual faith is non-sensical; science works at the scope of humanity as a whole. Many individuals being able to double-check many other individual's claims, not one individual proving their own.
Science is not about what individuals believe; it's about what the species as a whole knows. The scopes of faith and science are different; comparing them in this manner is non-sensical.
Let's make it simple why: Science is not what scientific disciplines have found out. Science is a set of methods to further human knowledge.
To confuse the two is to misunderstand science so thoroughly that it pains me.
More precisely, science is a set of tools to guard against our individual fallacies (such as blind faith) contaminating the species' body of knowledge, by enabling each and every person to apply these tools and validate or disprove every piece of knowledge in existence. In other words, it doesn't bloody matter if you, the individual, believe in the tooth fairy when you can prove P != NP. Nor does it matter when you, the individual, don't even know what there is to prove, what the problem is. What matters is that someone else can verify or disprove either your proof of P != NP, or your belief in the tooth fairy. Or both.
To be fair, it's terrifying how people will take on an "expert's opinion" on blind faith. The answer to that problem, though, is to teach scientific process, so that people can make better choices in what to believe. The answer most certainly is not to suggest that science is little more than faith in a different set of beliefs.
Apologies accepted, and my apologies to you. In my experience, trolls wouldn't reply to to this sort of bait, I must have been wrong.
I don't know what sort of point I was supposed to have missed, really, given that I started this sub-thread with an example; if anything - and yes, I'm nitpicking now - everyone else in this sub-thread is missing my point, pretty much by definition.
So let's get back to the point I was trying to make: efficient techniques for parallel programming are all about how you subdivide your data. This is completely language-independent. For a totally high-level approach to subdividing data (mostly) efficiently, look to MapReduce.
What you would do with MapReduce in a simple case on a single multi-core machine would be to divide your data set into N segments, where N is the number of threads you want to run in parallel. Take MapReduce to the level of networked machines, and the concept remains the same, except that you've got M machines to each process a chunk of the overall data (and maybe in addition, on each machine, you further subdivide the data into N segments).
The problem with talking about MapReduce in this context is that at this high level of abstraction, you might as well use OOP, too. It's a good example for illustrating the data partitioning problems that exist around writing parallel code, but not a good example for how OOP might stand in the way of efficient parallel execution.
I figured the best example would be one that takes the subdivision problem to the lowest level, which invariably means breaking down the problem to how efficiently a CPU's cache protocol handles data, based on how it's subdivided in memory. Using C++-ish code as an example made sense, as C++ is a language where you *can* influence the data layout, and where you *can* lay out data in a fashion that's typical to OOP.
As far as I am concerned, OOP is inherently great at a number of things, and at first glance none of them impact parallelism in any way. All of these things - encapsulation, access control, inheritance, etc. - have a side-effect, though, because the very concept requires you to lump data together that's conceptually related, whether or not it's used together (You might feel like rephrasing that as "the very concept IS to lump data together", but that would ignore some OOP features). In that sense, OOP is inherently about preferring some data layout in memory over another, whether you think about it in that way or not.
The downside of this data layout is that it makes it harder to split one set of relevant data off from another, that is, it makes *efficient* subdivision more difficult. Whether or not that's the case of course depends on the problem you're trying to solve; the assumption must be that you want to solve a problem involving one subset of your objects' data members in parallel to another problem involving a disjoint subset of data members.
You're arguing that whether or not data is, in fact, laid out in memory in a "bad" way is dependent on the language or compiler. To the degree where we're speaking about C or C++, that's just not the case - but of course clever enough compilers for other OOP languages might exist. This is something I doubt, though I would love to be proven wrong, with code to read. The reason I doubt it is primarily because it's pretty damn hard without marking your data as "please parallelize", which none of the programming languages I know/use provide a (portable, standardized) mechanism for. Never mind whether they're OOP. Someone mentioned Haskell here; I don't know the language well enough to know whether or not such a mechanism exists.
Does this explain things better?
Look elsewhere in the comments, there's a longer thread where I've commented :)
I'm neither opposed nor in favour of dropping OOP, personally. As far as I am concerned, a good CS graduate must know OOP. A good software engineer must know OOP. But whether or not they *start* with OOP is an entirely different question... because to be good, they also must know a lot of other stuff, which will include other programming paradigms.
What's dumb to me is to drop OOP completely. The principles of OOP can be taught to someone who understands programming in a matter of a few lessons. They won't come out of that being *good* at OOD/OOP, but they'll understand what it is. You can build on that in a sophomore course, much like CMU suggests.
Besides, the "being good" part happens after formal education anyway...