Programming Language Based on Limiting Function Arguments – Design Concepts

designfunctional programmingfunctionsprogramming-languages

The idea is inspired by the fact operators such as +, -,%, etc. can be seen as functions with either one or two arguments passed, and no side-effects. Assuming I, or someone else, writes a language which stops more than two arguments from being passed, and also only works via return value:

a) would such a language lead to easier to understand code?

b) would the flow of the code be clearer? (forced into more steps, with potentially less interactions 'hidden'

c) would the restrictions make the language inordinately bulky for more complex programs.

d)(bonus) any other comments on pros/cons

Note:

Two decisions would still have to be made- the first is whether to allow user-input outside main() or its equivalent, and also what the rule will be regarding what happens when passing arrays/structures. For an example, if someone wants a single function to add multiple values, he could get around the limitation by bundling it into an array. This could be stopped by not allowing an array or struct from interacting with itself, which would still allow you to, for example, divide each number by a different amount, depending on it's position.

Best Answer

Robert C. Martin in his book "Clean Code" recommends heavily the use of functions with 0, 1 or 2 parameters at maximum, so at least there is one experienced book author who thinks code becomes cleaner by using this style (however, he is surely not the ultimative authority here, and his opinions are debatable).

Where Bob Martin is IMHO correct is: functions with 3 or more parameters are often indicators for a code smell. In lots of cases, the parameters might be grouped together to form a combined datatype, in other cases, it can be an indicator for the function simply doing too much.

However, I do not think it would be a good idea to invent a new language for this:

if you really want to enforce such a rule throughout your code, you just need a code analysis tool for an existing language, no need to invent a completely new language for this (for example, for C# something like 'fxcop' could probably be utilized).
sometimes, combining parameters to a new type just does not seem worth the hassle, or it would become a pure artificial combination. See, for example, this File.Open method from the .Net framework. It takes four parameters, and I am pretty sure the designers of that API did this intentionally, because they thought that would be the most practical way to provide the diffferent parameters to the function.
there are sometimes real world scenarios where more than 2 parameters make things simpler for technical reasons (for example, when you need a 1:1 mapping to an existing API where you are bound to the usage of simple datatypes, and can't combine different parameters into one custom object)

Related Solutions

Why aren’t user-defined operators more common?

There are two diametrically opposed schools of thought in programming language design. One is that programmers write better code with fewer restrictions, and the other is that they write better code with more restrictions. In my opinion, the reality is that good experienced programmers flourish with fewer restrictions, but that restrictions can benefit the code quality of beginners.

User-defined operators can make for very elegant code in experienced hands, and utterly awful code by a beginner. So whether your language includes them or not depends on your language designer's school of thought.

Programming Languages – Dealing with Unknown Parameter Names in Functions

I agree that the way functions are often used can be a confusing part of writing code, and especially reading code.

The answer to this problem partly depends on the language. As you mentioned, C# has named parameters. Objective-C's solution to this problem involves more descriptive method names. For example, stringByReplacingOccurrencesOfString:withString: is a method with clear parameters.

In Groovy, some functions take maps, allowing for a syntax like the following:

restClient.post(path: 'path/to/somewhere',
            body: requestBody,
            requestContentType: 'application/json')

In general, you can solve this issue by limiting the number of parameters you pass to a function. I think 2-3 is a good limit. If it appears that a function needs more parameters, it causes me to re-think the design. But, this can be harder to answer generally. Sometimes you are trying to do too much in a function. Sometimes it makes sense to consider a class for storing your parameters. Also, in practice, I often find that functions which take large numbers of parameters normally have many of them as optional.

Even in a language like Objective-C it makes sense to limit the number of parameters. One reason is that many parameters are optional. For an example, see rangeOfString: and its variations in NSString.

A pattern I often use in Java is to use a fluent-style class as a parameter. For example:

something.draw(new Box().withHeight(5).withWidth(20))

This uses a class as a parameter, and with a fluent-style class, makes for easily readable code.

The above Java snippet also helps where the ordering of parameters may not be so obvious. We normally assume with coordinates that X comes before Y. And I normally see height before width as a convention, but that is still not very clear (something.draw(5, 20)).

I've also seen some functions like drawWithHeightAndWidth(5, 20) but even these can't take too many parameters, or you'd start to lose readability.

Best Answer

Related Solutions

Why aren’t user-defined operators more common?

Programming Languages – Dealing with Unknown Parameter Names in Functions

Related Topic