3 ms·

Not quite. "When you apply parentheses surrounding one or more values to a variable, Scala will transform the code into an invocation of a method named apply o

Not quite. "When you apply parentheses surrounding one or more values to a variable, Scala will transform the code into an invocation of a method named apply on that variable." So it's much closer to: class F(object): # you can't actually do this in Python, because F() isn't bound at this # point, but that's close to what Scala does. __name__.f = F() def __call__(cls, s): return s + "bar" f("foo") I'm not quibbling that f() isn't a "real" top-level function, but I would like to know what the essential differences are such that you feel that Scala's solution is inferior. It seems like an unbelievably fine hair to split to me.

chimeracoder 14y ago
Inferior (or 'unworkable', before you edited the comment)? Where are you getting that from? I never said that - I use Scala myself (and used to use it at work). Java is certainly inferior, because Java is OO done badly. > "When you apply parentheses surrounding one or more values to a variable, Scala will transform the code into an invocation of a method named apply on that variable." Now I've lost track of what you're quoting from, but that's by definition very OO. It's a modified form of the messaging pattern employed by Smalltalk. Scala isn't a functional/object-oriented hybrid; it's purely object-oriented (even more so than Java) because it has one single kind[1]: the object (Java pretends to have one, but it really has five, if you really wanted to get pedantic). So we shouldn't be celebrating Scala for being a functional hybrid - we should celebrate as being 'OO done right' (well, mostly right), which was the stated and failed intent of Java. The distinction is subtle, but the important thing to remember is that I'm operating on the premise that proper OO is essentially a subset/extension of FP, not an alternative. So what I'm saying is that this doesn't show that Scala is 'more functional' (vs. 'less functional') - rather, it shows that Scala is good OO (vs. bad OO, ie Java). I agree that it's a bit like the 'white horse is not a horse' argument, but it becomes important when we start talking about non-white horses; ie, functional languages that aren't OO). [1] I'm kind-of (no pun intended) abusing the term 'kind', but I can't think of a non-overloaded synonym as the moment, other than 'type' which would be worse.
- hythloday 14y ago
  The quote's from Programming in Scala, I wanted to look up exactly how the apply() sugaring is described by the author of the language. I'm not sure it is by definition OO, it just looks like operator overloading to me, similar to C++'s operator() or Python's __call__. Maybe I'm misunderstanding your broader point - claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency, and that it's such an obvious one you don't need to explain why. From my perspective the only reason I care about namespaces is a) that I can namespace my functions and b) so that I don't have to type things out longhand - the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me, and seems to me to be nearly irrelevant in evaluating if a language is "really" OO or "really" functional. If module-level functions are important to the question I would like to know why. :)
  - chimeracoder 14y ago
    > claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency It's not a deficiency, but it emphasizes the fact that Scala is object-oriented, not functional. Scala supports first-class objects, and you get more functional features than Java because, unlike Java functions, Scala functions are objects. In other words, Scala's support for certain functional features is a corollary of its support for first-class objects, not because of its support for first-class functions. > the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me Which probably means that most of this discussion may be irrelevant to your interests too. :-) That's not meant to be rude - I'm being a bit facetious, but I'll readily admit that the OO 'vs.' FP is far too subtle for most people to care about... and that's fine. Beyond a certain point, it's a discussion with more academic value than practical value. But if you really care, let me try and explain the following: > If module-level functions are important to the question I would like to know why. :) Lack of module-level functions is a hint (though not proof) that Scala is 'OO first, and FP by coincidence'. Objects are just classes that are automatically created and instantiated with a singleton. Scala permits nesting of objects (objects within objects). The nested objects may themselves be function objects or non-function objects. However, at the root, you must have a non-function object. In other words, picture Scala code as a tree: functions may appear as inner nodes or leaf nodes, but they may not be the root node, which is reserved for a non-function object. Inner/leaf nodes are of type psuedocode: type Object type ScalaFunction extends Object type NonFunctionObject extends Object We can have ChildNode[NoneFunctionObject] and ChildNode[ScalaFunction], but we can't have RootNode[ScalaFunction] - we must have RootNode[NonFunctionObject] Furthermore, if Scala functions are implemented as internal methods on variables (which are objects), that means that there is no way in Scala to write a function that is not eventually compiled to a method - ie, an object-bound function. If we can't break this binding, it's hard to make the case that functions are truly first-class. Objects are first-class, and because Scala provides first-class object support (unlike Java), many features of first-class functions can be simulated by using first-class objects, but that's subtly different from treating the function itself as the first-class citizen. For contrast, the inverse would be a functional languages with first-class functions and no first-class objects. All objects are constructed from functions (ie, 'bound to functions' in some sense), and there's no way to create an 'unbound' object, whereas there is in Scala.

chimeracoder 14y ago

Inferior (or 'unworkable', before you edited the comment)? Where are you getting that from? I never said that - I use Scala myself (and used to use it at work). Java is certainly inferior, because Java is OO done badly. > "When you apply parentheses surrounding one or more values to a variable, Scala will transform the code into an invocation of a method named apply on that variable." Now I've lost track of what you're quoting from, but that's by definition very OO. It's a modified form of the messaging pattern employed by Smalltalk. Scala isn't a functional/object-oriented hybrid; it's purely object-oriented (even more so than Java) because it has one single kind[1]: the object (Java pretends to have one, but it really has five, if you really wanted to get pedantic). So we shouldn't be celebrating Scala for being a functional hybrid - we should celebrate as being 'OO done right' (well, mostly right), which was the stated and failed intent of Java. The distinction is subtle, but the important thing to remember is that I'm operating on the premise that proper OO is essentially a subset/extension of FP, not an alternative. So what I'm saying is that this doesn't show that Scala is 'more functional' (vs. 'less functional') - rather, it shows that Scala is good OO (vs. bad OO, ie Java). I agree that it's a bit like the 'white horse is not a horse' argument, but it becomes important when we start talking about non-white horses; ie, functional languages that aren't OO). [1] I'm kind-of (no pun intended) abusing the term 'kind', but I can't think of a non-overloaded synonym as the moment, other than 'type' which would be worse.

hythloday 14y ago
The quote's from Programming in Scala, I wanted to look up exactly how the apply() sugaring is described by the author of the language. I'm not sure it is by definition OO, it just looks like operator overloading to me, similar to C++'s operator() or Python's __call__. Maybe I'm misunderstanding your broader point - claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency, and that it's such an obvious one you don't need to explain why. From my perspective the only reason I care about namespaces is a) that I can namespace my functions and b) so that I don't have to type things out longhand - the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me, and seems to me to be nearly irrelevant in evaluating if a language is "really" OO or "really" functional. If module-level functions are important to the question I would like to know why. :)
- chimeracoder 14y ago
  > claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency It's not a deficiency, but it emphasizes the fact that Scala is object-oriented, not functional. Scala supports first-class objects, and you get more functional features than Java because, unlike Java functions, Scala functions are objects. In other words, Scala's support for certain functional features is a corollary of its support for first-class objects, not because of its support for first-class functions. > the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me Which probably means that most of this discussion may be irrelevant to your interests too. :-) That's not meant to be rude - I'm being a bit facetious, but I'll readily admit that the OO 'vs.' FP is far too subtle for most people to care about... and that's fine. Beyond a certain point, it's a discussion with more academic value than practical value. But if you really care, let me try and explain the following: > If module-level functions are important to the question I would like to know why. :) Lack of module-level functions is a hint (though not proof) that Scala is 'OO first, and FP by coincidence'. Objects are just classes that are automatically created and instantiated with a singleton. Scala permits nesting of objects (objects within objects). The nested objects may themselves be function objects or non-function objects. However, at the root, you must have a non-function object. In other words, picture Scala code as a tree: functions may appear as inner nodes or leaf nodes, but they may not be the root node, which is reserved for a non-function object. Inner/leaf nodes are of type psuedocode: type Object type ScalaFunction extends Object type NonFunctionObject extends Object We can have ChildNode[NoneFunctionObject] and ChildNode[ScalaFunction], but we can't have RootNode[ScalaFunction] - we must have RootNode[NonFunctionObject] Furthermore, if Scala functions are implemented as internal methods on variables (which are objects), that means that there is no way in Scala to write a function that is not eventually compiled to a method - ie, an object-bound function. If we can't break this binding, it's hard to make the case that functions are truly first-class. Objects are first-class, and because Scala provides first-class object support (unlike Java), many features of first-class functions can be simulated by using first-class objects, but that's subtly different from treating the function itself as the first-class citizen. For contrast, the inverse would be a functional languages with first-class functions and no first-class objects. All objects are constructed from functions (ie, 'bound to functions' in some sense), and there's no way to create an 'unbound' object, whereas there is in Scala.