Live data from Hacker News

Why We Use OCaml

tech.esper.com

111–120 of 144 posts

Re: Why We Use OCaml

#111
post #4

Could someone comment on what instances you would typically apply lambdas and closures in real-world code? I figure that they are at least more convenient than callbacks with a *userData parameter like in C.

One simple use I like a lot is using tail recursion as a replacement for gotos. Its great for state machines and other "algorithmy" tasks. You get the benefits of gotos (the code you write is the same as the code you think) but the end result is actually manageable.

http://www.lua.org/pil/6.3.html

Lambda the ultiamte goto: http://library.readscheme.org/page1.html

Re: Why We Use OCaml

#112
post #35
post #4

Could someone comment on what instances you would typically apply lambdas and closures in real-world code? I figure that they are at least more convenient than callbacks with a *userData parameter like in C.

This is hard to answer because an honest answer is "practically everywhere". First class functions, used properly, will take over every aspect of a program. Here's a neat example from a paper which tried to compare programming speed between functional, oo, imperative languages [0]. We'd like to build a "shape server" which allows you to build geometries of overlapping shapes and query as to whether a given point (in…

This example is not very different from an object oriented approach (an opaque interface with a "contains" method). That said, in a functional setting the tail recursion is great for functions like union and intersect.

Re: Why We Use OCaml

#113
post #83

Earlier quoted context omitted.

Jon mentioned modularity, so what I imagine he's talking about is functors. They have a scary name (and no relation to Haskell functors) so you might rather call them parametric signatures and they allow one signature to depend upon a previously defined one. Ultimately that means that you can decompose signatures into constituent, reusable parts which is nifty sounding but transformative in how you express APIs

How is it that they have no relation to Haskell functors? > Functors are, roughly speaking, functions from modules to modules ( https://realworldocaml.org/v1/en/html/functors.html ) Functors in haskell have functions (fmap) that take a value (a function) from one category into another. Are they not at least the same Functor as in Category Theory?

Well, they're related at that level. Many, many things are category theoretic functors, though. It's a very general idea of a structure-preserving map between structures.

Re: Why We Use OCaml

#114
post #83

Earlier quoted context omitted.

Jon mentioned modularity, so what I imagine he's talking about is functors. They have a scary name (and no relation to Haskell functors) so you might rather call them parametric signatures and they allow one signature to depend upon a previously defined one. Ultimately that means that you can decompose signatures into constituent, reusable parts which is nifty sounding but transformative in how you express APIs

Functors are not parameterized signatures: they do not allow a signature to depend upon another signature, but rather a structure to depend on another structure. (However, SML/NJ has an extension called `funsig` which does what you have described).

Oomph. That's what I get for talking about OCaml after not using it for a really long time, s/signature/struct/.

Re: Why We Use OCaml

#115
post #112
post #35

Earlier quoted context omitted.

This is hard to answer because an honest answer is "practically everywhere". First class functions, used properly, will take over every aspect of a program. Here's a neat example from a paper which tried to compare programming speed between functional, oo, imperative languages [0]. We'd like to build a "shape server" which allows you to build geometries of overlapping shapes and query as to whether a given point (in…

This example is not very different from an object oriented approach (an opaque interface with a "contains" method). That said, in a functional setting the tail recursion is great for functions like union and intersect.

Sure, and functions can feel a lot like OO. I often think of it as though OO were blown apart into all of its constituent parts and those parts were made available. Then, further, those parts "hang together" better than the variety of OO formalisms ever did anyway.

Re: Why We Use OCaml

#116

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

The fact that OCaml is not an easy language might be a good way to find great developers.

It is. For the most part, the developers who use an esoteric language and understand it's benefits are usually of higher skill that your average developer, and those who are excited enough about it to want to work in it are usually even better still. It's the whole "Beating the Averages" thing that PG talks about. There are risks, but they can be managed, and the benefits are great if you know what you're doing!

Re: Why We Use OCaml

#117
post #60
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.

Do you have any specific examples? I ask as someone that has landed on the Haskell boat but still keeps an eye/ear on the Ocaml one ;)

Re: Why We Use OCaml

#118
post #54

Earlier quoted context omitted.

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://stackoverf…

Or even:

indexedList = zip [1..]

Love how ML-like languages let you express just the bare essence of an operation.

Re: Why We Use OCaml

#119
post #2

Good read. I really liked how the author concretely defined the things they use in OCaml, instead of just saying "functional programming" and waving their hands.

"Algebraic data types!" [waves hands vigorously]. Seriously though, I agree. It's a very solid run-down of all the main ways OCaml is cool. I'll probably link people here if they ask my about why they should bother with OCaml.

Re: Why We Use OCaml

#120
I think the HTML example in the blog post is excellent. It's a real, recognizable problem, and the solution is simple and concise.

Many FP blog posts get too fundamental/abstract at this stuff, but here it really shows how static typing and pattern matching makes something very simple that is much more involved in e.g. Python or C#.

Post reply on HN