If we were to show the general function definition in computer programming to somebody whose is not a software professional it would be nothing more than an unintelligible collection of words.

  • Example 9, Schematic definition of a function
  • [language specific modifiers] result_type function_name(
    		parameter_type_0 parameter_name_0,
    		…, 
    		parameter_type_n parameter_name_n){
    	…
    	function body
    	...
    }

As strange this may seem to the audience, the reason for this is that the generic definition form is nothing more than the definition, of the definition, of functions. The words are laid down in a very specific order, certain delimiters are used to separate words like, “modifier”, “return type”, “function name”, “parameter name”, and so on1 that make absolutely no sense to the untrained eye. This aspect may seem unimportant, considering that such people do not get deep enough into the technical side of applications for this to matter, however this emphasizes how in the understanding process of human beings, structure means nothing without context and meaning.

If on the other hand such a person takes a look at an actual example of a function, he or she might be able to comprehend what the function is suppose to do, even if they had no connection with programming, provided they are familiar with the terms used in the function:

  • Example 10, Intelligible function example
  • Number divide(Number nominator, Number denominator){
    	return nominator/denominator;
    }
    

Even if this person has never seen an operation written like this, but has knowledge of the division operation between numbers, he or she can realize that this operation is what the layout is actually about. This is possible because the words themselves “number”, “divide”, “denominator”, “nominator” have very well defined meanings in the individual’s intellect and together they hint towards the division of the nominator by the denominator.

It is not the structure of the function that leads the person to this conclusion, it is the combination of a certain set of concepts that together lead to a unique conclusion. It could be presented in any other form, as long as the person has knowledge of the division of numbers he or she would still come to the same conclusion. In fact the irony is that the function could actually do a completely different thing, with regards to the implementation, as long as the person does not see or cannot understand the implementation of the function, would still conclude that the function performs a division. This scenario however is not likely, because the fact that the function is laid out and named such is a consequence of the need of developers to embed additional knowledge in the description of the function which makes it recognizable and easy to work with.

Compilers completely do away with these human readable information, because programs do not need them to perform their pre-programmed jobs:

  • Example 11, Function stripped away of semantic hints
  • Number a(Number b, Number c){
    	return b/c;
    }

the definition in example: 11 is just as good from a computer’s perspective, if only a programmer could keep track of functions that way.

The computer can do this, because the program, when finished, does not require meaning in the operations only series of correctly laid out operations that in the end can yield the expected result. It is the cognitive process of creating the program itself which requires additional knowledge to be embedded in these functions and the definition form of function allows that for most programming languages2.

For simplicity, this knowledge that can be embedded in the description of the functions while building computer programs is not regulated. Neither is the order of the parameters, or their type. It is a generic scaffold that can be used to implement a great variety of operations, even multiple variations of implementations for the same operation.

The function:

  • Example 12, Division function with parameters in reversed order
  • Number divide(Number denominator, Number nominator){
    	return nominator/denominator;
    }

gives the same result as the one defined in the previous example but the input parameters need to be provided in a different order: 

  • Example 13, Call of division function for different implementations
  • divide(10, 5) = 2, in case of the definition at example: 10
    divide(5, 10) = 2, in case of the definition in example: 12

The program itself will not make this distinction, the programmer has to do it during the programming procedure and make sure the functions are used in the correct form. Failure to do so, result in errors in program that may be very difficult to find. For this reason, functions are usually accompanied by documentation which provide even more details about the way they behave, exceptional situations3, parameter types, and so on.

Notice that although the order of the parameters were reversed in the declaration of the function, they appear in the same order in the body of the function:

  • Example 14
  • nominator/denominator

This is because the names themselves were chosen to represent the position of the number with the operation that the function is supposed to perform. In a division in mathematics, the concept of “nominator” represents the number that is being divided and the “denominator” the number that is being divided with. By using these names, it is easier for program developers to use the function. Had we used the conceptless representation like in example: 11, there would be no way of knowing which one is which. Within the context of a programmer’s knowledge, such names, represent real information, because the names themselves are semantic charges that link whatever is being done there in the code to the actual reality that exists in the programmer’s head and as a matter fact in the entire reality (mathematical reality in our case) shared by all programmers.

After compilation, functions become machine language. They are stripped of all meaning, leaving behind an optimized chain of commands, which the machine executes blindly until it reaches an exit point. This is what software is, stacks upon stacks of commands interacting with a layer of standardized interfaces and communication protocols making it very difficult to quality test an application: the machine can’t do it, because it is not supposed to and it does not have the means, people can do it but they are basically testing a black box, which sometimes can be really complex.

  • 1, Notice the lack of underscore in the enumeration. Humans outside the technical realm, who do not understand the importance of space versus underscore from the perspective of parsing will not give any importance to it.
  • 2, Assembly language will not allow for such knowledge but languages like this are very rarely used and usually for small scale applications or modules.
  • 3, In the given example, division by zero is a mathematical impossibility and thus cannot yield a number as a result. This is an exceptional situation which is handled differently.