The Quiet Revolution in Programming
drdobbs.com
drdobbs.com
when the research and analysis firm Forrester recently surveyed our readers about how much time they spend writing in any given language
When the results change over time as indicated by the two charts, that can mean one of two things: either a lot of people who worked in just one language in 2010 now work in several languages, or a lot of people who work in just one language have stopped reading Dr. Dobbs. In order to support the claim that it's mainly the first and not the second possibility, one would have to submit at least some supporting evidence. (Edit: at first I thought that one would want to contact the same people in both surveys, but no, that's not good. It leaves out the effect of new people entering the arena. This doesn't seem to be easy.)
And also, this perhaps being a matter of taste, I find it questionable to have a caption like "Fraction of programmers..." underneath the charts. As much as I respect and admire Dr. Dobbs (I have published there): not every programmer is a Dr. Dobbs reader.
It'd be nice to see a time-lapse of the TIOBE index from 2009 to 2013: http://www.tiobe.com/content/paperinfo/tpci/index.html
Or any of these dozen other measures (including mentions on delicious, or IRC): http://www.langpop.com/
Or employer challenges posted on CodeEval: http://visual.ly/most-popular-programming-languages-2013
That said, the underlying thesis may be true that more projects today require more languages, hard to say.
>This doesn't seem to be easy.
Quite agreed. It's not an easy thing to measure accurately. I believe the explanation for the numbers is indeed the first of the two options you present, as I wrote in the original piece. As the Dr. Dobb's readership has grown vs. 2010, both in terms of unique visitors to the website and subscribers, I don't think the second option is likely.
>not every programmer is a Dr. Dobb's reader
Quite true. This is a problem inherent in all surveys. The survey size for these two questions were 1143 in 2010 and 500 in 2012, which statistically speaking would be fairly representative samples. The real rub is that programmers are not a homogeneous group, so the results will change a lot from one type of programming to another. For example, Dr. Dobb's does not cater much to embedded developers, consequently the effect that they would have on the charts is not captured.
If I assess the 2012 numbers based on what I know anecdotally, they seem acurrate insofar as capturing the broad trend towards polyglot programming. What was counterintuitive, at least to me, was how much the trend accelerated in the last two years.
Sorry, I'll have to very strongly disagree on that one. If, for example, you conduct a public opinion poll in the United States, then all that matters is the size of the sample and your method of selecting the sample. If those are both adequate, then you can draw conclusions (with margins of error) about the entire population. Furthermore, you can repeat the same poll at different points in time and draw conclusions on the changes that you observe. What's happening here is different. Your population is all programmers. Of that, a subset is taken, namely, the set of all Dr. Dobbs readers. From that subset, you take your sample. I trust that the size of your sample and the method of taking it are fine. But we don't know if the subset from which your sample is taken is sufficiently random, and we don't know if and how it changes over time.
In short, you cannot draw conclusions about the entire population if your sample is taken from a subset that does not qualify as a random sample. That problem is very definitely not "inherent in all surveys," as you claim.
It turns out that if you perform social science experiments to determine human behaviour and your sample is almost entirely drawn from a population of white american grad students, your results tell you an awful lot about the psychology of white american grad stuidents, but not so much about human beings in general. Oops. Bang goes almost the entire edifice of modern behavioural science.
[1] http://www2.psych.ubc.ca/~henrich/pdfs/Weird_People_BBS_fina...
Then you spend the rest of your comment restating exactly what he said--namely that programming is not a homogeneous community. And, as he points out himself, the Dr. Dobb's community is known to not be representative of the whole and he gives examples.
(C/C++ are two different entries in the first graph, while they are the same (adding up their scores, thus exaggerating the upwards tendency of the curve in the higher-value range of the x-axis) in the second. Something similar happened for VB.NET.)
> We have had to become polyglots to develop almost any current application.
...in my experience, by working in 2 languages instead of one, the time it takes to deliver something grows 3-4 times (!!), and there's still all the "lost" training time: instead of learning new paradigms, patterns and way to solve problems, people spend inordinate amounts of time learning the details of new languages. I used to love the polyglot way, but now I see language proliferation more as part of the problem than the solution. There was and advantage of all this, but now most paradigms of concurrency and everything are cross-language, and even if some languages like Clojure or Haskell injected new or better refined ideas into the mainstream, these ideas are nor longer tied to a particular language.
I think we should invest as much as we can in unifying languages and technologies, like:
- using one language by making a traditional client side language work server side: the Node way
- cross-compiling: the X to Javascript compilers (like Clojure-script and Python to Js or Ruby to Js techs)
- make languages use libraries from other languages: not to much exciting things happening here yet :( ...but I'd love having a way to, for example, mix C, Python and Ruby libraries inside a Clojure program, regardless of the performance or security issues
...they all seem like "boring plumbing work", I know. They are neither "exciting big problems to solve" nor "amazing business ideas" and you'll most likely neither change the world nor get rich by working on such things, but you can probably make a huge difference by working on such plumbing an let the really smart guys free to invent really new things!
Same for programming. The more you are aware of, the better able you are to chose the better way of proceeding on a project.
I'm probably scarred though, I work with people who believe that c# and sql server can solve all the world's programming problems. (I like c# and sql server, but they aren't always the best solution for a given problem)
This is a part of the problem. "The right tool for the job" has become an end in itself, rather than a means to an end. People spend so much time trying to develop more than a superficial understanding of a vast array of languages and frameworks, simply so they can say they are using the "right" tool for the job (perhaps so their future "show HN" post can be sexy). The right tool should always be understood as successfully executing your project as the goal. Sometimes the right tool is simply the one that you or your team has expertise with, or has a deep body of experience built up on StackOverflow. The "right" tool in absolute terms is completely meaningless. Often times it seems like people forget this.
For our purposes, there are "better" tools available than those that were chosen. A pain that we're feeling now, a couple of years on, as we start to migrate a live application to those other platforms. That's a big loss of productivity for us because choices were made to use tools that were familiar instead of figuring out if they actual made the most sense.
Am I missing something? I find the first graph in the article quite difficult to comprehend in terms of what it signifies. Although the numbers are "sub 2%" after the 50% line, isn't it an aggregation across 5 data points on the x-axis and 7 languages that will still add up to a substantial number of developers who program mostly in a single language?
I am yet to meet someone who vastly switches between languages on a daily basis in given 12 month period. One occurrence is probably working on a python and javascript for a webapp and writing an occasional chef cookbook in ruby.
I like looking at different languages/tools/platforms, and am a bit into different languages. I've actually liked JS for a long time. The nature of web based apps make it a requirement, so it is nice to see decent frameworks take hold server-side that use it.
Just pointing, that for me personally, if you add all the web stuff, more than half my time is in JS these days, and a decade or five years ago, I could not say the same.
It is possible that Google is unique in this though.
In fact, I think the majority of developers I know fall into that category.
I'm also strongly proficient in Adobe Illustrator, Photoshop, and InDesign though, so I don't know if that offsets my proficiency in only one language.
Of course, this is probably a lot rarer outside of business apps.
This is probably not far from the norm where a programmer "knows" multiple languages but are only expert in one. This is almost as scary to me.
At least for me, there's a refreshingly synergistic effect from knowing and understanding multiple languages well.
In fact, I would go so far as to claim that a good programmer should know and understand a variety of languages and, ideally, use them frequently.
How frequently? Can you describe the average week of this programmer?
I am not averse to using multiple languages in a project if each serves a need so, in the past two months, I have used gsl, TCL, Python, C, and Go for various components of an ongoing project. But not necessarily all at the same time. Most days, I focus on one and only deal with two simultaneously during integration or code generation.
I've been leaning towards full-stack JS as much as possible. If only that it makes some of the communication channels much easier to work across. There's still templating (html/jade/mustache/markdown) and styling (css/less/sass/stylus) to consider, and not mentioning interaction with other systems/services (mongodb/sql/salesforce). Bringing as much of that under one umbrella as possible is useful.
On the flip side, if you have well documented services, and workers/queues you can break your load up and use a lot of different platforms.
Also, "platform spread" is a real concern.
Note that "mainly just knows Perl" is quite different from "only knows Perl".
Since then, I have never met another programmer who knows only one language; I think they are pretty rare. As for proving the case, I don't think I can: there may well exist a good monolingual programmer out there. It's just not likely.
This is really common. Anyone who spends time with code should take the time to learn the *nix toolset. It's a shame to see so many people reinventing tools that have been around since the 70s.
Frequent usage is more difficult, though. I'd like to think I know C++, Java, C and Python all very well, SQL to a reasonable level. However, add the "dabbling" languages: Racket, Haskell, Scala, C#...where exactly would the time for using these frequently come from?
Arguably, languages are only important to an extent - libraries surrounding languages are the truly important part.
I know there is often a cost to using, for example the linq extension methods, it will look cleaner a lot of the time than the loop syntax.
Beyond this, simply using a new framework in an existing language can shape your views... for example, the differences in using JS with say jQueryUI, NodeJS, or AMD modules.
Knowing a language, and some platforms/libraries/approaches can greatly shape how you use that language. I once saw a VB app written by a COBOL convert... well, it ran in VB, but definitely looked like a COBOL application.
It takes a lot of work to become really proficient in any one language. Multiple languages? For most people, that means only adequate proficiency — or even barely adequate proficiency — in some of them. Don't we already have enough lousy programmers?
I do expect a programmer to be able to handle at least a few languages, let's say C, HTML, CSS, Java, PHP, Emacs LISP. Now throw in SQL, JavaScript, C++, ASP.Net, Python, Ruby, etc... It's not just syntax. How can anyone know most of the ins and outs of all of these, learn best practices, understand the libraries, keep up to date on new versions?
Is there a general principal for creating a whole new language as opposed to adding features.? Could you have a language where you could have a setting for something like static typing vs dynamic typing? The language would get more complex, but seems like it would still be less complex than a whole new syntax?
The proper tool for the task way is pushing things backwards! By going this way you're running towards a brick wall, the wall of your limited brainpower: at one point you will not have enough brainpower to keep juggling the increasing number of "proper tools" and you'll have to stop growing, stop learning and enclose yourself in warm niche/bubble. Yeah, this is exactly what your manager wants - you'll become a good but replaceable "programmer specializing in X, Y and Z" instead of the "uncathegorizable freak" that embeds a Scheme interpreter only he understands in his C++ code, can do in a day what the rest of the team does in a month, but that may bring the whole company close to bankruptcy if he's hit by a bus because, well ...nobody can replace him :)
"Universal" tools are always better overall even if they are worse for every particular situation you can imagine because the "problem space" in software is expanding. I an "all is open-ended" world universal tools are the only to avoid being trapped in a "bubble" (yeah, you may have warm and cozy in a "web dev with rails" bubble or "frontend dev in javascript" bubble, but you're still in a bubble!).
The pipeline was what make Unix great - the ability to chain different small stuff together. Huge monolithic is something I dislike. Personal taste.
By "Java" (bad example, I agree) I mean any multi-paradigm, multi-platform, general purpose language: it can just as well be Scala on the JVM or Python if its performance is good enough for you and you can put up with the way it annoys you out of your mind if you try to do functional programming in it. All languages claim to be so now but in practice they are not! If you use Haskell for something, Erlang for something else and integrate with some R code by means of some Python or C code, you pay a huge price in increased complexity and you'd better make sure the advantages given by using "the right tool for the job" are worth this price... If you can master the kind of polyglot skills you talk about, great, you're definitely not in a bubble, but this is because you are one of the top 0.1% in terms of "brainpower", not because you used you bp efficiently - imagine what you could do if all the mental energy spend understanding all the little tech details for all those things were focused on solving just one problem and with a smaller number of tools!
I couldn't disagree more with this statement; it seems to me you have this backwards. The purpose of "proper tools" is exactly to encapsulate the complexity and provide a simpler interface with which we can address the problems. In fact, as the level of complexity rises, you need tools that provide the right level of abstraction. In many cases, those tools are specialized because they address specific aspects of the problem. Each such tool pushes out the boundaries of our limited brain power.
For instance, I use a lot of code generation in my work. A complicating factor in code generation is the fact that you are working at two or more levels simultaneously; the code generator and the target language. However, with the proper tools, the problem becomes very tractable. In this case, I am referring to explicit code generation, but exactly the same issues arise when generating code with Lisp style macros.
As to the universality of languages, I can only say that the practice gives lie to the theory. Once you've used enough languages, their differences (and fitness for particular problems) become clearer.