I was just listening to a podcast introducing the F# language, and what struck me was that the two folks being interviewed–Chris Smith and Dustin Campbell–didn’t talk at any time about F# being the next big language for the CLR. Rather, they focused on what they thought the advantages were, and invited people to just try it out, in fact, to just continue using whatever language they were already using on the CLR, but to be open to using F# when it seemed called for. You can find the podcast here.
I contrast this with what I’ve been seeing in various discussion forums around the web–the ones for Java and JVM users seem to be the biggest culprits here–where selecting a programming language seems to be a winner-takes-all proposition. It seems to me that, at least from a marketing angle, it’s better to promote your own language (or the one you currently like) as an alternative, rather than the one which everyone should pick up–must pick up, in fact–after dropping whatever language they are currently using.
Competitions is useful in the market of ideas. Just yesterday, Jonas Bonér posted a great presentation on approaches to concurrent and parallel programming in the JVM. What’s clear from that talk is that in that area of investigation there is not only competition, but also room for experimentation. There’s even room for more than one implementation of a given idea, such as Actors. We saw this some years ago with dependency injection/inversion of control and O/R mapping, among others. And it’s clear that while there are winners (e.g. Spring for IOC and Hibernate for ORM) there is still room for other approaches even over the long term.
On the JVM we do see some people promoting a mix of languages to solve problems–for example, JRuby on Rails calling into Java libraries, or Groovy used as a build tool for regular Java applications instead of some XML-based build tool. But then, if we really believed that we could just mix-and-match, I doubt we’d be seeing the long, heated, rather anguished discussions about “which language to use”.
It seems to me on the one hand that for a certain class of organization it’s very important to have a single, mainstream language used for the bulk of programming tasks. I’ve worked at that sort of IT shop before, and I can see the value in that approach. They have a known quantity, their developers can move between projects more easily, it’s a straightforward proposition to find programmers skilled in a mainstream language, etc. That sort of environment also seems to favor a number of secondary aspects around language selection, including language and library stability, technical support, documentation, training and educational materials, and backwards compatibility during upgrades to the language and libraries.
I’ve also worked at shops on the other end of the language-selection spectrum which are willing to combine whatever set of tools got them to their end goal. They expect their programmers to be comfortable with a pile of programming tools, the same way we’d expect a carpenter to work with both power and hand tools. One gig that comes to mind relied on a combination of Perl, Lua, Java and C to get the job done, with a healthy amount of scripts written in Bash, Awk and Perl for admin tasks. It wouldn’t have been a stretch for them to add, say, Python and Ruby to that mix. They were, as far as it goes, language agnostic, though I wouldn’t say they were picking up new languages just for the heck of it. It’s just that they saw the value in each individual language and had no policy enforcing the single-language principle.
One group of programmers is of the opinion that there we in the IT industry will in the future no longer settle on one or two “mainstream” languages for, say, business applications. Rather, we will gradually move towards a model where a number of languages are used in concert, with each one applied to solve part of the problem.That seems counter-intuitive to me, as I’m not sure what fundamentals in the industry have changed; we certainly have had a plethora of stable, useful languages available for the last 30 years, and yet it seems that just a small handful rise to the top of the list at any given time. What would drive a move towards real polyglot computing?
Another group seems to feel that just as was the case in previous generations, we will run into the lack of flexibility in the current mainstream choices, for example Java or C#, and will find another one (or one+) to take its place. That generational change may be driven by external demands which the current crop of languages simply cannot fully or easily address, for example, the rise of the manycore system.
What I believe–and the reason I’m writing this–is that it’s counter-productive to be talking about the Next Big Language. If there is a NBL, believe me, you’ll know it, either because you jump on that bandwagon early and make a bazillion bucks or because you ignore it and find your job prospects shrinking faster than your worth in the marketplace. If, for economic reasons you want to make sure to be an early adopter, well, in this industry you have a lot of ground to cover, and likely you’re no better as a fortune teller than anyone else. In other words: wait for it, it will come.
I think it’s more interesting to talk about what different programming languages–big or not–allow me to do that those in my current toolset don’t. This podcast on F#, I think, took the right approach in just encouraging curiosity and interest in a different way of doing things.
