Now calling it a "poor man's Smalltalk", well, you might have a point there.

and

But even the other thing you mention, operator overloading... that is absent for a reason, simply because software design works differently in ObjC. You don't really need it in the same way that you do with C++.

In other words, you don't even know Smalltalk, but speculate about the similarity between ObjC and Smalltalk. For your information, Smalltalk has operator overloading (in the form of the unary and binary selectors) and uses it in the implementation for numbers. It works a bit differently (all binary operators have same precedence, so 5 + 4 * 3 = 17, but 4 * 3 + 5 = 32, I hope I didn't mix up the sequence, I am rather sure that binary selectors evaluated right to left), but it definitely has them. Also the big plus (and minus) for Smalltalk always was the integrated environment, you can literally change anything, if you want for example the compiler on the fly. It is similar to Lisp in that regard (though I think Lisp does it more elegantly). ObjC is a very, very distant cousin, basically only inheriting the compound selectors. And as I just found out, ObjC finally has inherited the BlockContexts, after only 20 years (or 30, I couldn't find out when they made it into ObjC exactly, Smalltalk had them fixed at least since 1980) that are a central part of Smalltalk. In Smalltalk there never was any kind of selection or looping statements, they were implemented as methods on objects taking blocks. E.g.:

|i| i := 0. i = 1 ifTrue: [^'It is 1'| ifFalse: [^'It is not 1'].

That defines a local variable i, assigns 0 to it and then tests if it is 1 and executes the first block returning a string if it is, else it returns the result of second block.

In any case, as I said in the end of my first post, I don't get into the merit of the theory. I just question why the "specialists" always seem to analyze the question from unrelated perspectives such as "if you change your password every two months, then the maximum time an attacker will have to use the password (as in the attacker already has it from day 0) is 2 months" instead of "the maximum time an attacker will have to discover and use the password is 2 months".

Simple, there is not only brute force to get a password. E.g. if the password hash is leaked and there is a matching rainbow table a password for your hash is known immediately (you also forgot, that hash functions are not 1:1 mappings, multiple passwords map to the same hash). Similar if the password is captured by a trojan or by a video camera. That is probably the most likely attack vector, brute forcing is very expensive.

So there are situations, where the password is known from the start. Also your analysis is flawed, you assume an attacker to systematically check all sequences of allowed characters. If you check, you will see, that the programs trying to crack passwords try a dictionary attack and do permutations on the dictionary as most people are not able to memorize a long random string of characters.

Your analysis has a second flaw, you assume interest in exactly your password. In most cases that is unlikely, an attacker of a business will try to get hold of one password to get into the system and then try to elevate the privileges, so any password will do, therefor you would go after the weakest, not the strongest.

So you say a law making it illegal to capture, store and distribute personal data is bogus? Because that is the German version of the law you just attacked. You know, that law also makes it illegal to scrape websites and build a database of mail-addresses to spam. It makes it illegal for merchants to collect data from their customers and sell it behind their back. It makes it illegal to combine data from multiple sources to create a profile. It even is forcing some of the data collection companies to open their data and gives everybody the right to see, what they have collected (those companies have an exception and create something similar to the US credit scores), something they wouldn't have to do otherwise. The law makes sense because it doesn't try to narrowly define for each case what is allowed and what not, instead it defined some simple principles and tries to protect the privacy of citizens.

Default assignment operator: All you need to do is add a pointer to your class and suddenly code that you don't see causes a bug. Yes, IF you know about this you can work around it. That's true of anything.

First, why is it causing a bug? Because you used a pointer to mean ownership and deallocate the object behind it in the destructor? If the class in question is not managing the object behind the pointer the default assignment operator is correct. But yes, that is one of the things you have to learn about C++. But how is that different from C? If I add a pointer to a struct and make a copy of that struct somewhere in the code I have exactly the same issue.

The use of << and >> was in my eyes just a poor choice. It would have been possible to use ".print(...)" in exactly the same form, so writing stream.print(3).print(" something"). I consider it an abuse and honestly I need way too few of them to make saving the few keystrokes worth the strange look. Is anybody really using a significant amount of those operators so that the few keystrokes are important?

References: references aren't what most people think of as references. They are pointers with syntactic sugar. Try getting a reference to an element of a vector, and then doing something that causes the vector storage to be reallocation. Voila, you have a "reference" that refers to junk.

Can you back your claim of "most people"? In a language without garbage collection you cannot have fixed references to value types. It would be way too costly to implement, if you need it you have to store pointers in your vector and pass those pointers. References are not 'pointers with syntactic sugar' as they are much more limited, e.g. there is no NULL-reference and currently a reference can only be bound to an lvalue and not to an rvalue. Even with the addition of rvalue references and reference collapsing in the coming standard you have to explicitly request a rvalue reference. Also references explicitly show, that the called function will not do any thing like release the object, something you can't be sure of a function taking a pointer.

How about we date the painting

I don't think it is easy, if even possible. Don't forget it was scribbled on a sheet of rock. The sheet was created by natural processes, so no use to date it. The ocher also is a mixture of natural material (clay and iron oxide) and I don't think there is a way to date its use either. So only some kind of adhesive to get the paint to stick to the rock might contain carbon which could be dated. But the amount is probably very small and can be contaminated (the paintings were exposed to the surrounding for an very long time). So it seems useful to use any clue you can get to help in dating the drawings.

The parents assertion is wrong. It is not illegal to take the photos, it is the publishing of photos without consent that is illegal. There are some exceptions, e.g. it is allowed if the person being photographed is only "decoration" (there is no hard rule, but taking a photo of a street scene shouldn't be a problem, as long as a single person is not the subject) or some kind of public figure.

Oh, I'm not disputing that Google keeps admitting to having harvested way more than they ought to have. I just don't see how giving the information to the government makes things better.

Easy, how can we be sure, that Google captured the data accidentally? How can we be sure, that they really only captures some fragments which are basically noise. They lied to the German government twice now. And had to admit to having collected way more data than previously admitted. Don't forget, they have been doing that for 3 years now and only now, that the German government actually started to take a look at what is happening we get the information, what has been going on. And not being from the US I actually trust my government more than a company which has a "strained" relationship with privacy.

I don't actually know what the remedy should be here, but showing that data to even more people isn't in keeping with the privacy laws either.

Actually it is, as the person asking for it has exactly the job of making sure, that companies respect the privacy laws. Their power is very limited (just look at the puny fee he can hand out).

And, if any of that data should end up on US soil, the US laws on their access to data collected by US companies would mean the US government could subpoena this and force Google to not tell anyone.

Actually the four hard discs containing the data seem to be in or near San Francisco (I guess, that they are actually in Mountain View). From the NYT article linked:

In a blog posting late Monday, Alan Eustace, a Google senior vice president for engineering and research, wrote that a San Francisco company, Isec Partners, had overseen destruction of the Irish data.

In his blog Mr. Eustace included a link to a report from Alex Stamos, the Isec Partners employee who witnessed destruction of the Irish data from the larger batch of WLAN data improperly collected around the world.

In his letter to Google, Mr. Stamos described the WLAN data in question as being contained on four hard drives, organized by individual country. Mr. Stamos said he created volumes on two new encrypted hard drives and copied over all of the data except for Ireland. The original four hard drives were then destroyed, Mr. Stamos wrote.

I mean, it boils down to "you have collected something which is illegal and invasive to have ... why don't you give it to us and we'll, er, keep it safe."

No, it boils down to "you have told us you take photos from public places of houses, then you have to admit, that you also collect MAC-addresses and SSIDs (which you 'forgot' to mention when we talked about it) and then just two weeks later you tell us, 'whoops, we also collected some mails and some web sessions, sorry' and now we want to see, what you have collected, as we don't see any more reason to trust you".

And in case you wonder, it is possible that Google broke the privacy laws, which in Germany also apply to unencrypted communication and might be liable. Courts here have ruled, that the Apache logfile also violates privacy, as it is not legal to gather privacy related data on people without their consent and without a specific reason justified by legal provisions or necessary to do your business. You also have to delete the data when it is no longer needed.

In any case, should Google actually have broken the law, then the charge for it would 2 to 5 years, but it is not entirely clear, if the law applies, because you have to prove intent and who knows how long this could drag on.

I have an idea, if you have a small child, don't let them wonder alone in the mountains. I know, responsibility isn't really "hip" these days, but seriously it isn't hard. Cougars aren't really interested in people as food most of the time, and they REALLY aren't interested if there is a full sized adult around. Further, if you live where there are wild cats, you should make sure they have enough food. My grandparents feed the bobcats in their area so that they won't eat the house cats and dogs. They specifically keep chickens on the property for this purpose. It works great, considerably better than trapping, and it doesn't cost much to keep chickens when half your neighbors are farmers.

They hope to save in the future. As a lot of the costs are consolidating their terrible IT landscape it is not clear, what a migration to the latest MS offering would have costs, either. It is not as if it would have been free either, who knows how many of the macros would have broken down when run in a current version of Excel, who knows how many old programs might stop working on Vista (and be it due to a stupid installer). It would have been cheaper, at least probably because a lot would have still worked, but when they write that they found 21 different Windows setups with differing patch levels and security settings, I am not so sure if it really would have been cheaper.

What they probably hope is, that the next migration will be cheaper, the OSS they use won't cost them to upgrade, the costs of the upgrade in work to be done by their IT department are probably not very different when upgrading a Linux solution from a MS solution. But all the work to get their systems closer to a common base might actually make the next big roll out simpler and therefor cheaper.

Sorry, but that argument is bogus. If we assume, that the format of the container does not change mid stream, then I need one page header to configure the decoder and all following packets will only be checked to make sure we are still at the same version. The cost difference is minimal. And as long as no new format is out (like currently) you won't have any cost at all. If that cost is even of any significance, I would be surprised if it would be measurable as the time difference is tiny compared with the time it takes to decompress audio/video and all that is necessary to make it audible/visible.

You misunderstood my argument. I don't mean to have two headers, one saying "use the last version you found in the stream" and one which defines the version. Instead I mean to say, that if the bit is 0 it says it is the first version of the file format. Currently there is no other version. If another version of the format is introduced the bit is set to 1 and meaning a decoder which doesn't support the new version will know, that it is pointless to try, as it won't be able to understand the format (because if it was compatible, where was the point to change it?).

But a newer version of the decoder can see, that it is not the first version and knows, that in the new version of the format, a field with the exact version (2, 3, 4, ...) can be found in a different location. It could again only be a single bit, but that would probably be a big problem, as with every version you need to look in more places, but you could add it immediately after the first bit giving you 10 (in binary) as the version identifier. Obviously that scheme gets expensive if many versions are needed, but as time has shown until now no new version was needed, so it is something happen rarely.

But you will still get the full version info in every packet, streaming is the same as now. You won't loose anything if you use only one bit, as it only serves as marker to define, that if is the first version of the file format or a later version.

in order to write individual 1/0, after all they had a solution that worked 40-50 years ago.

Sorry, but that is simply not true. Not even with MFM you could control the exact layout of 0 and 1. A 1 is signaled by a level change, the zero just keeps the last level. There are limits on how long you can go on without a level change (the level change is used to synchronize the clock). So even that stone old technology wouldn't work in the specified way, after a certain "number" (rather length depending on the clock of the system) of one kind of magnetic domain a change has to occur. And as long as the system doesn't have an alternate system to get the clock information, you will always run into the same issue. You could perhaps use one platter as "clock platter", but if that would work with the heads, I have no clue. In the past I doubt anybody would have used something like that as it wastes a lot of space.

It is not in the header, the 8-bit version field is in every single page. As according to the post a page is mostly 64K due to a strange length encoding, you send the version very, very often. I don't see any reason, why the version would have to change in the middle of a file in any case. And honestly, would you write a decoder taking that into account, if the probability of stumbling onto such a file was currently 0 (due to there being only one version) and very, very low in the future? That means it just adds to the size of the file.

The second reason is even simpler, you only need one bit to tell the current format from the future formats. As there hopefully will be a good reason for a future version the page header will probably be different, so I can add a version field there when I at least found one reason why I need it, no? That way I need one bit now and can still have different versions later.

I wrote a story once where this was done (here. I kind of got tired of so many SF stories and movies solving traumatic injury with some sort of magical "healing tank" (maybe with effortless "nanobots") that I wondered to myself what sort of effort would really be needed to put someone together from just a bunch of pieces.

The closest similar stories I found were the beginning of "Neon", by Harlan Ellison in 1973, and an early chapter of "Count Zero" by William Gibson.