I'm not aware of any static analysis that can factor in unit tests (as this work does) to decide what does and what does not make a suitable patch. Note that these patches are about dynamic semantics, not just about name or type analysis failures (which might indeed be easy to fix purely by using static analysis).

The reason for not attaching his name (or the name of the students working on the project) is to minimise bias. A patch coming in from a widely-published and highly experienced formerly-INRIA-now-KTH researcher might be viewed very differently than a patch coming in from a noob.

The reason for `not just checking the patches themselves' is again to reduce bias, though you'll note that they did a manual sanity check every time before they submitted the patch. That is, they only submitted patches that they hoped wouldn't waste the devleopers' time after submission. Evaluating purely by manual validation means that the judgment of whether the result is useful relies purely on the honesty of the researcher, since most publication venues don't leave enough space for researchers to submit source code (nor sufficient time for the reviewers to analyse the source code and patches in detail, unless it's all pretty small and can be squeezed in with the rest of what one must describe in the typical 6-12 pages (double-column) or up-to-25 pages (single-column).

See, I've heard this argument many times, but I've never been able to wrap my head around it. If you tell me that a social system (such as a system of government) has trouble scaling from 1 to 10 people, or from 10 to 100, or from 100 to 1000, then yes, I can see that. If you tell me that it scales fine up to 1000, but has trouble scaling to 10,000, then that's a bit odd (unless we have time/storage constraints and superlinear factors, of course, but that's not really an issue here). My line of thinking is that if you can scale fine to 10 million, then why wouldn't you be able to scale to 400 million or however many people live in the US these days?

In other words, there must be other reasons, and `we could never do that in the US / in Germany / in France / in Japan' is not something that I'm willing to buy.

I haven't tested this link yet (hesitant to update my Skype for that very reason), but here's a list of DNS names that supposedly cover all that Skype uses for ad lookup:

https://gist.github.com/eyecat...

Now, Skype could circumvent such a mechanism (hard-code the IPs-- which could be circumvented with custom routing tables-- or inline the ads into the regular data stream, which would be very hard to circumvent, or just refuse to run if it can't access any ads (or `signed ads')), so even if it works now, it may not be forever. ...and now I'll shut up and stop giving Microsoft ideas...

From that perspective, you might as well argue that the market distortion here is that the government doesn't permit foreign workers to work in the US under the same conditions as US nationals, since that `unnaturally' restricts the job market (i.e., `national borders distort the job market').

OP pointed out that the situation is more similar to the French Revolution than to the Kristallnacht/disenfranchisement of Jews in 30s Germany. I agree with you that most of the tech workers are scape-goats (I have been part of this very group in the past, for the record), but I agree with OP that the situation is closer to that in the French revolution:

(a) The targetted group holds considerable power and is connected to an apparatus that is seen with approval and benevolence `all the way up'
(b) The targetted group lives in a `bubble' that separates its concerns from those of the `lower' classes
(c) Targetting is driven by public disapproval, rather than by governmental machinations (sort of a fall-out of (a)).

Now, are the Googlers etc. to blame for the situation? Most of them aren't of course, they're just innocent participants `in the system' and can't be blamed for not wanting to not participate. But I'm confident that most of the French aristocracy had little intent of stomping on the common man either-- they just didn't deal with them much. Didn't do their necks much good, in the end.

So yes. This looks way more French revolution, `to the barricades, comrades! We shall throw off our shackles, and then guilloutine everyone who was or might have been sympathetic to these oppressors!' than Nazi `you really want to be there tonight to throw stones at the Jews, dude, or the Gauleiter will want to have a word with you, and you do remember that you have a wife and kids to feed, right?' Reichskristallnacht.

Except modulo the guilloutines. Please.

By this metric Java is still kicking everyone's butts. Also... *all* programming languages are "dying".

I've been around the block enough times to know that if you want to survive as a programmer you had better damn well learn to program. And not in just one language, you need to know a survey of language types. Ruby is just one type in the same category as Python and Javascript. If you really want to survive 20 years as a programmer (like I did) you need to branch out more.

Now, you kids get off my lawn.

Based on his description, he is using a very synthetic benchmark:

The code I’m testing contains no #include directives, and makes use of only standard C++ code. It starts with one class, and then is followed by 6084 small classes derived from various instantiations of the template classes. (So these 6084 classes are technically not templates themselves.) Then I create 6084 instantiations of the original template class, using each of the 6084 classes. The end result is 6084 different template instantiations. Now, obviously in real life we wouldn’t write like that (at least I hope you don’t).

So in his own words, the code does not reflect realistic compiles. There is no reason to assume that the result generalise to any programs that anyone actually cares about.

Also, there are no error bars of any kind listed.

In other words, I have no reason to assign any meaning to these numbers.

Or you could just get up earlier/later on your own time.
If there is a need for government regulation here (which I don't think there is, but I may be missing something), then you can regulate that opening hours of stores stores have to shift by an hour during the summer, relative to their normal posted times. Which will still affect some people, but at least (a) eliminate the main conceptual issues of double/missing hours, and (b) remove the practical issues for _some_ of the people affected now.

There's one big change that you are not considering there: the _rate of change_ is greater than ever before. In the past, if someone invented a loom, then a bunch of workers unable to learn the new skills would be out of work and replaced by (mostly younger) people who had grown up with the new technology. This was a problem for about half a generation, during which the younger people could support their out-of-work relatives.

Nowadays, the new skills come and go at a much faster rate. The 16 bit assembly programming skills I learned as a kid about a generation ago are almost useless to me today (in the sense that everything I _need_ to know about low-level programming I could have learned from C). Imperative programming, the way I learned it, is considered largely obsolete by today's vocal OO majority. The APIs I developed against in the late 90s are dead and buried, subsumed in wrapper APIs that one should use instead (who programs directly against xlib these days?) or evolved into entirely new forms (such as OpenGL). Sure, the core Unix APIs are still alive (and so is XML, sadly), but the vast majority of APIs, languages, tools, and hardware from the last few decades have gone the way of the dodo. Compare that to the small number of technological advances we saw in centuries past.

Now, I'm not complaining-- many of these changes were for the better, and even the ones that weren't are likely to be superceded by better ideas within the next couple of years. But note that at the same time at which we see this unprecedented rate of change, poverty statistics show that the gap between rich and poor is growing at similarly unprecedented rates.
Yes, this is merely correlation, and it shows nothing. For all I know it might just be that TPTB have become more effective at making people docile and exploitable, or that laws and legal practice have gradually become so complex and expensive that the privilege of freedom has become even more exclusive than it used to be.

But I'd like to think that the increased rate of change is a strong contributor to that change in poverty rates, if only because that is one thing that I see some hope for, via improved education and better tools.

I think Andy is complaining about the bad CS degree mills that I've run into. I am definitely in the camp that a CS degree should be *harder* to get. That said, we should probably re-evaluate our interview process as an industry. Instead of grilling a kid on if he has skill X ... we need some way to determine if they are smart, competent, and motivated.

If you can't attract smart, competent, and motivated people ... maybe you need to re-examine your organisation.

Now that you mention it, I *can* hang around for DAYS on wifi. My record so far is two and a half *days* on wifi. But, I usually use the phone as a mobile computer while traveling. In those situations it's a little TV for around 4 to 5 hours and it's a phone for 2 to 4 hours during lay overs and while navigating airports. For several hours before and after, it's a GPS... but it gets to be plugged into a car during those times.

I bought a triple sized battery for my 4G phone. My phone is friggin' enormous now... but I can use it on 4G for 12 to 16 hours. I have yet to completely kill it... even while using it on coast to coast flights.

The pledge is not about not submitting to these venues. It's about not reviewing for them.