My former colleague RedMonk's Stephen O’Grady writing about the diversification of language options and what might follow:
It may be difficult to conceive of a return to a more simple environment, but remember that the Cambrian explosion the current rate of innovation is often compared to was itself very brief – in geologic terms, at least. Unnatural rates of change are by definition unnatural, and therefore difficult to sustain over time. It is doubtful that we’ll ever see a return to the radically more simple environment created by the early software giants, but it’s likely that we’ll see dramatically fewer popular options per category.
Whether we’re reaching apex of the swing towards fragmentation is debatable, less so is the fact that the pendulum will swing the other way eventually. It’s not a matter of if, but when.
In the past, I’ve mildly disagreed with Stephen and his colleague Donnie Berkholz about whether we were really seeing anything more than the usual plethora of languages that see some use and even some hype but don’t have any real impact and eventually fade away. Most of the languages we use today would have been at least passingly familiar to Web 1.0 and enterprise programmers programmers of the dot-com era even if the mix has shifted over time.
However, Stephen and Donnie’s data has made me at least tentatively come to agree that there’s been an increase in fragmentation. Serious infrastructures, platforms, and apps being created with “non-mainstream” languages such as Scala. Go, from Google, is probably the latest major new entry; it’s used in Docker which is one of the hottest software projects happening right now.
Arguably, fragmentation doesn’t matter so much in a microservices world in which all manner of gratuitous differences can be abstracted from the underlying platform. And developers are supposed to be in control after all, aren’t they?
But as Stephen notes, quoting from a number of senior developers, there are limits to all this. Tim Bray, for example, points out that having to stay current in an overly broad toolchain takes away from having the time and attention to actually drain the swamp. And just because you can abstract gratuitous differences from the underlying platform doesn’t make gratuitous differences a good thing. Code usually needs to be maintained after all.
There great choice of tools out there. And it’s important to support that choice in programming platforms (as Red Hat does with our OpenShift PaaS). But, at the same time, that choice can offer a lot of rope and it’s up to developers and programming teams to use that rope for good and not for ill.
Image source: Startapp.com
No comments:
Post a Comment