5 ms·

Scala has always been multi-paradigm -- that can be a strength or a weakness. Martin Odersky seems brilliant, and I've enjoyed watching some of the talks he's g

Scala has always been multi-paradigm -- that can be a strength or a weakness. Martin Odersky seems brilliant, and I've enjoyed watching some of the talks he's given, but he also seems to define words in a way that goes against the way I use those same words. For instance, he seems to conflate "module" and "object" to the point that any language with "modules" is also an object-oriented language, which is odd, since that would make Haskell and Erland object-oriented. I'm thinking of what he wrote here: "Objects done well provide a lightweight module system (in the sense of ML). The requirement for a good module system is something that's often overlooked when all you do is a simple application, but its lack becomes painfully apparent for large systems and systems that are maintained over time. You can go the SML route and provide a module system and a functional core language. But then there's the pressure that you want to generalize your modules to be more flexible, which means you want them to become recursive and first-class. If you do that, you end up with a de-facto object system in addition to your core language of algebraic data types and functions. Scala's approach of unifying modules and objects is more parsimonious: The same constructs define the core language and the module language. So Scala is simpler, in the sense that fewer concepts are needed to describe the total feature set." Others have already commented on this, and I have nothing more to add, but I do find myself doubtful about whether the "Scala is simpler" is justified. Scala has always been multi-paradigm, so I don't think of it as simple -- and, again, that can be a strength or a weakness. I'm reflecting on what was written here: http://scala-programming-language.1934581.n4.nabble.com/OOP-is-an-expensive-disaster-which-must-end-td4636898.html http://scala-programming-language.1934581.n4.nabble.com/OOP-...

tel 12y ago
Modules as Odersky refers to them here (modules "in the sense of ML") do not exist in Erlang or Haskell at all. They are a unique typing discipline. In MLs, in large part to ensure that HM-style type inference remains "complete", the module type language is stratified from the value type language. This feels a bit repetitive, causes slow expansion of flexibility and power in the module language, and makes it difficult to refer to modules dynamically. For some, these are all good things. In this point of view, modules are "large" in a way that makes them difficult to reason about and so the restrictive language they're manipulated with is vital for making them reasonable. For others, you might as well just unify the "large" module language and the "small" value language. If you do this carefully you might not even lose "complete" HM inference [0]. This is the path that Scala takes though it unabashedly tosses out HM inference for the a highly incomplete (e.g. "local") subtype/supertype logic. Now there's a bit of an assertion that floats around that Scala's objects are essentially equal in power to what ML's modules would be if they were first class. I'm not sure if anyone could quite make this formal prior to the core calculus clean-up that is going through with dotty. Perhaps after that point the unique features of Scala will be emphasized... or we'll truly determine that Scala is just a unique approach to ML modules which has a different type inference engine. [0] http://www.mpi-sws.org/~rossberg/1ml/ http://www.mpi-sws.org/~rossberg/1ml/
- tomp 12y ago
  I'm not sure you can emulate objects with modules. In particular, there is no "self" type with modules... or am I missing something?
  - jamii 12y ago
    No, ML modules are usually early bound which prevents open recursion eg module First = struct let rec even x = if (x >= 0) then ( print_endline "even!"; odd (x-1) ) else () and odd x = if (x >= 0) then ( print_endline "odd!"; even (x-1) ) else () module Second = struct include First let odd x = if (x >= 0) then ( print_endline "weird!"; even (x-1) ) else () end Second.odd(3) (* weird! * even! * odd! * even! *) In ocaml you can use classes for open recursion but that is implemented using dynamic dispatch. For static dispatch you would have to hack something together using a record that is passed itself.
    - tomp 12y ago
      That's more of an issue with implementation than with typing. I mean more like, in an OO language it is possible to declare an interface with a method that returns the final subtype (i.e. the object's this type), which isn't even know yet at the point the interface is defined.
      - jamii 12y ago
        Ah, I see what you are getting at. They seem related to me though. Open recursion requires calling the method from the final subtype rather than the current type - `even` would have to call `this#odd` instead of `odd`. The core problem in both cases is not being able to refer to the final subtype in any way. Hmmm, even if modules could refer to this final subtype you would probably have to choose between doing it via dynamic dispatch or sacrificing separate compilation, since the parent module doesn't know what method to dispatch to at the time of compilation.
  - 12y ago
vezzy-fnord 12y ago
For instance, he seems to conflate "module" and "object" to the point that any language with "modules" is also an object-oriented language, which is odd, since that would make Haskell and Erland [sic] object-oriented. I cannot weigh in with regards to Haskell, but in the case of Erlang this actually isn't all that odd. The actor model is to a large extent an object system for modelling concurrency - this being per Alan Kay's definition of OO as isolated units that communicate via message passing, as opposed to the more common definition of polymorphism/encapsulation/inheritance, which in practice is usually a quasi-procedural sugar coating. Admittedly this does neglect some of the more detailed Smalltalk properties like class objects holding shared state, but the terminology behind OO is murky and Erlang exhibiting elements of it can nonetheless be argued.
- discreteevent 12y ago
  " Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism." - Joe Armstrong http://www.infoq.com/interviews/johnson-armstrong-oop http://www.infoq.com/interviews/johnson-armstrong-oop
sixbrx 12y ago
I don't think he's conflating the ideas, so much as pointing out that Scala's ideas of "objects" can do what other module systems can do, but are "first class" in the sense that the can be created on the fly and passed around as values. This has to do with things like path-dependent types and being able to import from arbitrary object instances instead of just from static namespaces.
kyllo 12y ago
I don't think he's conflating modules with objects. He's saying that if you have (class-based) objects, you don't need modules because object classes already provide superset of the functionality of modules. In particular they provide open recursion, which is something he thinks you're going to want to have anyway.

tel 12y ago

Modules as Odersky refers to them here (modules "in the sense of ML") do not exist in Erlang or Haskell at all. They are a unique typing discipline. In MLs, in large part to ensure that HM-style type inference remains "complete", the module type language is stratified from the value type language. This feels a bit repetitive, causes slow expansion of flexibility and power in the module language, and makes it difficult to refer to modules dynamically. For some, these are all good things. In this point of view, modules are "large" in a way that makes them difficult to reason about and so the restrictive language they're manipulated with is vital for making them reasonable. For others, you might as well just unify the "large" module language and the "small" value language. If you do this carefully you might not even lose "complete" HM inference [0]. This is the path that Scala takes though it unabashedly tosses out HM inference for the a highly incomplete (e.g. "local") subtype/supertype logic. Now there's a bit of an assertion that floats around that Scala's objects are essentially equal in power to what ML's modules would be if they were first class. I'm not sure if anyone could quite make this formal prior to the core calculus clean-up that is going through with dotty. Perhaps after that point the unique features of Scala will be emphasized... or we'll truly determine that Scala is just a unique approach to ML modules which has a different type inference engine. [0] http://www.mpi-sws.org/~rossberg/1ml/ http://www.mpi-sws.org/~rossberg/1ml/

tomp 12y ago
I'm not sure you can emulate objects with modules. In particular, there is no "self" type with modules... or am I missing something?
- jamii 12y ago
  No, ML modules are usually early bound which prevents open recursion eg module First = struct let rec even x = if (x >= 0) then ( print_endline "even!"; odd (x-1) ) else () and odd x = if (x >= 0) then ( print_endline "odd!"; even (x-1) ) else () module Second = struct include First let odd x = if (x >= 0) then ( print_endline "weird!"; even (x-1) ) else () end Second.odd(3) (* weird! * even! * odd! * even! *) In ocaml you can use classes for open recursion but that is implemented using dynamic dispatch. For static dispatch you would have to hack something together using a record that is passed itself.
  - tomp 12y ago
    That's more of an issue with implementation than with typing. I mean more like, in an OO language it is possible to declare an interface with a method that returns the final subtype (i.e. the object's this type), which isn't even know yet at the point the interface is defined.
    - jamii 12y ago
      Ah, I see what you are getting at. They seem related to me though. Open recursion requires calling the method from the final subtype rather than the current type - `even` would have to call `this#odd` instead of `odd`. The core problem in both cases is not being able to refer to the final subtype in any way. Hmmm, even if modules could refer to this final subtype you would probably have to choose between doing it via dynamic dispatch or sacrificing separate compilation, since the parent module doesn't know what method to dispatch to at the time of compilation.
- 12y ago

vezzy-fnord 12y ago

For instance, he seems to conflate "module" and "object" to the point that any language with "modules" is also an object-oriented language, which is odd, since that would make Haskell and Erland [sic] object-oriented. I cannot weigh in with regards to Haskell, but in the case of Erlang this actually isn't all that odd. The actor model is to a large extent an object system for modelling concurrency - this being per Alan Kay's definition of OO as isolated units that communicate via message passing, as opposed to the more common definition of polymorphism/encapsulation/inheritance, which in practice is usually a quasi-procedural sugar coating. Admittedly this does neglect some of the more detailed Smalltalk properties like class objects holding shared state, but the terminology behind OO is murky and Erlang exhibiting elements of it can nonetheless be argued.

discreteevent 12y ago
" Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism." - Joe Armstrong http://www.infoq.com/interviews/johnson-armstrong-oop http://www.infoq.com/interviews/johnson-armstrong-oop

sixbrx 12y ago

I don't think he's conflating the ideas, so much as pointing out that Scala's ideas of "objects" can do what other module systems can do, but are "first class" in the sense that the can be created on the fly and passed around as values. This has to do with things like path-dependent types and being able to import from arbitrary object instances instead of just from static namespaces.

kyllo 12y ago

I don't think he's conflating modules with objects. He's saying that if you have (class-based) objects, you don't need modules because object classes already provide superset of the functionality of modules. In particular they provide open recursion, which is something he thinks you're going to want to have anyway.