Yeah, but solar energy itself is free, so conversion ratio in Watts doesn't matter. Only cost per Watt-hour matters. If that can be made cheap enough in money, then the required land area won't be a limiting factor. We'd get a bunch of new oil countries, for example around Sahara, in a matter of decades.

Especially if weather patterns really change and people start believing that elevated CO2 level in the atmosphere is the cause (whether it's true or not doesn't really matter for this purpose), then what ever it takes politically (including extremes like "pacifying" unstable Saharan countries by invading) to get clear synthetic crude flowing, it will get the votes of the masses, as well as lobbying money from those wanting to profit. It wouldn't be a new industry, it would be the old oil industry with a few tweaks, which is a huge factor in favor of this over other solutions.

If we ever have a reasonably efficient way of producing hydrocarbons from CO2 with solar energy, we won't have any need for nuclear power for a long time (and by then we might have working fusion). Just burn the hydrocarbons. Using a fuel cell to directly produce electricity might take off, too, if we have process which makes clean hydrocarbons of desired type. We've got most of infrastructure from giant oil tankers and pipelines to distribution and final storage built up, all we need is a synthesizing technology to take place of drilling, pumping and fraking.

Lasers are most certainly used to "blast" things. Start reading for example here.

Any change in environment puts stress on the species living in it. This results in species adapting through evolution, as well as species going extinct. Every gene transfer and mutation creates this stress, pressure for change, too. Now we are about to start introducing radical genetic changes that are bigger than anything which could happen naturally (nature works through gradual random changes where every generation has to be viable, while we can design bigger changes and retry any alteration until we get it right), at a far more rapid pace than what happens naturally (out alterations don't need to spread through natural population on their own, we can for example produce altered seeds and grow them as much as salesmen can sell them).

This evolutionary pressure, happening in the middle of an already ongoing mass extinction, that's what gives me the creeps.

And no, we do not really understand how the ecosystems will respond to the pressure created by genetic engineering, especially on the scale it is like to be done in a few decades. I bet most (probably not you, but most) proponents of genetic engineering don't even know what "ecology" is as a science, so them saying that opposing genetic engineering is ignorance is kinda ironic.

Unless being able to negotiate benefits for themselves at the expense of others (there's usually a fixed amount of money for raises etc) improves quality of their work, I don't see why being a better salary negotiator is reason to have higher salary. On the contrary, a good negotiator is likely to be able to push their inferior solutions through over better solutions from less good negotiators. Also if it leads to poorer salary (as well as envy) and therefore higher attrition rate for people whose skills lie elsewhere, it can be very damaging. Salary should be based on employee value to the company, and negotiation skills should be a factor only if they actually increase that value.

MS bought mobile phone business of Nokia. I guess you could say MS pwned Nokia by getting Elop as the CEO, but that too is in the past now and Elop is back to MS payroll (I mean, publicly).

The Qt 3 to Qt 4 transition was painful enough for too many projects to make similar breakage very unpalatable for the community. Sort of "been there, done that, didn't enjoy it" situation. And what you are suggesting (replace every container etc with a different one) would be even bigger breakage.

And of course from cost (be it money or time) point of view, touching basically everything in the Qt source code to strip out Qt classes would be gigantic work. Not going to happen, there's neither business case nor developer demand for breaking everything, so there's almost nobody who has any interest in making it actually happen.

Qt COW is thread safe, programmer does not need to worry about that. For performance critical parts, feel free to use something else, but for the usual GUI code, COW is very convenient. Also remember, Qt 5 is already so old that it couldn't require move semantics support from C++ toolchain, which is also a performance issue.

Moving forward, what I hope for future is, C++ enabling reflection and introspection (in ways required by Qt features) without extra code generators (like Qt's moc). That'd be great for Qt 6, if such a thing ever comes. Another thing which would greatly benefit Qt is C++ removing the need for manual implementation of the PIMPL idiom. And supporting C#-like extension methods might make transition to standard C++ containers more likely, with missing functionality added as extension methods (current need to mix methods and free functions is not very nice IMO).

"Insist duplicating"? What do you propose as alternative, when you don't want to destroy source compatibility of old applications? Qt 5 API is almost identical to Qt 4, no big break like after Qt 3, and having it any other way would have been very bad, because underneath Qt 5 has major improvements (starting from being able to connect C++11 lambdas to Qt signals, and being able to construct QStrings at compile time). So most apps still under development should and can easily be upgraded to Qt 5 (while staying Qt 4 compatible if desired, with a few #ifdefs), and this is a great thing.

It's not Qt's fault it took so long for C++ to get its act together. "Horrible naming convention" is also rather subjective. I find using undescore in names ugly, and boost-like nested namespaces hurt my eyes. Yet many seem to like them, and I don't judge them for it.

Note, tone of your post sounded like you're trolling, but I'm giving you the benefit of doubt. If you are trolling, ignore above two paragraphs, and if you aren't, ignore this paragraph :-)

The energy to load the spring comes from the user as part of the normal operation cycle. That makes it unpowered.It does not bring extra energy to the operation (user walking by converting chemical energy to muscle contraction), it only changes how the energy is used.

The trick is to define the system and timeframe you are looking at sensibly. In this case you have the braces and the user taking a number of steps. The user generates the power, the braces are unpowered. If you looked at the braces for one unloading of the spring, you could say the frame is powered by the spring, but that is not very useful choice in most contexts outside design of the device.

(replying to undo mod)

Declarative programming obviously. Of course sometimes some pieces may be missing, and sometimes they may be most conveniently implemented using a more imperative programming style or language, but once you have the pieces, it's liberating to be able to just declare how they fit together.

Node.js is the server. Perl and PHP are rarely used as servers. Python's Twisted stuff resembles Node.js in many ways, I believe. Not domain expert, I'm sure someone corrects me shortly.

"try to teach everyone", yes, absolutely. Same way we try to teach everyone some arts and crafts: skills (using equipment), knowledge (knowing colors, notes, names of tools etc) and history (famous pieces and artists etc).

Not everybody will learn or remember much, but that's ok.

Umm... Actually carbon dioxide is pretty deadly. 10% carbon dioxide in breathing air starts to kill people, even if there's normal level of oxygen. And this can actually happen, for example in mines (this is why canaries were used, as they're more sensitive to high CO2 levels than humans). Carbon Dioxide can kill in exceptional but realistic concentrations, so it's not very far from being toxic.

Nah, /. is just dying.