Since I've been interested in how the Functional paradigm might help us developers deal with concurrency, there are 2 items here that really strike me:
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?
A few (rambling) thoughts, as a long-time Clojure dev who's recently been focusing on Elixir.
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)
> 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.
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.
According to these rankings JavaScript is the most popular language, and it's not based on the JVM/CLR, and it doesn't have great c/c++ interop. Other compile-to-JS languages like Typescript, Elm, and Idris are in the same boat.
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.
Small correction : there is a good (not stellar but good) interop with C/Rust/c++ on the Beam.
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.
I also dropped Clojure/ClojureScript, even though it was my favorite language between 2012 and 2014/2015.
The main reason for me is the progression of Java and JavaScript during these years, which make ClojureScript less useful. ES6 has completely transformed the JavaScript development. I finally enjoy to code in JavaScript - this wasn't the case before. On the contrary, coding in ClojureScript became painful. It's difficult to follow the recent trends, to integrate new libraries without hassle. Currently I work on a project that use DraftJS. I don't want to know how to integrate it in ClojureScript ! It's a waste of time, and again the "joy of Clojure" still exists but is now less superior to the "joy of Javascript".
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.
The Android team did a AMA on Reddit this week, they were pretty clear that regardless of people wishes only Java, C and C++ matter on Android.
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.
"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."
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.
"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.
I don't understand why Scala would drop the Java 6 backend. Surely Android is a big enough "market" to be worth maintaining it as a compilation target? Particularly now that Scala is expanding to be very clearly multi-backend (ScalaJS as first class, Scala Native starting up).
> Every time I think about using Scala and go through the list of configurations I need to do, I just give up.
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.
"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.
> For Kotlin, all I need is to install the plugin on Android Studio and am off to the races.
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 guess no-one cares enough to support it? Definitely a shame though. (In the rare cases where I write Android apps I stick to Eclipse, stick to Maven, use Scala, and for me it all works - but presumably people have their reasons for preferring android studio/intellij).
Fair enough, but there are bugs/missing features in Scala 2.11 that I want fixed, and they're going to be fixed in Scala.js and Scala-Native so it would be a real shame if they weren't fixed in Scala-for-Android at the same time.
The usual ones, I'm sure. Poor syntax for type lamdbas. Unification across kinds (hopefully possibly going to be backported to 2.11). All the ways of expressing union types (or indeed basic enums) are a bit clunky. Irrefutable patterns in for/yield constructs compile to a silly withFilter call. PartialFunction/Function having the wrong subtyping relationship. mapValues being lazy when all the other functions on the same interface are strict. Stream implementing the collection interface.
More than anything specific though, I don't want to be stuck on an old version as the language moves forward.
Huh? None of that will be in 2.12 except unification, and that's already planned for backporting to 2.11 (and you can just use the compiler plugin until then).
> 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?
Where are you getting this confidence that Google will "get their shit together" quickly, or ever? I can easily imagine Google not shipping Java 8 for as long as Oracle remains in business.
Hi, Scala team lead at Lightbend here (I left academia in 2012 to lead the team). We dropped Java 6 because we did not anticipate any business case for it, based on surveying our customers (we have continued to monitor the adoption of Java 8 amongst our customers, and everyone is upgrading, save for 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.
> 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).
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?
Yes, if you're tied to Java 6, you're also tied to Scala 2.11. Why is the former version peg ok but not the latter? We do everything we can to enable 2.11.x maintenance by the community (and contributions are trending up!), as well as doing some of our own -- time permitting. If you'd like to get commercial support, we do offer that to our customers.
> Yes, if you're tied to Java 6, you're also tied to Scala 2.11. Why is the former version peg ok but not the latter?
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)
Yes, but from a "business" standpoint, Java 6 hasn't EOL'd. If your business needs to build Android applications, it doesn't matter that it's technically EOL'd.
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.
In addition to being supported by the community, we (Lightbend) offer commercial support for Scala 2.11. If you're paying Oracle for Java 6 support beyond its EOL, perhaps you'd be willing to establish a commercial relationship with us as well? That said, the vast majority of our customers are eagerly upgrading to Java 8 (https://news.ycombinator.com/item?id=7346224, https://info.lightbend.com/COLL-2014-10-20-Java-8-II-Survey-...)
The code emitted by 2.12.0-M5 is slower in certain benchmarks, but I don't expect this to be the case for the final 2.12 release.
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).
Actually, I'm hoping to avoid TypeScript. Its use in Angular 2 probably makes it inevitable, though.
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.
To clarify, I wasn't trying to convince you to use TypeScript, just saying that it's taking a larger share of the compile-to-JavaScript crowd, along with ES2015, both competing with ClojureScript.
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 don't feel like clojure stalled out. You have to realize the redmonk rankings are using very weak heuristics to get these results. I'd rather choose languages and tools by how much they match the problem space rather than how popular they are at any particular point in time.
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. That's what you do in a pop culture, not in an engineering one.
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.
Having worked in both huge teams using popular languages/libraries/frameworks and small teams using what works best I'll choose the later any day.
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.
> 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.
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 never said I'm allergic to open-source, I said I'm allergic to frameworks and the vast majority of libraries out there. That leaves the few gems like React.js but they're libraries, not frameworks.
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.
I tend to think the other way - the more popular the language, the more mature it's open source libraries. For instance, there are amazing open source java libraries out that's been battle tested in the wild.
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.
As much as I like to contribute to open-source, the reality is I have budgets and deadlines to meet.
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.
"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 can understand in these environments they want to limit risks. And because the work is boring and the conditions are average to begin with, these companies are always on a massive roll of junior developers. It's especially bad if code isn't their main area of expertise.
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.
Yes, that, and the quality of applicants tends to be higher for some of the less popular but more interesting languages. I worked at a company that had a large java codebase and was reluctant to try anything different for fear of not being able to find developers. But then we'd get these applicants with dozens XML/JAX-WS related keywords on their resumes but who couldn't write a simple for loop or understand what a database transaction meant.
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.
I think its google who also asks for Python experience next to Java experience because it shows you went ahead and learned something on your own that wasn't spoonfed to you in school.
While others have pointed out the value of popularity, I think you make an interesting point about SO part of the ranking.
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 :-)
Because if you like a language and that language is popular, you're more likely to find a job using that language, which in turn will make you happier.
I will be blunt and state that neither of them matter.
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.
I agree and add even 90% sounds like conservative estimate. One reason I think is Java is good enough and the incredibly loud communities of smaller JVM languages have not produced enough libraries, tooling etc to attain a 'just works' title which is needed for most common type of development done by salaried workers.
I am not sure why Clojure is "stagnating". I don't think it's about Emacs, we have Cursive now which is very powerful and runs on top of IntelliJ. Clojure also is picking up in webdev. A new book just came out from Sotnikov, Arachne was announced recently, Om is being worked on, couple of different screencast series are being made, etc. I am not a seasoned developer but I like Clojure and I am sticking with it because it makes sense to me. I think it's an awesome language and I wish more people would try it and develop in it.
I am yet to do any web development project where the customer allow us to use anything other than JavaScript, eventually TypeScript but only because it is a Microsoft language.
Elixir's doing very well for its age—before 1.0 it had four books, a conference, and a dedicated video series. With the rise of Phoenix there's quite a lot mire of resources for it.
Clojure (and ClojureScript via Reagent[1]) is what got me into functional programming in the first place. However, as a developer working in a .NET shop I found more opportunities (e.g. .NET interop) to do "functional programming" in F#, which has also been well support cross-platform for some time.
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.
"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.
I think ClojureScript could benefit my team as both a productivity and performance boost. But convincing a large team to switch to a lisp is pretty much never going to happen. I might as well try to get everyone to switch to dvorak keyboards while I'm at it.
Clojure worked for me until I started to do parallel programming. I tried to use core.async but immediately found that I'm using two distinct style of programming, and code reuse became a serious problem.
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.
I don't think it matters much what these charts say as long as they do not measure merit and Clojure has a lot of it. You can use it irrespective of how an ill-advised majority of developers think Javascript/Node/Angular is good.
Please think about what you are saying when you write "You can use it irrespective of how an ill-advised majority of developers think Javascript/Node/Angular is good."
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."
Regarding the reliance on Emacs, might not be the case anymore. When I was new to Clojure, I immediately used an IntelliJ plugin called Cursive. It was/is great, same experience as writing Java in IntelliJ. (https://cursive-ide.com/)
But the problem is you really do need a "paredit" for your editor when developing in Clojure. It's a double whammy for beginners, and a huge one at that. Pretty much every other language ever is perfectly editable in everyone's editor as it exists today.
Check out parinfer! It's a great new editing mode for lisps that doesn't require memorizing any special commands. It's built into Cursive as well as my own IDE (Nightcode).
You don't even need a full-blown "paredit", just the ability to jump back and forth between different kinds of opening and closing braces. I've been using vim for Clojure exclusively since I first started dabbling with it in 2011, I'll die before succumbing to emacs... A bigger issue though is that to really sell Clojure you need to sell the alternate mindset of developing it represents as a lisp. With emacs, you can assume slime, and immediately you're exposing people to developing their code iteratively instead of the traditional approach of edit file, save, run from scratch.^1 With every other editor you need to first give beginners^2 something to approximate slime^3, or else you're going to present developing in Clojure the same as you'd present developing in Java, which is to say you'll lose a lot of the punch.
^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.
As a beginner I found that learning a single keyboard shortcut - Ctrl+W - "expand the selection to the surrounding semantic unit" was a huge productivity boost (the opposite action is Shift+Ctrl+W).
Coupled with the setting "Settings→Editor→Smart Keys→Surround selection on typing quote or brace." it's amazing.
My point is you have to use a paren tool to keep lisps sane. That's not true of any other type of language. So when trying to introduce someone to clojure, they see not only a very strange language but a new tool requirement as well. It really creates barriers to entry.
And for those of us who prefer editors (vs IDEs), Proto REPL for Atom (https://github.com/jasongilman/proto-repl) is a great option to work with Clojure. I think it deserves more attention, as it can help a lot with Clojure adoption.
Full time Clojure dev here who has been transitioning to non-Clojure projects recently, for two main reaons:
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.
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.
Regarding FP: My daughter is a (non CS STEM) student at UC. She knows one language: "R". (I tried to get her to learn Python in high school, but it never took)
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 that's the worst issue, I'm not seeing much of a problem. I guess I'm not particularly hyped about intro of "let" (block scope) into Javascript, vs "var" (function scope), either, but it bothered somebody enough to need "let".
Does R have an "IIFE" type construct, similar to JS or Golang?
When looking at github-provided data it doesn't make sense to differ between C++, C and Objective-C/C++ since the detection for these languages is still completely broken. For instance this project doesn't have a single line of Objective-C in it, yet github says there's 9% Obj-C in it: https://github.com/floooh/yakc. Similar oddities in my other C++ projects.
I have a bunch of repositories written in pure C (no C++) with a few Makefiles and some supporting shell scripts. When I google my name, the result from GitHub has the following description:
"my_username has X repositories written in Shell, Makefile, C++, and C. Follow their code on GitHub."
It reflects the biases of github and stackoverflow which tend to reflect the interests of enthusiasts and web developers.
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.
> It reflects the biases of github and stackoverflow which tend to reflect the interests of enthusiasts and web 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.
>SO doesn't reflect "interest in" as much as "having difficulties with".
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.
This is more or less our position. COBOL has never been ranked, for example, because COBOL isn't highly visible on GitHub or Stack Overflow. The last time we checked, for example, COBOL was present in 11 total repositories on GH.
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.
You are spot on. The reason why this list resonated with me is that I am an "enthusiast and web developer". It's confirmation bias at play.
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.
TIOBE seems to be the most realistic with history tracing back to 1986. C/C++ coders have tons of code not on github and a lot of references like books, which are sometimes more useful than SO. Also the metrics, native language and area of application are very important.
Tiobe seem to alter their methodology fairly often which afaik also has the effect of altering historical rankings.
In other words if you look at the TIOBE rankings on the wayback machine for a particular year in the past they can differ greatly from the rankings for that year given on the site today.
For example, I think that VB was affected greatly by this
I find TIOBE to be so far from reality I question why it exists and anyone continues to pay any attention to it. It still ranks Delphi higher than Objective-C. Assembly language above Visual Basic. Dart above Scala, Erlang, Haskell, and Bash.
TIOBE is much more about general computing/IT, evidenced by the relatively high ranking of things like COBOL and Transact-SQL. RedMonk, in contrast, seems more focused on pure programing (or, you might even say, the "hacker" community).
I prefer StackOverflow careers as an indicator of language popularity in the industry.
When you post a job you can only select 5 tech tags that accurately describe the position.
I have been scraping SO for couple of months now. If you want to dig into the data, right now it's aggregated as json.
I've been suspicious of Tiobe's ranking of C higher than C++ because I know hardly anybody using C any more. 90% or more of C/C++ programming I'm aware of is C++.
Embedded and system level programming is still done almost universally in C and that's a huge segment. In reality I'd say C is even higher, because only a small part of code written in it ends up on GitHub, the rest is deep inside legacy systems.
C rules the roost in embedded Linux devices. I suggested in my team that we move to C++ and was met with incredulous reactions. To be honest the only thing I seriously miss in C is std::vector.
That one makes more sense to me. There's no legacy platform that only supports Objective-C and not swift, so virtually all the developers switched to the more pleasant to use language.
But there's almost a decade of existing Obj-C code (I'm guessing iOS apps comprise the bulk of objective C code). I would have thought porting that To Swift would be a Herculean effort - but I'm not using either language so maybe I'm not best placed to talk about this
Hmm...I wish they had taken a bit more time to dig into the situation with Julia than simply to note it moved from position 51 to 52 on the ranking (is that even a significant shift?). Having just come from giving a presentation at this year's JuliaCon, I am more optimistic about Julia's future than at any point in the past. I think what we're seeing here is that Julia is making a concerted push toward v1.0. It was announced at JuliaCon 2016 that they are targeting JuliaCon 2017 for the v1.0 release. It should be expected, then, that the break-neck pace of innovation has taken a back seat to a focus on stability, but based on what is already on the roadmap for Julia v2.0, I don't see Julia moving anywhere but up.
(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.)
This is sample selection bias. Cavorting with converts at their conference is always going to lead to a temporary afterglow of bullishness and says nothing about adoption rates.
I think there's a general misconception that Julia is a DS/scientific programming focused language. It just so happens that these are areas where its advantages are most apparent, and give the biggest early wins. Given enough time, though, I think the paradigms that Julia is exploring will make it a killer general-purpose language.
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.
"Given enough time, though, I think the paradigms that Julia is exploring will make it a killer general-purpose language."
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.
The thing about Julia is that it's playing a whole different ballgame than pretty much every other popular language today...it's just that most people don't realize it yet! The work and design that's gone into Julia's type system and multiple dispatch has the potential to be a real game-changer, but outside of a core community putting it to good use, I don't think it's potential has been fully realized.
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.
> The thing about Julia is that it's playing a whole different ballgame than pretty much every other popular language today
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.)
It is unmaintained now, but you might want to have a look at [1], which builds on the type inference system to add some static checks. I believe there may also be some related work in [2].
> Then again, maybe nobody else has these issues and I'm just bad at deducing when AbstractVector can't be used.
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
but in the future you might be able to do something like:
function foo(myarray::ANY{getindex(), setindex(), iterate(), append()})
...
end
what's really neat, though, is combining this with type aliases, you could have:
typealias Arraylike ANY{getindex(), setindex(), iterate(), append()}
function foo(myarray::Arraylike)
...
end
The difference between structural typing and behavioral typing is subtle. In Scala, you're essentially asking the type system to check for the presence of a member function on the object with a specific type signature. Since the function is contained within the object, you're still only typing based on the object's structure (hence: structural typing).
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.
You could also view C++ templates as a kind of behavioral typing, although the experience of using them in that way is not very pleasant. Concepts should help clean that up when they finally arrive in the spec.
It seems like the weak spot for using Julia outside of scientific computing is deployment to interesting targets.
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.
Yes. Module pre-compilation is already possible, and last I heard there is work underway to use the same sort of mechanism to allow for single-executable compilation. The problem, of course, is that Julia and Go are very different beasts, and pre-compilation will almost certainly limit some of the currently available dynamism. (Already there are packages that cannot be pre-compiled due to these limitations.)
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.
Setting aside the specific Julia functional merit questions, the answer is that in general, no, the difference between 51 and 52 is not particularly significant.
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.
"GitHub language rankings are based on raw lines of code, which means that repositories written in a given language that include a greater amount of code in a second language (e.g. JavaScript) will be read as the latter rather than the former."
This has huge impact on the ranking - it does not seem right to me..
AFAICT (based on years of poking around various projects, and based on the data they provide on my own projects), the data provided by GitHub are largely broken.
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.
I love this ranking because while all rankings have flaws, this at least is very transparent on how it works, it's parsimonious, it is entirely numerical, easily reproducible, and it gives us at least a small amount of cross validation via two (mostly) orthogonal variables. Now all we need to do is to animate the plot over time.....
I know right? The fact that the metric makes absolute sense is beautiful. Yes it probably misses out on a ton of factors that contribute to ranking (see TIOBE index metrics) but the transparency and simplicity of it all make up for it. You can directly see how each metric is contributing to the factor and the numbers are very easily verifiable.
The reasons you cite are certainly the reasons we found the original analysis by Drew and John compelling.
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.
That is certainly true but I wonder if this effect is exaggerated by the methodology of this study.
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.
That reasoning is plausible, but a large portion of their longevity could easily be due to network effects (libraries + legacy code) and nothing to do with the quality of the languages.
Well is there really any incentive to change? Code is just a method of communication with the computer, just like language is. Sure a country like France could move over to speaking English instead of French and probably be a little better off for it, but fundamentally, French gets the job done just fine. There's too much inertia to change amongst established companies I think.
Maybe it was around about the time Microsoft started adding git support to their Visual products? (I don't know, as I don't really use any Microsoft products, but I know Microsoft did embrace git and a lot of OSS tech over the past few years.)
Misleading title. It's entirely github and SO-centric and as such misrepresents C and probably C++ as well, since those languages have scads of code elsewhere.
I tend to agree. I believe JavaScript is misrepresented too, mainly because many of other languages would include JavaScript modules, that are mostly copy/pasted because those other languages don't have a mechanism to reference a JavaScript module.
Unrelated but still annoying. This website is a prime example of responsive design gone wrong. Trying to read it on an iphone, but the chart with the trends overflows out of the screen, and the website locked the ability to zoom out.
In this example as often, the website would be more readable without responsive design.
Surprises me that there's apparently so much Haskell code out there (in absolute terms), given its reputation as the archetypical "high barrier to entry" language.
Maybe the people who do get comfortable with it end up using it a _lot_.
Much of this is attributable to these rankings being counting stats rather than rate states, which makes age an asset. There's a surprising amount of Haskell in existence, but certainly if you're looking at rate at present Swift is growing far more quickly.
TeX has its own stackexchange site [0], and so does Emacs [1].
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.)
I think its going to outpace Angular as a point of its popularity, as it seems to be gaining support throughout the javascript communities (including React!). I started using it in my React projects only a month ago, but it's been so beneficial I honestly already can't imagine going back.
We actually started with Flow, and at the time I'd assumed it was the more popular, robust, and entrenched one. Its definitely the opposite tooling wise, and that's our main reasoning for using it (over Flow). Flow seemed like a better overall typings layer (Im absolutely not qualified to judge this) but a common suggestion here on HN was "They are more similar than different, learn one and you learn the other" -- so we dove in with the one with more mature tooling. I worried it would be harder to integrate than Flow -- it is somewhat -- but its not been a major issue. Its not flawless, but overall its been a fantastic boost to (personallly, my) productivity (code completion, free documentation, and more-correct code).
Rust is a very useful and pragmatic language, and probably the best one in its niche. I don't think you have much to worry about. As things stand right now, it's not going anywhere.
Do people put their hardware description language code on github and ask questions on Stack Overflow? I think there's a lot of programming that doesn't fit into the view that RedMonk goes into.
Dart held static at 37, which leaves it 11 spots behind TypeScript. We have seen very little movement in the language generally, and it hasn't really gotten any notable boosts from outside drivers.
> There is no movement, in fact, among languages ranked within our Top 10.
> 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.
It's more C with some macros. The Arduino UNO and older classic Arduino models like Mega had only a few KB of memory, you want to keep an eye on the resources and in many cases even avoid malloc. The compiler supports a limited C++ dialect. http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplu... (Not sure about the newer hardware with ARM CPUs and newer tools.)
Most people using it don't have computing background, if you watch Arduino presentations most will actually refer to Sketches as a programming language.
No reason it should blow your mind. Aside from the fact that Fortran has been around decades longer than Elixir, it is still the language of choice for vast areas of the scientific and technical industries, because of certain ways it works that no other language offers for high-speed computation.
You are making a broad characterization of Fortran as superior in "certain ways" to other languages. I'd love to read a justification of that claim, perhaps in a blog post.
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.
I did a quick Algolia search for stories posted in the last year on HN with "Fortran" in the title. I couldn't find any articles that compare Fortran language/compiler features with other languages. Maybe you could help me out?
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?