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

Why We Use OCaml

tech.esper.com

Post reply on HN
Print view View original

51–60 of 144 posts

Re: Why We Use OCaml

#51

Post by sgeisenh »

ryen wrote: post #43
sgeisenh wrote: post #30

Earlier quoted context omitted.

But there is a strong community behind OCaml. A lot of undergraduate programs use a dialect of ML for their core classes. While most OCaml implementations have poor standard libraries, Jane Street Capital has released several open source libraries that make it easy to implement high quality, performant applications.

> But there is a strong community behind OCaml. A lot of undergraduate programs use a dialect of ML for their core classes I don't understand your response. Are you saying the OCaml community primarily consists of undergraduates? > While most OCaml implementations have poor standard libraries That right there should tell you something.

>I don't understand your response. Are you saying the OCaml community primarily consists of undergraduates?

What I am saying is that a sizable portion of academia uses a variant of ML. Maybe it hasn't caught on in industry, but that doesn't mean that there isn't a community that uses it.

> That right there should tell you something.

A lot of development of core tools for mainstream languages comes from the companies that use them. Clang and LLVM, for example, received support from Intel, Google and Apple just to name a few.

Jane Street has reimplemented much of the OCaml standard library for their own purposes. Facebook has already started implementing tools in Haskell. Once functional languages gain more traction, I suspect that the tools will improve substantially.

Re: Why We Use OCaml

#53

Post by dllthomas »

tel wrote: post #36
runT1ME wrote: post #34

Earlier quoted context omitted.

Neat reply, thanks. In regards to #2, this sounds like the ST monad, are they comparable at all? What makes OCaml easier to debug with GDB opposed to haskell specifically? I don't have experience doing either, but that's a curious statement, I would have assumed they were similar (both native code w/ some sort of GC...)

OCaml allows you to use mutation pervasively without marking your type. Haskell requires you mark your type with `IO`, `ST`, `State`. You can see Haskell as advantageous because it means that if you have a type without one of those markers you can be certain there is no observable mutation occurring. You can also see Haskell as disadvantageous because those markers are a little annoying. The ST monad lets you transit…

Basically, all OCaml code runs in IO. You can still only modify things that you've marked as modifiable (analogous to an IORef), but there is no constraint on where you can modify them from.

(In case it's unclear, I'm agreeing with tel and rephrasing.)

Re: Why We Use OCaml

#54

Post by spott »

seliopou wrote: post #18
toby wrote: post #3

What are some advantages of OCaml over Haskell?

I've used Haskell to build JavaScript tools and analyses[0], among other things[1], and have been using OCaml for the past nine months to develop a software-defined networking controller called frenetic[2]. Off the top of my head, here are a few areas where OCaml has an edge on Haskell: 1. The module system. OCaml's module system is a language in and of itself. It not only allows you to define modules that export cer…

One more thing: OCaml is strict by default, Haskell is lazy by default. The later allows for some nice code idioms[0], but makes reasoning about performance and memory characteristics very difficult[1].

[0] indexedList :: [a] -> [(Integer,a)] indexedList l = zip [1..] l

[1] http://www.reddit.com/r/haskell/comments/15h6tz/what_isnt_ha...

http://www.haskell.org/pipermail/haskell-cafe/2013-September...

http://stackoverflow.com/questions/2064426/reasoning-about-p...

Re: Why We Use OCaml

#55

Post by quchen »

seliopou wrote: post #29
quchen wrote: post #20

Earlier quoted context omitted.

Why do you think termination is easier to reason about in eager languages? I think it's quite the opposite: in lazy languages functions compose, in strict ones they don't necessarily. For example, you cannot compose a "take ten values" and "square all elements" function in a strict language if the argument you apply their composition to has infinite length (e.g. is cyclic).

The eager vs. lazy distinction is not relevant here. There are some programs that under eager application semantics will not terminate, but under lazy application semantics they will, and vice versa. What complicates reasoning about termination is the presence of mutation. In a lazy language, you'll never have mutation so you don't have to worry about those complications. You could have an eager language with no muta…

I don't think that's right. There is a basic theorem in (untyped) lambda calculus that says that if a term has a normal form, then any evaluation strategy, including strict and non-strict, will reduce that term to that normal form. Since non-strict evaluation can "skip" arguments that may have no normal form, there are expressions in non-strict languages that terminate while their strict counterparts don't. The opposite scenario does not exist: if a term has to be evaluated, it has to be done in both the strict and non-strict versions. (And in simply typed lambda calculus, all reduction sequences terminate.)

Re: Why We Use OCaml

#56

Post by tikhonj »

claudiusd wrote: post #25

> OCaml includes many features that are not available in the more mainstream programming languages ... and we believe this gives us a competitive advantage. ... The purpose of this post is to explain the benefits of OCaml and compare it to other languages. We hope to convince readers, especially other developers, to consider adopting OCaml for their projects as well. The authors did a great job explaining the benefit…

People say functional programming is hard, but it feels just like a knee-jerk reaction. In practice, it doesn't seem to be much of an issue. For example, IMVU gave an experience report at BayHac about switching from PHP to Haskell; they found that onboarding a new employee (without significant Haskell experience) took about as much time as it did for their particular flavor of PHP (conventions, frameworks... etc)[1]. They found Haskell became much easier to teach given a strong set of opinions on code style and library choice.

Jane Street has had a similar experience with OCaml. In fact, they even teach all of their new traders—largely non-programmers—OCaml in a few months! [2] In fact, one of the main reasons they stuck with OCaml was because it made it easier for their domain experts to review and read code.

The same happens for hiring: it's not nearly as difficult as people seem to think. Sure, the supply is relatively low in absolute terms—but demand is even lower, proportionally! If anything, it's probably easier to hire quality developers in a language like OCaml because it serves both as a filter (applicants really self-select) as well as an additional perk to people interested in the language.

[1]: https://www.youtube.com/watch?v=gl3expkos4Q#t=483 [2]: https://www.janestreet.com/ocaml-bootcamp/

Re: Why We Use OCaml

#57

Post by dustingetz »

claudiusd wrote: post #25

> OCaml includes many features that are not available in the more mainstream programming languages ... and we believe this gives us a competitive advantage. ... The purpose of this post is to explain the benefits of OCaml and compare it to other languages. We hope to convince readers, especially other developers, to consider adopting OCaml for their projects as well. The authors did a great job explaining the benefit…

I think it comes down to if your company has strong enough technical leadership to retain an ocaml engineering team. If there is dissonance between how engineering thinks about the business and how the leadership thinks about the business, you'll not reap the benefits of ocaml and the team will leave. In practice I think this means the founding team has to have an ocaml expert for ocaml to work (or any other not-mainstream tech choice). You can't just hire one and hope for the best.

Re: Why We Use OCaml

#58

Post by spott »

quchen wrote: post #20
edwintorok wrote: post #6

Earlier quoted context omitted.

Haskell uses lazy evaluation by default, which makes it hard to reason about the space usage (or termination) of a particular program. OCaml on the other hand is not lazy by default (but supports it if you need it). At least that is one of the reasons why I chose to learn more OCaml than Haskell.

Why do you think termination is easier to reason about in eager languages? I think it's quite the opposite: in lazy languages functions compose, in strict ones they don't necessarily. For example, you cannot compose a "take ten values" and "square all elements" function in a strict language if the argument you apply their composition to has infinite length (e.g. is cyclic).

Because I can walk through a strict program in my head (or on paper), and see every value, what is being calculated, and what is being stored. With a lazy language, I can't necessarily do that. The entire memory of my program can quickly fill up with thunks. The optimizer determines when things actually get calculated, and I need a much deeper understanding of my code to figure out the space constraints.

Just writing code? I guess I can agree that lazy evaluation makes it easier, but performance still needs to be considered.

Re: Why We Use OCaml

#59

Post by seliopou »

quchen wrote: post #55
seliopou wrote: post #29

Earlier quoted context omitted.

The eager vs. lazy distinction is not relevant here. There are some programs that under eager application semantics will not terminate, but under lazy application semantics they will, and vice versa. What complicates reasoning about termination is the presence of mutation. In a lazy language, you'll never have mutation so you don't have to worry about those complications. You could have an eager language with no muta…

I don't think that's right. There is a basic theorem in (untyped) lambda calculus that says that if a term has a normal form, then any evaluation strategy, including strict and non-strict, will reduce that term to that normal form. Since non-strict evaluation can "skip" arguments that may have no normal form, there are expressions in non-strict languages that terminate while their strict counterparts don't. The oppos…

For (actual) programming languages without mutation and with more than just lambdas and application for control flow, it is right:

    f x y = y
    f (raise Done) Ω
Under lazy application semantics this program will never terminate. Under eager application semantics it will.

Re: Why We Use OCaml

#60

Post by TylerE »

toby wrote: post #3

What are some advantages of OCaml over Haskell?

Haskell tries to be exceedingly (some might argue excessivly) clever. OCaml strives to be pragmatic and predictable.
Post reply on HN