Live data from Hacker News

Why OCaml, why now? (2014)

spyder.wordpress.com

61–70 of 132 posts

Re: Why OCaml, why now? (2014)

#61

Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are: 1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possib…

Adding my own two cents:

- I like that with OCaml you can choose if you want your code to be functional or imperative, and both are equally well-supported. I am writing a compiler in OCaml, and I am able to use the API described in Peyton-Jones & Lester for doing pretty printing while still using imperative algorithms from the Dragon Book. This sometimes feels like cheating, but not having to figure out how to transform imperative code into functional code while still maintaining the same complexity constraints is really nice.

- OCaml code is usually a lot more "boring" than Haskell code, which is nice when reading other people's code. Let me explain: I am T.A.'ing an intro to compiler class where some students use Haskell and some use OCaml. The Haskell styles of the students varies a lot: some prefer to use point-free style, some used Parsec others AttoParsec, some passed state around manually while other use a state monad, etc. The OCaml submissions on the other hand were a lot more homogeneous: ocamllex for the scanner, menhir for the parser, the AST definition was almost identical to mine, and the code generation was also very similar.

- This may just be me, but I have had less problems with opam than with cabal. Also, the merlin tool and its integration with Emacs are really good and give me the kind of minimal, out-of-my-way IDE experience that I am looking for.

Re: Why OCaml, why now? (2014)

#62

I wanted to like OCaml, mainly for working with Unikernels. When I looked at the syntax it just looked very arcane, which was discouraging.

The syntax is certainly very wonky but you get used to it. Installing merlin (vim / emacs plugin) helps a lot too.

Re: Why OCaml, why now? (2014)

#63

Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are: 1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possib…

I generally prefer programming with immutability, but I certainly appreciate the ability to use "benign effects" in my programs. Besides the case for performance, I have applied a strange combination of benign effects, GADTs, and functors to generate a sort of "proof of type equality" between two values passed into a framework, each of which are not known to the framework because they're passed into the framework by…

After numerous discussions with Bob Harper (and reading Derek Dreyer's work, who has been the biggest proponent for applicative functors), I have come to understand that there are only two compelling use-cases for applicative functors:

1. higher order functors.

2. modular type classes

Higher order functors are kind of cool, but IMO Standard ML does not seem to be suffering too much from the lack of them. I'm not too interested in it, since it gets super gnarly super fast, and this happens to be pretty much the main use-case for applicative functors. I suspect that most use-cases of higher order functors in OCaml could be reformulated to be first order, with a lot less monkeying around in the module system. There may be compelling use-cases though.

The other use-case is possibly a version of modular type classes that behaved a bit more like Haskell's. The idea is that if functors are going to be applied automatically during elaboration to provide something like type classes, you'll get MkWelp(S) called in multiple places, and you would prefer that any type members of the resulting structure be compatible. Applicative functors would do this.

I am not too convinced by this use-case, though I could see that people would find it useful.

In all other cases, generative functors have the correct semantics. Pretty much the whole use-case of putting abstract types in a functor is that you can then reason intensionally about them (i.e. distinguish them based on their access path). This is super useful, for instance, if you have a notion of "index" or something and you want to prevent yourself from using indexes from one table in another one, or something along those lines.

This is what the Scala people mystifyingly call "path dependent types". It's just generative abstraction.

So maybe it is an interesting feature to have applicative functors, but these should be added post facto, and generative functors should be the default. OCaml now supports generative functors if you add an extra () parameter; it's strange syntax, but it's good enough for me! :)

Re: Why OCaml, why now? (2014)

#64
post #19

I honestly don't get how people can claim that Haskell is unusually hard to learn. I started learning Haskell with zero functional programming experience, and after getting over that initial pure+functional learning curve (which took two or three weeks of casual learning), it was smooth sailing. Haskell is actually a very simple language compared to popular languages like python or C++; you just have to do a bit of t…

The language itself is not very big. The category-theory based abstractions built on top of it, on the other hand... Just look at the lens library.

That's fair. But I don't think it's reasonable to lump learning about lenses (or other abstractions that aren't part of the prelude) into learning Haskell.

Re: Why OCaml, why now? (2014)

#65
post #35
post #19

I honestly don't get how people can claim that Haskell is unusually hard to learn. I started learning Haskell with zero functional programming experience, and after getting over that initial pure+functional learning curve (which took two or three weeks of casual learning), it was smooth sailing. Haskell is actually a very simple language compared to popular languages like python or C++; you just have to do a bit of t…

From your website, you appear to be a college student. Perhaps your expectations and uses are different than commercial developers.

I am also a commercial developer; I work full-time during the summer to pay for college. My expectations don't really change much. Of course, everyone has different expectations.

Re: Why OCaml, why now? (2014)

#66
post #56

Earlier quoted context omitted.

There's a bunch of other nice features of OCaml such as named arguments, fast compile times, strictness, c-types, and reasonable records. To achieve (some of the feature in) Elm style "structural subtyping" records in OCaml you use the more verbose "object" keyword which is just a record with row polymorphism. Most choose to stick with standard records because they compile to more efficient code. I think the ML modul…

Named arguments may be just "syntax sugar" but its one of the biggest things I miss from Haskell. They make library functions more consistent and they also make it much easier to write point free code because you don't need to resort to combinators like "flip" or "." as much.

I believe they are slightly beyond "syntax sugar". If I'm mistaken, I'd love to see the equivalent of what they desugar to. Some of the nuances that I believe OCaml's named arguments get right (and what greatly distinguishes them from passing a record) may require additional work in the type system beyond simple desugaring to something like records. Someone please correct me if I'm wrong.

- Partially applying arguments. You can apply one named argument, and get a function that expects the remaining named arguments. This is pretty great though confusing when you see it for the first time.

- Defaults for omitted arguments. If the caller doesn't specify an argument, you can define what should be used instead. This is kind of like the opposite of subtyping on record arguments. With structurally subtyped record arguments, you can pass a record that has more information than a certain minimum set of labeled fields. But with named optional arguments with defaults, you can pass less than a certain maximum number of labeled fields.

Re: Why OCaml, why now? (2014)

#67

I think the author doesn't give enough credit to things that OCaml has that Haskell doesn't have: a powerful module system (ie, functors), polymorphic variants/subtyping, etc.

I'm the author, and to be honest I agree. I was still fairly new to OCaml (and ML in general) at the time, so I tried to focus on what I knew rather than rattle off a list of things I had heard were better but didn't really understand.

Re: Why OCaml, why now? (2014)

#68

Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are: 1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possib…

>1. modularity (and now that they have added generative functors à la SML, you can have true abstraction)

Could you share some information regarding Haskell and it's 'modularity' problem (vs. the ML family of languages). I'm fond of the way SML projects can be structured. How are people solving this using Haskell? Are there any interesting solutions for creating modular Haskell application/system's I can see today?

Thanks for your comment.

Re: Why OCaml, why now? (2014)

#69
post #19

I honestly don't get how people can claim that Haskell is unusually hard to learn. I started learning Haskell with zero functional programming experience, and after getting over that initial pure+functional learning curve (which took two or three weeks of casual learning), it was smooth sailing. Haskell is actually a very simple language compared to popular languages like python or C++; you just have to do a bit of t…

Keep in mind that writing something like this is not actually going to be perceived as helpful to most people who may have difficulty with Haskell. Consider a couple of possibilities. First, you may be unusually quick, gifted, clever -- whatever you might want to call it. In this case, the new concepts in functional programming might come easy for you. That's great, but to people for whom they don't come so easily, t…

>Keep in mind that writing something like this is not actually going to be perceived as helpful to most people who may have difficulty with Haskell

No, but hopefully it well help people who have yet to learn Haskell that not everyone thinks it's particularly difficult. I'm not interested in convincing the people who've tried and given up on it.

>That's great, but to people for whom they don't come so easily, this could easily be considered discouraging, or else bragging.

So what do you propose? That I pretend it's really hard for me, even though it's not? What effect do you think that's going to have?

>So unless you're SPJ or beyond, I wouldn't be quick to claim that Haskell isn't "unusually hard to learn."

You don't have to be SPJ to learn Haskell (or talk about how hard it is). Do I have to be Stroustrup to pass judgement on how hard it is to learn C++?

>In particular people who are older and have "work/life balance," ... and the life part of that work/life balance doesn't allow much time to do so.

I obviously don't mean that Haskell is easy for every single person in the world to learn; I mean that, as far as languages go, it's relatively easy enough to learn. If I didn't have enough time to learn Haskell, I also wouldn't have enough time to learn C++ or Python.

> but just maybe don't be so glib to claim it is not hard.

Again, what do you propose? Lie and tell people that it's super hard, so I don't hurt their feelings if they can't figure it out?

Re: Why OCaml, why now? (2014)

#70
post #68

Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are: 1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possib…

>1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) Could you share some information regarding Haskell and it's 'modularity' problem (vs. the ML family of languages). I'm fond of the way SML projects can be structured. How are people solving this using Haskell? Are there any interesting solutions for creating modular Haskell application/system's I can see today? T…

There is a weak form of modularity which can be achieved by using two parts of haskell:

1. hiding constructors in files 2. type classes

But it doesn't really begin to approach the kind of structuring that is possible in an ML-like system. Unfortunately, the issue is very (needlessly) controversial, and I don't think I want to get dragged into it here.

I'll mention, though, that Haskell does have one form of modularity which ML doesn't really, which is the fact that you can write algorithms separately, compose them together after the fact, and expect to get reasonable performance in most cases. This is because of two things: haskell is non-strict, and GHC has pretty good fusion. In ML, you often end up manually fusing things together in order to get good performance, so composition can be a bit more difficult.

Post reply on HN