3 ms·
There is a difference though. In a (strict) functional language, foo(bar) always returns the same way and always has the same affect. In almost every non-stri
by eof 10y ago
There is a difference though.
In a (strict) functional language, foo(bar) always returns the same way and always has the same affect.
In almost every non-strict language foo(bar) can do anything, and can always be different based off some state not contained in foo or bar, but only the scope of the program.
So while mathematically they may both be equally as predictable at the physical level, given only a function its parameters, a strict functional language is predictable while a 'traditional' language is not
- clusmore 10y agoI don't think that this is because of functional vs other, but because of the assignment operator and mutable primitives (which functional languages tend to omit). Consider \x y -> g (f x) (f y) We have no way of knowing what this function will do, because f and g are free variables with respect to the function. But we assume they are constant, so we're happy. And if you zoom out far enough eventually you'll find the binding locations. Instance members and globals are just the imperative version of free variables, and if it weren't for that pesky assignment operator or mutable primitives, they'd be constant and hence completely harmless too. You could imagine an OO language without assignment or mutable primitives that would have all the advantages of "functional" languages but that would still feel different enough in style that we wouldn't call it one.