The Top 10 Programming Languages On GitHub, Over Time

An anonymous reader writes with a link to VentureBeat's article on the information that GitHub released this week about the top-ten languages used by GitHub's users, and how they've changed over the site's history. GitHub's chart shows the change in rank for programming languages since GitHub launched in 2008 all the way to what the site's 10 million users are using for coding today. To be clear, this graph doesn't show the definitive top 10 programming languages. Because GitHub has become so popular (even causing Google Code to shut down), however, it still paints a fairly accurate picture of programming trends over recent years. Trend lines aside, here are the top 10 programming languages on GitHub today: 1. JavaScript 2. Java 3. Ruby 4. PHP 5. Python 6. CSS 7. C++ 8. C# 9. C 10. HTML

Comments

i think it shows trends in GitHub's demographic

[lisabeeren]

> it still paints a fairly accurate picture of programming trends over recent years

i don't think it does (at least not very much). i think it tells us about shifts in GitHub's demographic.

java usage has increased at GitHub, but this more likely reflects greater adoption of GitHub by the business community.

ruby has declined, but this probably just reflects that the ruby community really embraced GitHub at the beginning.

Re:i think it shows trends in GitHub's demographic

[AuMatar]

And why would CSS be more than HTML? There's nobody who uses CSS without HTML, but people do use HTML without CSS. So CSS should be a subset of HTML (also neither are programming languages, but that's a separate argument). So even ignoring massive bias problems, I question their accuracy.

Re:i think it shows trends in GitHub's demographic

[tkrotchko]

I agree. If you look up what programming language experience companies are looking for, you usually end up with two very unsexy choices: Java and C.

http://spectrum.ieee.org/compu...

Javascript will continue to be popular if only because it's becoming the defacto standard for cross-platform mobile development.

Re:i think it shows trends in GitHub's demographic

[Anonymous Coward]

with .NET it's the same, probably using some intern or microsoft specific versioning control program. We have our own servers to host our sources, we would never think about hosting it on GITHUB... So it also needs a certain kind of program...

Re:i think it shows trends in GitHub's demographic

[h33t l4x0r]

Any project related to jQuery or scss/sass has something to do with CSS but nothing to do with HTML.

Re:i think it shows trends in GitHub's demographic

[Anonymous Coward]

How is that? What is one styling if not HTML?

Re:i think it shows trends in GitHub's demographic

[Anonymous Coward]

They're styling HTML, but the HTML is generated by jQuery, so the files showing up in github are primarily CSS and javascript files.

Re:i think it shows trends in GitHub's demographic

[Anonymous Coward]

Easy: Most of the PHP files will generate HTML as output, and have CSS files associated with them, but github wouldn't see that as an HTML file.

Re:i think it shows trends in GitHub's demographic

[El_Muerte_TDS]

> java usage has increased at GitHub, but this more likely reflects greater adoption of GitHub by the business community.

Not to forget that Google Code is closing, Codehause closed, SF.net becomes more shit every day. They housed a lot of Java projects, and they are moving to alternatives like GitHub.

Re:i think it shows trends in GitHub's demographic

[angel'o'sphere]

You forget:
node
nodeJS
angularJS

and all the other mixed server/front end frameworks.

In business the trend right now goes to so called "full stack" developers that are fluent in Java, preferred Scala and nodeJS/angularJS depending on the architecture.

No one does C, unless he is forced by someone to do so, people usually do C++.

Re:i think it shows trends in GitHub's demographic

[h33t l4x0r]

jQuery for example uses CSS to target DOM elements. I think you can imagine why a CSS preprocessor it wouldn't use HTML for anything.

Re:i think it shows trends in GitHub's demographic

[kervin]

And isn't the business community part of "programming trends"? And hence should be included?

java usage has increased at GitHub, but this more likely reflects greater adoption of GitHub by the business community.

I can't understand the resistance to give Java credit here. It's one of the most successful modern programming languages and entirely open-sourced.

Re:i think it shows trends in GitHub's demographic

[Antique Geekmeister]

> No one does C, unless he is forced by someone to do so, people usually do C++.

Or they write in C and use a C++ capable compiler, like "gcc". A lot of "C++" code being published has no elements specific to C++.

Re:i think it shows trends in GitHub's demographic

[Gondola]

What does the number of CSS projects have to do with the number of HTML projects? There's no reason their numbers should correlate to each other at all on GitHub, especially considering neither is a programming language.

Re:i think it shows trends in GitHub's demographic

[narcc]

There's no reason their numbers should correlate to each other at all on GitHub, especially considering neither is a programming language.

This will either interest or agitate you. HTML5 + CSS3 has been proven to be Turing complete. Just to drive the point home, someone's even made the effort to produce a desktop calculator app using only those two technologies.

Re:i think it shows trends in GitHub's demographic

[phantomfive]

No one does C, unless he is forced by someone to do so, people usually do C++.

Uh, have you heard of Linus? A lot of embedded developers prefer C over C++, because there are fewer side effects. Other programmers prefer C over C++ because it has a cleaner design.

Re:i think it shows trends in GitHub's demographic

[flargleblarg]

That's just sick and wrong. But kinda in a cool way.

Re:i think it shows trends in GitHub's demographic

[angel'o'sphere]

I did a lot of embedded projects the last 25 years: everyone was in C++, non in C.

An Linus is now using C++ as well.

Perhaps you should look at the graph again, C++ is far above C.

And our parent claimed that C would be a prime chose, which it is clearly not.

Re:i think it shows trends in GitHub's demographic

[angel'o'sphere]

A lot of "C++" code being published has no elements specific to C++.
Never seen such a thing.
And frankly, professional code usually does not get published ;D

Re:i think it shows trends in GitHub's demographic

[phantomfive]

I did a lot of embedded projects the last 25 years: everyone was in C++, non in C.

If everyone was using C++, then your experience is obviously not representative.
If most people you associated with used C++ in embedded, then your experience is different than mine.

Re:i think it shows trends in GitHub's demographic

[phantomfive]

A cleaner design?! Hand re-implementing inheritance and polymorphism is cleaner? Hand implemented vtables is cleaner? Hand implemented intrusive containers are cleaner?! Lack of generics is cleaner?!

C has been described as a really nice assembly language, and it does that very well. It's easy to remember, easy to use, and is logical and fills its purpose. These are things you look for to determine a clean design. There were features that were left out of C because they didn't really fit.

On the other hand, C++ is a sausage factory. Features get added because people say, "oh look, that language has a cool feature." Half the language is deprecated, and no one can agree on the best way to use it. Different groups use completely different feature sets. The grammar of the language is complex, and few people understand it completely.

Saying "C has a cleaner design than C++" is not a surprising claim. The surprising thing would be to find any mainstream language that has a messier design than C++.

Re:i think it shows trends in GitHub's demographic

[Forever Wondering]

Right you are. Linus did a pretty good [well, succinct anyway :-)] job explaining this.

Here are a few more detailed reasons why you can't write a kernel in C++:
- C++ constructors [or destructors] can't return error codes. They can only throw exceptions.

- Leaving aside the fact that relying on exceptions (vs. checking error codes, which the kernel code already does at every step of the way) is largely unsuitable in a kernel [or an app even]

- The kernel has several modes/states: in ISR, in syscall, entering/leaving syscall, in kernel thread, in tasklet/ISR bottom half and most of those, if not all, an exception can't be used.

- Even you still wanted to try, the exception code that C++ generates can't be used in the kernel. It would have to be something custom.

- So, you can't wrap a lock acquisition inside a constructor [and release inside a destructor] because if you're in an ISR, you have to do "trylock" [and test the return code] instead of "getlock". Trying to wrap the trylock in a constructor requires that you be able to throw an exception.

- Nothing in C++ (inheritance, polymorphism, operator overloading, etc.) helps the kernel with the bulk of what it does (e.g. programming devices, ordering of FS writes with journaling, setting up page tables, etc.). A lot of things the kernel does are "dirty" jobs (e.g. some device interfaces are straight out of kafka, particularly for older devices).

- The linux kernel [and *BSD] are shining examples of how to program in C in a "clean" way, despite having to do a "dirty" job

- As to "object oriented" programming, the kernel already does a fair bit of it already, but without the fanfare/hoopla.

When Linus first introduced git, he gave a video talk. He said [paraphrasing] "It's all about the merging, stupid". To me, it's all about the debugging

Disadvantages of C++ over C:
- constructors can't return error codes, only throw exceptions. In C, you can choose what ever you want:
{
foo_t *new_ptr;
int errcode = alloc_and_construct(&new_ptr);
}
{
int errcode;
foo_t *new_ptr = allow_and_construct(&errcode);
}
{
foo_t *new_ptr = alloc_and_construct();
if (new_ptr == NULL) // error ...
}

- new/delete are operators and not functions [defective by design]. See http://www.scs.stanford.edu/~d... for a far better/in-depth explanation/condemnation than I could give.

- templates and stl -- they can simplify some code, but if the stl implementation has a bug, where do you put the breakpoint? Of course, the stl is like "Westworld" [1973] "Where nothing can ever go wrong ... go wrong ... go rong ..." :-)

- Try to explain to your boss that the reason you can't ship a product is because you used the stl heavily and you'll have to wait six months before the bug fix gets propagated to all the platforms you ship on.

- A simple "x = y" can generate a copy constructor [or two other things that I can't remember]. Trying to decide which one gets generated "at a glance" is problematic. The simple line may generate a lot of code that is slow. In C, there's little to no ambiguity (e.g. x/y are either simple types (e.g. int), pointers [to structs], or structs and the execution time is more easily predictable). There was a proposal a while back to come up with a C++ subset for realtime [IMO, why??? If you want realtime, just use C]. The one feature I remember was removing copy constructors [as evil].

- In C++, if you're trying to use some of the more advanced/powerful featur

Re:i think it shows trends in GitHub's demographic

[SQLGuru]

There was an article recently that showed that HTML5+CSS3 was Turing complete. http://lemire.me/blog/archives...

Which qualifies them (together) as a real language.

Re:i think it shows trends in GitHub's demographic

[K. S. Kyosuke]

You silly. What do you need inheritance for in C++, except for marketroids? C++ is nowhere near CLOS anyway, would you hand-reimplement generic functions or meta-object protocol in C++ by the same measure? I mean, that's your argument - C++ must be crap because some other language is vastly more capable.

The main problem with C++ is that even at 1300 pages of spec, it does so little. The power/weight ration is simply horrendous, that is what is dirty about it. I'd rather work in a language that can do 80% of the stuff in a 20% of C++'s size than to ever touch that crap. Pity that something similar to Modula-3 hadn't caught on instead.

Re:i think it shows trends in GitHub's demographic

[K. S. Kyosuke]

My favourite mind bleach after reading any piece of C++ code. Arguably, some things in that could be extended, but still...

Re:i think it shows trends in GitHub's demographic

[Antique Geekmeister]

A great deal of professional code is published: it's key to the Apache foundation and the Free Software Foundation. And a great deal of the more straightforward being published as "C++" for lightweight applications is standards compliant C. I just went through a similar issue with a job applicant who wrote backend website processing: That person's code had _no_ C++ elements in it, written for the simplest and most reliable compilation. It was very lightweight, the libraries it required were very stable, and it had _no_ dependency confusion common to the "overloading" of C++ functions. I was quite pleased with their code.

Re:i think it shows trends in GitHub's demographic

[Tablizer]

Java usage has increased at GitHub, but this more likely reflects greater adoption of GitHub by the business community.

I would suspect it has more to do with Android apps. It will be interesting to see if Oracle's legal games change that.

Re:i think it shows trends in GitHub's demographic

[ultranova]

There's nobody who uses CSS without HTML

JavaFX uses something that looks a little bit like CSS. In fact CSS is theoretically applicable to any kind of hierarchical scene graph, you just need to define what object types exist and what properties they have. You'd think that'd be more widespread nowadays, when every project requires programmers and multiple artists to work together and modding is all the rage.

Re:i think it shows trends in GitHub's demographic

[angel'o'sphere]

Ofc my experience is not representative.

However I'm a bit tired about posts of people who have no experience at all :D

"All embedded software is done in C!" ... So Android stuff is not embedded? A GPS running on Android or an Rasperi PI is not embedded?

As I said before: more than half of the embedded development in the world is in C++. And ALL embedded development I was involved in the last 20 years was C++ (or meanwhile in a few exceptions: Java)

Re:i think it shows trends in GitHub's demographic

[ultranova]

Inheritance violates encapsulation. If you have three classes X, Y, and Z (X is the base class, Y inherits from X, and Z inherits from Y), and each has various fncX1/fncX2/..., fncY1/fncY2/..., and fncZ1/fncZ2/... Now, you instantiate class Z. Then, when you use Z.fncX1 you're violating encapsulation because you're having to have [incestuous] knowledge of how Z was implemented in order to know that is has [by virtue of a two level inheritance from X] that Z.fncX1 is valid.

But how does that violate encapsulation? You yourself talked about the difference between "is a" and "has a". "Is a" is not an implementation detail, it's a declaration about the API of the class.

Re:i think it shows trends in GitHub's demographic

[Antique Geekmeister]

> Might be because the systems I was involved in where not supposed to run on washing machines.

Then you don't look at Linux device drivers, and apparently don't look at highly performance optimized daemons. That's fine: you may not have needed to do this.

> That is a non sense sentence. What exactly is an unreliable compilation?

"Unreliable compilaton" could mean many things. Code that is likely to give different results based on subtle compilaton option differences, such as optimization levels, due to assuming default population of uninitialized variables is my current favorite. Code that produces different binary functions dependent on compiler assumed architecture is another, such as using "int" versus "uint_32", is another older favorite from when I did more porting of 32-bit code to 64-bit environments. Code that relies on replacing system libraries with its own particular "tuned" versions of libraries or standard OS functions is another, since it becomes vulnerable to inconsistencies in the compiler flags and a developer who fails to set them correctly can get surprisingly inconsistent behavior.

Other features do not so much prevent compiler inconsistency, but help with programmer consistency. Following the local style guide, using consistent naming schemes for variables, keeping memory handling in one consistent area of code so "free" and "malloc" are easily tracked, and sanitizing I/O before relying on it are all aids to consistent behavior.

Re:i think it shows trends in GitHub's demographic

[mr_mischief]

You can also make a box of toothpicks and a handful of rules written in crayon on a piece of notebook paper for how to arrange those toothpicks on a tabletop Turing complete. It still doesn't make it a suitable programming tool. Also, 9*111 was not, the last time I checked, equal to 99. So it doesn't seem to be a very successful desktop calculator in Chrome 44 on OS X at least. HTML is a markup language and CSS is a styling and presentation language. Yes, one can press them into service to write crude programs given enough effort.

I find it interesting they've been found Turing complete as a pair, but it still doesn't make them programming languages, especially individually.

Re:i think it shows trends in GitHub's demographic

[Tablizer]

If you bring suitability into this then we could potentially do a lot of slicing and dicing* of the statistics. JavaScript is not suited to be a systems software language for building GUI engines, for example, but has ended up that way through historical accidents.

* No corporate pun intended

Re:i think it shows trends in GitHub's demographic

[phantomfive]

However I'm a bit tired about posts of people who have no experience at all :D

True, if someone says embedded only uses C, then they are not correct either (I know of one chip that includes an embedded python interpreter).

Android barely counts as embedded though, maybe........it's a fairly advanced system.

Re:i think it shows trends in GitHub's demographic

[angel'o'sphere]

I think iOS and Android blurs the line where embedded is on one site and "ordinary" software is on the other side.

Remember that embedded version of windows? It was mainly aimed to car entertaining, radio, navigation systems.

iOS and Android are from an architectural standpoint not very similar.

Re:i think it shows trends in GitHub's demographic

[angel'o'sphere]

I suggest you once work in a company/team that actually does embedded development instead of populating forums, web sites, blogs etc. with your nonsense.

Then you don't look at Linux device drivers, and apparently don't look at highly performance optimized daemons. That's fine: you may not have needed to do this.
This is not embedded software development so out of scope of this discussion.

Code that is likely to give different results based on subtle compilaton option differences,
If that is so, it is a compiler bug and has nothing to do with C versus C++.

Like the rest of your comment!

Re:i think it shows trends in GitHub's demographic

[phantomfive]

iOS and Android are from an architectural standpoint not very similar.

How so?

Re:i think it shows trends in GitHub's demographic

[angel'o'sphere]

Sorry, I typoed, ment to say: "very similar". Delete the "not".

Re:i think it shows trends in GitHub's demographic

[phantomfive]

lol
too bad, I was looking forward to a subtle exposition of some differences that I had overlooked.

Re:i think it shows trends in GitHub's demographic

[angel'o'sphere]

I fear it is more likely that I overlook something ;D
My age is catching up with me ...

Re:i think it shows trends in GitHub's demographic

[Forever Wondering]

is_a/has_a is so you can determine if you can/should inherit. While the standard literature might say that the inheritance is part of the class definition, it's also an implementation detail of the given class. Radical idea, no? Read on ...

Back to school for the sake of common ground: An airplane is not an engine. It has an engine. An airplane is a vehicle. So airplane could inherit from vehicle but would have:
engine_t engines[4];

Encapsulation has two definitions:
https://en.wikipedia.org/wiki/...

(1) A language mechanism for restricting access to some of the object's components.
(2) A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data

I'm talking about (1), and also using it for information hiding.

For reference below, a "Z user" or "user of Z" means ordinary code that does not inherit from Z.

Referring to my original X/Y/Z example, suppose X or Y was a pure abstract virtual class. That is, all member functions were:
virtual void fncX1() = 0;
virtual void fncX2() = 0;
A side comment here: the "= 0" seems bizarre. Back when it was created the mantra was to avoid new keywords [at any cost]. Wouldn't "virtual void fnc() pure;" or "pure virtual void fnc();" be easier to grasp?

Thus, Z would have to provide real definitions for fncX1, ... and they are part of the definition of X. Thus, any user of Z would be blocked from trying to "go around" Z to get to X member functions. A side benefit is that a user of Z would only need to look at X to find the functions that could be used.

If one of X's member functions is not pure virtual, Z doesn't have to provide a definition for it. But, suppose the creator of Z does not want a user of Z to access a particular X function. C++ has public/protected/private but not on a per-function/member basis for classes it inherits from.

So, how does the user of Z know whether accessing X::fncX6 (via Z::fncX6) is what the Z author expects/intends? Nothing in the language prevents it if X is a public ancestor of Z.

What I would want is that for any function in X that is not specified in Z, no access is allowed to any user of Z. In other words, you'd need an explicit [not the keyword] definition of a member function:
Z {
alias void fncX1() to X::fncX1();
}

In more standard terms:
Z {
void fncX1() { X::fncX1(); }
}

Thus, Z must clearly spell out all functions that can be used. The usual way might be to make Z inherit from X as private, then Z would have to provide public functions to allow controlled access to X. If Z doesn't want a Z user to access X::fncX6, it just doesn't define Z::fncX6.

So, a user of Z can see everything at a glance. If the author of X adds a new function, it is not usable by Z until the Z class gets a definition. This would be the case if X were pure virtual as Z lacking a definition of the new X function would generate a build error.

But, I'm talking about enforcing that restriction for regular classes. Yes! For a base class that had 50 member functions, that would require each child class to provide 50 definitions. A possible workaround would allow some wildcard matching:
Z {
alias fncX[1-20] to X::fnc[1-20]
}

Consider the following development timeline:
(1) Author X creates class X with public functions fncX1, fncX2, and fncX3
(2) Author Z creates class Z that inherits from X (as public) and adds fncZ1 and expects that users of Z will have access to fncX1, fncX2, and fncX3 [and fncZ1]
(3) Author X adds fncX4 and some additional stuff that author X will find unsuitable.
(4) Author Q starts u

Re:i think it shows trends in GitHub's demographic

[ultranova]

A side comment here: the "= 0" seems bizarre. Back when it was created the mantra was to avoid new keywords [at any cost]. Wouldn't "virtual void fnc() pure;" or "pure virtual void fnc();" be easier to grasp?

How about "unimplemented"? Why try to come up with witty synonyms when there's a perfectly accurate word in the English language already? Especially since "pure" already has a completely different meaning in relation to functions: it's a function that has no side effects and returns a value that depends only on the parameters.

By the same token, "virtual" is less clear than "overridable".

My notion is that any public class hierarchy that allows fncX4 from class X to show up in class Z without an explicit definition in Z violates encapsulation.

Suppose W is a private member of X. Suppose the author of W changes some public function W.f which X relies on so that another function X.g develops a bug. Has encapsulation been violated? Remember that any complete and unambigious definition of W.f is itself already an implementation.

If your code references any outside code in any way, it can be broken by unexpected changes in that outside code. That loss of control is the price you pay for not coding everything yourself. It's not avoidable by any means whatsoever.

However, it seems like your specific complaint could be solved with a simple addition of syntactic sugar: "private X someName (exports: public: fncX1, fncX2, fncX3)" which would make compiler generate the corresponding proxy functions for you (or better yet, just make Z.fncX1 be a synonym for Z.someName.fncX1 for all purposes except checking for access permission).

Re:i think it shows trends in GitHub's demographic

[david_thornley]

Literally nothing you wrote there is a reason to use C rather than C++. C++ can optimize at least as well as C (typically, in implementations where there's any cost to throwing exceptions, there's a compiler switch to disable them), since it can do anything C can do and more. Your idea of "unreliable compilation" has absolutely nothing to do with C vs. C++. Your "features" that help with programmer consistently are not C-specific, and frequently C++ smart pointers are superior to trying to tracking "free" and "malloc".

You strike me as somebody who's simply ignorant of C++, but who wants to spout opinions on it anyway.

Re:i think it shows trends in GitHub's demographic

[david_thornley]

Let's see.

If you want to write a constructor or destructor that returns nullptr rather than throwing in C++, use "(nothrow)". You can normally avoid throwing exceptions, and many compilers have "no exceptions" as an option. C++ is just as suitable for the "dirty jobs" as C is, and object orientation is a lot easier in C++ (I've done both).

Your rant on "new" is by somebody who didn't understand what he was saying. void * is indeed a hole in the type system, and even in C its use is very limited. You really can't do much with a void * without casting it to something else. If you need raw memory in C++, you can always use "new char[X]". You'll have to cast from char *, but you'd have to cast from void * anyway. (For people who have used C for a long time, malloc() used to return char *.) If you want to make sure it's deleted properly, use std::unique_ptr.

Overloaded operators are easy to abuse, but they are powerful when used properly. C++ is a more abusable language than C. The equals sign calls the copy constructor only in initialization, by the way, and that's pretty obvious.

I've not seen any problems with the STL in over five years, and then it was an obsolete version anyway. I've never heard of anyone having to wait for a bug fix that couldn't be worked around (except that one in a COBOL compiler that one time). The STL libraries are written in standard C++, and you have to have the source to a template library.

You're willing to blame "advanced features" for slowing things down, but not giving credit for speeding things up. There's a lot of C++ stuff I use simply because it's a fast way to get readable, correct, code. If you have examples of things that are a net loss, and that people actually use, get more specific.

If you're learning C++, learn C++ as you're going to write it. If there's any need for a class on basic data structures, address that need. If you're going to pick a simple language to learn so you can cover those, consider Python, which is faster to learn than C. (I'm a fan of Scheme as a beginning programming language, but that's me.)

I note that you are confused by polymorphism. If you lack the mental capacity to use C++ properly, use something else, sure.

As far as inheritance, pretty much everything I read on the subject says to keep inheritance trees short and don't overuse it. Any newbie around here using it as other than a "is-a" relationship is going to get corrected in the code review.

Inheritance doesn't violate encapsulation. Your examples are, quite frankly, stupid. If you add a capability to a superclass that you don't want in a subclass, you're doing it wrong. Inheritance is "is-a", remember? If you're going to pull something out of an inheritance hierarchy, which is not something I've seen, then, yes, you'll have work to do. C++ is easy to abuse, yes. It's also very powerful.

Having done a lot of C++ work for three companies, in none was the RTTI forbidden, and all allowed std::dynamic_cast. If I worked in an environment where I couldn't use std::dynamic_cast, there's things I can do to make std::static_cast efficient and safe. You see, I actually know what I'm talking about, and I know how to write C++.

Re:i think it shows trends in GitHub's demographic

[david_thornley]

After some unobjectionable stuff (except that I wouldn't specify exactly four engines in an airplane), you misunderstand a pure virtual function and an abstract base class. A pure virtual function can have an implementation (it just isn't automatically used), and an abstract base class doesn't need to have all functions pure virtual (sometimes there's reasons to have standard implementations of some but not all functions). I've never heard anybody complain that "= 0" was really confusing; if they know what it is, fine, if not, they know how to find out what it does.

If a subclass doesn't want to use a public inherited function of a superclass, you're doing it wrong. You might want to look up "Liskov substitution principle" to find out why in more detail. What you seem to be saying is that, if a bunch of incompetents write a C++ program it'll be a mess. That's pretty obvious, and applies to other languages as well. If your scenario does happen, you really need to hire somebody competent. Alternatively, find another job before that company collapses. If an author makes Z a public subclass of X because of shared functionality, the author is incompetent, and the code would be of a quality you'd expect from incompetence (note that private inheritance wouldn't have the added-function problem). If an author removes Z from an inheritance tree, then either the author is incompetent or Z should never have been there in the first place.

Public inheritance is not an implementation detail, it's an interface issue with optional implementation. Private inheritance, or composition, is an implementation detail, and I prefer composition. You need to understand that, so you understand why doing what you suggested with Z is wrong, and why it's going to cause problems that a programmer using inheritance properly wouldn't have.

Re:i think it shows trends in GitHub's demographic

[Forever Wondering]

The rant on new (the stanford paper) was not mine. And, it was about new being an operator instead of a function. BTW, I've been programming in C for 35 years (+ 10 before doing C). I haven't seen malloc use char * in at least 15. And why does one need to use std::unique_ptr to force C++ not to be "cute"?

The RTTI is disallowed at Google and C++ is their goto language. It's also slow. There was a recent usenix paper https://www.usenix.org/confere... that has a CaVer tool for detecting bad downcasts. It does much of what the RTTI does but as a tool. It could easily be adapted into an alternate RTTI implementation and it's much faster than RTTI (e.g. it uses RB trees instead of walking the hierarchy with string compares)

C++ makes code easier to write, but because it's easy to abuse, it's harder to review/debug. Because, you have to detect the abuse, which can be much harder. Particularly when you have to peruse 50,000 lines of code to get the first clue as to the bug.

Inheritance does violate encapsulation. See a better example I did here: http://slashdot.org/comments.p... You're assuming you control the superclass instead of just inheriting from it. That is, the author of X and Z are the same programmer, or even in the same organization. Read that post, especially the timeline.

In C, if you "inherit" a class, you can do so thus:
Z {
X z_x;
}
At first glance, that looks like a "has a" but it's really an "is a" in this context. That is essentially what C++ does [invisibly] and in C you just do z.z_x.fncX4 instead of z.fncX4. And, you can put a comment that says "// don't use fncX12" in Z. So, if you do that, how do you classify it?

"x = y" can generate a copy constructor or a copy assignment operator. If either of these is overloaded in the class, they can generate a "deep copy" whether you want it or not. In C, "x = y" either copies the scalar value, pointer value, or does a struct element by element copy (e.g. can be done with memcpy). In C, if you wanted a "deep copy" (e.g. a member has a char *, and you do a strdup), you'd create a "deep_copy" function and you'd say "x = deep_copy(y)". That is explicit as to intent.

Another example: "x += y" might generate a huge amount of code because the creator of the X class decided that the "+" and/or "+=" operator should do things with a database. That's an abuse. The creator clearly abused things, but the [hapless] programmer trying to find this would have their work cut out for them. They're not going to be able to check every "+" statement for "is this overloaded in an insane/abusive way?". If the "+" were actually a member function called "plus" or better yet "addto", a reviewer would be much more clued in to look at the "addto" function than a simple "+".

Or, the "+" operator is defined such that if you were using an unsigned int it prevents wrap (e.g. 0xFFFFFFFF + 1 --> 0xFFFFFFFF instead of 0--common for some video calculations and saturation). Somebody who is not the original author would probably not realize this on the first pass through the code and might take much longer to realize that this is the bug they're looking for (e.g. the value needs to wrap to 0). If you want FF+1 --> FF instead of 0, create a sat_add function that does the job. You'd have to do that anyway in any OO lang that doesn't support operator overload (e.g. java)

And, don't get me started on ">>" and "" for streams. This is one of C++ most obvious "hacks". People realize how defective it is, but swallow it, because it's ubiquitous and idiomatic, but nobody should try to defend it.

As to polymorphic functions:
void foobar(int i)
void foobar(float x)
void foobar(int i,int j)
Is that incorrect?
What the trial found was that:
vo

Re:i think it shows trends in GitHub's demographic

[Forever Wondering]

I wouldn't do engines[4] IRL, but, c'mon, this is slashdot. It's hard to post meaningful code fragments using what they provide. Would engines[NENG] be less objectionable, even if I hadn't defined NENG?

The whole point of "= 0" is that it came from a time in C++ when adding new keywords was eschewed because C++ wasn't fully adopted and the more new keywords used, the more places it would blow up C code that was being ported. For example, I do believe I had a function called "new" and when I recompiled the code in C++, I had to rename it. These were the cfront days. The early adopters of C++ were C programmers looking for a better way.

When C++ first arrived, it was billed as an incremental addon to C [to get quicker mindshare/acceptance]. Nowadays, it's considered a language in its own right, with a native compiler. But, cfront had some advantages. You could do "cfront xyz.cpp" to get xyz.c and compile that. Having xyz.c to look at, you could see where "x = y" generates "deep copy". To do that now, with a modern compiler, you'd probably have to generate the .s file and peruse the assembler output. So, which is really better?

C++ was brought in stealthily lest it frighten off the C programmer base at the time. Now, C++ adds keywords just fine: template, mutable, explicit. But, why not use "+++" for mutable? Or, "---" for explicit? If mutable/explicit had been in the language at its inception, these keywords would probably have gotten some quirky syntax instead. But, I'll tell you, when I first saw "= 0" some 20+ years ago, my first reaction was "WTF?". So, if you would find "+++" objectionable instead of "mutable", that's the reason I prefer "pure" over "= 0". The only reason you're not hearing objections about "= 0" is that it's part of the language, no matter how quirky it may be. Try showing it to a java programmer. Nowadays, if "= 0" didn't exist, and somebody wanted to add "= 0" in lieu of a keyword, the general reaction would be "burn the keyword and we'll adjust our code to fit rather than add more quirky syntax". Another case: why use "class" [a new keyword] instead of "@struct". Using class added something. But, it's just shorthand for "struct { private: ... }".

Why have [our now favorite class :-)] Z's constructor be "Z" and the destructor be "~Z"? In other OO languages, they are _creat and _destroy respectively [squirrel, I think]. Personally, I prefer _creat/_destroy, but "The mayonaise you like is the mayonaise you grew up with".

I do believe I mentioned handling things by having Z inherit privately from X. Then, create public forwarding functions in Z, leaving off the offensive fncX12.

Most of the code I write uses composition. I have a number of objects that have doubly linked pointers. And, I have standard routines for these. Consider:
Z {
Z *z_prev;
Z *z_next; ...
}
In C, I'll usually have a bit of either metaprogramming or macros that do:
Z {
DLINK(Z,z_); ...
}
where DLINK is:
DLINK(_typ,_pre)
_typ *_pre##prev;
_typ *_pre##next;
The traversal is handled with a FORALL(lst,cur) macro. This is:
cur = lst->head; cur != NULL; cur = cur->z_next
This stuff is available to code outside the class. Thus, the links need to be public (in C++)

Now, in order to get the same cur->z_next in C++, you can do the above, or you can inherit from a zlink class that might be generated from a template with the appropriate type (e.g. Z) that has the low level stuff in a dlink class. The template generated code does upcasting to the dlink class. So, you can, for example, have a single copy of dlink.check_list_integrity without having to do massive casting by hand.

I've also done this via:
Z {
dlink z_dlink;
}
But, I find this

Re:i think it shows trends in GitHub's demographic

[david_thornley]

I don't make arrays anymore unless I really have to. Unless there was a good reason not to, I'd use a std::vector instead of an array.

C++ started out as C with Classes, and then developed into its own language. It's not just "nowadays". BTW, if I want to know if a copy is deep or not nowadays, I look at the copy constructor and/or copy assignment operator. I don't see that examining what the compiler spits out is any more convenient.

I'd say that "= 0" is more readable than "+++", and it seems to fit into the meaning. We're already used to overloaded keywords from C, such as "static".

If I want a doubly linked list, I use std::list, and I iterate it using the container-based for statement (for auto element : container). That's a lot fewer opportunities I've got to make mistakes. It also means I'm not polluting the namespace with macros.

I fail to understand what the practical difference is between C and C++. You write unclear C, and if I'm on the code review you'd better fix it. The exact same thing is true of C++. The reason you don't violate the Liskov Substitution Principle in C++ is the exact same reason you don't write "if (x = y)" in C: you're writing confusing code. I have no reason why you'd think C++ doesn't trust the programmer, since there's LOTS more things you can screw up. BTW, modern C++ code isn't just object-oriented, it's also generic. Whether you use OO or templates depends on the situation.

BTW, C++ has mixins and trait templates. Mixins are just an application of multiple inheritance, and an innocuous one since you're not risking the diamond inheritance pattern. Trait templates are just functions or values that get filled in differently depending on the type or value used to instantiate the template.

Re:i think it shows trends in GitHub's demographic

[david_thornley]

std::unique_ptr isn't to solve a purely C++ problem; it solves a C problem by ensuring that there are no memory leaks or double freeing or use after free. If you have to get rid of the memory now, without waiting until the end of the block, that's what the .reset() member function is for. I didn't say that the "new" rant was yours, but you linked to it, and it was clearly by somebody who didn't understand C++ well enough. There's lots of that going on for lots of different programming languages, which is why I look over language criticisms to see if they're making serious mistakes.

If you can do something in C, you can do it in C++. Unless you're using something like C99's variable-size arrays (which always looked like a mistake to me), it's usually trivial to convert standard C code (I believe the Linux kernel is written in C90) to C++ code that means the exact same thing. There's usually going to be something in C++ that can do something a little better than C. Whether you want to do this is another matter, of course, and when Linux was being started C++ compilers tended to be unreliable and unstable, so C was the right choice there.

C++ is indeed more abusable, but it can be written more clearly than C in many cases. If you take advantage of that, it's often easier to find bugs, and there are entire classes of bugs in C that don't exist in well-written C++. If you have to look at thousands of lines of code to find a bug, it doesn't matter if it's in C or C++, you aren't going to find it on a code review. C++ has more complicated code than C, but it's also much more expressive, so well-written C++ will probably be less buggy than similarly well-written C.

Google has unusually restrictive C++ standards. They make sense for Google's situation, but not in general. We have our own standards, and we make constant use of things Google forbids. If we used Google's standards, our code would be longer, less readable, and buggier.

Inheritance doesn't break encapsulation if done right. Private inheritance can't violate encapsulation any more than composition can, and public inheritance should always follow the Liskov Substitution Principle, and so adding functions to a base class is not a problem. If you screw up, then, yes, your code can be screwed up, but that's true of any language. Remember, private inheritance and composition add implementation, while public inheritance is primarily for interface, although it usually carries a lot of implementation with it. (Similarly, it is possible to abuse operator overloading. So what?)

The functions you call "polymorphic" aren't. Polymorphism is a property of inheritance, and there is none. The word you're looking for is "overloaded". In your example, you'd have problems understanding only in particularly large functions, and only if the functions did functionally different things. If you're doing that, you're doing it wrong.

And, yes, I have done OO in C. You know what? Compared to C++, it sucks. There's a lot of stuff you have to write to make it work, instead of being able to write it easily.

Odd

[Anonymous Coward]

What, no COBOL?

Re:Odd

[aNonnyMouseCowered]

LOL. I do find Ruby's position surprise. It outranks Python and all three C-derived languages! Where do they teach this stuff? Certainly not in school, where C rules. (I can understand the lowly position of HTML, which while probably the most popular computer language ever is too basic to be worth a Github.)

Re:Odd

[ArhcAngel]

What, no COBOL?

You meant that humorously but there is evidence it's star is on the rise.

Re:Odd

[phantomfive]

The Ruby community was one of the first groups of people who noticed github. That's why there's so much Ruby.

Programming?

[lorinc]

If it is about programming, then why are CSS and HTML along the list? These are rendering languages...

Re:Programming?

[smittyoneeach]

Hey, hey, hey: everyone gets a participation trophy, mister.
We don't want anyone feeling diminished because their specialty is not considered "programming".
More seriously, especially with CSS, the capacity to design something that doesn't look like a mud fence is a substantial skill.
That is: don't discount the work just because it executes subjectively in the mind of a user. You want to know where the sale is made? It sure ain't in the elegance of the design patterns buried in the server code.

Re:Programming?

[angel'o'sphere]

Because:
a) lots of stuff hosted on GitHub is HTML
b) the guys making such graphs don't know the difference between a programming language and a mark up language
Stop bitching and deal with it ;D

If it was an article comparing languages regarding programming, I would agree with you!

Re:Programming?

[Viol8]

"More seriously, especially with CSS, the capacity to design something that doesn't look like a mud fence is a substantial skill."

So is riding a unicycle while juggling. That doesn't make it a programming language.

If CSS ever supports logical, mathematical and iterative operations then maybe it deserves to be on this list. Until then - no.

Re:Programming?

[lorinc]

Making beautiful interfaces is a very valuable skill, of course. But it still isn't programming. It's like you're making a list of top flowers and you rank tomatoes 6 in that list. That doesn't make any sense.

Re:Programming?

[Antique Geekmeister]

Because they are both used with API compliant software to accomplish specific computer behavior, including I/O, programmed operations, and back end integration with style guides, QA verification, and clear functional success of the computer application if misused or if ocrrectly implemented. They may not be Turing complete and able to compile their own interpreters written in their own language as source code, but they're certainly "languages" as far as listing them on a resume or planning training are concerned.

Also, they're quite a _lot_ of the hosted code on github: it's certainly reasonable to acknowledge their roles in open source.

Re:Programming?

[smittyoneeach]

I fell short of saying CSS is programming: "it executes subjectively in the mind of a user".

Re:Programming?

[Gondola]

Next up: the TXT, NFO, INI, and CSV programming languages!

Re:Programming?

[Khashishi]

HTML+CSS is turing complete
http://lemire.me/blog/archives...

Re:Programming?

[ChrisMaple]

You've never seen a tomato flower? https://upload.wikimedia.org/wikipedia/commons/0/04/Solanum_lycopersicum_-_Tomato_flower_(aka).jpg

Re:Programming?

[ClickOnThis]

HTML+CSS is turing complete
http://lemire.me/blog/archives...

Well, so is TeX, but you'd be insane if you used it for serious programming. The same goes for HTML+CSS.

Re:Programming?

[serviscope_minor]

HTML plus CSS is Turing compete.Someone proved that by implementing rule 110. Quite astonishing, but they're you go.

http://lemire.me/blog/archives...

Re: Programming?

[slack_justyb]

Not hating on your comment but I'm going to toss out less and sass/sass script. Additionally CSS does support matching syntax, mathematic operations like every even/odd/nth selection, and has a pretty diverse query notation. So that said, not saying that qualifies it as whatever someone says is a "programming" language, but CSS has come quite a way from what a lot of people think CSS does. So just so we're clear, I'm not disagreeing with you here, just augmenting the idea of CSS here.

Re:Programming?

[NBarnes]

My understanding, though I haven't looked into it myself, is that CSS is Turing-complete.

Re:Programming?

[ADRA]

A CSV based scripting/DSL language could actually be viable, though terribly ugly. Admitedly HTML & CSS are arguable. You can write some pretty elaborate selectors in CSS, but I'd still consider it a declarative markup over a language. Its probably just a conspiracy to keep bash outside the top 10!

Re:Programming?

[infidel_heathen]

Just because something is Turing complete doesn't mean I would want to program in it. I would rather use HTML5 + CSS3 for the purpose they were designed for (rendering web pages), and use a proper language to program the backend.

OTOH, I agree with putting HTML & CSS on the Github's top 10 list, since it takes skill & practice to develop in those as much as in a conventional programming language.

Re:Programming?

[serviscope_minor]

Just because something is Turing complete doesn't mean I would want to program in it.

Oh gosh no. But I think "Turing complete" is the only objective definition of a programming language I can actually think of. Befunge, Intercal, Brainfuck and ahem sed are all programming languages, but one wouldn't want to program anything in any of the first three (and anything but some simple text substitutions in the case of sed) except for fun.

HTML+CSS certainly earns the classification of "Turing Tarpit".

Javascript copies

[Meneth]

I think Javascript may have had its ranking artifically inflated due to all the libraries people copy into their own repos, like jQuery and Bootstrap.

Re: i think it shows trends in GitHub's demograph

[Anonymous Coward]

Eg there might be 20,000 lines of CSS, 600 lines of HTML and 500,000 lines of PHP (which is capable of generating billions of lines of HTML but GitHub doesn't see any of that).

Since when are HTML & CSS programming language

[Viol8]

They're page layout and style description languages, NOT programming languages. They have no place on this list. Otherwise you might just as well include troff & latex too.

Small sample size in the early years?

[m.shenhav]

There is a possibility that the early adopters of GitHub just randomly happened to be using particular programming languages. One needs to see the number of users/projects along side this ranking plot.

This relates to the evolutionary process of random drift, and in particular to one manifestation of it known as the founder effect.

Re:Since when are HTML & CSS programming langu

[DamonHD]

LaTeX is astonishingly versatile (as evidenced by the underlying TeX \primes demo macro for example) and I spent way too much time 'coding' in it to make my thesis look pretty for example.

And plenty of non-imperative computer languages still require skills of scope and data design etc etc, from Prolog through SML to any of the functional languages, never mind the JS/HTML/DOM/CSS nexus.

So I think you protest too much.

Rgds

Damon

Interpreted labguages

[Anonymous Coward]

I found it very interesting that 9 of thr 10 top languages are interpreted rather than native code labguages. That seems to indictate a strong focus on the part of the projects/people who use GitHub.

# github projects != language popularity

[tomhath]

All this shows is a count of github projects by language. I expect that the vast majority of those projects were created by people trying to learn a language by working through tutorials. It would be more useful to display languages by number of downloads or something like that, so we could see what languages are actually being "used" rather than what languages self-taught programmer wannabes are trying to learn.

Re:# github projects != language popularity

[Anonymous Coward]

Posting AC due to mod points: I'm someone who has spent a lot of time on websites like Project Euler and Code Eval practising and learning new concepts regarding the programming languages that I'm learning, Code Eval for instance with their problem sets has taught me a lot about pointers, malloc, FILE pointers, mmap and so on in C. I have been considering lately uploading my solutions to github in a private repo because I rely on multiple operating systems, hard drives, machines and locations when using computers. Having a centralised repo would help me to see where and why I've made fundamental changes to programs for efficiency or combating errors such as segfaults. The fact that I can then login to github and download the exercises that I've done are an added bonus. I don't only use github for 'programming', I've got books written in LaTeX, cheatsheets written in MarkDown and configuration files for programs that will come in handy should I need them with bash and batch scripts to deploy the configs and change variables to a new value such as a username or password from '' to "$username". Github isn't only used for those who wish to upload code for deployment.

And InfoWeek Has Posted the Inverse

[kjhambrick]

http://www.informationweek.com/it-life/11-programming-languages-that-lost-their-mojo/d/d-id/1321678?f_src=informationweek_informationweek_mostpopular_fornewsletters&_mc=NL_IWK_EDT_IWK_daily_20150822&cid=NL_IWK_EDT_IWK_daily_20150822&elq=70d72d20140f4602a92820472e5c17fa&elqCampaignId=16221&elqaid=62985&elqat=1&elqTrackId=35c8af5f447d4d2a8f19ad601c98a3be/

Re:And InfoWeek Has Posted the Inverse

[SQL Error]

Well, that's depressing. Great languages like Ada, Algol, Pascal, Modula-2, and Logo, and in their place we have PHP and Javascript.

Re:And InfoWeek Has Posted the Inverse

[ChrisMaple]

If it weren't for Borland, nobody would care about Pascal or have investigated further to find Modula*. Waste of time and effort.

Re:Since when are HTML & CSS programming langu

[willy_me]

LaTex is horrible for programming in. Painful does not even begin to describe the experience. But LuaLaTeX is different - it allows you to script using Lua thereby making what used to be horrible, feasible. Very useful for automatically generating tables based on external data.

Re:Interpreted labguages

[Anonymous Coward]

That's because many of them are toy/easy-access languages, and GitHub has a lot of "look ma, I'm a coder too" users.

Re:perl is dead

[preaction]

Since Github reports half of my Perl 5 code as Perl 6 (all my test files), neither show up on the report. But, keep thinking that as you want.

HTML is a programming language?

[rnturn]

Us old-timers always called HTML a markup language. Just what did the author think the "ML" stood for?

No VB?!

[BECoole]

N/T

Re: i think it shows trends in GitHub's demographi

[Anonymous Coward]

If it's based on lines of code then it would explain why JavaScript is number one. Everyone has to keep a copy of the gazillion libraries javascript requires in their repos for easy deployment. One place I worked at they had 400k lines of code but most of it was libraries for node.js and etc. Our python code was much shorter even though the custom lines were much longer. Also javascript sucks so everyone writes a new library to try to make it better and easier to work with.

Re: i think it shows trends in GitHub's demographi

[Anonymous Coward]

Does there is no C++ compiler count as being forced?
Still lots of 8 and 16 bit CPUs left if the world. An they do not all have C++ compilers. Some are still at ANSI C89.
Not everyone works on desktops and servers.

Re: i think it shows trends in GitHub's demographi

[boteeka]

That's not accurate. Rather, jQuery uses the same DOM selectors to target elements as CSS does.

Re:Unique?

[phantomfive]

Excellent point.. If github does de-duping, they might be able to extract such stats.

De-duping? They don't even recognize languages correctly. They list that I have Objective-C code in some of my projects, but I have no Objective-C code in any of my github projects.

popularity lol

[Anonymous Coward]

c is far too powerful for most of the script kiddies pretending they are real programmers these days.

If a programming language doesn't hold their hand, actively keeping them from drawing outside the lines with their little coding crayons, they can't write code to save their lives.

But that's ok. That's why they can't take my job. :)

Re:Unique?

[phantomfive]

Why should I accept a pay cut for you?

You shouldn't. When a recruiter contacts you, ask him for $1000k.

Re: i think it shows trends in GitHub's demographi

[h33t l4x0r]

The selectors are CSS selectors. The elements are DOM elements. Otherwise I think we agree.

Re:Interpreted labguages

[Kyogreex]

Both C++ and C are on the list, and both are native languages unless we're talking about C++/CLI. And then Java and C# are compiled to an intermediate language and run on a VM, not really interpreted. So you have 6/10 really. Which is quite a bit, but not nearly as much as 9 out of 10 makes it out to be.