Sometimes to chose a solution rather then an other could be a philosofical issue, but sometimes is not.
I think that one of the most important differences between SUBs and FUNCTIONs, is the way they can be "called", as to say a SUB must formally CALLed, FUNCTIONs are more likely used as a kind of command.
For example:
FUNCTION Arrotonda! (num!)
Arrotonda! = _ROUND(num! * 100) / 100
END FUNCTION
This function takes a number, for example 453.326789, it multiplies it by 100 = 45332.6789, it rounds it to 45333 and it divides it by 100 = 453.33. Eventually, it simply rounds 453.326789 to 453.33.
If "Arrotonda!" were a SUB, I should have called it by someting like that:
CALL Arrotonda(N!)
so, I should had this SUB:
SUB Arrotonda (num!)
num! = _ROUND(num! * 100) / 100
END SUB
And that's ok: this SUB makes almost the same thing of the FUNCTION.
But, let's take this line:
_PRINTSTRING (x% + 4, y% - 16), "(" + _TRIM$(STR$(Arrotonda!(X!))) + ";" + _TRIM$(STR$(Arrotonda!(Y!))) + ")"
If "Arronda" is a SUB, it's not possible to use it like that: it doesn't work.
I could do this:
CALL Arrotonda (X!)
CALL Arrotonda (Y!)
_PRINTSTRING (x% + 4, y% - 16), "(" + _TRIM$(STR$(X!)) + ";" + _TRIM$(STR$(Y!)) + ")"
But I have the variable X! and Y! changed.
The SUB can't be equal to the FUNCTION like that:
SUB Arrotonda! (num!)
Arrotonda! = _ROUND(num! * 100) / 100
END SUB
because the "!" is not admited and, without the "!", we will have:
SUB Arrotonda (num!)
Arrotonda = _ROUND(num! * 100) / 100
END SUB
but in that case we have a "variable" named "Arrotonda" which is effective only in the SUB. Even with SHARED, the line:
_PRINTSTRING (x% + 4, y% - 16), "(" + _TRIM$(STR$(Arrotonda(X!))) + ";" + _TRIM$(STR$(Arrotonda(Y!))) + ")"
doesn't works, just because "Arrotonda" in that case, even if effective also in the main code, it is, as said, a variable itself, not a function that does something with a varabile.
Furthermore, in order to avoid the changing of the variables X! and Y!, it would be necessary to make some modifications, as to introduce SHARED variables. And it will be always impossibile to use the SUB into a line as it were a FUNCTION. Eventually, in order to make with a SUB the same thing that with a FUNCTION, it would be necessary, before the line, to CALL the SUB first (as said) many times and then, by means of SHARED variables, use the line changing the "Arrotonda!" function with those variables. But it would be all much much more complicated, with an useless use of memory for useless variables. We can easily think about the importance of FUNCTIONs even in this very simple example, not to notice if lines like the above, which uses "Arrotonda!" many times itself, have to be used a lot of times in similar ways.
"Arrotonda", as a SUB "does someting" that could return a value. "Arrotonda!" (just with the "!"), as a FUNCTION it takes the value itself.
So, for what I can say, FUNCTIONs return a value. Also SUBs can return a value, but in the first case you have a kind of usable command, on the contrary in the second one you have a kind of "function" that must be CALLed alone, and not inside something more complex. In other words, generally when you call a SUB you are interested to have done only what the SUB is intended to do. For that reason, SUBs are often true programs inside the program.
I think that one of the most important differences between SUBs and FUNCTIONs, is the way they can be "called", as to say a SUB must formally CALLed, FUNCTIONs are more likely used as a kind of command.
For example:
FUNCTION Arrotonda! (num!)
Arrotonda! = _ROUND(num! * 100) / 100
END FUNCTION
This function takes a number, for example 453.326789, it multiplies it by 100 = 45332.6789, it rounds it to 45333 and it divides it by 100 = 453.33. Eventually, it simply rounds 453.326789 to 453.33.
If "Arrotonda!" were a SUB, I should have called it by someting like that:
CALL Arrotonda(N!)
so, I should had this SUB:
SUB Arrotonda (num!)
num! = _ROUND(num! * 100) / 100
END SUB
And that's ok: this SUB makes almost the same thing of the FUNCTION.
But, let's take this line:
_PRINTSTRING (x% + 4, y% - 16), "(" + _TRIM$(STR$(Arrotonda!(X!))) + ";" + _TRIM$(STR$(Arrotonda!(Y!))) + ")"
If "Arronda" is a SUB, it's not possible to use it like that: it doesn't work.
I could do this:
CALL Arrotonda (X!)
CALL Arrotonda (Y!)
_PRINTSTRING (x% + 4, y% - 16), "(" + _TRIM$(STR$(X!)) + ";" + _TRIM$(STR$(Y!)) + ")"
But I have the variable X! and Y! changed.
The SUB can't be equal to the FUNCTION like that:
SUB Arrotonda! (num!)
Arrotonda! = _ROUND(num! * 100) / 100
END SUB
because the "!" is not admited and, without the "!", we will have:
SUB Arrotonda (num!)
Arrotonda = _ROUND(num! * 100) / 100
END SUB
but in that case we have a "variable" named "Arrotonda" which is effective only in the SUB. Even with SHARED, the line:
_PRINTSTRING (x% + 4, y% - 16), "(" + _TRIM$(STR$(Arrotonda(X!))) + ";" + _TRIM$(STR$(Arrotonda(Y!))) + ")"
doesn't works, just because "Arrotonda" in that case, even if effective also in the main code, it is, as said, a variable itself, not a function that does something with a varabile.
Furthermore, in order to avoid the changing of the variables X! and Y!, it would be necessary to make some modifications, as to introduce SHARED variables. And it will be always impossibile to use the SUB into a line as it were a FUNCTION. Eventually, in order to make with a SUB the same thing that with a FUNCTION, it would be necessary, before the line, to CALL the SUB first (as said) many times and then, by means of SHARED variables, use the line changing the "Arrotonda!" function with those variables. But it would be all much much more complicated, with an useless use of memory for useless variables. We can easily think about the importance of FUNCTIONs even in this very simple example, not to notice if lines like the above, which uses "Arrotonda!" many times itself, have to be used a lot of times in similar ways.
"Arrotonda", as a SUB "does someting" that could return a value. "Arrotonda!" (just with the "!"), as a FUNCTION it takes the value itself.
So, for what I can say, FUNCTIONs return a value. Also SUBs can return a value, but in the first case you have a kind of usable command, on the contrary in the second one you have a kind of "function" that must be CALLed alone, and not inside something more complex. In other words, generally when you call a SUB you are interested to have done only what the SUB is intended to do. For that reason, SUBs are often true programs inside the program.