anonymous "one" can argue that black is white and get killed on the next zebra crossing too

Define "won". And then try explaining it to a Vietnamese civilian who went through that war.

No.

I agree. Semantics (the relation of language to meaning) is important. I wasn't defending HP's misuse of the word 'memristor'.

The issue here isn't the imperfection of the HP device. It is a matter of semantics.

The 'memristor' was conceived as a term to describe a basic device where the change in flux is related to the change in charge.

What HP have produced is a device that substantially behaves like a memristor, if you are only measuring current and voltage at the terminals. That's useful if you want to build a memory device, since the behaviour is such that resistance will vary with the integral of the current through it.

However, the physics by which the HP device works is not a physics of memristance. For practical purposes, that may not matter; it is a simple device with useful properties. But terminology wise, it is memristance behaviour, not an unqualified memristor.

Equivalently, one can build an active circuit that uses a capacitor and a feedback loop to emulate an inductor. It isn't technically an inductor at all, but it does get called an "active inductor".

The advantage of the object oriented paradigm is not primarily that it makes programming easier or faster. It is the better support of separation between different components, which makes it possible to contain the complexity of large projects with multiple software engineers.

Of course, there are other ways of handling large projects (for example, there are examples of large projects written in C that control complexity by conventions about the separation of data and modules). But the object oriented paradigm is a common choice for large software engineering projects.

You might miss this when learning from a text book, since you are often only given small code examples and toy object hierarchies. But that extra 'overhead' around the defining of object abstraction pays off as the complexity increases. For many problems, thinking in terms of objects rather than instruction sequences can make the problem easier to solve.

Starting off with C and moving to C++ is not necessarily a good process, as you will not begin to learn to think in terms of objects; it is a completely different way of problem solving. Even for experienced programmers, the transition from C to C++ can be a six month process, not because of the extra language features, but because it requires a change in approach. Many don't stick at it long enough to realize the benefits.

The trade-off over speed is not an issue at all; for example, C++ is not significantly slower than C. Speed is affected far more by other choices; data structures and algorithms, memory localization, parallelism, and so on.

And you would also be aware that there are other paradigms as well, such as functional programming. These paradigms are not just "different tools for the job". They can have a radical impact on problem solving methods.

Your topic was whether nuclear weapons will keep 'non-fanatical' countries out of a war. My point is that you are overconfident of the rationality of the two countries that maintain the bulk of nuclear weapons. Woodrow Wilson taked about "the war to end war". Now you say that nuclear weapons are the weapons to end all major wars. Forgive my skepticism; I base this on past behaviour, not on suppositions about whether large states will or will not join a conflict. We are still over reliant on wise and considered decision making (such as the judgement call by Stanislav Petrov); I don't think we can take that short term stability for granted. If the assassination of a single person in Bosnia can lead to a world war, what do you imagine might happen if a nuclear weapon was used to murder an entire city?

Conflicts have been known to escalate beyond rationality in the past; World War I is a prime example.

Yes, for example, there were a number of anecdotes of MySQL databases using 100% CPU time, and the article mentions the similar Java/Cassandra problem. I suspect these two probably account for the majority of issues encountered.
http://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/

The reason that the command line survives is that it is a model of the way that humans communicate abstract concepts - primarily using language, not using pictures. Yes, there are plenty of examples where a picture is worth a thousand words. For many applications (such as one-off editing of a photograph) a GUI makes a lot of sense. But there's no need to rip out the language facility from the user interface!

If you were going to criticize the command line interface, it would be to criticize the poor "grammatical constructions" (the inconsistent syntax and quoting methods), and the poor "semantics" (difficult to remember option codes, hard to access manuals). But these are arguments for improving the command line interface, not for discarding it. The prime reason that puts people off using the command line interface is that there are no hints as to what to type next, no feedback. It is a problem we should address.

A graphical interface is quite poor for some things, for example "do this a thousand times". The problem isn't the "thousand times"; easy enough to have a GUI element that handles it. The problem is the denotation "this", an abstraction that is hard to visualize. At best, you represent "this" as a macro sequence of GUI actions, but that is only a single level of abstraction with no parameterization. A command line interface can handle such abstractions with ease.

While ground turbulence is going to detract from peak performance, in level flight helicopters do benefit from translational lift, which increases the weight capacity. On take off, you cannot achieve forward motion until you are off the ground; ground effect helps to gain ground clearance in order to start moving forward under heavy loads. Thus the maximum load can potentially be higher than can be maintained in a hover (not that I'm saying this is necessarily a desirable scenario). In mountainous terrain, the pilot may make use of a descent to gain the forward speed rather than ground effect.

Reminds me of an interesting case in the 1970s in Australia. Edward Ward shot a fisherman on the Murray riverbank near Echuca, and the body ended up half in the water. He was found guilty of murder in Victoria. But because the boundary wasn't well defined (the river itself belonged to NSW), there was a drawn out legal battle that eventually ended up in the High Court having to define the boundary more precisely. Ward didn't get a reprieve though, because he was retried in NSW and still got life imprisonment.

The implementation of the state machine is of less interest because it is finite. The aim of the exercise is to reduce the the notion of computability to a machine-like process. The most simple conception is that only one part of the machine is infinite and variable. That is why Turing needed to show how to implement a Universal Machine as a single Turing Machine, so that the transition table could be made fixed in size (and after that point, uninteresting in implementation). It would have been sufficient to posit a human reading a pencil and paper transition table and methodically applying the transitions to the tape; the important part is that the process is "mechanical" meaning without the involvement of creativity, not "mechanical" meaning that it can be realized in a mechanical form.

Of course, if you want to build a model of a Turing Machine, then the implementation does become more interesting, so I agree with you that this Lego model is only half of the puzzle.