I was lately doing some research about different programming languages. I was interested particularly to learn unique features of popular programming languages and situations where these assets shine. I believe this can help me to decide what language to use depending upon the problem to solve.
I found that many languages offering high level of flexibility (“can adapt to new, different, or changing requirements”) are also inconsistent,
for example in JavaScript (just an example, no offense to js people), arguments of a function get be manipulated either by naming them in the function declaration (classic approach):
function max(x,y)
Or by using the arguments variable:
function max() {
if (arguments[0] < arguments[1])
return arguments[1];
else
return arguments[0];
}
c = max(1,2);
The arguments variable is useful for many situations such as function overloading, however, it defeats the purpose of function prototyping (which is to give information about the function), and I saw many JavaScript samples where the argument variable is being used despite there is no need for it, which clearly makes the code harder to understand and debug.
I know that this depends heavily on the users of the language, but usually, code written in a language offering high flexibility tends to be unsafe, harder to understand,optimize and to debug.
Do flexibility and inconsistency overlap? How do languages designers make the choice?
Edit: I’m not critiquing any particular language here, I’m rather focusing on the relation between Flexibility,Safety,Consistency of programming languages.
3
I don’t think flexibility and inconsistency overlap or have a natural 1:1 relationship. More on this in a bit.
As for your other question, I would assume that language designers make these choices the same way they make any other choice; by comparing the pros and cons and deciding which one is the most suited for the language and the problem. Inconsistency is a con but there are pros that outweigh it.
For example, in your specific question about the arguments keyword, it’s very useful in a functional context where you apply arguments to function calls. In fact, documentation for apply indicates such. Otherwise you would specifically have to loop through arguments that you might not even have named. This can be a significant benefit.
Consider:
function f() { console.log(arguments); }
f(); // [ ]
f(1, 2, 3); // [1, 2, 3]
In JavaScript, the binding between named arguments happens automatically based on position, but you can provide any number of arguments to any function. Because of this behavior, it doesn’t seem inconsistent to provide a facility to interact with the arbitrary arguments. Additionally, you could view the named argument binding as the special case; syntactic sugar over var arg1 = arguments[0]; etc.
As far as flexibility and inconsistency, I think they’re primarily two separate measurements of modifications. I don’t really have any references to discussions of the two forces, however, in C#, for example, you could increase the flexibility of generic constraints quite a bit by providing mechanisms to constrain generics to delegates or enumerations. This is completely consistent with the existing language.
It just so happens that often a price to pay for flexibility is inconsistency, for example, C++11 added trailing return type declarations simply to support lambdas and a couple other compile-time type inference features. This was completely inconsistent but it allowed a new dimension of flexibility which was deemed important enough to allow the inconsistency.