Hacker News Reader

Comment by gnuvince | Hacker News Reader

I recently picked up a project in OCaml that I had begun last summer and never finished. I have to say, compared to my day-to-day tools (mostly Java these days, Python before), OCaml is a breath of fresh air. For instance, today I did a refactoring where I replaced a type that was simply an alias to string with a proper abstract data type. Fixing the code was simply a matter of compiling, going to the file/line number in the error message, fix and repeat. Algebraic data types (sometimes called discriminated unions) are great for properly separating the logic of a data structure instead of sticking everything into one big class.

I highly recommend you give it a try. By the way, although we hear about OCaml less often than other languages, it is still used in many well known places such as Facebook (for pfff and Hack), Microsoft (SLAM, a verification tool for drivers), and Airbus (they use the ASTRÉE static verification tool which is written in OCaml).

View on HN

> Although we hear about OCaml less often than other languages, it is still used in many well known places such as ... Microsoft

Microsoft's F# language is essentially a .NET version of OCaml.

> Microsoft's F# language is essentially a .NET version of OCaml.

Oh, how I wish there was a JVM variant of F# (no, Scala does not count).

"Fjord, F# programming language for the JVM."

https://github.com/penberg/fjord

It doesn't seem to be in active development, though.

Not all features could be supported though.

The key missing feature -- module functors -- was thought by many to be impossible to represent correctly within the CLR's metadata. I had an idea last year about how they could be implemented within the CLR's type system; the proof-of-concept code is gross, but keep in mind it's only meant to prove that F# could eventually implement module functors: https://github.com/jack-pappas/experimental-functors

I guess you misunderstood me.

A few F# features depend on CLR features that JVM does not offer, like value types and reified generics.

This will probably change with the planned changes for Java 9+, but until then not everything can be efficiently supported.

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.

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.

> 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.

Unless you're going to argue that Wikipedia's classification is entirely wrong, the array languages are certainly functional.

On the J Wikipedia page there's this sentence:

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.

> This is the flaw in the Scala implementation of type-classes.

Wrong, wrong, wrong, wrong, wrong. I wonder where this myth comes from ...

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.

I love how everyone quotes what someone said, without any kind of fact checking.

I'm happy to be corrected, or pointed to relevant literature.

Neither does F#.

> 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.

> 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.

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.

Reply on news.ycombinator.com