A meteorite which does not create a big crater will throw a lot less stuff up into the atmosphere, and will have much less global consequences. Getting a shower of smaller pieces would not be fun, but a single big impact penetrating deep into the crust with equal energy is worse.

Depends on your definition of fine...

http://en.wikipedia.org/wiki/2013_Stockholm_riots.

http://en.wikipedia.org/wiki/Rosengård#Violence

Well, not the only reason. They also wanted to verify it does not trigger destruction of the planet, or a phase change of our universe. No point gathering data, if there's nobody left to examine it, is there?

Qt does not change C++ language. Qt application code (C++ side) typically compiles with multiple C++ compilers, so not only is it C++, it is often made very compatible/portable C++.

Qt build process does not read in $FOO source files, it reads in C++ source files, and generates extra source files in addition to the original. The original source file stays there, and can do anything C++ can do. This is a rather critical point, all modern features of C++ are fully usable in Qt apps code, and also support from them tends to be added to Qt (like connecting Qt signals to C++ lambdas). Another very important aspect of being pure C++ is, you can use any C++ tools with Qt C++ code. Debuggers. Static analysis. Any IDE "intellisense" (though Qt Creator does have a few customized features specific to Qt code).

I am not sure what you actually mean when you imply that Qt should have dropped "most insane parts" of C++, but it sounds like you suggest that Qt should not be a UI framework, it should be a new language of its own (which would then be compiled to intermediate C++ code, which would then be compiled by C++ compiler to machine code, unless someone wrote an actual compiler backend for it)? Creating a new language is an order of magnitude bigger undertaking in all fronts, than just writing a framework for existing language. Language design is hard, and getting people to use new languages is hard. Also, Qt was originally "just a library", so if it changed to "not C++ any more" in some version, it wouldn't really be Qt any more anyway, it would need to be called something else (and see the new version not getting adopted, while old GPL code base would be forked).

Nah, Python, like any dynamic, duck-typed language, is antithesis of "doesn't compile if not correct". Correctness of Python code rests solely on developers (design of app, reviewing code, having tests, etc), Python itself does not lend a hand in spotting bugs.

If a chainsaw doesn't have all the appropriate modern safety features, and you hurt yourself with it in a way which would have been prevented by these features, then it certainly is the fault of the saw, or rather the person choosing to use it. There certainly are some parallels here to programmers and their choice of programming languages. Perceived efficiency with familiar old "trusty" tools and habits trumps long term gains of more modern tools, or even just using modern practices and extras with the old tool.

You seem to agree with "shove systemd down the admins' throats", you just say it in a more roundabout way. "Open wide or GTFO and switch everything you use to something else."

And I do feel the Linux FOSS community has dropped a ball here a bit, as there doesn't seem to be a good, complete server distro without systemd dependency, even though there seems to be demand for one. I'd have thought somebody would have picked that ball and run with it.

Me, I just expect the Linux distros I use to basically work out of the box, and keep working with minimal hassle. Xubuntu has been doing it for me lately (since Ubuntu switched to Unity), together with Ubuntu Server, mostly using LTS.

I hope you realize that's exactly the kind of forcing he's talking about? Most users need an OS now. Creating a stable, tested, trustworthy, secure custom distro is beyond resources (be it employers willingness to pay for maintaining an independent Linux distro, or hours per day reserved for maintenance of custom Linux instead of doing what one actually wants to do) of 99% of even those Linux users, to whom systems matters. For them it's basically, use systemd or switch to Windows (not a bad choice, actually, for a modern semi-decent PC with enough RAM to run a few VMs). Ie. showing systemd down their throats.

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).