A Comment on “Multilanguage Programming”
May 3rd, 2008 | Published in code, column, commentary, emacs, languages, productivity, tools | 12 Comments | Bookmark on Pinboard.in
A commenter named Nick left a thoughtful response to my post about my “Multilanguage Programming” column. Rather than respond to it with another comment, I thought I’d turn my response into a full posting, as I think Nick’s feedback is representative of how many people feel about the topic.
Nick said:
I would say that instead of spending a lot of time on a conceptually different language it could be more beneficial to study, say, distributed algorithms or software/system architecture principles or your business domain. There is so much knowledge in this world that learning how to code the same thing in, roughly speaking, one more syntax seems like a waste of time. Even paying real attention to what is going on in the cloud computing can easily consume most of one’s spare time.
I think there are assumptions here that are not necessarily true. Specifically, you’re not necessarily learning how to code the same thing in multiple languages; rather, the idea is that by choosing the best language for the task, coding is “just right” for the problem at hand. For example, I know from significant first-hand experience that if you want to write a set of distributed services that support replication, failover, and fault tolerance, the code you’d write to do that in C++ will be extremely different from the code you’d write in Erlang to achieve the same thing (well, actually, you’d be able to achieve far more in Erlang, in far fewer lines of code).
This is about much more than syntax. It’s about facilities, semantics, and trade-offs. If it were just syntax, then that would imply that all languages are equal in terms of expressiveness and capability, which we already know and accept to be untrue.
The cloud computing topic actually provides a good example of why knowing multiple languages can be useful. To use the Google App Engine, for example, you need to develop your applications in Python. What if you don’t know Python? Too bad for you.
From a real life perspective, it takes years or working on nontrivial software to master a language. For example, some people still manage to have only a vague idea of util.concurent — and this is just a small enough (and well explained in the literature) part of Java. How realistic is it to expect that the majority of developers will be able to master multiple languages concurrently?
I disagree that it takes years to master a language. One of the best OO developers I ever worked with was a mechanical engineer who taught himself programming. One of my current coworkers — a relatively young guy — started programming in Erlang only a few months ago, and he’s already writing some fairly sophisticated production-quality code. In 1988, I started using C++; by 1989, I was starting to help guys like Stan Lippman, Jim Coplien, and others correct coding mistakes in their excellent books. I have a BSEE, no formal computer science training whatsoever, and am completely self-taught as far as programming languages go. (The only class I ever had in any computer language was a BASIC class I had to take in 1981.) Two other coworkers started with Python just a few months ago and they do quite well with it at this point. I can cite numerous such examples from throughout my career. I don’t think any of us are super-programmers or anything like that, so if we can do it, I don’t see why it would be a problem for anyone else.
Perhaps you’re falling trap to the “huge language” problem I mentioned in my column. It certainly can take some people many years to master enormous languages like Java and C++, but most languages are simply nowhere near that big.
And who wants to maintain a code base written in widely different languages? Which most likely means multiple IDEs, unit testing frameworks, build systems (hey, not everyone is using even Maven yet), innumerable frameworks etc. And most of the interpreted languages among those are not even likely to run in the same VM. Not to mention the number of jobs asking for non-C++/Java skills.
I use a number of languages daily and I really have no trouble maintaining the code regardless of which language any particular piece happens to be written in, or whether I wrote the code or one of my teammates did. Once you know a language, you know it; switching to it is no more difficult than using your one and only language if you’re a monolingual developer.
You also mention the “multiple IDE” problem. The first draft of my column contained some fairly direct language describing my dislike of IDEs, or more accurately, my dislike of the IDE culture, but Doug Lea suggested I take it out, so I did. The problem is that some folks let the tool drive their solutions, rather than using the tool as a means to developing solutions. I’ve had numerous people tell me they won’t consider using a language unless their IDE fully supports it with Java- or Smalltalk-like refactoring. To me, that’s completely backwards. I’d rather use an extensible editor that can handle pretty much any language, thus letting me develop optimal solutions using the right languages, rather than having a mere editing tool severely limit my choice of possible solutions.
But there are language mavens and there are tool mavens, and they typically disagree. Follow that link and read, as the posting there is incredibly insightful. I am definitely a language maven; languages are my tools. I suspect, though, that Nick and others who raise similar questions to the ones quoted here lean more toward being tool mavens. I’m not passing judgment on either; I’m only pointing out the different camps to help pinpoint sources of disagreement.
As far as unit test frameworks, build systems, and frameworks go, I haven’t ever found any big issues in those areas when using multiple languages. The reason, not surprisingly, is that knowing multiple languages gives you multiple weapons for testing and integration. Ultimately, when you’re used to using multiple languages, you’re used to these kinds of issues and thus they don’t really present any formidable barriers.
And as far as jobs go, the best developers I’ve known throughout my career have been fluent in a number of programming languages, and each of them could work virtually wherever they wanted to. I don’t believe this correlation is mere coincidence.
Curiously enough, this argumentation is hardly ever mentioned. Authors tend to assume that developers are lazy or have nothing else to learn.
I don’t assume developers are lazy. Rather, I think our industry generally has a bad habit of continually seeking homogeneity in platforms, in languages, in tools, in frameworks, etc., and we really, really ought to know better by now. Once you learn to accept the fact that heterogeneity in computing is inevitable — since nothing can do it all, right? — you find yourself able to use that heterogeneity to your advantage, rather than continually battling against it and losing.
Personally, I am planning to look at Scala and probably Erlang but even judging from the number of books on those it’s clear to me that they represent merely a niche market.
Today’s niche market is tomorrow’s mainstream market. Regardless of whether either of those languages continues to grow, learning one or both will make you a better developer than you are today.
Consider the final question I ask in my column:
After all, do any of us really believe we’ve already learned the last programming language we’ll ever need?
I suspect the vast majority of developers would answer “no” to this question. Assuming that’s the case, then if you don’t regularly practice learning new languages, how do you know when you really need to start learning a new one, and how capable will you be of learning that next language when the need arises? The longer you stay with one language, the more isolated you become, typically without even realizing it. Shifting gears gets harder and harder. Then one day you look up and all the interesting work is elsewhere, out of your reach. Is that a position you want to put yourself in?
May 3rd, 2008 at 1:49 am (#)
While I appreciate the benefits of being proficient in several languages, I find that developers who are overly enthusiastic about the practice usually turn out to work on small, or even individual, projects. They hardly ever deal with a team, and if they do, they are lucky to be surrounded by like-minded individuals who just happen to be, like them, outliers on the general bell curve.
Steve, I find this echoed somewhat in your following comment:
“I use a number of languages daily and I really have no trouble maintaining the code regardless of which language”
The original commenter was making a general observation which, for some interesting reason, you immediately connected back to you.
When it comes to multiple languages and liking exotic languages — such as Erlang — it’s not about you: it’s about your teammates. And by relating your own personal, and necessarily anecdotal, experience, you are completely missing the point that Nick was trying to make in the first place.
So, I’m curious: how many people do you write code in collaboration with? What language(s) do you use? What is their background? Is it easy to hire people with such a broad knowledge?
May 3rd, 2008 at 9:23 am (#)
I agree with you.
I think that the opinion expressed in nick’s comment comes from comparing languages which have similar design goals (e.g. C# vs. Java). However when you look at languages which are “different enough” i.e. do have differnt design goals, it is more obvious why you’d want to use several of them (e.g. ruby vs. C# vs. erlang)
Arnon
May 3rd, 2008 at 12:45 pm (#)
I think mastering a language doesn’t take very long (C++ is a bit of an exception, as it has a lot of syntactic surface area). The libraries tend to be what takes a while. On the bright side, as I grow in Python, Ruby, Erlang, and Prolog, I find that “seen one class library, seen 80% of them”. The features are all the same, the differences tend to be the popular idioms. i.e. There are some ways to use Ruby’s libraries in a very Java-ish way , and then there’s the more terse/compact Ruby way.
The concern I often hear raised about smaller, more specialized, languages, is the practicality, or the “unknown” factor, for a team that isn’t well versed with it. There are the typical risks of performance, or general bugginess that seem to ring true to me when I’ve seen a team adopt a language or framework for the first time. Yet, I wonder if those risks outweigh the ones you implicitly take on when you use a language that’s unsuitable for your problem domain. You’ll wind up with likely *more* code, more hard-to-read code (as you’re stretching the features of the language), and i.e. Why build a rules system in Java when you could use a logic language?
p.s. I always felt a language that lacked Maven support was a good thing :shudder: “Now we go to lunch while Maven downloads the Internet.”, indeed. Sometimes I choose languages that aren’t Java to escape the community, not the language… :-)
May 3rd, 2008 at 12:48 pm (#)
To the first commenter (named “a”): I see you conveniently left off the rest of that sentence you quote — the entire sentence was:
Note that I also mentioned my teammates using Erlang and Python — you conveniently left that part out as well. Also, you give me a hard time for relating personal anecdotes, but ironically, the point you try to make in your first paragraph about multilingual developers being lone developers is your own personal anecdote.
You should be aware that I’ve served as chief engineer and technical development lead for a number of teams over the course of my career, and have always been very hands-on. You certainly don’t need to preach to me about teams, teammates, and such. In fact, it’s my experience with real-world costs of software development that leads me to promote the use of multiple languages as a way of helping reduce development and maintenance costs.
To answer your last set of questions, I’ve always worked on teams of 10-15 people, but given my roles I’ve always concurrently done a fair bit of consultation and collaboration across a number of teams as well. These teams have generally consisted of a mixture of experienced developers and new developers, some good, some not so good. The team I’m on today, though, is excellent across the board. In the past languages have typically been C, C++, and Java, but no Java today. Today we also deal with Erlang, Python, and a few others. There are multiple developers using each language; no language is used by only a single developer, but some team members use only a single language. I personally also use a fair bit emacs-lisp in my own day-to-day development work, but that’s just my own tooling. Hiring good developers capable of working in multiple languages has never seemed to be a problem, since good developers are always attracted to interesting work and good teams.
May 3rd, 2008 at 2:12 pm (#)
I used to be a Java guy early on in my career (I’d written some C, C++, and Perl). I worked for two Java houses in quick succession and Java was the only thing you needed. Both companies built their success on leveraging Java as a more productive language than C and C++. You would spend your time on reading about UML, patterns, and OO design.
Later on a friend kept bringing up languages that he felt were cool in some way or another (Ruby, Erlang, Scala, OCaml, …). My friend was a big wig in the Java community having architected one of the big J2EE app servers, so I paid attention when he had something to say.
I started by learning Ruby. I decided to implement a Scheme interpreter in Ruby killing two birds with one stone. Ruby turned out to be brilliant! An absolute delight to program in. Spurred on by my success with Ruby I learned Erlang, some Common Lisp, and Haskell. I’ve also had a quick look at OCaml and F#, but I can’t claim to know them.
Many people have said this before: learning a new language makes you a better programmer in what ever language you choose to / have to program in even if you don’t actually use the language that you just learned.
I have to agree with Stu: learning languages is not very hard nor time consuming. Ruby and Erlang for example are very small languages with very little syntax. The same is true for Haskell, but monads increase the required effort somewhat. OCaml and F# both have more syntax related to classes and functors.
The downside is that you want to use the language you just learned at work and in many cases it’s a long, hard road to introduce a new language to an organisation. Sadly many companies, like the two I mentioned above, concentrate on only one language. It’s quite a change in mindset to allow / embrace the use of multiple languages.
May 3rd, 2008 at 3:45 pm (#)
Steve,
I assume you could probably classify me as a language maven, where the languages I gravitate toward are always those that allow me to easily manage some class of programming task.
After reading this thread, I must once again site Dijkstra’s 1972 ACM Turing Lecture entitled – “The Humble Programmer”.
From that lecture Dijkstra argued the following point:
Thus, when we select from our toolbox of languages it really is an attempt to find a nicely factored solution.
I think upon reflection that you may agree that you choose Erlang since it actually allows you to factor the somewhat untractable problem “programming a set of distributed services that support replication, failover, and fault tolerance”.
From my personal experience I discovered what it means to ruthlessly refactor code from using the Forth programming language. Forth is one of a special class of concatenative programming languages, which at its core is more of a meta-language for defining a lexicon of words, that is only manageable by iteratively refactoring.
I truly believe that the reason Forth is not more popular is that people don’t understand how to ruthlessly refactor their code. Rafactoring is a philosophy of problem solving in addition to a programming style. If you are interested in learning about refactoring then I suggest that you read Leo Brodies – “Thinking in Forth”
If we can all agree with Dijkstra that “that the only problems we can really solve in a satisfactory manner are those that finally admit a nicely factored solution” then we can all agree that as individuals and teams that we should all seek languages and tools that allow the construction of nicely factored solutions in the most intellectually manageable way.
Regards,
Tony
May 5th, 2008 at 9:58 am (#)
Steve,
This is definately a topic near and dear to my heart. When I came out of college I was a C++ programmer. While I had learned Basic and Pascal in school, C++ was my language (although in reality a small subset of C++ was my language), and I was hired by a company to write hardware support libraries in C++. However, I met a great developer there, actually my same age, but much more plugged in to development communities than I had ever been. We were both interns who had stayed on after graduation and he went on to take a job at the DOD. But as he was leaving I was tasked to write a tool to go through all our source code and update/replace/add copyright notices. It was clear that C++ was not a good choice for this task and my friend recommended AWK. I found a tutorial on the web and in 2 hours I had written a 5 line program consisteng of a DOS batch file and awk which generated code to do the replacement. My bosses were very happy and so was I. I was sold on multilingual development from then on.
Next I had a project to work on where I had to write a networked data backup system for a large NOAA sponsored project. I decided to give Python a try after a friend had said how he used it easily for some things. I bought “Learning Python” and within a couple of days had finished it. It took only a few weeks to write a full fledged protocol to handle data backup using both compression and data checking with md5sums. Python’s “Batteries Included” libraries allowed me such ease. It would have taken me months to do this in C++. I even got a call from my boss at that company to update the program a few years later for $500 dollars. Not much, but it only took me about 6 hours, due to the small size and readability of the Python. And keep in mind that I had not looked at this code in over 2 years!
So when people claim they don’t have time to learn a language, I laugh, just as I laugh when they say they don’t have time for automated testing. Sadly I feel this is the result of the industry focus on Java and C++ and the enormous complexity of these languages. I have been programming in C++ for 10 years and still cannot say I am an expert, and probably never will. The one thing I will say is that I don’t ever want to be called “An X programmer”, whatever that value of X may be!
May 5th, 2008 at 12:37 pm (#)
> It certainly can take some people many years to master enormous languages like Java and C++, but most languages are simply nowhere near that big.
Even when the languages are nowhere near that big, deep knowledge of libraries lets us avoid writing code ourselves.
> If it were just syntax, then that would imply that all languages are equal in terms of expressiveness and capability, which we already know and accept to be untrue.
When there’s common syntax we can playfully refactor from functional style to oo style to imperative style and figure out what fits. Several languages do to some extent support different styles but either take destructive assignment as basic or forbid destructive assignment.
Mozart/Oz provides a different syntax for destructive assignment, and with that we can more obviously refactor from a destructive assignment style to a pure functional style. It’s slightly strange watching the programs become more declarative as you write more of them, without having any particular intention to make them more declarative – using destructive assignment when it feels right rather than as a matter of course.
http://www.mozart-oz.org/features.html
May 6th, 2008 at 1:37 am (#)
While I started reading your blog with a healthy bit of skepticism and a premeditate bias to disagree with your points, I actually agreed with most of your points in the end. From my own experience, being hardly two years out of college (just to give a measure of actual industry programming experience), I am already much more proficient in switching between languages like Java, C, Python and Javascript seamlessly, without losing context. Even Common Lisp and Scheme (which I have started seriously learning).
I agree that any “smart” (sic) person would be able to master the “paradigms” of programming and suitably adapt to an ever-changing technological world, which inevitably means being proficient in more than three languages of different principles ( to use Norvig’s insinuation ;-) ).
Nice, balanced rebuttal of the mentioned comment.
May 6th, 2008 at 8:38 am (#)
Actually fluency in multiple languages is becoming a requirement nowadays. I have been using Java for quite a long time but now I use Rhino too. I am learning powerful features of JavaScript because our tool uses Rhino. This helps me to implement these features to write JS libraries.
One thing leads to the other.
When I was using WebSphere I used JACL ( JPython is supported too ) to write deploy scripts.
One language alone is usually not enough even in conservative projects.
Mohan
May 6th, 2008 at 7:10 pm (#)
The ability to adapt and a hunger for improvement are the key traits I have seen in most of the sucessfull programmers I have worked with during my career. Most of those folks were proficient in several languages and always experimented with new languages and tried different things in their own free time. They were not hung up on one language. They appreciated the strenghts and knew the weakness of those languages and wasn’t shy in using the right language for the right job allthough most times java was forced upon them by stupid managers.
If you are sound with programming concepts you should be able to pick up a new programing language easily. All you need is an open mind and a genuine willingness to learn something new that may (or may not) push you out of your comfort zone.
For most people it’s their unwilligness to change, not any lack of ability that prevents them from learning something new. They are content with java or c++ (or whatever they are working with) and is quite happy with the status quo. I have met folks who think assembly or c is all they need.
I always believed in using the right tool for the right job. It saves me time and effort. Why should I write 100 lines of java code when 10 lines of python can do the same job?
I usually learn as I go. I have never felt the need to completely master a language before I start coding seriously with it. I have been coding for 10 years now and I am still learning things. If I have the opportunity to write something in a new language, I grab it with both hands.
May 7th, 2008 at 2:44 am (#)
As Lauri Pesonen wrote in one of the above comments:
This has been my experience as well. In a response to David Heinemeier’s October 26th, 2004 post titled “Fear-driven technology choices”:
http://www.loudthinking.com/arc/000333.html
Where David’s “Fear-driven technology choices” is basically the same as Steve’s assessment of our industry’s “bad habit of continually seeking homogeneity in platforms, in languages, in tools, in frameworks, etc “monolingual” choice
I commented that:
Management in IT has a strong tendency to state the problems they want their technical people to solve in terms of solutions. If they want two systems to be integrated they should refrain from mentioning Web Services, XML, Java, or whatever potential solution they are vaguely familiar with. They should leave it to their architect, technical team lead, or whoever is (should) be in the position to make those decisions. Getting Erlang, Python or some other language considered is almost insurmountable when management is thinking along the lines of Java and Web Services.