Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
We’ve got decades of experience in programming and language adoption under our belt at this point, and there are a few things we can say definitively that developers in general (and DevOps engineers specifically) should be aware of.
First, it doesn’t matter as much as you think. It really doesn’t. Most developers don’t choose programming languages based on important things like optimization or general applicability. They choose a language based on ease of use, availability of third-party libraries and simplification of things like UI. Open source version availability helps, but only insofar as it spawns more third-party libraries. So, use the language that works best for the project, and don’t get too hung up on whether or not it’s the newest shiny one.
Second, the changes in use and adoption that matter–the top five to 10 languages that make up the vast majority of all professional programming activity–don’t happen overnight. Both JavaScript and Python are considered “rapid ascent” in terms of uptake when they took off … but both were around for years before that spike in adoption occurred. So, learning any of the top few languages is a far better long-term investment than learning the hottest new language.
Third, those top languages actually don’t change much. They were written to fulfill a need, and that doesn’t change much over time. Indeed, the only language I can think of that has fundamentally changed in its lifetime is C++, which seems to want to keep up with the times rather than keep serving its original niche. Python? Java? Still pretty much the same as when they became popular back in the day. And that’s a good thing. But that means if you want to try something new and engaging, you need to look to up-and-coming languages. At the time of this writing, specialist languages like R and Kafka are having their day, and that’s a good thing. After all, we know that different applications have different needs and different platforms have different needs–and have been trying to address that second one forever, currently with languages like Flutter. All of these will offer new ways of doing things, which is good exposure.
Fourth, (though we briefly toyed with eliminating this one) organizations do determine the pool of available languages. Frankly, allowing each team to build a separate architecture was never a good idea from a long-term maintenance point of view … but a fairly large number of organizations played with the idea and learned the lessons about technical debt all over again. Now we’re back to “We use these languages, pick one,” which is better than “We’re an X shop,” and offers maintainability over time without burning a ton of man-hours.
And finally, you can do anything with those languages your organization makes available. I’ve seen object-oriented assembler, I’ve seen entire websites served in C; the list goes on. The language you choose makes certain things easier or harder, but if you need to get it done, you’ll either get an exception to the language list, or you’ll figure out how to get it done with what’s available. But you can … But as my father used to love to say, “Just because you can, doesn’t mean you should.” He had nothing to do with programming and as little as possible to do with computers, but his logic still applies perfectly.
So, grab an approved language, and crank out solutions. Just keep driving it home; you’re rocking it. Don’t stop, and don’t worry too much about which language you’re using, just focus on the language and do what needs doing–like you’ve done all along. And spin us up even more cool apps.
