Hacker News Reader

Comment by nons3nse | Hacker News Reader

I am learning Haskell but it is very s-l-o-o-o-w to get to a point where I feel I am actually able to write useful software (probably my fault in fairness!). I have looked over the fence at OCaml and it seems it hits a sweet spot between practicality and rigor.

Can anyone advise on whether learning OCaml is worth it when compared to Haskell, considering I am on my way with Haskell, if only slowly? The lack of tooling on Windows (I write cross platform desktop software) and the maturity of the web frameworks (compared to Haskell) has put be off learning OCaml in the past...

View on HN

Learn F#. It's basically OCaml for .NET (there are some differences between them, but they're very similar). You get great tooling, a huge library of functions (F# supports all .NET libraries), a welcoming community, and the language itself is very well thought out.

If you decide you'd like to learn OCaml at a later date, you'll find it easy if you've already learnt F#.

With regards to web frameworks, you've got some good options, ranging from heavyweight frameworks like WebSharper, to lightweight frameworks like Suave.

Much of F# is cross platform too. It's been open source for a long time, and runs fine on Mono.

If you'd like some extra information about F#, I'd recommend the website 'F# for fun and profit':

http://fsharpforfunandprofit.com/

I'm surprised by how many people recommend f# over ocaml. Seams to me that ocaml has more features, better tools and support (but on windows), and more creative community, though. Am I missing something obvious?

F# has the distinct advantage of native interoperation with anything in .NET-land.

It's not as one sided as you make out. OCaml definitely has some advantages (such as native code compilation and support for some extra language features such as functors), but F# has it's own advantages too, such as:

* A larger choice of available libraries.

* Multicore support (OCaml is getting this soon, but it's currently single core).

* A more straightforward standard library (OCaml has three different competing standard libraries (the default one, Batteries, Core), and as far as I can see the F# one is better than all of them in terms of consistency (for example, can expect the same group of Iter, Map, Filter, etc... on all grouped data structures (Arrays, Lists, Sequences, Maps, etc...).).

* Visual Studio is a damn good IDE, and makes coding in F# even better. Perhaps something similar exists for OCaml, but I'm not aware of anything of the calibre of VS. Worth noting in both cases you don't need an IDE to be effective.

I'm not dismissing OCaml, I'd like to learn it one day too, but I hope I've helped explain why some people would want to learn F# first.

Learning Haskell is rewarding in long term, since it deepens your understanding of things.

I learnt both Haskell and OCaml at the same time since their core is essentially the same. But in real world scenarios the way you think about problems is different in both languages. Haskell tends to be more abstract and favor mathematical reasoning, while OCaml is pragmatic but still very expressive.

TL;DR: It depends on your needs, if you want to learn the language and start building something quickly, OCaml is definitely a better choice. You can always come back later to Haskell, and you'll be surprised to see how similar they are.

You might want to start with: http://blog.ezyang.com/2010/10/ocaml-for-haskellers/ and explore the languages for what they are yourself.

I haven't tried Haskell apart from the very basic stuff, but if you have tried your hand at it for too long, and aren't able to make any headway, then you might as well invest time in learning OCaml/F# or Erlang or Idris or Rust or Elm instead. I hear Rust and Elm are pretty good too.

OCaml doesn't do mutli-core, I think [0], whilst Haskell has great support parallelism, concurrency [1]. Erlang, of course, is absolutely amazing at that too.

I primarily learn languages to expand my understanding of various programming constructs. It feels liberating to know that things are much easier in certain languages due to presence of certain constructs absent in other languages. For instance, OCaml is insanely good for compiler design and/or static analysis primarily due to 'variants' and the type system; Go (channels)/Erlang (actor-based programming, hot-plug code)/JVM-based languages (Clojure/Scala et al running on vastly optimized vm) for building massively concurrent systems; Ruby for being expressive, powerful, and simply awesome; JavaScript for... well... getting a taste of event-driven programming.

The challenges faced when using some of these languages are fascinating and at some point, it all comes together, as you try searching for a language in another language (like trying to mimic functional/reactive paradigms in Java 7 or below when faced with problems in handling "streaming data" for example).

In my personal experience, I have found strongly-typed languages to be easier to master and adopt in production than dynamically-typed languages.

----

[0] https://news.ycombinator.com/item?id=9582980

[1] https://ghcmutterings.wordpress.com/2009/10/06/parallelism-c...

> OCaml/F# or Erlang or Idris or Rust or Elm

I think PureScript deserves to be in this list as well :)

> OCaml doesn't do mutli-core, I think

Yes and no. Currently, OCaml has only cooperative or GIL-restricted multi-threading support, but multi-process/distributed systems work just fine (largely due to its built-in near universal serialization mechanism, which handles even closures).

It's not perfect, but it's still functional.

Can you expand on this point? When I tried OCaml a little time ago, it was a pain even to have a polymorphic print function. I would be surprised if there was a serialization mechanism that produces a binary form that cannot be adapted to produce a textual form

Have a look at the Marshal module. Marshal can be polymorphic because it has compiler support and can rely on runtime internals (similar to how comparison is polymorphic or the Printf module can work). It works for pretty much everything where the representation is known to OCaml (the exceptions are things like extern C types wrapped in OCaml types).

Example:

  let f x = 2 * x + 1
  let s = Marshal.to_string f [ Marshal.Closures ]
  let g: (int -> int) = Marshal.from_string s 0
  let () = Printf.printf "%d\n" (g 2)

Note: this may not work in the REPL and you may have to put it in a file and compile it.

Note also that serialization need not be polymorphic. See e.g. the s-expression mechanism [2], which relies on metaprogramming facilities.

[1] http://caml.inria.fr/pub/docs/manual-ocaml/libref/Marshal.ht...

[2] https://realworldocaml.org/v1/en/html/data-serialization-wit...

Thank you. s-exps are a pain, because you have to manually specify the function sexp_of_t for any type t that you want to support

No, that's what the ppx rewriter is for (the metaprogramming I mentioned). You write type foo = ... with sexp and those functions will be generated automatically for you. Mind you, the whole Jane Street Core machinery is still a bit heavyweight for my taste, but that particular concern shouldn't be an issue. For example, in utop:

  utop # #require "core";;
  utop # #require "core.syntax";;
  utop # open Core.Std;;

  utop # type foo = int * string with sexp;;
  type foo = int * string
  val foo_of_sexp : Sexp.t -> foo = <fun>
  val sexp_of_foo : foo -> Sexp.t = <fun>                                         

  utop # sexp_of_foo (1, "foo");;
  - : Sexp.t = (1 foo)

OCaml has most of the "good and easy parts" of Haskell, without the ones that prevent you from using your old habits:

* no lazy evaluation => your usual sense of what's executed when isn't challenged

* imperative features included, albeit often syntactically ugly => You're not stuck because you need to compose 3 monad transformers together, you can't make sense out of the resulting types, and you have absolutely no idea of how the result might be executed anymore. Empirically, the imperative syntax is just ugly enough to make you slightly ashamed of going imperative, and spend 1/4 hour figuring out whether there's a clean and reasonably easy alternative. I don't known whether it's been done on purpose but it's well done :-)

What I miss the most from Haskell in OCaml are type classes. I bet they would have been included, if OCaml had been invented after Haskell.

From Haskell you keep a type system which helps you thinking and finds many error classes, encouragement to think functionally, godd terseness/readability compromise. If you have the time, I'd advise you to learn Haskell, in order to stretch your mind and become an excellent OCaml developer, the way learning Latin makes you a better French or Italian writer.

Re: lack of tooling: I'd be surprised if F wasn't properly supported, and if you're targeting Windows that's probably your best bet. More fundamentally, your truly valuable tooling isn't the IDE, it's the type system. I need a fancy IDE for Python or Java, not for OCaml.

Typeclasses play poorly with Modules. One is the picture of a global phenomenon and the other the essence of forsaking global phenomena.

There's current work under the name "modular implicits" to solve this problem, though.

For those interested in modular implicits, see http://www.lpw25.net/ml2014.pdf

But there are a few languages that have both, such as Ur and Coq, and possibly others. Also, I know that there's work on a more powerful module system for Haskell called Backpack (although, I'm not really familiar with it). I agree that there are certain conceptual incompatibilities between the two as you mention, but they're both so useful that it seems like there must be good ways to bring them together, or at least make both of them available.

If you are looking for web frameworks, F# (a cousin of OCaml) is a better bet for you compared to OCaml and fits well with your current development environment.

F# has Suave.io which is more idiomatic along with asp.net mvc where you can fit F# into.

Freya for OWIN - RESTful development looks very nice too.

Canopy - for Web UI automation (DSL on selenium) is also an awesome tool.

I attended the talk Yaron gave so I have a little context - OCaml is definitely, definitely worth it, and I feel like I have a decent grasp of the language after only 3 weeks of working with it, to the point that I can make useful, large programs.

I've learnt Haskell in the past and it was slow primarily because Learn You a Haskell is I think poorly written.

Read Yaron's book Real World OCaml. It's great.

I was also shocked how quickly I was able to write code in OCaml after having no prior experience with static typing. A couple weeks in and I was quite comfortable.

Definitely. I learned OCaml from the online tutorial and that gave me a pretty good starting point in a few weeks. Compared to the Haskell tutorial on Haskell's website, it focuses a lot more on building real programs versus the sort of REPL-based approach given on the Haskell site (which basically doesn't teach anything more than short one-liners due to its limitations). And even the most popular Haskell book (LYAH) is a worse resource IMO.

I personally found Ocaml to be perfect for learning typed (Hindly Milner) functional programming.

Haskell with its strong syntactic support was good to learn about Monads and how to work with enforced purity.

From there, I went back to Ocaml, using both Monadic IO and Ocaml's better module/functor system.

I did the exact same thing.

I also have been going through a multi-year Haskell learning curve. One thing that helped make me more productive was writing the pure code first (use mock data) and after the pure code works well, then worry about writing the main program, dealing with impure code for file IO, web access, etc.

I have heard great things about OCaml but it seems to make more sense to master one strongly typed language first, and since you already are partially up to speed on Haskell, why not stick with it for now?

This is very similar to how I've been writing my Idris code. I start from the sort of core operations of a program and then slowly spread out from there, before finally incorporating IO at the end.

You are right that it can take a long time to learn Haskell. I've been learning it for probably six years now. At this point I can browse through most libraries on Hackage, read the types, and usually figure out how to use something. I'm still picking up bits and pieces of category theory to help use the more academic-minded libraries, but invariably I find that once I grasp a concept it seems like such a simple and elegant idea. It's just that the implementation and use take getting used to.

Nowadays I think it's easier to do real-world stuff thanks to the amazing work by Michael Snoyman et al. on Stack, the curated package set and build tool, and other projects like Chris Allen and Julie Moronuki's haskellbook.com.

AFAIK F# is supposed to be an ML that is more like OCaml, but on the .NET runtime. Give it a look, it may be useful for you. Also, IIRC, the compiler for it went OSS recently. But I've not tried the language myself, so this is hearsay.

idk about OCaml but if you find learning Haskell slow I highly recommend learning Erlang. It's similar to Haskell in some way but 10x simpler and highly practical. Probably the most practical language/framework (OTP) I've ever come across outside of maybe Ruby/Rails.

By 'practical' I mean in terms of starting out new -> launching a production-worthy business application in an efficient time window.

My problem with Haskell is that I spend all of my time trying to build perfect software instead of productively pumping out software. This is why I prefer Erlang, despite the fact Haskell is a superior language in many ways.

I love Erlang and OCaml both, but I am hesitant to describe it as "highly practical" without major caveats. If you're writing clusters of non-HTTP network servers, sure; nothing beats Erlang/OTP. But outside that niche it's difficult to justify.

Reply on news.ycombinator.com