Scott Wilson from Automic is always a great source of knowledge around DevOps. I have spoken with him several times and he never disappoints. In this DevOps Chat, Scott talks to us about dead-end computer languages. Scott, who is a developer himself, often marvels at the explosion of languages available today and wonders how many will survive beyond the useful life of the applications that they are written in.
It is a great point. We did a survey a while back that showed the average organization is supporting upwards of 10 + languages concurrently. Talk about tower of Babel. Well, Scott gives us some great background on this.
Streaming Audio
Chat Transcript
Alan Shimel: Hi, everyone—Alan Shimel, staging-devopsy.kinsta.cloud, here for another DevOps Chat. This episode’s guest on DevOps Chat is Scott Wilson of Automic. Scott, welcome to DevOps Chat.
Wilson: Thank you, Alan. I’m glad to be here.
Shimel: Yep, and Scott, we’ve spoken before, we’ve done webinars and podcasts in the past, and are fairly familiar, but for our audience who may not know who Scott Wilson is, why don’t you give us a quick background?
Wilson: Okay, great. Thank you, Alan. I am currently the product marketing director at Automic Software, and basically, I am specializing particularly in DevOps and application release automation.
I come from a pretty technical background. I started basically in high school writing code. I was a software developer for a long time, and you know, in many evolutions, different vertical markets of writing code, and I’ve evolved ultimately now into marketing, so.
Shimel: That’s not such a bad thing, Scott. But [Laughter]—there are fates worse than death.
Wilson: [Laughter]
Shimel: But anyway, Scott, we were gonna talk a little bit today about, you know, sort of, we can call them dead-end languages—and by that, I mean, you know, it’s a great time to be a developer today. You have so many choices in what you want to develop.
But, like anything else, you know, there will be winners and losers among development languages that you can choose from. And I know this is a—
Wilson: Absolutely.
Shimel: – yeah, this is a topic you’ve spoken and written on. So I wanted to kind of, you know, with that premise, why don’t you explain to our audience a little bit about what you’re talking about?
Wilson: Okay. Well, you know, as I mentioned in the intro, Alan, I am no stranger to code, and I will admit I still write code on the side for various things here and there. And one of the things that has struck me over my experience, especially with talking with customers and even working for a couple of vendors for application release automation products is that, in DevOps in general, there’s this great level of interest and experimentation going on with languages. A lot of the ARA tooling provides ways for you to build your own plug-ins, for example, so that you can extend these products and extend their reach into building a nice, cohesive tool chain—a DevOps pipeline, if you will.
And the challenge is, as I started looking at a lot of these products and a lot of the momentum in DevOps is, I started realizing that people are choosing languages that are kind of dead on arrival already. What really sparked my interest in this was not only my observation here, Alan, but I spoke with an executive at a large company, and he was telling me that they were having to rewrite a lot of their DevOps code—their deployment code, if you will—because the folks that had written their pipeline five years ago used a language that they can no longer hire people to write it. And so they’re having to scratch it and rewrite it again, and I have actually heard this theme a few other times as I’ve met with executives across the U.S.
So that had me really diving in and trying to figure out, well, how big of a problem is this? There is—and I won’t name the company, but there is one area vendor that does offer a PERL toolkit, just for example, to connect to their API and interact with it. The problem is, PERL is a dying language. So, if—now, this vendor also does not exclusively demand you use PERL, but I just found it an odd choice that they would even support that, given its decreasing popularity. Additionally, I was at a Chef conference this last summer, summer of 2016, and they announced their new Habitat write platform, and it was all written in Rust. Again, another odd, obscure language.
And so, Alan, what I did is, I went around and started looking to find out, well, why are some of these companies choosing a language and then five years later, not able to support the language and the tool that they have built it in? And there are several, it turns out, popularity indexes, Alan, and you can look around for these. There’s one called the Popularity of Programming Language, PYPL, and it’s listed on GitHub, and it lists all the popularity—languages by popularity and share. There’s the TIOBE index as well, and there are several indexes. Some of them compile indexes, I think—what is it? There’s one that is garnered by what’s called Coding Dojo, and several others that go look at job listings to see what are the most popular language requirements in job listings.
And if you wanna get a good sense of this, actually, you can actually go to ZDNet.com. They wrote a great article that basically took all the different indexes, aggregated them, and put them together. And what’s interesting in their findings is that you don’t see PERL, you don’t see Rust, you don’t see a lot of these, I call them doctorate languages, meaning people going to get their doctorates in computer science wind up creating these languages and they each kinda have their own cult following, Alan. Which is cool in one respect, but in the other respect, it means that if you’re not careful, you can latch on to some programming language for your DevOps practice and wind up choosing a language that is in fact not sustainable. That’s a trend, and you wind up—
Shimel: Certainly—so Scott, in the case of Rust and maybe some of the other more obscure kinda languages we run into, I get what you’re saying and I don’t disagree, but you know, when you look at PERL, you know, you and I are not 20-somethings, Scott, right? I mean, PERL has been around a long time, and in its day, you know, back in the dot com bubble, you know, PERL was the equivalent of PHP, you know? And recently I saw, I think PHP is out—PHP 5 or whatever is out there now.
But, you know, PERL—if you would have asked me a language to bet on in 1998, I probably would’ve bet on PERL. You know, I wouldn’t think it would become obscure or obsolete—though, look, ’98, you know, we’re talking 18, 19 years, and certainly nothing lives forever.
But how are people out there—you know, it’s so hard. We don’t have a crystal ball, right? And we do have these indexes, but how do we know, like, what’s the next hot one and which is the next dud?
Wilson: That’s an excellent question, and just to provide me the story, Alan, of your, what you’ve pointed out—because there is no crystal ball, and it is tough—I think the whole IT industry right now, including programming languages, it really reminds me a lot of the turn of the 20th century when there was really no clear definition of what an automobile should look like. And there were various versions—Edison had his battery operated vehicle, and there were several steamers, there several combustion engines and there were lots and lots of losers, lots of investments that went bust.
And it took, you know, basically a couple of decades, but by the time we hit the 1920s, everyone understood and knew what an automobile looked like, and it looked like and operated like a Model T, right?
And so it’s really kinda tough right now. So what I like to do, or what I recommend in the context of what we’re talking about here with languages is to really look at where it’s trending and what its longevity has been. If you look at that, you know, Java, C++ are popular. That might be, C have had, and even JavaScript have had a great deal of sustained momentum over a couple of decades.
You were right—PERL, at the time, was great, but according to the popularity index, it is as its lowest popularity point since 2001 and is continually trending down. PHP has been holding its own, and in the composite index, it is still listed as one of the more popular languages.
And so, you know, I would be—frankly, if I were practicing a language to help extend my DevOps practice, I would definitely look at what things have been sustainable over the last several years—decades, rather—and really look at the trending. And that’s why—and not to sound too critical, but when I look at Chef, placing Habitat on Rust, for example, was probably not a great idea for the future. If you look at what languages have sustained over the last 20 years, it would have been better for them to have chosen Java, because you have a huge base of Java developers and you could have then had a much larger contribution base to the project. So I think there’s just things you can do like that.
And then, you know, the other thing, Alan, to your point—and it’s very unsexy to say this, but there has been one kind of, I’ll call it quasi-programming interface that has spanned the entire test of time and has remained consistent. And it also, what’s neat about this, is I have observed, it transcends every IT specialist, and then as a command line interface or a CLI. I’ve found, in looking at this, that it was very interesting that one of the challenges of, let’s say, extending some new fad DevOps tool using a programming language is that it requires a programmer, and you have to understand the grammar of the language. And that usually silos the expertise that is capable, or readily capable of picking this up. Where, versus a command line interface, they were designed, frankly, for the use case to be readily understood and easily picked up, and they transcend everybody, whether you’re a software developer, a DBA—everyone kind of gets to very quickly understand how command line interfaces work.
So I’d be, if I were trying to build my DevOps practice today, I would actually be more keen on looking at using command line interfaces, published ones, to set up a lot of my extensions and automation mechanics, just because they have transcended time and have the longest life span of any language, though I wouldn’t say command line interface is a language, it is an interface, right? But the nice thing is, they are mostly self-documenting, where the programming languages, you have to know the language to understand what it’s doing, and they’re generally not self-documenting.
Shimel: Got it. Scott, I don’t wanna put you on the spot, but give our listeners, if you can, what you think are your top three choices for the languages to use, let’s say, in the foreseeable future.
Wilson: Alright. Excellent question. Well, as always, it depends on what you’re looking to do. That’s what’s very interesting when you look at the indexes and the aggregates and the composites of these indexes is, it really depends. I look at languages a lot like tools in a tool shed. They do a specific thing. You wouldn’t want to write a web server, for example, in C. I mean, you could, but you know, it has diminishing returns.
I would say, in the modern cloud that we’re in, the more popular languages that would support this are certainly Java, you’ve got Python, PHP, JavaScript and C# are amongst the more popular ones. They’ve been around for a while. C#, as you know, is backed by Microsoft, a big company, and is recently going open source, the .net platform is. It works on every platform—Mac, Windows, Linux, what have you. So that could be interesting. JavaScript, I mean, for its ease of use? I mean, goodness, it’s been around for quite a while. You’ve got services like Node.js in which you can run very sophisticated apps on it.
I’d probably be looking in that tier for the modern, cloud-based apps—Java, Python, PHP, C#, JavaScript would probably be the languages I would be more keen on looking at.
Shimel: Got it. So, Scott, believe it or not, we’ve kinda used up our 15 minutes of fame, here. But you know, this is an interesting subject matter, Scott, that I think many developers sort of delve in. You know, there’s the, I call it the shiny trinket syndrome where everybody wants to use the latest and greatest cool tool, but sometimes, you know, these fads fade out quickly and you’re left, you know, with a fantastic product that was developed in a dead-end language, or a fantastic app developed in a dead-end language. So definitely something to be wary of.
Wilson: [Cross talk] Yeah, like I said, the languages that are great for creating a project, if you’re trying to do a lot of those DevOps automation mechanics, I would really, highly recommend looking at command language interfaces to stitch a lot of that together.
Shimel: Yep. So, Scott, we’re gonna call it a wrap on today’s podcast. Obviously there’s big news going on with Automic and acquisition news and stuff, and maybe once the dust settles on that, we could have you back on and talk about that a bit.
Wilson: Absolutely. I’d love to.
Shimel: Until then, though, Scott Wilson, Automic—continued success, keep doing what you’re doing, and thanks for being this episode’s guest on DevOps Chat.
Wilson: Thank you, Alan. Have a great day.
Shimel: Alright. This is Alan Shimel for staging-devopsy.kinsta.cloud for DevOps Chat, and thanks for listening and we’ll see you on the next chat. Bye bye, everyone.
— Alan Shimel
