Yeah, but the point is that variables can also encapsulate behaivor, and variables can also occupy a heirarchy of namespaces. So, a "global function" really isn't any better than a "global variable". They're both just globals.
| [reply] |
Yeah, but the point is that variables can also encapsulate behaivor, and variables can also occupy a heirarchy of namespaces
Under certain circumstances this is true, but I would say its the exception rather than the rule. Unless of course you care to elaborate on what exactly you mean by "variables encapsulating behavior" outside of tied variables.
So, a "global function" really isn't any better than a "global variable". They're both just globals.
Yup, very true, just one more reason to always use packages, then your functions will never have to be global ;-)
Although, I will say that the one (very important) difference between global functions and global variables is that one contains state and the other does not (barring things like closures and other assorted silliness). It is tracking all the state transistions that make global variable (all variables actually) difficult and unweildy.
There is a reason why most functional languages either do not have assignment (Haskell), have single assignment variables (Erlang) or have large caveats surrounding their more imperiative features (LISP, ML, etc). A program is much easier to reason about and study when you dont have a rat's nest of state transitions to follow. If your program can be looked at as one giant (highly complex) expression, it becomes much easier to prove a level of 'correctness' for your program.
| [reply] |
If your program can be looked at as one giant (highly complex) expression, it becomes much easier to prove a level of 'correctness' for your program.
Balderdash Functional programs have stacks and lists, and they are state. The difference is, that state is hidden, and nearly impossible to interogate. A misplaced parens can completely alter the behaviour of your "one giant (highly complex) expression" without ever raising an error.
Quite how that makes it easier to prove correctness is beyond me.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
| [reply] |