Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why OCaml, why now? (2014)

spyder.wordpress.com

Post reply on HN
Print view View original

81–90 of 132 posts

Re: Why OCaml, why now? (2014)

#81

Post by sgeisenh »

jonsterling wrote: post #70
YAYERKA wrote: post #68

Earlier quoted context omitted.

>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 modularit…

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

I'd actually argue the opposite. MLton is one of the best whole program optimizing compilers I have ever used. There are virtually no penalties for abstraction. OCaml has a bit of trouble here, from what I've heard, but I've never personally run into serious performance problems as a result of abstraction.

Re: Why OCaml, why now? (2014)

#82

Post by spyder81 »

jonsterling wrote: post #52

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…

Thanks! (I'm the author). I focussed on JavaScript because it's what I know, it's my day job, and I wanted to share a bit of my research while trying to introduce AltJS to it.

I wasn't (and am still not) really enough of an expert in either Haskell or OCaml to talk about other differences; including a bunch of dot points I don't understand wouldn't help anyone :)

Re: Why OCaml, why now? (2014)

#83

Post by jonsterling »

jonsterling wrote: post #70
YAYERKA wrote: post #68

Earlier quoted context omitted.

>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 modularit…

sgeisenh — wow! How cool. If that is the case, than that's awesome, and makes me very happy.

Re: Why OCaml, why now? (2014)

#84

Post by peter-fogg »

jonsterling wrote: post #52

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…

> 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 possibility of, e.g., using effects to implement a semantically pure interface. On the other hand, OCaml has actual effects, which can be used in an open-ended way to implement all sorts of functional interfaces.

So, to be all pedantic and stuff... You've always got unsafePerformIO, first off. This is used in Debug.Trace (https://hackage.haskell.org/package/base-4.7.0.2/docs/src/De...) to allow printf debugging in pure code. This is also used in some Haskell libraries to provide restricted effects in monads other than IO. But if you don't want to use unsafe* functions, you can always use ST to get direct access to mutable memory in a safe way. If you can runST within that interface, then you can present a pure interface to users.

Re: Why OCaml, why now? (2014)

#85

Post by jonsterling »

peter-fogg wrote: post #84
jonsterling wrote: post #52

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…

> 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 possibility of, e.g., using effects to implement a semantically pure interface. On the other hand, OCaml has actual effects, which can be used in an open-ended way to implement all sorts of functional interfaces. So, to be all pedantic and stuff... Y…

1. that's why I qualified it "proper". Of course there is unsafePerformIO, but in the presence of laziness, this is really unsafe. as opposed to ML, where doing IO may harm your ability to reason about stuff, but it won't be unsafe.

Debug.Trace is also unpredictable; actually, it's perfectly predictable if you understand laziness, but it's still not what's really wanted in most cases.

2. ST is a single instance of an effect that can be interpreted into "pure" code. There are plenty of other effects that don't work like this in Haskell, not to mention the problem of composing them together.

So thanks for chiming in! But what you have said is not really that different from what I have said.

Re: Why OCaml, why now? (2014)

#86

Post by tel »

ufo wrote: post #60
tel wrote: post #51

Earlier quoted context omitted.

If you have an ADT but want pattern matching, try Scott Encoding. For instance, here we have Option module Option = struct let scott (some : 'a -> 'r) (none : 'r) (opt : 'a option) = match opt with | Some a -> some a | None -> none end For Option, since it's non-recursive, the Scott Encoding and the recursor/inductor/Church Encoding are identical. Here's a linked list, though module LL : sig type 'a t val fold : ('a…

If you look at this from an "expression problem" point of view, this version with the records-of-functions is very similar to OO programming. But without inheritance, classes and so on.

I'm very much a fan of that POV. I think OO has a lot of mythology, but the technology is relatively similar to something like OCaml or Haskell. Classes are essentially just functions which return "structures".

Inheritance and open-recursion/dynamic binding are usually what remain. I'm not terribly sure I miss them.

Re: Why OCaml, why now? (2014)

#87

Post by lpw25 »

ufo wrote: post #60
tel wrote: post #51

Earlier quoted context omitted.

If you have an ADT but want pattern matching, try Scott Encoding. For instance, here we have Option module Option = struct let scott (some : 'a -> 'r) (none : 'r) (opt : 'a option) = match opt with | Some a -> some a | None -> none end For Option, since it's non-recursive, the Scott Encoding and the recursor/inductor/Church Encoding are identical. Here's a linked list, though module LL : sig type 'a t val fold : ('a…

If you look at this from an "expression problem" point of view, this version with the records-of-functions is very similar to OO programming. But without inheritance, classes and so on.

Indeed classes are great for these kinds of encodings. It is one of the use cases for which classes are the nicest approach in OCaml.

For example, see this section of Real World OCaml:

https://realworldocaml.org/v1/en/html/classes.html#open-recu...

Re: Why OCaml, why now? (2014)

#88

Post by aphexairlines »

ignoramous wrote: post #38

Unless start-ups or top companies [0] start adopting OCaml, I doubt its rise would be meteoric. Take go-lang, for example. It performs no better than Java on JVM, but is gaining tremendous traction because Google is putting all its weight behind it. I believe C# gets far less credit than it deserves... and MSFT knows exactly what its doing by open sourcing it. I digress. I feel, one is better off investing time in Cl…

It doesn't take much to boot up a community in a large company like Amazon or Facebook as long as it brings value. See the FXL, Haxl, and React work at Facebook. (I removed my comments on Amazon as it's hard to gauge what's ok to mention in public)

Re: Why OCaml, why now? (2014)

#89

Post by aphexairlines »

lmm wrote: post #73
tejinderss wrote: post #2

Now that .net is going cross platform, I see a great future of f# (another variant of ML family). Its got multi processors support too.

I think most people who wanted a cross-platform, VM-based, corporate-ecosystem-integrated ML derivative with good concurrency support have already found Scala :P.

The problem with Scala is that you don't just get ML -- you have to accept everything else that comes along -- so F# can be a more comfortable choice.

Re: Why OCaml, why now? (2014)

#90

Post by aphexairlines »

wyager wrote: post #64
mercurial wrote: post #39

Earlier quoted context omitted.

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.

Judging the ecosystem is fair in the same way that Java is lumped together with the reams of j2ee, spring, AbstractFactoryFactory sort of libraries that it yields.

For better or worse, switching to Haskell does entail asking yourself how hard it'll be for your team to become comfortable with things like http://learnyouahaskell.com/functors-applicative-functors-an...

Post reply on HN