By M. Ben-Ari
To say that a good programmer can write good software in any language is like saying that a good pilot can fly any aircraft: true, but irrelevant. A passenger aircraft is designed for safety, comfort and economic viability; a military aircraft is designed for performance and mission capability; an ultralite aircraft is designed for low cost and operational simplicity.
The role of language in programming has been downgraded in favor of software methodology and tools; not just downgraded, but totally repudiated when it is claimed that a well-designed system can be implemented equally well in any language. But programming languages are not just a tool; they furnish the raw material of software, the thing we look at on our screens most of the day. I believe that the programming language is one of the most important, not one of the leastimportant, factors that influence the ultimate quality of a software system. Unfortunately, too many programmers have poor linguistic skills. He/she is passionately in love with his/her ``native'' programming language, but is not able to analyze and compare language constructs, nor to understand the advantages and disadvantages of modern languages and language concepts. Too often, one hears statements that demonstrate conceptual confusion: ``Language L1 is more powerful (or more efficient) than language L2''.
This lack of knowledge is a contributing factor to two serious problems in software. The first is the ultra-conservatism that exists in the choice of programming languages. Despite the explosive advances in computer hardware and the sophistication of modern software systems, most programming is still done in languages that were developed about 1970, if not earlier. Extensive research in programming languages is never tested in practice, and software developers are forced to use tools and methodologies to compensate for obsolete language technology. It is as if airlines would refuse to try jet aircraft on the grounds that an old-fashioned propeller aircraft is perfectly capable of getting you from here to there.
The second problem is that language constructs are used indiscriminately, with little or no regard for safety or efficiency. This leads to unreliable software that cannot be maintained, as well as to inefficiencies that are solved by assembly language coding, rather than by refinement of the algorithms and the programming paradigms.
Programming languages exist only for the purpose of bridging the gap in the level of abstraction between the hardware and the real world. There is an inevitable tension between higher levels of abstraction that are easier to understand and safer to use, and lower levels of abstraction that are more flexible and can often be implemented more efficiently. To design or choose a programming language is to select an appropriate level of abstraction, and it is not surprising that different programmers prefer different levels, or that one language may be appropriate for one project and not for another. Within a specific language, a programmer should understand in depth the safety and efficiency implications of each construct in the language.
The role of language in programming has been downgraded in favor of software methodology and tools; not just downgraded, but totally repudiated when it is claimed that a well-designed system can be implemented equally well in any language. But programming languages are not just a tool; they furnish the raw material of software, the thing we look at on our screens most of the day. I believe that the programming language is one of the most important, not one of the leastimportant, factors that influence the ultimate quality of a software system. Unfortunately, too many programmers have poor linguistic skills. He/she is passionately in love with his/her ``native'' programming language, but is not able to analyze and compare language constructs, nor to understand the advantages and disadvantages of modern languages and language concepts. Too often, one hears statements that demonstrate conceptual confusion: ``Language L1 is more powerful (or more efficient) than language L2''.
This lack of knowledge is a contributing factor to two serious problems in software. The first is the ultra-conservatism that exists in the choice of programming languages. Despite the explosive advances in computer hardware and the sophistication of modern software systems, most programming is still done in languages that were developed about 1970, if not earlier. Extensive research in programming languages is never tested in practice, and software developers are forced to use tools and methodologies to compensate for obsolete language technology. It is as if airlines would refuse to try jet aircraft on the grounds that an old-fashioned propeller aircraft is perfectly capable of getting you from here to there.
The second problem is that language constructs are used indiscriminately, with little or no regard for safety or efficiency. This leads to unreliable software that cannot be maintained, as well as to inefficiencies that are solved by assembly language coding, rather than by refinement of the algorithms and the programming paradigms.
Programming languages exist only for the purpose of bridging the gap in the level of abstraction between the hardware and the real world. There is an inevitable tension between higher levels of abstraction that are easier to understand and safer to use, and lower levels of abstraction that are more flexible and can often be implemented more efficiently. To design or choose a programming language is to select an appropriate level of abstraction, and it is not surprising that different programmers prefer different levels, or that one language may be appropriate for one project and not for another. Within a specific language, a programmer should understand in depth the safety and efficiency implications of each construct in the language.
Read More/Download
