4 ms·

In general, this is true, but the proper way to view Scala is as a 'fixed' version of Java. Scala isn't really competing for the same mindshare as Ruby/Python/e

In general, this is true, but the proper way to view Scala is as a 'fixed' version of Java. Scala isn't really competing for the same mindshare as Ruby/Python/etc., and for good reason. Scala is basically what Java should have been (or at least, that's the goal). Scala is not truly functional - like Java, it is object-oriented. It just so happens that, once you step outside the Java bastardization of that term and think about a more 'pure' OO, the result is fairly functional-looking. OO and FP aren't really competing paradigms; rather, OO is a more complex paradigm that can be constructed from a functional system. (The inverse is technically true too, but much uglier in practice). (To give an example of what I mean, Scala supports first-class objects, and functions/methods are included in that statement. Scala does not support first-class, module-level functions (outside an object). That's not functional programming; it's object-oriented! But if you design your OO system well, you get something similar. Java does this badly, because methods aren't first-class objects - and unlike C, you can't really use pointers/references to fake the same behavior, so you get the worst of both worlds). Of course, Scala has to deal with limitations of the JVM - that's their compromise to gain binary inter-compatibility - but the designs of the two languages are a night-and-day comparison.

yummyfajitas 14y ago
Scala does not support first-class, module-level functions (outside an object). Sure it does. object f { def apply(x: String) = s + " - foo" } Elsewhere: val t = f("bar")
- chimeracoder 14y ago
  I don't understand what you mean. That's a function definition within an object; it's not top-level. EDIT: Okay, I see the confusion. That seems like a 'top-level' function in the sense that it's not acting on any parameter that's not explicitly passed to it, but it is still bound to the singleton object 'f'. That would be analogous to the following Python code: class F(object): def __init__(self): pass def x(self, s): return s + 'hi' >> Foo().x('hey') 'heyhi' Just because you ignore the implicit parameter doesn't mean it doesn't exist. Scala handles the implicit parameter differently, but the function still very much needs to exist inside the namespace of another object.
  - hythloday 14y ago
    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.
      - 14y ago
andolanra 14y ago
It is possible to be both object-oriented and functional—for example, OCaml and several Lisps are functional languages that nonetheless feature object systems. The two paradigms are not necessarily in conflict, and Scala is a perfect example of a language which is both. (The definition of 'functional language' is vague and generally somewhat informal, but broadly speaking it has more to do with how one approaches problems than e.g. where functions are defined.)
- chimeracoder 14y ago
  > The two paradigms are not necessarily in conflict. Agreed - that's my whole point. It's better to think of object-oriented programming as a construction within FP. Of course, some (badly-designed) OO languages like Java sandbox you and restrict your access to some of the more powerful, higher-order concepts, which is why they seem to be 'in conflict', when in reality, one is just a more abstractly implemented, whereas the other's more specifically implemented. > Scala is a perfect example of a language which is both. No, it's not - for example, functions have to exist within an instantiation of a class (a singleton object counts). By providing true first-class objects (unlike Java), you get many of the same benefits as first-class functions, but it's fundamentally not the same thing. Really, an easy way to create a language which supports both is to start with a very basic language with true first-class functions and closures (like Lisp) and then define a few closures that encapsulate state (objects), and then add a couple of basic macros that turn generic functions into bound methods (ie, automatically provide the implicit parameter instead of calling it explicitly). ...which is why I agree that they're not in conflict - a well-designed OO system can be easily implemented within a well-designed functional system! (The reverse doesn't work so well because you can easily add an implicit parameter to generic functions, but you can't completely remove an implicit parameter from a bound method, even if you pretend it doesn't exist - ie, treat all methods as static methods).
  - andolanra 14y ago
    A "first-class function" is a function that can be passed to a function, returned from a function, assigned to a variable, or stored in a data structure or basically used in any way that you would use any value. In Scala: object Foo { def f1(x : Int) : (Int => Int) = { return { y : Int => x + y } } def f2(f : Int => Int) : Int = { return f(5) } val f3 = f1(1) val f4 = List(f1(2), f1(3), f1(4)) } Yes, functions cannot be defined at the toplevel (unless you're in the REPL), but values also cannot be defined at the toplevel; they too must exist within an object or class. In that sense, functions are on equal footing with values.

yummyfajitas 14y ago

Scala does not support first-class, module-level functions (outside an object). Sure it does. object f { def apply(x: String) = s + " - foo" } Elsewhere: val t = f("bar")

chimeracoder 14y ago
I don't understand what you mean. That's a function definition within an object; it's not top-level. EDIT: Okay, I see the confusion. That seems like a 'top-level' function in the sense that it's not acting on any parameter that's not explicitly passed to it, but it is still bound to the singleton object 'f'. That would be analogous to the following Python code: class F(object): def __init__(self): pass def x(self, s): return s + 'hi' >> Foo().x('hey') 'heyhi' Just because you ignore the implicit parameter doesn't mean it doesn't exist. Scala handles the implicit parameter differently, but the function still very much needs to exist inside the namespace of another object.
- hythloday 14y ago
  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.
    - 14y ago

andolanra 14y ago

It is possible to be both object-oriented and functional—for example, OCaml and several Lisps are functional languages that nonetheless feature object systems. The two paradigms are not necessarily in conflict, and Scala is a perfect example of a language which is both. (The definition of 'functional language' is vague and generally somewhat informal, but broadly speaking it has more to do with how one approaches problems than e.g. where functions are defined.)

chimeracoder 14y ago
> The two paradigms are not necessarily in conflict. Agreed - that's my whole point. It's better to think of object-oriented programming as a construction within FP. Of course, some (badly-designed) OO languages like Java sandbox you and restrict your access to some of the more powerful, higher-order concepts, which is why they seem to be 'in conflict', when in reality, one is just a more abstractly implemented, whereas the other's more specifically implemented. > Scala is a perfect example of a language which is both. No, it's not - for example, functions have to exist within an instantiation of a class (a singleton object counts). By providing true first-class objects (unlike Java), you get many of the same benefits as first-class functions, but it's fundamentally not the same thing. Really, an easy way to create a language which supports both is to start with a very basic language with true first-class functions and closures (like Lisp) and then define a few closures that encapsulate state (objects), and then add a couple of basic macros that turn generic functions into bound methods (ie, automatically provide the implicit parameter instead of calling it explicitly). ...which is why I agree that they're not in conflict - a well-designed OO system can be easily implemented within a well-designed functional system! (The reverse doesn't work so well because you can easily add an implicit parameter to generic functions, but you can't completely remove an implicit parameter from a bound method, even if you pretend it doesn't exist - ie, treat all methods as static methods).
- andolanra 14y ago
  A "first-class function" is a function that can be passed to a function, returned from a function, assigned to a variable, or stored in a data structure or basically used in any way that you would use any value. In Scala: object Foo { def f1(x : Int) : (Int => Int) = { return { y : Int => x + y } } def f2(f : Int => Int) : Int = { return f(5) } val f3 = f1(1) val f4 = List(f1(2), f1(3), f1(4)) } Yes, functions cannot be defined at the toplevel (unless you're in the REPL), but values also cannot be defined at the toplevel; they too must exist within an object or class. In that sense, functions are on equal footing with values.