Programming Language Rankings: June 2016
redmonk.com
redmonk.com
1.) Clojure fell back
2.) Elixir, though small, is still moving forward
I've been a fan of Clojure since 2009. It grew rapidly for a few years, from 2009 till at least 2014. It has stalled out. This makes me sad because I've loved working with it and I think it a great community, in most ways. But it is true that the community has been unable to answer some of the criticisms leveled against it. The reliance on Emacs has meant it is not easy for beginners. On the other side, the elite (the purists?) have wanted to see Clojure be more like Scheme, or more like Racket, or more like Haskell. Clojure has offered up many interesting ideas, but perhaps hasn't quite built a complete eco-system that makes it broadly appealing.
Elixir, though very small, still seems to be moving forward, and perhaps has a chance to answer some of the demands that people made of Clojure (more pure? easier syntax?). Maybe Elixir is the language that make the Functional style the dominant style in computer programming?
Most of the places I work will only allow the use of a language that is in the top 10. I am not allowed to introduce Clojure, because it is not popular enough. But if I told management "We should use Angular" that would be an easy sell. You sentence would be more accurate if you had simply written:
"You can use Javascript/Node/Angular irrespective of how good they are, but you can't use something that is great because a sometimes ill-advised majority of managers base their decisions on their estimate of future risks."
Coupled with the setting "Settings→Editor→Smart Keys→Surround selection on typing quote or brace." it's amazing.
^1 As an aside this is why I'll never be satisfied with plain Java/JavaScript no matter how many new static features they get so long as they remain fundamentally opposed to the build-up style of programming.
^2 By beginner I mean to Clojure; I don't think Clojure is a good language for programming beginners. It is suitable for people as a second or later language, but not their first. So basically I agree the need to explain the preferred editing environment is a hurdle -- if the person's first language was Scheme, maybe there wouldn't be a problem since you don't really-really need paredit or syntax highlighting or auto-indent or anything besides the ability to edit and save text.
^3 For me that's just a separate terminal in a screen session that a vim plugin talks with, though there are others (and probably better, I haven't tried them seriously) for vim.
At the time, Leiningen was still in its infancy and I hit a lot of issues getting things running but when I finally did the language had a profound impact on me as a developer.
I think Clojure will remain in the developer culture for that. Clojure will be recognized for its action in LISP resurrection and functional programming renaissance. It's often said that "The Velvet Underground's first album only sold a few thousand copies, but everyone who bought one formed a band.". It's the same for Clojure: there will be never a lot of apps, but I'm pretty sure that all the developers who learned Clojure became better developers, developed good libraries in other languages, started a blog, etc.
Some people might hate Java and search for alternatives on the JVM, but 90% of the production code on the JVM, its commercial variants, and Android is plain Java.
Also ClojureScript is not 100% Clojure and most web shops across the world only care about JavaScript.
Likewise, the majority of developers targeting BEAM will be using Erlang.
If something I learned from my Turbo Pascal/Delphi, Oberon experience, is that programming languages that aren't considered a first class experience from the platform owners never manage to get a significant market share, long term.
The thing I like most about Elixir is the low friction between it and it's host language, Erlang. Erlang is a functional language right from the start, and the BEAM is designed to run a functional language, which means you never hit the weird FP-OO barrier that comes up so commonly in Clojure.
I really think the impedence mismatch between Clojure and the underlying Java implementation is a big, painful problem which is going mostly unacknowledged by the inner-core of the Clojure community. And that makes sense, because they're all (or mostly) "Java Guys" who are already sold on the Java ecosystem and are fine with there being a layer of spindly OO horror in their projects. They don't mind the Java layer poking through in unpleasant ways.
When I bring this up in a congregation of Clojurists I just get "shrug, welp, Clojure is a hosted language", not even an acknowledgement that there may be a problem worth discussing.
For the rest of us, the FP enthusiasts who don't have an emotional or professional attachment to Java, this sucks, because you can't do much in Clojure without also touching Java. As I said at the start of this ramble, Elixir/Erlang don't suffer from this problem, it's FP all the way down. Erlang idioms fit in with Elixir, and vice versa. No friction, no bullshit.
One final point: I think the Elixir team visibly care about ergonomics and good design, much more than the Clojure team seem to. Look at `mix` and compare it to `leiningen`, honestly. Look at Plug and Phoenix and compare to something like Luminus in Clojure-land. The difference is night-and-day. Look at how fast the `iex` repl boots up, or how fast the stop-compile-start workflow is in a Phoenix app. Even look at the content of the languages respective homepages (http://elixir-lang.org and http://clojure.org)
I'm not quite sure what you are expecting. It is a tradeoff they explicitly made.
I've yet to see another platform come close to rivalling the JVM ecosystem. It is a powerhouse.
I think it's a great tradeoff. From a team and organisational productivity point of view unless you are based on either the JVM, the CLR, or have fantastic c/c++ interop you are dead in the water.
Elixir made some solid gains this quarter, and it's based on the BEAM VM, so not JVM/CLR, and not great c/c++ interop. It has great concurrency support, and is widely regarded as being rock-solid.
Haskell fell one spot, but it's still in the top 20, and it's not based on the JVM/CLR, and doesn't have great c/c++ support. The library support is similar to the situation in Python 3, and I've written plenty of performance sensitive Haskell code that's within 2x the speed of c.
It's a big world out there, and there are so many great languages. The JVM/CLR definitely provide a nice head-start, but they're not the only way to build a good language.
NIFs work quite well even if htey have quirks and are limited. And with ports and Dirty Schedulers, you have other solutions for more complex and longer things.
Not perfect, but there is a good story here.
On the Clojure/JVM side, Java 8 is far from perfect but the lambdas expressions have made the language a bit less boring. I think many developer feel less the urge to leave Java for an alternative language. And if they really want it, there is Scala, still the best strong statically typed language on the JVM, and so, for me, still the best language for backend development.
In short, Clojure/ClojureScript was for me the best language for rapid prototyping and for front development. I've never really considered it for "serious" backend applications based on a complex data models, because of its dynamic typing. However, JavaScript development became much more pleasant, making ClojureScript less attractive, less differentiating. I believe that today, you have to be a true Clojure fan to code in ClojureScript.
However the comparison beyond language features is very much relevant, including the lack of Android support in Scala 2.12
Adding to the woes, the code emitted by 2.12 is slower ( https://news.ycombinator.com/item?id=12066653 )
Not to say things can't improve. After the initial announcement of 2.12 at ScalaDays 2015 and 2016, expect more at ScalaDays 2017.
Anything else it is up to the respective language communities to make it work.
Right now only Kotlin seems to be improving their Android support, but that is because JetBrains needs a killer application for it, which appears to be improving the world of those stuck in Java 6.
They were very clear at the AMA:
"Anwar: Nope, not happening."
"Anwar: We don’t have any plans to officially support a new language in Android, so we’d encourage folks to continue to use Java:) That said, you should continue to use what works for you."
https://www.reddit.com/r/androiddev/comments/4tm8i6/were_on_...
People have to get over the fact that regardless of what happens in the Oracle vs Sun, the Android team which has a quite a few Sun alumnis, doesn't want to use anything else.
Even the NDK is designed in a way that native C and C++ code is always exposed via Java native. The example code on the NDK start page is pretty clear how they see the NDK.
https://developer.android.com/ndk/index.html
"The Android NDK is a toolset that lets you implement parts of your app using native-code languages such as C and C++. For certain types of apps, this can help you reuse code libraries written in those languages."
And another fun fact is that given the NDK constraints, having Linux as kernel doesn't matter that much, they could change to something else and only OEMs would notice.
Even Microsoft is only improving the Objective-C support on their iOS bridge, in spite of the Swift support requests, at least for the time being.
If you check Brillo, which is basically Android without the Java layer, their plans are to create a C++ Frameworks layer not Swift and not Go.
I would guess there's probably quite a few VB6 applications out there in business-land, and it's been EOL'd since 2012 IIRC. Not that most people would want to deal with them, but they exist, just like Java 6 in Android.
We did consider (and regret) potentially leaving android behind, but we were (perhaps naively) hoping that something like retrolambda would suffice, or that android would catch up. In any case, it doesn't make a lot of sense to have 2.12 still support Java 6, since most of its features require Java 8 (those that don't, we first implemented in 2.11.x).
As announced in http://scala-lang.org/news/2.12-roadmap/, we will continue to support 2.11 for a bit longer than most releases, and we welcome community backports of 2.12 features that you'd like to see in 2.11.
Presumably 2.11 won't be supported going forward? Or as someone who would like my libraries to work on android and doesn't particularly care about them being callable from Java 8, should I just stay on 2.11 indefinitely?
a) Java 6 is forward binary compatible with later versions
b) Google has a reasonable excuse in terms of the Oracle lawsuit. Don't get me wrong, I'm not happy about Android being stuck on Java 6, but there are extenuating circumstances.
c) Scala 2.11 has issues that affect me and I want to see fixed. Java 6 doesn't, at least not that I've noticed. (If JVM 8 were necessary to the implementation of a Scala feature I cared about I would understand that, but as far as I can see it's irrelevant to my use cases)
I don't want a SBT based build that eschews the way Android developers work.
I want a setup that embraces Gradle (even though we love to hate it), Android Studio GUI designers, plugins and annotations.
Last time I mentioned this, someone pointed me to
http://scala-on-android.taig.io/editor/android-studio/
which hasn't been updated in ages.
Using InteliJ with Android support means always being outdated as it is usually two versions behind from Google's fork.
It's pretty easy. You have to setup less things than with Gradle, because SBT deals with all the downloading, installing and managing of the two dozen SDKs Google wants you to use.
> I want a setup that embraces Gradle (even though we love to hate it), Android Studio GUI designers, plugins and annotations.
You can keep all you Gradle configuration. SBT-Android has a Gradle support mode so you can e. g. use the Gradle definitions for your IDE, but enjoy the fast turn-around and compile-times of compilation with SBT.
> Last time I mentioned this, someone pointed me to http://scala-on-android.taig.io/editor/android-studio/ which hasn't been updated in ages.
Yeah. The documentation is at scala-android.org. If you feel something is missing, I think the maintainers are happy to read your ticket.
> Using InteliJ with Android support means always being outdated as it is usually two versions behind from Google's fork.
The current IntelliJ is pretty much up-to-date with current Android Studio.
Sorry but it is not.
Android Studio 2.2 is about to be released and IntelliJ IDEA 2016.2 only supports the plugins from Android 2.0 with caveats.
https://www.jetbrains.com/idea/whatsnew/#v2016-2-android
"The update includes the Android Studio 2.0 features: faster Emulator, experiment GPU Debugger, faster full builds, and code generation and testing for App Indexing. Note, Instant Run is not fully-merged yet."
If you want to drive adoption, it should work on Android Studio as well.
This is what I usually mean by using first party platform languages versus relying on third party support.
For Kotlin, all I need is to install the plugin on Android Studio and am off to the races.
And still I am not using it, because there are a few rough edges with all the Android workflows.
What is preventing you from doing that with Scala?
I see that you filed a ticket that the setup of IntelliJ != Android Studio, but is there anything that works in one, but not the other? (Except having to skip the "install android support" from the install guide?)
I don't get the whole dooms day scenario.
- Google is working on Java 8 support.
- The current version of Scala supports the current Android stack.
- Depending on the timing, the next version of Scala might also support the then-current Android stack.
- You can always use Scala-for-Android (aka 2.11). Just think of it as a flavor like Scala-JVM, Scala.js or Scala-Native.
More than anything specific though, I don't want to be stuck on an old version as the language moves forward.
> I don't want to be stuck on an old version as the language moves forward.
How are you going to be stuck? You might need to stay on 2.11 a bit longer until Google gets their shit together. Most likely this will be during 2.12. Sure, you might miss the first few minor releases of 2.12 ... but stuck?
We're working on the performance issue, with help from the team at Oracle. The problem is likely the JIT having trouble optimizing the bytecode we emit in M5 (we know of other schemes that don't suffer this slowdown, but require more bytecode).
Read the article and you will notice that Scala 2.12-M5 will solve some of this slower code emittion. It's in the middle of your linked article.
At the moment, still using ES 5 (for an Angular 1 app), as we have to support IE 11 and started the project a while back before Angular 2 shipped.
I'm more interested in the functional-friendly features of ES 6 / 2016 (tail call elimination, gather/spread params & return values operations, etc) than I am in emulating Java with TypeScript. Also, I actually like JS, and would like to avoid a transpiler step.
I would like to clear something up, though. TypeScript is not very much like Java, in my experience. To me, it feels like programming in JavaScript but with type annotations where you want them. If you think that TypeScript will make programming like Java, I'd encourage you to at least reevaluate that position.
I guess the patronizing and uncooperative attitude towards the community plays its part. If you don't accept Rich Hickey and Relevance / Cognitect / whatever they call themselves nowadays as the ultimate source of wisdom, your opinion is worthless and you're "Doing It Wrong™".
But on the other hand, they're very much keeping the tradition of the of the Smug Lisp Weenie alive, albeit as a caricature rather than a rebirth.
First as tragedy, then as farce.
I didn't find any resources on how other Clojure programmers deal with this problem, but this eventually lead me to drop Clojure and Clojurescript, and use Elixir and Elm instead.
Parallel programming in Clojure is nowhere near as well developed as the glory of OTP on the Elixir/Erlang platform.
If you trim out all the worthless SO questions/anwsers you'll get radically different rankings on redmonk. JavaScript could very easily drop from its first place doing just that.
I don't get why people chase popularity in programming languages. That's what you do in a pop culture, not in an engineering one.
"I don't get why people chase popularity in programming languages"
I am forced to do this simply because I consult at companies where the managers do exactly this. They will not let me use a language unless it is a top language. If I say "Clojure would be excellent for the project that you have in mind" they will reply "We can not use Clojure because it is not popular enough. We have to use a language where there is a large pool of developers that I can hire, and there is no risk that the language will disappear in 5 years."
I've seen companies of 300-500 employees struggle to keep even a single senior programmer over half a decade. They'd get far more talent by actually embracing an engineering culture. What I always see is that the juniors start getting experience, realize the place they work at is a huge pop culture and leave for an engineering one, thus lowering the talent pool of said company.
Basically they don't want smart engineers, they want replaceable code monkeys. They have yet to realize there's a few orders of magnitude worth of quality and productivity between the two.
I used to work in such an environment until I had enough of this cancer and decided to move to a small studio with less than 30 employees but with a very strong engineering culture.
I recall reading about someone (was it Spolsky? IDR) who looked for candidates with certain niche languages on their resumes, because it served as a quality signal. If they're interested in learning Clojure, for example, they may just be more generally curious and/or have a desire and interest in learning about different paradigms.
That said, at a practical level one has to balance competing demands. If you have someone on your team working on a project in X and they're the only X developer you have, you're at risk because if they leave, you may be screwed. Plus, they won't be getting quality feedback on their work because no one else can understand X.
And yeah, Spolsky did talk about the perils of Java schools here: http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool... Great article!
Having a single guy work in X can be bad indeed, but if you want to try something new its much safer than switching entire departments overnight.
According to Alan Kay, the whole computer industry is a pop culture.
https://news.ycombinator.com/item?id=4956430
http://queue.acm.org/detail.cfm?id=1039523
http://www.drdobbs.com/architecture-and-design/interview-wit...
That's wrong. Every civic engineer I know, for example, would prefer standard, and lacking that, popular nuts, bolts, construction parts, materials etc, over niche ones, unless there's some very pressing reason not to. They are cheaper and available in greater volumes, you can find skilled workers easier, their properties are more studied, etc.
That's even more important in programming, where ecosystem, availability of libraries, continued support on the language and compiler, availability of skilled programmers, existing codebase support, etc, matter even more than pure language level issues.
Popularity in a language is crucial, to the point that other attributes, like expressiveness, or even speed, can be inconsequential compared to that.
And while engineering can be a pop culture (e.g. Mongo or the latest fad), popularity is important for aspects that are totally counter to pop culture too: namely, pragmatism.
Programming is not about using what's "best", it's about using "what's best given business constraints" (which is something else altogether).
Besides, the hipster figure who listens to obscure music because it's "best" is also a pop culture phenomenon -- not to dissimilar to certain programming cults.
We're already allergic to frameworks where I work and we're slowly moving away from libraries as well given how low quality the average open-source library is. Once you realize you spend more time debugging open-source libraries than your own codebase, you stop caring about popularity.
If you hire developers for what they know right now, of course you'll limit yourself to only the popular languages/frameworks. Its much more lucrative to hire developers for their potential to learn and grow; these people will make the best of any language/library/situation.
Of course, like you said, economics come into play but my point is that the popular choices often lead you to a path where you end up with a lot of mediocre developers, terrible architectures and endless conceptual debt. At the end of the day this is much, much more costly and doesn't even yield quality software.
Also, isn't the alternative of debugging open-source libraries writing the functionalities you need yourself? Working with faulty open source library is tedious, but that work can be seen as way to contributing your time to make open source library better for everyone.
Most libraries out there will do a LOT of things I couldn't care less about, making them harder to integrate and debug and reason about, on top of bloating your executable.
I do agree there are a lot of amazing libraries out there and we do use a lot of them. But that's after analyzing them and figuring out they solve our problems and actually will save us time. For the vast majority of libraries we look at, its usually faster and better to roll our own.
See, the problem is, you still need to use frameworks and libraries, you just end up rolling your own, and now you are responsible for supporting and documenting all the different use cases your developers have. If I have an issue with, say, React.js, I can tap into the pool of the thousands of Stack Overflow questions and discussions, whereas I can't do that with a home-grown framework. Unless I'm doing something really low-level, I'll take the thing that has had thousands of man hours poured into it and an entire ecosystem built around it over the thing that you made because you're "allergic" to open source. You're going to be debugging someone else's code anyway, but the time spent doing that with open source frameworks is offset by the time saved because you don't have to build everything from scratch.
I won't have to write my own framework by not using one, while it may be easier to use one, its far simpler not to use any. You spend so much time trying to fit your use-cases into the framework's paradigm that its usually much faster to just write from scratch. Every single framework I've seen so far had huge scalability issues, they're easy to get started with but you end up crippling your agility as the codebase scales.
As for rolling our own libraries, we can make them specifically for the use-case at hand without anything extra. What's the point of using a few dozen libraries when you only use a fraction of each and now your bundle is megabytes in size? And that's not even counting all the extra code required to wire them all together. There's a reason why we say the web is bloated.
Consider the corners in the graph off the line. E.g. - SQL: "nobody" is making voluntary github projects with it, but it generates a lot of questions (the legacy code quadrant). Alternately, there are fewer things below the line, but those would be the things that people are using, and NOT being regularly confounded by WTF they do :-)
While R is certainly not a general purpose language (yet?), it is very much an FP type language, and gaining in popularity. I have only tinkered with it a little, but it looked pretty sound.
> if ("blah" == "blah") {
y = 2
x = y + 2
} else {
x = 1
}
> x
4
> y
2
Does R have an "IIFE" type construct, similar to JS or Golang?
1) I've decided that static typing is the world I want to program in, for a wide range of reasons.
2) The JVM (and JS) have their limits, and Clojure is just not as portable as I'd prefer.
Otherwise, I learned a lot from working with Clojure over many hundreds of programming hours, and it is an impressive feat of engineering, but it's limitations are insurmountable at this point.
A lot of what I learned in Clojure I can now use in C++ since the C++14 version of the languages supports a lot of functional programming techniques (though not thoroughly). C++ today is not the language it used to be, and the ability to write and use standard library higher-order functions with my own simple anonymous functions is really nice.
"my_username has X repositories written in Shell, Makefile, C++, and C. Follow their code on GitHub."
The trouble is that I make this statement from a place of intuition, conscious of my own biases, so I could be wrong.
I don't think it very accurately reflects what's used in real life, either for the innumerable hours of boring everyday programming work that people do or even what kind of code is being cranked out in the major open source projects - the ones that are actually used by other people.
What it does provide is an interesting leading indicator: what's hot right now. Languages like clojure which get a lot of attention for a while but aren't used in a whole lot of real applications tend to peak and then drop relatively quickly.
As you said, this is still interesting, even if not accurate in absolute terms, as an indicator of what technologies are currently emerging among passionate developers.
That's a bit oversimplified IMO. SO doesn't reflect "interest in" as much as "having difficulties with". There must be "WAT"-type effects vs. simple, intuitive languages like Go factored in for it to provide useful information regarding popularity. It's a bit like counting hospitalized patients with sports injuries to rank sports activities by popularity.
As for the relevance of github - people are always claiming their language detection is broken and I'd worry about the (intentionally?) skewing effects of moving the core language/library development to github.com like the Go project did.
They are using it to have difficulties, so I think it is an interest in. Also, perhaps those that are beginners in things might have more questions, and show that also shows interest.
This redmonk has some horrible graphs, and as you said, the method at which they categorize on github is flawed, let alone using stackoverflow or github as indicators being flawed.
Which obviously stands in contrast to the reality that there are many enterprise systems - some of them mission critical - still running on the platform.
But from our perspective, that tells us less about what might be used moving forward than what is actively being discussed and written in by developers on the platforms we survey.
So no, we would not argue that these rankings accurately reflect the current distribution of languages within large enterprises. We do feel that the actions of a large number of developers from two different properties has the opportunity to be more predictive, however.
Anything other than C and Assembly is sacrilege.
(Also, I think the comparison to CoffeeScript is rather unfortunate. In my mind, CoffeeScript was primarily addressing shortcomings in JS that JS has, since, done quite a bit to rectify. Julia is not trying to be a better "X", so there's no "X" to steal away its momentum.)
As for Julia 2.0, it was decided to put off implementation of traits and interfaces until then. That said, some of the ideas that were being bounced around during the post-con Hack day in these areas are really exciting. In short: Julia may be the first language to pull off behavioral typing in a practically usable way.
I think its already a Killer general-purpose language (except for the module system).
I'm just not sure if it is good enough to unseat incumbents when there are things like rust with its deterministic memory management or python with all its momentum and compiler technology coming along.
Not sure whether to bet on it at this point.
This is also why I'm excited by what's coming next in v2.0. Some of the early ideas being explored at JuliaCon with respect to traits and interfaces will begin to really shine a spotlight on its true power.
I've noticed this. I've been using it the past four years for much of my dissertation work (starting right when it was released). Julia's type system has the potential for some extremely cool things.
I've been toying around with the idea of making a package that focuses on runtime static typing. This would be particularly useful when using the language interactively (like in a Jupyter notebook). The idea is to perform a check at runtime to make sure all variables in a function are assigned an immutable, concrete (non-abstract) type, and then compile an optimized version of that function on-the-fly . One source of pain in a lot of my Julia code is that unintentional type instability contributes to a lot of unnecessary performance penalties, and it takes quite a bit of poking and prodding before I figure out exactly which line is responsible. Forcing a check over the function would prevent these occurrences.
I also seem to have the problem of inadvertently calling functions that allocate and deallocate tiny amounts of memory on the innermost for loops.
(Then again, maybe nobody else has these issues and I'm just bad at deducing when AbstractVector can't be used.)
> Then again, maybe nobody else has these issues and I'm just bad at deducing when AbstractVector can't be used.
Nope, not just you. This is definitely an issue.
[1] https://github.com/astrieanna/TypeCheck.jl [2] https://github.com/tonyhffong/Lint.jl
I haven't heard of behavioral typing before. What would be an example (or pseudo-example) of this?
If you're familiar with duck typing, behavioral typing is (in essence) the reification of duck typing in a concrete type system. In other words, instead of specifying the type of your argument as "Array", you could specify "some type that is indexable, iterable, and can be appended to".
In Julia (mind you this was just the idea I saw being considered), today you would do:
function foo(myarray::AbstractArray)
...
end
function foo(myarray::ANY{getindex(), setindex(), iterate(), append()})
...
end
typealias Arraylike ANY{getindex(), setindex(), iterate(), append()}
function foo(myarray::Arraylike)
...
end[0]: https://dzone.com/articles/duck-typing-scala-structural
In Julia, objects are data-only and methods are defined at a module level. So, whereas Scala's structural typing need only introspect the object being passed as an argument, Julia's behavioral typing requires introspection of the entire dispatch tree. The benefit to behavior typing and Julia's multi-dispatch is that if you are missing one or two methods for some type in order to be able to use it in some function, you can always define the missing methods locally.
For example, with Go you can build a standalone executable in many platforms, and other languages run on interesting targets like browsers or phones, or run on the JVM.
Any news on that front?
Of course, in this regard Julia is not any different than Python, Ruby, JS, PHP, etc. Also, it's worth noting that Julia has cluster-computing as a concept baked into the language. So, whereas you might need to worry about distributing Go executables to multiple machines in a cluster, with Julia you need only have the Julia runtime installed, and from there any Julia program can distribute itself to any available nodes without further action required.
:%s/Julia/[your favourite challenger language]/g
Also apparently stackoverflow julia questions have clear exponential growth.
That being said, the macro perspective - in which Julia is growing more slowly than other languages, or arguably not at all - is relevant for those wishing to see more adoption.
This has huge impact on the ranking - it does not seem right to me..
Making analyses and comments on these data is futile, as I have already argued directly (and with vigour on my side) with several Redmonk employees in the past. This didn't end well, since I'm pretty passionate about these things in particular, and "the truth" in general (vs. "opinions").
I'm sure real scientists could do some interesting work on this subject, but Redmonk's methodology is anything but scientific, and in consequence, their results are just content marketing, not something that you should base business or engineering decisions upon.
It's not a perfect analysis, in part because there isn't one, but we've found it interesting both as a snapshot in time and for observing long term trends.
If they simply count existing lines of code/SO questions and none of those ever get deleted, then inertia is bound to increase.
The more old lines of code/questions there are, the longer it takes for any new language to rise in the rankings, even if the new language is used for all new code.
But I don't know enough about the methodology of this study. Maybe they are doing something against this statistical incumbency effect.
2. Talent pool in said languages.
I'm guessing that VB uptick was from VB devs finally discovering git?
In this example as often, the website would be more readable without responsive design.
Maybe the people who do get comfortable with it end up using it a _lot_.
While both TeX and Emacs Lisp questions are still treated on StackOverflow, it probably explains why TeX in particular appears to be such an outlier. (It's sure not because people aren't having trouble with it. The stackexchange site is indispensable.)
When Google own teams rather use Typescript, it speaks a lot about it.
> the difficulty of growth is proportional to the rankings themselves – as one rises, so does the other.
OF COURSE this will be the case when your analysis is looking at total cumulative usage instead of current usage (i.e. deltas in cumulative usage)!
For example, say language X has been around 20 years, and language Y 5. Language Y could be 10 times more popular than language X today, but if the analysis is counting 20 years of accumulated code in X, X will easily rank higher.
I hunted for their methodology, and found none. Nothing they say indicates they are doing delta analysis. Since such analysis would not be trivial and be a lot more expensive, I'm pretty sure they'd mention it if they were doing it.
To corroborate my criticism, the TIOBE Index, which measures signals where accumulation is less a factor, shows much more movement over time, with languages rising and falling as one would expect: http://www.tiobe.com/tiobe_index.
Its C++, just hidden.
https://www.arduino.cc/en/Hacking/BuildProcess
'Arduino' is simply a set of C/C++ frameworks for the peripherals and a simple IDE.
Its just that its called C++... and it isn't a distinct and separate language.
This study is generated by and aimed at people who know the difference. Therefore, its a mistake.
One could argue that because Cobol is the language of choice for large banks using mainframes, it is superior at doing tasks required by financial applications. Somehow I doubt that it has anything to do with that.
the popular languages seems to fall more on stack overflow side
those on the line are vanillas