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];
        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.

  • 1
    One trick I can think of is to use a few powerful metaphors and to introduce ad-hoc syntactic sugar to capture frequent idioms. IMO what causes inconsistency is to introduce ad-hoc semantics instead of ad-hoc syntax.
    – Giorgio
    Commented Mar 17, 2013 at 11:37
  • I have never seen Javascript code that used the arguments object in a situation where named arguments could be used instead like your example implies.
    – Esailija
    Commented Mar 17, 2013 at 14:25
  • @Esailija If I had to guess, I think Pindexis is thinking of something where the function had 1 or 2 required arguments (which could be named), but the rest are variable. The function body was probably written to use arguments for all of them (which, IMO, is usually easier to read, since the named arguments would still show up in arguments IIRC)
    – Izkata
    Commented Mar 18, 2013 at 1:40

1 Answer 1


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.