4 ms·

Scala came at the problem from the wrong direction. F# started with the functional pieces of ML/OCaml and added the 'OO' stuff in record types resulting in a si

Scala came at the problem from the wrong direction. F# started with the functional pieces of ML/OCaml and added the 'OO' stuff in record types resulting in a simple and powerful language. Scala seems to have started with the 'OO' stuff and then has kept on adding and adding and adding.

frowaway001 12y ago
That's ... nonsense? You know what's the defining property of OCaml's OO/module systems? That nobody actually uses it. Compared to that, Scala tries to make all parts of the language work in an orthogonal and consistent fashion. In OCaml, one part of the language is crippled intentionally, due to what seems to be ideological reasons. Apart from that, I'm unsure how OCaml counts as "functional". It doesn't even have typeclasses, let alone higher-kinded types.
- chriswarbo 12y ago
  > I'm unsure how OCaml counts as "functional". It doesn't even have typeclasses, let alone higher-kinded types. Erm, what? Functional languages are those which implement as much as possible using functions, rather than adding language primitives (eg. if/then/else, looping, mutable state, etc.). If anything, typeclasses make a language less functional, since they're a language primitive which could be implemented with functions instead (by passing records explicitly). Lambda Calculus doesn't have typeclasses or higher-kinded types, does that mean it doesn't count as "functional"? Hell, even Joy is a purely-functional language and it can't even call functions! Type systems are a completely orthogonal concept to functional style; they're a way of embedding a formal logic into a programming language. It just-so-happens that many logics make heavy use of implication (a -> b), and that corresponds to functions. It's possible to give a rich type system to, for example, Prolog or assembly, but the logical operators would be quite unfamiliar.
  - lmm 12y ago
    In Scala typeclass is not a language primitive, it's just an idiom that can be easily expressed in the language. Whereas programming in the typeclass style with F# is difficult to say the least, basically requiring Greenspunning. "Functional" means many things to many people, but it's the term a lot of people use when talking about the recent rise of languages like Haskell, Scala, F# and OCaml - much of which rise is, IMO, attributable to their type systems. Whatever "it" is that these languages have (and sure, it might be more accurate to talk about "languages providing ADTs and controlled sequencing of effects" or some such), I think it's fair to say that OCaml/F# have less of it in this area, because their type systems don't allow you to express higher-kinded types. F# may have its advantages, but you're definitely missing out on some of the "functional language renaissance" - because whatever the terminology, at least some of that renaissance is about the value of powerful type systems.
    - theseoafs 12y ago
      > "Functional" means many things to many people, but it's the term a lot of people use when talking about the recent rise of languages like Haskell, Scala, F# and OCaml - much of which rise is, IMO, attributable to their type systems. These are new languages in the functional paradigm but functional programming isn't itself a new concept, and strong static typing has never been a prerequisite in order to be "functional". The first functional language, Lisp, was dynamic, and to this day no commonly used Lisp has been statically typed out-of-the-box. Erlang and the array languages (APL, J, etc.) are other examples of dynamically typed functional languages. You can say that functional languages are more likely to have strong type systems than other languages, but it's totally disingenuous to claim that languages are somehow "less functional" because they lack typeclasses and higher-kinded types.
      - klibertp 12y ago
        To be precise most array languages are not functional, although they do support "function-level programming" - the distinction is not clear to me just yet, but I hope to improve. :) The K language, which presumably incorporates parts of Scheme, is a notable exception to this.
  - Chattered 12y ago
    > If anything, typeclasses make a language less functional, since they're a language primitive which could be implemented with functions instead (by passing records explicitly) I'm not exactly sure what you're thinking of here, but if you try to turn a typeclass into a dictionary of its methods, you'll need a dictionary for each instantiation of type variables in the typeclass. And then it still won't be as type-safe as Haskell, because nothing stops a programmer from swapping in random dictionaries. This is the flaw in the Scala implementation of type-classes.
    - frowaway001 12y ago
      > This is the flaw in the Scala implementation of type-classes. Wrong, wrong, wrong, wrong, wrong. I wonder where this myth comes from ...
      - Chattered 12y ago
        It comes from my knowledge of functional programming and the problems that come from trying to do this stuff by passing dictionaries. I'm not a Scala programmer, so maybe I've missed some subtleties, but I doubt it. Here's Edward Kmett: "Since you can pass any dictionary anywhere to any implicit you can't rely on the canonicity of anything. If you make a Map or Set using an ordering, you can't be sure you'll get the same ordering back when you come to do a lookup later. This means you can't safely do hedge unions/merges in their containers. It also means that much of scalaz is lying to itself and hoping you'll pass back the same dictionary every time." You get the same issue with Ocaml's implementation of polymorphic tree-based maps, where you lose type-safety. This is why you don't want to pass dictionaries for this stuff, but instead want to use modules and functors, which allow you to emulate existential types, higher-order kinding and higher-rank polymorphism.
        frowaway001 12y ago
        I love how everyone quotes what someone said, without any kind of fact checking.
- Paradigma11 12y ago
  Neither does F#.
- _pmf_ 12y ago
  > In OCaml, one part of the language is crippled intentionally, due to what seems to be ideological reasons. That's one thing that cannot be claimed for Scala, at last. No matter what concept it is or whether it fits anywhere, it goes in. It's what is called language design.
  - frowaway001 12y ago
    > That's one thing that cannot be claimed for Scala, at last. No matter what concept it is or whether it fits anywhere, it goes in. That's absurd, and you know it.
- klibertp 12y ago
  It would be probably important to note that F# module and object systems are completely different from OCaml as they are designed to support interop with the rest of .NET. On the other hand, OCaml is able to express typeclasses with it's module system.

frowaway001 12y ago

That's ... nonsense? You know what's the defining property of OCaml's OO/module systems? That nobody actually uses it. Compared to that, Scala tries to make all parts of the language work in an orthogonal and consistent fashion. In OCaml, one part of the language is crippled intentionally, due to what seems to be ideological reasons. Apart from that, I'm unsure how OCaml counts as "functional". It doesn't even have typeclasses, let alone higher-kinded types.

chriswarbo 12y ago
> I'm unsure how OCaml counts as "functional". It doesn't even have typeclasses, let alone higher-kinded types. Erm, what? Functional languages are those which implement as much as possible using functions, rather than adding language primitives (eg. if/then/else, looping, mutable state, etc.). If anything, typeclasses make a language less functional, since they're a language primitive which could be implemented with functions instead (by passing records explicitly). Lambda Calculus doesn't have typeclasses or higher-kinded types, does that mean it doesn't count as "functional"? Hell, even Joy is a purely-functional language and it can't even call functions! Type systems are a completely orthogonal concept to functional style; they're a way of embedding a formal logic into a programming language. It just-so-happens that many logics make heavy use of implication (a -> b), and that corresponds to functions. It's possible to give a rich type system to, for example, Prolog or assembly, but the logical operators would be quite unfamiliar.
- lmm 12y ago
  In Scala typeclass is not a language primitive, it's just an idiom that can be easily expressed in the language. Whereas programming in the typeclass style with F# is difficult to say the least, basically requiring Greenspunning. "Functional" means many things to many people, but it's the term a lot of people use when talking about the recent rise of languages like Haskell, Scala, F# and OCaml - much of which rise is, IMO, attributable to their type systems. Whatever "it" is that these languages have (and sure, it might be more accurate to talk about "languages providing ADTs and controlled sequencing of effects" or some such), I think it's fair to say that OCaml/F# have less of it in this area, because their type systems don't allow you to express higher-kinded types. F# may have its advantages, but you're definitely missing out on some of the "functional language renaissance" - because whatever the terminology, at least some of that renaissance is about the value of powerful type systems.
  - theseoafs 12y ago
    > "Functional" means many things to many people, but it's the term a lot of people use when talking about the recent rise of languages like Haskell, Scala, F# and OCaml - much of which rise is, IMO, attributable to their type systems. These are new languages in the functional paradigm but functional programming isn't itself a new concept, and strong static typing has never been a prerequisite in order to be "functional". The first functional language, Lisp, was dynamic, and to this day no commonly used Lisp has been statically typed out-of-the-box. Erlang and the array languages (APL, J, etc.) are other examples of dynamically typed functional languages. You can say that functional languages are more likely to have strong type systems than other languages, but it's totally disingenuous to claim that languages are somehow "less functional" because they lack typeclasses and higher-kinded types.
    - klibertp 12y ago
      To be precise most array languages are not functional, although they do support "function-level programming" - the distinction is not clear to me just yet, but I hope to improve. :) The K language, which presumably incorporates parts of Scheme, is a notable exception to this.
- Chattered 12y ago
  > If anything, typeclasses make a language less functional, since they're a language primitive which could be implemented with functions instead (by passing records explicitly) I'm not exactly sure what you're thinking of here, but if you try to turn a typeclass into a dictionary of its methods, you'll need a dictionary for each instantiation of type variables in the typeclass. And then it still won't be as type-safe as Haskell, because nothing stops a programmer from swapping in random dictionaries. This is the flaw in the Scala implementation of type-classes.
  - frowaway001 12y ago
    > This is the flaw in the Scala implementation of type-classes. Wrong, wrong, wrong, wrong, wrong. I wonder where this myth comes from ...
    - Chattered 12y ago
      It comes from my knowledge of functional programming and the problems that come from trying to do this stuff by passing dictionaries. I'm not a Scala programmer, so maybe I've missed some subtleties, but I doubt it. Here's Edward Kmett: "Since you can pass any dictionary anywhere to any implicit you can't rely on the canonicity of anything. If you make a Map or Set using an ordering, you can't be sure you'll get the same ordering back when you come to do a lookup later. This means you can't safely do hedge unions/merges in their containers. It also means that much of scalaz is lying to itself and hoping you'll pass back the same dictionary every time." You get the same issue with Ocaml's implementation of polymorphic tree-based maps, where you lose type-safety. This is why you don't want to pass dictionaries for this stuff, but instead want to use modules and functors, which allow you to emulate existential types, higher-order kinding and higher-rank polymorphism.
      - frowaway001 12y ago
        I love how everyone quotes what someone said, without any kind of fact checking.
Paradigma11 12y ago
Neither does F#.
_pmf_ 12y ago
> In OCaml, one part of the language is crippled intentionally, due to what seems to be ideological reasons. That's one thing that cannot be claimed for Scala, at last. No matter what concept it is or whether it fits anywhere, it goes in. It's what is called language design.
- frowaway001 12y ago
  > That's one thing that cannot be claimed for Scala, at last. No matter what concept it is or whether it fits anywhere, it goes in. That's absurd, and you know it.
klibertp 12y ago
It would be probably important to note that F# module and object systems are completely different from OCaml as they are designed to support interop with the rest of .NET. On the other hand, OCaml is able to express typeclasses with it's module system.