How to counter the "one true language" perspective?

Question

How do you work with someone when they haven't been able to see that there is a range of other languages out there beyond "The One True Path"?

I mean someone who hasn't realised that the modern software professional has a range of tools in his toolbox. The person whose knee jerk reaction is, for example, "We must do this is C++!" "Everything must be done in C++!"

What's the best approach to open people up to the fact that "not everything is a nail"? How may I introduce them to having a well-equipped toolbox, selecting the best tool for the job at hand?

Answer 1

Give them a screwdriver and tell them to build a house?

Answer 2

Give them a task which can be done much easily in some other language/technology and also its hard to do it the language/technology that he/she is suggesting for everything.

This way they will eventually search for alternatives as it gets harder and harder for them to accomplish the task using the language/technology that they know.

Answer 3

Don't hire them.

Answer 4

Put them in charge of a team of COBOL programmers.

Answer 5

As long as there are valid reasons for it to be done in C++, I don't see anything wrong with this monolithic approach.

Of course a good programmer must have many different tools in his/hers toolbox, but these tools don't need to be a new language, it can simply be about learning new programming paradigms.

As much as I've experienced actually, learning many different languages doesn't make you much of a better programmer at all.

This is also true with finding the right language for the job. Yeah ok, if you're doing concurrency you might want a functional language rather than an Object Oriented language, but what are the gains of using another programming language?

Answer 6

Lead by example, give them projects that play to their strengths, and encourage them to learn.

If they are given a task that is obviously better suited for some other technology and they choose to use a less effective language, don't accept the work. Tell them it's not an appropriate solution to the problem. Think of it as no different then them choosing Cobol to take the replace of a shell script -- maybe it works, but it will be hard to maintain over time, take too long to develop, require expensive tools, etc.

You also need to take a hard look at the work they do and decide if it's really a big deal or not if it's done in C++. For example, if you have plenty of staff that knows that language and they finished the task in a decent amount of time, what's the harm? On the other hand, if the language they choose slows them down or will lead to long term maintenance problems they need to be aware of that.

There are plenty of good programmers who only know one language well. That fact in and of itself can't be used to determine if they are a valuable member of a team. I've known one-language guys who were out of this word, and some that I wouldn't have on a team if they worked for free.

Answer 7

Ask them to produce a binary that outputs an infinite Fibonacci sequence.

Then show them the few lines (or 1 line, depending on the implementation) it takes in Haskell, and that it too can be compiled into a binary so there are better ways forward.

Answer 8

At the end of the day; "Maintenance".

If it can be maintained without undue problems then the debate may well be moot and comes down to preference or at least company policy/adopted technology.

If that is satisfied then the debate becomes "Can it be built efficiently to be cost effective and not cause integration problems?"

Beyond that it's simply the screwdriver/build a house argument.

Answer 9

How may I introduce them to having a well-equipped toolbox, selecting the best tool for the job at hand?

I believe that the opposite of "one true language" is "polyglot programming", and I will then refer to another answer of mine:

• Is polyglot programming important?

I actually doubt that anybody can nowadays realize a project in one and only one language (even though there might be exceptions). The easiest way to show them the usefulness of specific tools and languages, is then to show them that they are already using several ones, e.g. SQL, build file, various XML dialect, etc.

Though I embrace the polyglot perspective, I do also believe that in many area "less is more". There is a balance to find between the number of language/tools, the learning curve, and the overall productivity.

The challenge is to decide which small set of languages/tools fit nicely together in your domain and will push productivity and creativity to new limits.