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.
> 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.
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.
> "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.
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.
Like the original FP/FL languages, J supports function-level programming via its tacit programming features (note that function-level programming is not the same as functional programming).
As I said, it's unclear to me what the difference is, but that's what I based my previous comment on.
That sentence only means to say that J supports function-level programming, which itself is different from functional programming. The very same Wikipedia page also calls J a functional language -- the fact that it supports function-level programming doesn't contradict the fact that it also supports functional programming.
The meanings of words shift, particularly in a fast-moving field like ours. But like I said, which word use isn't really important. I care more that:
Something is going on in the languages I mentioned - and from my perspective, distinctly isn't going on with any Lisp (including Dylan or Clojure), isn't going on with the array languages, and mostly isn't going on with Erlang. So it's not a functional language thing by your definition of a functional language
Whatever that something is, it involves powerful type systems
F# and OCaml therefore have less of it than Haskell and Scala (though more of it than languages outside those four list).
> Something is going on in the languages I mentioned - and from my perspective, distinctly isn't going on with any Lisp (including Dylan or Clojure), isn't going on with the array languages, and mostly isn't going on with Erlang. So it's not a functional language thing by your definition of a functional language
Um, no. Lisp and Erlang are still functional. They have always been and will always be functional. The definition of that word has not changed. You seem to want to redefine "functional" to make Haskell the end-all and be-all of functional languages, but that's just not how it works.
The whole point of the post you were replying to is that arguing about what the word "functional" means is beside the point. To many people there is a categorisation of languages to which Haskell and Scala more strongly conform than Lisp and Erlang. What that category is called is of secondary importance to the discussion.
Semantic arguments are tiresome, and I wish more people would focus on the content of the discussion, instead of arguing about how it might better have been conveyed. Sometimes people misunderstand the commonly accepted meanings of terms, and it's worth correcting them. But if people start arguing about terminology, then it's better to just define terms and move on, since there's clearly not a consensus worth teaching anyone.
> 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.
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.
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.
