Also, if 39% of all developers work on Windows, and 36% of windows developers work on Visual C++ compiler (sic!), it means that 14% of all developers use Visual C++ compiler. This is higher than 12% of "other" compilers overall, but, paradoxically, Visual C++ is supposedly somewhere inside that category.
If it's a cross-platform projects then no wonder. Also we know quite a lot of cases when developers are working on Windows and using VS, but compile for Linux and use GCC for sure.
As I answered in our blog:
That’s a good observation. The point is that various data has come from various data sources, that can be influenced by many factors. When we got some data on the same topic from different sources, we were trying to get some average. Actually various data sources gives slightly different numbers with inaccuracy up to 4-7% for each of these questions. For example for platform distribution we saw 40/50/10 variant (however the order was the same for all the options), and 39/44/17 is a average across all the sources given platform distribution numbers.
Compiler stat is more accurate across various resources, however we suspect that all-platforms compiler distribution was mostly measured across cross-platform projects, that means less percent for the Visual C++ compiler (and that’s the reason we include the Windows stat separately from the all platforms stat here).
Most likely because their "C++ developers by platform" statistic does not include an "other" category, while there are actually developers working on platforms than Windows, OS X, or Linux (such as Solaris, BSD, etc). Since they didn't include an "other" category but the numbers add up to 100%, they probably just left out people who didn't respond to that question; thus in fact, in their sample, the number of Windows developers is probably less than 36%.
Another thing to note is the sources of information used for these statistics, including their own user surveys. These aren't necessarily accurate for the industry as a whole, but rather represent a particular sample, which happens to include their own existing users, people on Reddit, people sharing code on GitHub, etc.
I also find the 12% fact hard to believe. IMHO lots of commercial software is still developed and runned on windows, and seing anything other than MSVC there is an exception. For games I'm thinking the situation is the same. So I would guess it alone is at least 20%.
Also the embedded SW development market is really big, and C/C++ is still dominant there. E.g. in automotive nearly all ECUs are pure C, using compilers that fall in the "others" category of this survey.
But I guess the issue could be the used sources here. E.g. embedded is in large parts a closed ecosystem with less visibility on the internet sites about programming (which are often very web-focused).
I was surprised of the amount of Linux devs using C++ compared to the number of Windows devs (given the desktop marketshare). Also the fact that finance was leading sector using C++ - and by such a high margin - was unexpected to me.
I'm guessing that it's the finance industry itself which accounts for a high Linux usage, since they mostly need C++ for server-side use.
Another surprising number was that Windows users use GCC almost as often as Visual Studio. GCC on Windows is kind of a PITA, and the VS toolchain is really pretty good. Maybe people go with GCC because they need proper C99/C11 support.
I hadn't expected the dominance of Java in the "programmers per language"; I should have, but didn't. I also hadn't expected the disparity between Python and Ruby numbers.
I'm looking forward to digging into this further; it's a really useful and interesting dataset!
I think the usefulness is limited by the fact that they haven't explained how they gathered this data. At first glance, the data looks to have some specific quirks (44% Linux users, overwhelmingly in the Finance industry) – you'd have to wonder it that's due to how the survey was conducted.
There are a couple of resources listed in the end. So we've gathered the information from reddit surveys, stackoverflow, our own surveys (with more than 5000 respondents), job ads, various language popularity indexes like Tiobe.
I really doubt #10, there is no way that they number of people using gcc and the number of people using VSC++ are even close. The only time I've seen someone use gcc on windows is to test some cross compiler errors.
It does seem odd. Then again, don't underestimate the amount of people developing for embedded devices on windows - which is often done with a gcc toolchain supplied by the chip or rtos vendor.
To be honest i'm surprised with the adoption of C++11, i know the toolchain supports C++11 since some time but still i can imagine there's lots of legacy code using C++03 or older.
There were a handful of breaking changes in C++11, but nothing that takes any meaningful amount of time to resolve. IME the only source of porting pain is libraries which conditionally use C++11 features where the C++03 and C++11 versions aren't semantically equivalent.
I really wish people would stop lumping C and C++ together. They are two separate language that have a common lineage, but neither is a subset of the other. The people who write C well do not generally write C++ well, and vice versa. It's a pretty different development community between the two languages. Bjarne Stroustrup, also thinks that treating the two language as if they were one is kind of silly.
I'm really glad people do lump C and C++ together, because the tiny fraction of the C language which is not a proper subset of C++ affects life very little in practice. C++ is a multiparadigm language and it is completely reasonable to use it like one uses C, if that's what suits your need and environment.
In embedded firmware development, for example, one often simply can't afford the RAM it would take to run a malloc/free heap, and may have hard realtime constraints that would preclude the use of dynamic memory management even if more RAM were available. It may still be worth using C++ for such systems even if you're writing functions-and-pointers style code like you would in C, because namespaces and class/struct encapsulation are useful tools on their own.
They are separate languages, but it is definitely not like saying ML/Haskell. Most C code can be converted in C++ without too much work. In fact, that is what GCC did:
That is bad, and is ripe to create a lot of errors.
C programmer who tries to write C code in C++ has the worst problem ever, IMO: he doesn't know that he's wrong. Everything compiles, everything works, and he goes home happy after a productive day of laying mines for future maintainers.
This is an opinion that I see a lot and it's very overstated IMO. If you write good C code, I'm perfectly happy to see it in C++.
In fact, you could almost say it's a relief, largely because it tends to be impossible to write any overly-clever template-inspired madness that will be hard to understand and drag down compile times for a small benefit.
Additionally, when it comes time to optimize code (assuming this block is worth optimizing, and already is using the optimal algorithm), the C code tends to be closer to what you want to optimize than the C++ code. With the C++ code, you typically have to spend more time removing abstractions before you can start actually tuning it.
That said, while bad code in either is bad (obviously), someone could probably make the argument that bad C++ code is easier to fix than bad C code. I might be able to be convinced of this.
How does that work?