"In Flanders Fields" was written during the Great War, not World War II.

Except that the basic research has been done, fusion has been demonstrated. Yes, there are still some significant materials and confinement hurdles to achieve a commercially viable system, but it is primarily a engineering challenge, not a basic research one.

You don't invest in money, whether it is fiat currency or bitcoin currency. You invest in things that are known to have long term desirable value. You may speculate on currency fluctuations (and futures, and so on), you might even do well out of it, but that can only work while there is liquidity in the system, while transactions are being made.

For bitcoin to have long term desirable value, it has to have a purpose. It's purpose is to make transactions, at the moment specifically catering to a desire for anonymity. However, in order for there to be transactions, there has to be both a buyer and a seller, and this can only happen if the currency is stable. In unstable currencies, all transactions cease (because either buyers or sellers stop trading, depending on the direction of the instability).

At the moment the bitcoin currency is relatively stable (allowing for the small size of the economy), as mining replaces the bitcoins that have been squirrelled away into 'investment' accounts. As mining becomes exponentially more difficult, the deflation will also increase exponentially. Initially, that will simply increase the value of a bitcoin. At some point though, either people will start to bail out when they see the end in sight (which happens when there aren't enough sellers in the system), or the satoshi will no longer be small enough...

There's no point in having a million dollars worth of bitcoins if you can't spend them on something you actually need or want.

Don't get me wrong, I like the idea of a peer based financial system, and I watch the bitcoin experiment with interest. It has technical merit, but I am not convinced of its long term stability. And stability is the key factor in a sustainable trade system.

It is a software implementation of OpenGL, but it now also provides the libGL glue to various hardware acceleration drivers. So it does have a role on most Xorg systems. An exception is the Nvidia proprietary infrastructure (which replaces large portions of the normal 3D graphics stack).

Actually, you can even do that too using Winelib. Might require a certain tendency to masochism.

Language boundaries are defined by mutual intelligibility of the communication system. This can be simplistic, but it provides a good first approximation that is testable. There are border cases (such as language chains), but on the whole it is a useful definition.

In comparison, dialect contours are defined in terms of specific language features. What speakers call a "dialect" is an identification, and while this may correspond roughly to collections of language features, it is really a sociolinguistic definition of language variety.

The notion of race is analogous to these sociolinguistic definitions, not to language; it is not defined by external factors, but by social ideas. There may be superficial features that are assumed to be associated with particular "races" (much as superficial language features are assumed to be associated with particular dialects), but these features are a poor definition of "race", because they are not clustered, and cross the boundaries of what people perceive as "race". In other words, "race" is a social construct.

It is the notion of species that is analogous to language. Species boundaries are defined by fertile offspring. Again, there are border cases, but it is testable.

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?