Programming languages are not just tools

Let me start this article with a disclaimer: I absolutely agree that I understand the value of multiple programming languages and think that "using the right tools to do work" is a good idea. But in programming, people have a misunderstanding of this concept. I think it is necessary to point out it here. However, remember that the interpretation of this misunderstanding does not deny this idea.

 

Multilingual movies
Let me start with an odd analogy: Suppose there is a movie about a political conspiracy that involves a series of complex international adventures and conflicts that spread to seven or eight countries. Every actor speaks their local language without subtitles. Who can understand the plot of this conspiracy? I'm afraid only a few multilingual producers can enjoy this movie. Most of us will not look at it.

 

Multi-language programming
Our previous Web application project used 6 or 7 Programming Languages (Groovy, Java, HTML, CSS, HQL/SQL, Ant ). If we feel we need it, we can easily add more languages. Adding Clojure, Scala, Ruby/JRuby is not inappropriate. A programmer who understands multiple languages and has the ability to switch between multiple languages is called a "multi-language programmer ".

 

A major reason for multi-language projects is generally the concept of "using the right tools to work. This "work" usually refers to some small tasks in a large project, such as compiling a project, accessing a database, and implementing business logic that is never finalized. For each subtask, a language can be better accomplished. In addition to disputes over the hidden cost caused by this multilingual approach, there is also a misunderstanding of the word "tool" which requires attention.

 

Programming language is not a tool
If we use a tool in a simple or complex traditional project, for example, using a hammer to pin a piece of wood into a cupboard, or using a start to disassemble a computer, after you finish this "job, you will leave the tool aside. Your final product (A New Wooden Cabinet or a pile of circuit boards) does not include tools. Most of the time, after your work is complete, there will be no "change requests" on your products ".

 

If your tool happens to be a programming language, the source code you produce will be integrated with your tool. Without this tool, your product cannot run at all. If you think that the compiled binary code is a "product", you are not likely to make "demand changes" for it. This is an incorrect concept that programmers may initially have. Obviously, programmers produce "source code ". A programming language is not a tool role. In terms of the nature of software, it should be material. Tools can be discarded, and materials constitute the main body.

 

The programming language is the product material.
Because the source code is attached to its programming language, they are a conceptual fit. Therefore, I suggest that when we are talking about programming languages, we should change it to "use the correct materials to do the work. Compared to the use of Phillips screwdrivers or the change of Mitsubishi's cone, our modified statement will play a more profound role in programming language selection. Materials need to be durable, and most of the time the tool is left aside.

 

But they are also tools
We have used many tools in the Web application projects we mentioned above. Grails is our Framework, Jetty is our Web Container, Spring Framework provides powerful services, and we use IDEA to combine them. We can easily replace Jetty With Tomcat or IDEA with Eclipse. The tool must be replaceable or even disposable.

 

Summary
"Using the right tools to work" cannot be simply applied to programming languages, because they are not tools, but materials. This is why it is dangerous to use multiple languages in a project. It easily turns a project into a chaotic "Compound board" project.