You also are bringing up a good point that an accurate review of any complex software requires an unreasonably large time commitment. What's the learning curve like? (This beats "intuitiveness".) How often are updates buggy or force re-learning on users? (Beats bugs-I-just-found reports.) How helpful is the community when it comes to resolving problems? What has the history of security flaws been like? How would you estimate the software's long-term viability and adoption by others? Does an experienced user find common tasks to be easy and fast, while unusual tasks are not too difficult? (Beats feature-list comparisons).

To review a movie you need (1) a decent understanding of ... I don't know maybe "filmography". Then you need to (2) watch the movie. After a couple hours you can write about it. None of the important questions about software can be answered after a couple hours' exposure. Combine this with the sheer quantity of software out there and you can see how software reviews aren't as prolific or celebrated as one might hope.

This claim (regulatory capture) would be possible to argue against if only internet access in the US were cheaper or as cheap as it is in other countries without subsidies. We know that's not true, therefore we have a market (and government) failure. Case closed.

FTA: "Vehicle tests confirmed that one particular dead task would result in loss of throttle control, and that the driver might have to fully remove their foot from the brake during an unintended acceleration event before being able to end the unwanted acceleration."

I was reading through comments hoping to find some general opinion of whether or not Barr's findings could have applied to practically any software stack. You usually don't have to work very hard when reading through code before you spot a bug or two. But in my experience most of these bugs are never (or rarely) exposed because they lie in corner cases. But in the case of Toyota's electronic throttle control system, you'd have higher expectations.

It sure sounds like Barr's group indeed found code of "unreasonable quality." I'm just not sure how to put that into proper context. One can always spend more time and money on code analysis and robustness improvements. Did Toyota really fall short of reasonable expectations? It sounds to me like they did, but I'm only hearing one side of the argument.

What I can't yet understand is how this experiment helps validate the theory of time as an emergent quantum phenomenon. It seems more like a demonstration than an experiment to me. What alternative theory is their experiment excluding?

I'm a physicist but that doesn't mean I understand any of this QM stuff. I have a feeling this is a little like experimentally demonstrating Bell's inequality -- one can do experiments whose results are consistent with predictions of QM, and in ways that one might expect other general classes of theories to differ even though you don't have a specific alternative theory to exclude. Most experiments are like this really. But in the case of this time-entanglement experiment I really don't see room for alternative predictions. I think the paper's title acknowledges this: "Time from quantum entanglement: an experimental illustration" (my emphasis).

I'm not saying that the experiment is in any way unhelpful or bad. It's a great idea, but I would not go so far as to say that this is "experimental evidence."

You're running Kubuntu 13.10? How is it so far?

I've long enjoyed KDE and pyqt programming. It's nice to see the underlying library move forward so successfully. I've found that, at least with pyqt, the QT libraries are rather large to ship around. I hope this doesn't increase the size of wireshark too much. It's nice to be able to easily install and run it on platforms like raspbian.

For numeric code, I find that stepwise debugging is rarely helpful and never necessary. Print statements are my primary tool for spot-checking numbers, data structures, and even for evaluating the general flow of the program. The next tool is to create histograms and other plots of the data you're getting at various stages or calculations. By varying the inputs and seeing the effects on plots (in vague terms), you have a very powerful and underrated diagnostic. The more work you put into analyzing your program's data, the better off you'll be.

I second the Python/C++ combination, and should add that you can do a lot with numpy and scipy so you may very well not need the C++ side of things.

I've also written a lot in Fortran years ago, but only because I was working with a ton of legacy code. Compared to C and C++, Fortran is actually more elegant for pure numerical computing. I'm not actually recommending it, mind you, but I also found the main weaknesses of Fortran could be mitigated by writing wrappers in Perl to get data in and out. Java is not actually bad for numerical code either, and it's arguably easier to learn than C++. I guess I'm saying this to point out that it doesn't actually matter much what language you use. Visual basic is a rare exception -- never use that for any reason. :-) And you have to be aware that high-level languages like Python are going to be slow if you have no consideration for what operations are time-consuming. Be particularly mindful of memory allocation / object creation.

Agreed. I'm surprised there weren't more posts mentioning Gradle here!

It took me a few days to watch the videos and read through this article, but I think the main problem with the OP's arguments lie in this "for the good of the whole society" bit.

On the one hand I agree with this in principle, in a world in which lawyers and detectives are working foremost to uncover the truth in any given case. But our justice system is inherently an adversarial one, for better or worse. In the adversarial system, the police and prosecution is working almost exclusively for the plaintiff in a case and therefore against all suspects as well as all those who may potentially be a future suspect in any case that exists or is yet to be created. The goal of uncovering truth is purely secondary, thought to be a natural consequence of prosecution and defense each arguing their side to their best ability. Most of the OP's objections are, I think, rooted in the counter-intuitive nature of this adversarial system.

It's easy to find problems with our legal system. There is a lot of evidence that not all lawyers are equally matched ("buy the best lawyer you can afford" is common advice). A "jury of peers" is very easily misled and influenced by propaganda techniques. This may partly explain why some lawyers are better than others -- some are more skilled with propaganda and rhetoric. This system also is economically inefficient in the sense that it tends to necessitate its own professionals. That's the driving force behind these videos: the audience, legal students, are being told how absolutely essential they are in the legal process, so much so that virtually all communication to law enforcement must go through lawyers. There are also a LOT of cases (anyone have percentages?) where innocents have been convicted, jailed, even executed.

But on the other hand it's very difficult, for me anyway, to envision a system that is not antagonistic and also has as many checks and balances as ours does. It may be a little like democracy, "the worst form of government except for all those others that have been tried." I can't help but suggest that propaganda is also the Achilles's heel of democracy as much or more as it is for the legal system.

There's an interesting parallel between the adversarial justice system and a free, unregulated market economy. In both cases the ultimate goal, truth and justice for one and economic efficiency for the other, is thought to be achieved as a result of individuals working toward myopic or selfish ends. The invisible hand of justice, anyone? Also in both cases real world results show that there are major flaws in the theories. Perhaps these flaws result from simplifications or assumptions that are just not true.

It sounded to me like article is responding to a change in management (Peter Lee taking the reigns). It's not very direct about what it's advocating however, probably there's some inside context for this. The following points stood out to me:

  - Research is not advanced development on potential new products
  - Research areas should be carefully chosen with an eye toward giving the company an edge

That first point is probably what Bob Buderi is most concerned about. Management may be pushing Microsoft Research to be more product-focused. His response might be to instead focus on more careful selection of research areas, and more willingness to try productizing the research output.

For me, Unity would take a long time to get used to. I found the MacOS-like unified menu bar to be flaky, hard to use, and worked badly with a lot of software. Unity was fine with most apps if I wanted one window on the screen at a time, but that's not even close to how I work.

I'm using Kubuntu at the moment on my laptop, and Gentoo on a desktop at home. I'm happy enough with kubuntu but it does require a lot of tweaking, care and maintenance. It certainly does not "just work" the way Ubuntu used to several years ago. My coworkers (who mostly use xubuntu) and I have a hard time with lockups and experience lots of installation issues. About half of these relate to Nvidia drivers and multi-monitor support, but that still leaves a lot of other problems to contend with. It just seems less stable than it used to for me. GTK and QT seem to work less and less well with each other, and Network Manager and the networking service sometimes fight each other (lockups on boot even). In my office there have been several instances of whole-system corruption where people had to re-install everything from scratch. Distribution upgrades have not been smooth. I used to be very happy with Ubuntu but these days I'm falling out of love with it.

A lot of this may be hardware-related. I notice that coworkers with newer laptops have many more problems than I do. Some of this is expected, but again not to the degree that I'm seeing it.

The itunes, google play, and other paid app stores seem to me to discourage open source development. AFAICT there is no standard way to go from the market page to a project or source code page. Very few Android apps are open source, and the few that are open are hard to identify as such and find the code. But most desktop Linux-based distributions have package managers that allow easy access to the source code.

There is something about the mobile development community that almost discourages open source. Part of this may be the ease of creating paid or add-supported apps. Is this drawing developers that otherwise would not be coding or just writing Windows software onto a (mostly) open-source platform? Or is it outright discouraging open-source development? I'm thinking it's mostly the former but a little of the latter too.

I feel like the Guardian article's mention of "regression toward the mean" is incorrect because it attributes this effect as a causal one. The wikipedia link cited warns against using this effect as a predictive one under "misunderstandings." Past deviations do not predict future returns to the norm, just like rolling a high number with dice doesn't predict that the next roll will be below average. Dana makes it sound like climatologists predicted this year's rise as a consequence of last year's fluctuation.

I do agree with the conclusion that the 2013 sea ice level remains consistent with a decreasing trend.

The actual doc says "Some aspects of Python’s C code are not yet understood by Coverity." That's much more vague admittedly, but not as shameful.

It all depends on your frame of reference. CPython is a blurry rocket of speed when compared with Jython. And in theory you can write all the compute-expensive routines in C++.