I'm surprised by your answer at so many levels. First, I thought the guys doing scientific calculations were scientists that many times (not always of course) are only used to Matlab, Mathematica or even Excel. Second, obviously we will need native code, as well as interpreted, functional, and lots of code in domain specific areas (what the heck... I spent this Sunday morning writing in VimL, a language so stupid that can't copy a file without reading the whole contents in memory or invoking system(), but I needed to program in that and there is no way around it).

But the final sentence of the article isn't targeted at people doing heavy lifting. Is an "attack" at Google's Native Client (NaCl). I peeked at NaCl, and you needed a some set up and some APIs to run some native code invoked from the browser. ASM.js is way simpler, since is just a subset of JavaScript, and has much more possibilities of being followed by vendors like Opera or even Microsoft.

Oh, and, I do native code for a living, and while I would kill for making my code faster, my manager would kill for making me finish projects earlier. :-) Native code is awesome, but sometimes dumb languages are more business successful if you can use all your developers in a project, including that 50% that, by definition, are below the average.

You are missing an important point: many people that work on a software project in their spare time do it to have fun. I work as a programmer for a living, and at work I do what my employer wants me to do. I might not like the way I have to do things at work, but I do as my manager says.

If I work on a hobby project to have fun, I want to do things the way that make me happy. It might be the case that you are happy making a killer product that has tons of users, even if the internals are crap. Or it might be the case that you are only happy with something that has a nice architecture and uses bleeding edge technologies, even if that makes the product unstable an unpopular.

I don't know what is the state of Kdenlive and the opinion of Jean-Baptiste Mardelle, but I hope you know better if you make such assumptions about other's projects.

Yes, I saw that earlier this morning, but I wonder how legal is that, and how easily you can be blocked by Google. I doubt is a solution for a vendor.

As I understand it, that is not going to happen if you want Google's bless (i.e. their applications and Google Play Services, which are critical for some applications to work). Read Google’s iron grip on Android, especially page 3.

Since the Kindle OS counts as an incompatible version of Android, no major OEM is allowed to produce the Kindle Fire for Amazon. So when Amazon goes shopping for a manufacturer for its next tablet, it has to immediately cross Acer, Asus, Dell, Foxconn, Fujitsu, HTC, Huawei, Kyocera, Lenovo, LG, Motorola, NEC, Samsung, Sharp, Sony, Toshiba, and ZTE off the list. Currently, Amazon contracts Kindle manufacturing out to Quanta Computer, a company primarily known for making laptops. Amazon probably doesn't have many other choices.

Seems like a terrible move against market freedom. Even worse for consumer freedom.

OK, I give up. The fact that you still think that using a string as a vector of bytes is comparable with a class that is capable of understanding the text it stores, with some encoding conversion capabilities, and more, should be a clear enough indication that we don't have the same expectations on what is a class for human text. And the fact that you still try to put words in my mouth signals that it isn't worth wasting time with you.

Luckily enough that people admit that you should use a Unicode library, because even C++11 supports Unicode terribly, and there is work underway to improve it. Meanwhile, I'm happy to have QString. And I'll be happier if with Qt6 there is a type that can replace it.

Read again the thread. You said that MOC is a precompiler (wrong, is a code generator), and that it transforms the input text in ways impossible with C macros (even more wrong).

I said "Is the classic C preprocessor" in response to "these keywords are pre-processed by a special compilation step into C++ code" which is absolutely right.

And you still fail to explain how you can use std::string for text instead of for low level manipulation of the string bytes.

Next time you write about something, use it first, please. MOC is not a precompiler nor "transforms" input text. It generates code. Like a bazillion other tools that generate perfectly standard C++ code.

Execellent. That's why everyone is using std::string in i18n-ed text, and why C++11 didn't introduce new string types.

But yes, call people stupid as long as you want. Now you are probably right.

Thanks for the hint, but I've found the Wikipedia page on it (and the first results on the web) not very exciting. However, Software for Infrastructure from Stroustrup has a really cool example on how to do it very pretty. It uses user-defined literals to create expressions such as "Speed s = 10m/2s".

My C++ compiler doesn't compile "#include" either. Because it doesn't have to. You need to run the file through a preprocessor. That's part of the standard, and is unavoidable at this time.

If don't like the use of the C preprocessor, fine. But don't lie saying that is not "standard". It might not be the part of the standard that you like the most, but is standard. And using a tool for generating code is perfectly normal. Or is protobuf no longer a "standard C++" tool?

There is a proof of concept clang plugin that would provide the QObject features without MOC. That doesn't make it better in all use cases, since that would be tied to a compiler.

No, seriosly, one might not like one solution to a problem. But having no solution is worse. If one day there is a better solution, the Qt project will adopt it. But right now there isn't one that fills all the features provided by Qt with the current implementation.

You've made me ruin my moderation in this thread, but I can't let such wrong statements unreplied.

Wrong. Is not a special compilation step. Is the classic C preprocessor, which is as standard C++ as any other feature of the language. Does this mean that udev is not standard C because it defines a foreach with a macro?

Qt has its own notion of string, because till C++11 there was no string type that allowed Unicode. Likewise for threads. Besides, QThread has features to integrate with an event loop, notion that the standard library doesn't have.

How the hell were programs written with WxWidgets using threads? Relying on Windows POSIX capabilities? Seriously.

And don't even try again the "but Qt duplicates all the containers". Qt's containers use a very different implementation (e.g. with implicit sharing), and so have pros and cons against STL containers. And Qt's containers have compatibility APIs with the STL ones as well. And you are not forced to use them at all. If some part of the API exposes a Qt container, you can convert to and from STL, since such functions are provided.

The C++ standard library is now much better than it used to be, but Qt started in an age where the STL wasn't even an acceptable option in all the environments where it had to run.

Certainly not. People is migrating from VxWidgets (e.g. VLC) to Qt, and not the other way around. Why it might be? Maybe is because is such a good application framework that is convenient to use, even for non-graphical applications.

The problem wasn't if Nokia should have killed Symbian, the problem is how.

They told the world all their flagship products sucked, and they would replace them... eventually. They were only ready to deliver a first device almost a year after, and they killed Symbian for good much time afterwards. They should have lied, and tell that they were only adding Windows Phone to their portfolio, and then time will tell.

Or better: they should have done an embrace and extend to the whole Android ecosystem. Elop was selling that this was a "war of ecosystems", so Nokia should have said "The operating sytem is irrelevant. Just use Qt to target Symbian, MeeGo, Android, and next year iOS".

They could have taken several paths, and they took the worst, in the worst possible way.

Thank you for insulting the other companies and the individuals that work hard on Qt. Digia maybe owns the trademark and the right/obligation to relicense, but is not the owner of Qt, and certainly not the only contributor. See the statistics about Qt created by Thiago Macieira.

The Android port started as a community only project, by the way.

I am perfectly aware that for some people (most people?) playing the video embedded in the browser might be the most straightforward way of playing it. For some it might be somewhat challenging finding the "save as" option in the context menu, and deciding a path that later they have to find again, but...

Embedded video players are the worst video player ever. Ever. There, I said it.

I'm following a class in Coursera, and the first thing I do is save the videos as local files and play them with VLC. When I press the spacebar to jot down something, sometimes the video pauses, sometimes an invisible blank character is written in a text field of the page, or some link that has the focus is accidentally clicked.

If the embedded player in the browser can't get right something as simple as toggling the playback, don't get me started on the convenient shortcuts that a video player has to play faster and slower, or going some seconds/minutes/hours forward and backward.

Browsers are nice, and some cool fancy webpages can be done combinating transitions, text, images, and yes, video, but attempting that a browser is going to be a good video player is never going to happen.

This is as stupid as saying that you are going to complain in all stories about Foo that is not Bar. I've seen long term X11 developers move from XFree86 to XOrg, and now to Wayland (I have a bad memory, but for example, Keith Packard and Daniel Stone). I've read them claiming that Wayland will probably have even better performance over the network because it will have less roundtrips. And still we have to accept that people complain on what others are doing? Even though they know better? That's trolling.

Wrong. The problem are not the 3800 gadgets. After all, when you run a program through ssh+x11, is just the application. The problem is that normally the application, if is something meaningful, requires to interoperate with other tools, and normally such tools, frameworks or services don't comunicate properly through ssh+x11.

I've tried to achive such allegedly cool network transparency on my local network several times, and has always been useless because real world applications use things like D-BUS.