This time of year journalists amuse themselves by making lists of the most popular programming languages for the year. A lot of people are interested, for career reason.
“The”
So what was *the* fastest growing programming for 2018?
- Kotlin, according to GitHub’s The State of the Octoverse report. We’re seeing trends toward more statically typed languages focused on type safety and interoperability. And HCL, a human readable language for DevOps, has more than doubled since 2017.
- Swift, according to RedMonk.
- Python, according to Business Insider from TIOBE data in August.
- JavaScript, accorting to JaxEnter in September.
- C++ (almost as much as Python, and Java almost as much as C++), according to IEEE Spectrum trends in July
And, I should note, Java is not trending up because it is sitting pretty at the top of most lists.
So if we can get at least five different languages confidently asserted as the fastest growing language, what does it mean? I think the obvious answer has a lot to commend it: these rankings are meaningless clickbait. Over-abstractions.
Indeed, when you look at how many of these are measured, you can see that in fact some of these rankings are actually dishonest or incompetent. For example, there are rankings based on how many questions were asked on StackOverflow. But a language that is poorly documented or confusing or in the stage of the hype cycle where people are shoehorning trying to using it for an inappropriate takes, any of these things will cause extra questions on StackOverflow. You might even go as far as saying that a large number of questions on StackOverflow should be used as a sign there there something defective! The larger the number of questions, the more that there are gotchas or deficiencies; though of course, once the questions are asked and answered, that becomes to some extent a viable workaround.
Schematron has been permeating rather than growing?
Where does Schematron come in? It is not a general purpose language, so it won’t be on any lists. The metric of success for a niche language is how good it is for that niche, not how good it is for inappropriate uses (a lesson for XML versus JSON versus GraphQL partisans too!) But in the 19 years of its existence, the thing that has impressed me most has been that people don’t tend to ask questions about it: it is simple enough that people can start with small things and get going. And the complexity comes from the XPath, so I presume questions about Schematron XPath mainly go to XPath lists: they certainly don’t go to Schematron lists.
But that being said, Schematron is overdue for being integrated with modern platforms better: people rightly ask about Maven resources etc. And the answer? If you need it, contribute it. What Schematron has lacked has been a critical mass of maintainers and integrators, with the notable exception of Tony Graham: while there have been dozens of implementations in different languages and while many are still under active development (I am impressed with ph-schematron for example) there are other good ones that are stable (such as the .NET SchemaTron or the NCAR CRUX for Java and SAXON), nevertheless the current generation of platforms and languages is based on packaging, and Schematron needs attention to this.
Frankly, I think Schematron has thrived to the extent it has in spite of mainstream developers not because of their grassroots support. What do I mean by that? I mean that while people from the document community (the old SGML and XML crowd) grok Schematron fast, and while standards lead efforts which necessarily employ a waterfall approach (i.e. get requirements, evaluate technologies, discover Schematron often has no viable platform-independent alternative) also often converge on Schematron, it is notable that at the time when TDD and BDD have almost won the day, Schematron is not playing much of a role: I am not finding fault with mainstream developers here, by the way. They need or, rather, expect, the extra layer of packaging: Scheamtron in Maven, Schematron in JUnit, Schematron in an annotation processor, etc.