8 ms·

kinda sorta, the reason why people still thing of ocaml is because janestreet use them, and janestreet makes a lot of money .. and we all want to make money, so

by systems 11y ago

kinda sorta, the reason why people still thing of ocaml is because janestreet use them, and janestreet makes a lot of money .. and we all want to make money, so somewhere vaguely some people can/may link ocaml with money i love ocaml, i love ml languages, and i think ocaml is a very good ml but, i think its kinda too late for it, i think people who want to program with types today most likely will go to rust, scala or f# ocaml is very niche

pcwalton 11y ago
Which is a shame really, because OCaml is a very nice language. Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming (not counting the module system of SML and the object system of OCaml). I honestly think that OCaml's type system is simpler than a lot of other type systems that people think of when they think of "simple type systems". (Including its support for generics—OCaml is proof that generics can be an extremely simple feature that add basically no complexity to a type system, contrary to popular belief.) I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly.
- hxegon 11y ago
  Been sampling a bunch of languages in the past 3+ months and I have to say, [| |] is really, really off-putting.
  - pauldirac137 11y ago
    All the minor syntax issues in Ocaml are just that, minor. After a week of coding in Ocaml you won't even notice them. The operator underloading is the most annoying, but with modular implicits on the way that will probably go away.
    - tomp 11y ago
      I disagree. I used OCaml extensively 10 years ago, and syntax is, in one word, terrible. I don't care about the minor issues, but about the major ones; the ambiguities concerning ;, if and match; essentially, as soon as you're using imperative features (which often result in using ;), you have to be very careful to make sure your code means what you think it means.
- swah 11y ago
  I suppose many folks will assume later languages (Rust) have learned from older ones and will just use the more widespread one without a second thought...
- virtualwhys 11y ago
  > I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly. Indeed, a barrier in itself, after working through RWO I was impressed with the language, clearly very powerful, but some aspects of the language are syntactically unpleasant. Yes, yes, semantics, not syntax, but new comers will come in all forms, including those who will just say no based on the general "look" of the language. IMO, if OCaml had the same power but looked more like SML it would have much greater adoption. Anyway, modular implicits and multi-core will certainly help OCaml to grain traction, syntax notwithstanding.
  - daxfohl 11y ago
    In layman programmer terms, what are modular implicits? Are they like (please no) Scala's implicits? (Or is there some way Scala's implicits are less scary than years past?)
    - whateveracct 11y ago
      Scala implicits are really one of the "killer apps" of its type system. No language I know of really has anything quite like it. Scala "implicits" mean two different things: 1) implicit conversions. e.g. If there is an implicit def f(x: Int): String = x.toString in scope, then any time you try to use an Int where a String is expected, Int::toString will be called automatically. Using implicit conversions like this is generally frowned upon and also where the "please no" probably comes from. implicit conversions are used frequently but almost entirely for extension methods (there's even sugar for it now: "implicit class") 2) implicit parameters. These are parameters in a functions type signature keyed by type. You can emulate Haskell typeclasses (sans canonicity) with these. For instance def monoidSum[A](as: List[A])(implicit m: Monoid[A]): A = as.foldLeft(m.zero)(m.append) is equivalent to the Haskell monoidSum :: (Monoid a) => [a] -> a monoidSum as = foldl' mappend mempty Scala implicit parameters can be defined inductively and depend on other implicit parameters. You can do this to perform some really cool type-level computation. The shapeless library is full of stuff like this. Once you understand implicit parameters, it really is somewhat nice to write functions that operate on arbitrarily-sized HLists and Coproducts. Modular implicits are similar to (and inspired by?) Scala implicit parameters.
- wtetzner 11y ago
  Actually, for me the biggest obstacle is the lack of a good build/dependency tool along the lines of cargo. The closest I've been able to get is Oasis+OPAM, but it's just not the same.
- nickpsecurity 11y ago
  "Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming" Didn't think of it that way. Well-put and I totally agree. So odd that one hits that sweet spot in design yet gets almost no uptake. Whatever problems like OP posted need to get solved because interesting and useful things are sure to come from mainstream attention to it. Useful even outside Ocaml given its influences on other languages. Another thing is the compiler. It's reportedly easy to understand and robust compared to most. I recall reading Esterel's report on DO-178B certifying their code generator written in Ocaml. They had to do source-to-object-code equivalence. They said that, very unusually, the Ocaml toolchain was well-structured to the point they only need minor tweaks to get the job done. So, great language design plus great implementation equals great opportunity for robust, app development. The concurrency situation is ridiculous, though. Even C-like languages and Haskell have safe concurrency techniques. They need to get on that shit cuz nobody uses single-core boxes anymore unless they're a small shop licensing Oracle. ;)
ZenoArrow 11y ago
I don't see why someone would evaluate F# but not OCaml, they're very similar languages. The breadth of libraries available for F# may be greater, but OCaml has some strengths that F# currently doesn't, such as native compilation. I'm teaching myself F# at the moment but I'd not rule out using OCaml in the future.
- alkonaut 11y ago
  F# will likely have a native compiler soon (and you could argue it does in case you compile it for mobile using Xamarin). The key difference for me is "is there a polished development environment where I can get from zero to debugging within minutes".
- mercurial 11y ago
  To be fair, for most people who may use something for work, "lack of available libraries" can easily be a death knell.
  - ZenoArrow 11y ago
    Sure, but it depends on what you need to do. From my perspective Mirage is OCaml's 'killer app' (I'm sure others would disagree). Where I could see it excelling is as an open-source home server platform. I'm not sure what the current progress is but I know some of the Mirage developers were working on this particular use case, I'll see if I can find the link. Could something like Mirage exist for F#? It could, though the Mirage team have a considerable head start. EDIT: The project I was referring to before is Nymote: http://nymote.org/ http://nymote.org/
- pauldirac137 11y ago
  F# is nice but it doesn't have the Ocaml module/functor system, which is a huge loss in expressiveness. It does have seamless .NET interoperability, which is a big win in some cases. YMMV. Both are good languages.
cm3 11y ago
Why Rust though? It doesn't provide much in terms of an expressive type system when compared to Haskell, SML, OCaml, Idris. I like Rust for many reasons and it's a huge boon for more correct software produced by more people (aka those who don't use an Ada profile :D) but Rust's type system isn't something to weight heavier than OCaml's. There is at least one SML implementation with region types from what I understand. Need to look it up, but it was the implementation from that Dane whose name was something like Elsberg or something and which also had tracing and stuff. For SML I use the MoscowML REPL and MLton for executables. But I don't do much SML, unfortunately. In some ways it's nicer than OCaml.
- pcwalton 11y ago
  What features does SML or OCaml's type system have that Rust's doesn't? Haskell has higher-kinded type parameters and Idris has dependent types. But SML and OCaml don't even have typeclasses at all, much less higher kinds. Furthermore, what makes Rust's type system interesting isn't just its use of regions (which the ML Kit used); it's regions combined with inherited mutability plus the borrow check to maintain soundness.
  - cm3 11y ago
    OCaml's module system is a nice tool for many cases that is only slowly getting into Haskell via Backpack but not there yet. So that's one. GHC 8.0 almost has dependent types and the expectation is feature completeness in 8.2, thought what's in 8.0 is already useful. I like and use Rust and the design decisions that led to a very capable region system that allows one to write data race free and memory correct code is excellent. Haskell doesn't have such a thing because it doesn't try avoid GC. I didn't do a point by point comparison of Rust expressiveness vs Haskell recently, but I don't remember it being close. Rafael might need to write a Rust for for Haskellers as an update of his "for OCamlers" post a while back.
    - knz42 11y ago
      The post is called "Rust for functional programmers" and contains side-by-side comparisons with both OCaml and Haskell. http://science.raphael.poss.name/rust-for-functional-programmers.html http://science.raphael.poss.name/rust-for-functional-program... you might be confusing it with the other post "Haskell for OCaml programmers"? It is a bit outdated but as far as I can see not inaccurate yet. I only plan to update it when HKTs make it to Rust.
draven 11y ago
> i think people who want to program with types today most likely will go to rust, scala or f# I'm a Scala dev. I'm playing with Rust for lower level stuff, don't know much about F#, but FWIW I would rather code in Ocaml than Scala.
- daxfohl 11y ago
  Serious questions: Why, and why don't you?
  - hisham_hm 11y ago
    Probably because they're paid to write Scala.
  - draven 11y ago
    As suspected by hisham_hm, I'm paid to code in Scala. At my previous job I tried to introduce some functional languages without much success. The stack was C++/Java and a lot of Python. I learned Scala because it runs on the JVM and I thought that may help. Later I moved to another city and when looking at job offers I saw a few Scala offers (and no Ocaml in sight) so I settled on Scala. IMHO Scala gained traction because it runs on the JVM. It's easier to train Java devs because you can start by writing Java-in-Scala and incorporate specific features as you go. The web ecosystem is nice (at work we're using Play.) There's also a few killer apps, like Spark. I'm currently trying to become as proficient in Ocaml as I am with Scala, but I'm already working with Scala 8+ hours a day so it's not that easy.
dwc 11y ago
I don't agree with your Jane Street / money reasoning. I had never heard of Jane Street until I started looking at OCaml. That Jane Street makes money and is "all in" on OCaml does support the idea that one can use OCaml for serious projects. But does anyone really think (even subconsciously) that using OCaml will make them rich, just because?
pauldirac137 11y ago
I completely disagree. I'm a typoholic to the core. For the last five years I've mostly been programming in Haskell, but lately I've come back to Ocaml and I have to say it's improved massively and continues to do so. I'm happy if people use any decent typed language (including Rust, Scala, F# etc.) but Ocaml has some unique strengths. The module/functor system is the best in the business, and is incredible for defining parameterized data structures. It's even better than anything Haskell has in that regard, as the Haskell community freely admits (they are working on their own version of it). Polymorphic variants are also amazing, and are found in no other language. The object system is really good, although it's seemingly little used because with modules and functors, you rarely need it. And there are lots of exciting things coming down the pipeline, including true multicore support with user-definable schedulers, modular implicits to get the effect of Haskell type classes (but better), a new inliner, and much more. Ocaml is ripe for a massive comeback. I've started using it in my university courses, and students are amazed at how often code "just works" if it type checks (this is also true of the other languages I mentioned). And Ocaml is much easier to learn than Haskell (though I still love Haskell). So give it a try! Once you get past the odd syntax, it's pure pleasure.
- daxfohl 11y ago
  Okay I (having done a little Haskell and enough F# to know a higher abstraction was needed) thought that modules were already OCaml's counter to Haskell typeclasses, and they were already better. Some weird set-theory-looking T-shirt (obviously) proved it. So what are modular implicits, and how are they better than modules and typeclasses, why are modules not actually enough anymore as an answer for typeclasses, and are they (please no) related to Scala implicits?
  - mercurial 11y ago
    You don't get "magic" to_string and equals with just modules, for instance.
    - daxfohl 11y ago
      explain? And how do modular implicits fix?

by systems 11y ago

pcwalton 11y ago

Which is a shame really, because OCaml is a very nice language. Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming (not counting the module system of SML and the object system of OCaml). I honestly think that OCaml's type system is simpler than a lot of other type systems that people think of when they think of "simple type systems". (Including its support for generics—OCaml is proof that generics can be an extremely simple feature that add basically no complexity to a type system, contrary to popular belief.) I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly.

hxegon 11y ago
Been sampling a bunch of languages in the past 3+ months and I have to say, [| |] is really, really off-putting.
- pauldirac137 11y ago
  All the minor syntax issues in Ocaml are just that, minor. After a week of coding in Ocaml you won't even notice them. The operator underloading is the most annoying, but with modular implicits on the way that will probably go away.
  - tomp 11y ago
    I disagree. I used OCaml extensively 10 years ago, and syntax is, in one word, terrible. I don't care about the minor issues, but about the major ones; the ambiguities concerning ;, if and match; essentially, as soon as you're using imperative features (which often result in using ;), you have to be very careful to make sure your code means what you think it means.
swah 11y ago
I suppose many folks will assume later languages (Rust) have learned from older ones and will just use the more widespread one without a second thought...
virtualwhys 11y ago
> I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly. Indeed, a barrier in itself, after working through RWO I was impressed with the language, clearly very powerful, but some aspects of the language are syntactically unpleasant. Yes, yes, semantics, not syntax, but new comers will come in all forms, including those who will just say no based on the general "look" of the language. IMO, if OCaml had the same power but looked more like SML it would have much greater adoption. Anyway, modular implicits and multi-core will certainly help OCaml to grain traction, syntax notwithstanding.
- daxfohl 11y ago
  In layman programmer terms, what are modular implicits? Are they like (please no) Scala's implicits? (Or is there some way Scala's implicits are less scary than years past?)
  - whateveracct 11y ago
    Scala implicits are really one of the "killer apps" of its type system. No language I know of really has anything quite like it. Scala "implicits" mean two different things: 1) implicit conversions. e.g. If there is an implicit def f(x: Int): String = x.toString in scope, then any time you try to use an Int where a String is expected, Int::toString will be called automatically. Using implicit conversions like this is generally frowned upon and also where the "please no" probably comes from. implicit conversions are used frequently but almost entirely for extension methods (there's even sugar for it now: "implicit class") 2) implicit parameters. These are parameters in a functions type signature keyed by type. You can emulate Haskell typeclasses (sans canonicity) with these. For instance def monoidSum[A](as: List[A])(implicit m: Monoid[A]): A = as.foldLeft(m.zero)(m.append) is equivalent to the Haskell monoidSum :: (Monoid a) => [a] -> a monoidSum as = foldl' mappend mempty Scala implicit parameters can be defined inductively and depend on other implicit parameters. You can do this to perform some really cool type-level computation. The shapeless library is full of stuff like this. Once you understand implicit parameters, it really is somewhat nice to write functions that operate on arbitrarily-sized HLists and Coproducts. Modular implicits are similar to (and inspired by?) Scala implicit parameters.
wtetzner 11y ago
Actually, for me the biggest obstacle is the lack of a good build/dependency tool along the lines of cargo. The closest I've been able to get is Oasis+OPAM, but it's just not the same.
nickpsecurity 11y ago
"Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming" Didn't think of it that way. Well-put and I totally agree. So odd that one hits that sweet spot in design yet gets almost no uptake. Whatever problems like OP posted need to get solved because interesting and useful things are sure to come from mainstream attention to it. Useful even outside Ocaml given its influences on other languages. Another thing is the compiler. It's reportedly easy to understand and robust compared to most. I recall reading Esterel's report on DO-178B certifying their code generator written in Ocaml. They had to do source-to-object-code equivalence. They said that, very unusually, the Ocaml toolchain was well-structured to the point they only need minor tweaks to get the job done. So, great language design plus great implementation equals great opportunity for robust, app development. The concurrency situation is ridiculous, though. Even C-like languages and Haskell have safe concurrency techniques. They need to get on that shit cuz nobody uses single-core boxes anymore unless they're a small shop licensing Oracle. ;)

ZenoArrow 11y ago

I don't see why someone would evaluate F# but not OCaml, they're very similar languages. The breadth of libraries available for F# may be greater, but OCaml has some strengths that F# currently doesn't, such as native compilation. I'm teaching myself F# at the moment but I'd not rule out using OCaml in the future.

alkonaut 11y ago
F# will likely have a native compiler soon (and you could argue it does in case you compile it for mobile using Xamarin). The key difference for me is "is there a polished development environment where I can get from zero to debugging within minutes".
mercurial 11y ago
To be fair, for most people who may use something for work, "lack of available libraries" can easily be a death knell.
- ZenoArrow 11y ago
  Sure, but it depends on what you need to do. From my perspective Mirage is OCaml's 'killer app' (I'm sure others would disagree). Where I could see it excelling is as an open-source home server platform. I'm not sure what the current progress is but I know some of the Mirage developers were working on this particular use case, I'll see if I can find the link. Could something like Mirage exist for F#? It could, though the Mirage team have a considerable head start. EDIT: The project I was referring to before is Nymote: http://nymote.org/ http://nymote.org/
pauldirac137 11y ago
F# is nice but it doesn't have the Ocaml module/functor system, which is a huge loss in expressiveness. It does have seamless .NET interoperability, which is a big win in some cases. YMMV. Both are good languages.

cm3 11y ago

Why Rust though? It doesn't provide much in terms of an expressive type system when compared to Haskell, SML, OCaml, Idris. I like Rust for many reasons and it's a huge boon for more correct software produced by more people (aka those who don't use an Ada profile :D) but Rust's type system isn't something to weight heavier than OCaml's. There is at least one SML implementation with region types from what I understand. Need to look it up, but it was the implementation from that Dane whose name was something like Elsberg or something and which also had tracing and stuff. For SML I use the MoscowML REPL and MLton for executables. But I don't do much SML, unfortunately. In some ways it's nicer than OCaml.

pcwalton 11y ago
What features does SML or OCaml's type system have that Rust's doesn't? Haskell has higher-kinded type parameters and Idris has dependent types. But SML and OCaml don't even have typeclasses at all, much less higher kinds. Furthermore, what makes Rust's type system interesting isn't just its use of regions (which the ML Kit used); it's regions combined with inherited mutability plus the borrow check to maintain soundness.
- cm3 11y ago
  OCaml's module system is a nice tool for many cases that is only slowly getting into Haskell via Backpack but not there yet. So that's one. GHC 8.0 almost has dependent types and the expectation is feature completeness in 8.2, thought what's in 8.0 is already useful. I like and use Rust and the design decisions that led to a very capable region system that allows one to write data race free and memory correct code is excellent. Haskell doesn't have such a thing because it doesn't try avoid GC. I didn't do a point by point comparison of Rust expressiveness vs Haskell recently, but I don't remember it being close. Rafael might need to write a Rust for for Haskellers as an update of his "for OCamlers" post a while back.
  - knz42 11y ago
    The post is called "Rust for functional programmers" and contains side-by-side comparisons with both OCaml and Haskell. http://science.raphael.poss.name/rust-for-functional-programmers.html http://science.raphael.poss.name/rust-for-functional-program... you might be confusing it with the other post "Haskell for OCaml programmers"? It is a bit outdated but as far as I can see not inaccurate yet. I only plan to update it when HKTs make it to Rust.

draven 11y ago

> i think people who want to program with types today most likely will go to rust, scala or f# I'm a Scala dev. I'm playing with Rust for lower level stuff, don't know much about F#, but FWIW I would rather code in Ocaml than Scala.

daxfohl 11y ago
Serious questions: Why, and why don't you?
- hisham_hm 11y ago
  Probably because they're paid to write Scala.
- draven 11y ago
  As suspected by hisham_hm, I'm paid to code in Scala. At my previous job I tried to introduce some functional languages without much success. The stack was C++/Java and a lot of Python. I learned Scala because it runs on the JVM and I thought that may help. Later I moved to another city and when looking at job offers I saw a few Scala offers (and no Ocaml in sight) so I settled on Scala. IMHO Scala gained traction because it runs on the JVM. It's easier to train Java devs because you can start by writing Java-in-Scala and incorporate specific features as you go. The web ecosystem is nice (at work we're using Play.) There's also a few killer apps, like Spark. I'm currently trying to become as proficient in Ocaml as I am with Scala, but I'm already working with Scala 8+ hours a day so it's not that easy.

dwc 11y ago

I don't agree with your Jane Street / money reasoning. I had never heard of Jane Street until I started looking at OCaml. That Jane Street makes money and is "all in" on OCaml does support the idea that one can use OCaml for serious projects. But does anyone really think (even subconsciously) that using OCaml will make them rich, just because?

pauldirac137 11y ago

I completely disagree. I'm a typoholic to the core. For the last five years I've mostly been programming in Haskell, but lately I've come back to Ocaml and I have to say it's improved massively and continues to do so. I'm happy if people use any decent typed language (including Rust, Scala, F# etc.) but Ocaml has some unique strengths. The module/functor system is the best in the business, and is incredible for defining parameterized data structures. It's even better than anything Haskell has in that regard, as the Haskell community freely admits (they are working on their own version of it). Polymorphic variants are also amazing, and are found in no other language. The object system is really good, although it's seemingly little used because with modules and functors, you rarely need it. And there are lots of exciting things coming down the pipeline, including true multicore support with user-definable schedulers, modular implicits to get the effect of Haskell type classes (but better), a new inliner, and much more. Ocaml is ripe for a massive comeback. I've started using it in my university courses, and students are amazed at how often code "just works" if it type checks (this is also true of the other languages I mentioned). And Ocaml is much easier to learn than Haskell (though I still love Haskell). So give it a try! Once you get past the odd syntax, it's pure pleasure.

daxfohl 11y ago
Okay I (having done a little Haskell and enough F# to know a higher abstraction was needed) thought that modules were already OCaml's counter to Haskell typeclasses, and they were already better. Some weird set-theory-looking T-shirt (obviously) proved it. So what are modular implicits, and how are they better than modules and typeclasses, why are modules not actually enough anymore as an answer for typeclasses, and are they (please no) related to Scala implicits?
- mercurial 11y ago
  You don't get "magic" to_string and equals with just modules, for instance.
  - daxfohl 11y ago
    explain? And how do modular implicits fix?