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

31–40 of 144 posts

Re: Why We Use OCaml

#31

Post by Dewie »

orbifold wrote: post #23
IvarTJ wrote: 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 instance would be function composition. If functions are values in your language, you can define function composition in the language, that is given a function f : a -> b and g : b -> c, you can define their composition g . f : a -> c as g . f = \x -> g(f(x)) (Here \ denotes lambda) Why would it be useful to have function composition in your language? Well it gives you similar power as "method chains" in an objec…

Why do you need lambdas/closures in order to have function composition? Don't you just need higher order functions?

The thing about map id = id etc. probably has more to do with equational reasoning (can use equals to substitute terms, since there are no side effects, at least in Haskell), but I don't see the connection to lambdas/closures.

Re: Why We Use OCaml

#32

Post by jonsterling »

_random_ wrote: post #17

A bit surprised F# was not even mentioned. I guess they are hardcore meta-programming users?

F# is an ML without any of the things which make ML good (modularity). It's a breath of fresh air if you're on a Microsoft platform, but if you can use OCaml, it is superior.

Re: Why We Use OCaml

#33

Post by oinksoft »

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…

You speak of "the business case" as if there is only one kind of software business in the world, one that focuses on getting to market quickly with inexpensive developers. Reasons like "OCaml is hard" are short-sighted unless you are only planning for the short term. You wouldn't have to hire for OCaml, just for functional programmers.

Re: Why We Use OCaml

#34

Post by runT1ME »

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…

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

Re: Why We Use OCaml

#35

Post by tel »

IvarTJ wrote: 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 longitude/latitude) is covered by your shapes. The idea was to model a radar or early engagement system or something like that.

The obvious way might be to build a whole nest of objects which communicate among one another to consider the formation of the geometry. Another method is to just use functions from points to booleans which model the eventual question "is this point covered".

    type Geometry = (Lat, Long) -> Bool

    type Radius = Double
    type Length = Double

    circle :: Radius -> (Lat, Long) -> Geometry
    circle rad (x0, y0) (x1, y1) = sqrt (dx*dx + dy*dy) where
      dx = x0 - x1
      dy = y0 - y1

    square :: Length -> Length -> (Lat, Long) -> Geometry
    square width height (top, left) (x, y) =
         y  top - height
      && x > left
      && x
So here we build our geometry straight out of lambdas. A Geometry is just a function from (Lat, Long) to Bool and we generate them through partial application. We can also combine them

    union :: Geometry -> Geometry -> Geometry
    union g1 g2 pt = g1 pt || g2 pt

    intersect :: Geometry -> Geometry -> Geometry
    intersect g1 g2 pt = g1 pt && g2 pt

    minus :: Geometry -> Geometry -> Geometry
    minus g1 g2 pt = g1 pt && not (g2 pt)
and then using all of these "combinators" build a sophisticated geometry which describes the final question "is a point covered by this geometry".

The ultimate modeling tool was just lambdas. They are used so pervasively here I'd have a hard time pointing out each and every application.

[0] The comparison itself is sort of stupid, but the paper is still neat http://cpsc.yale.edu/sites/default/files/files/tr1049.pdf

Re: Why We Use OCaml

#36

Post by tel »

runT1ME wrote: post #34
seliopou wrote: post #18

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…

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 transition from regions which allow mutation to pure regions and then back again.

Re: Why We Use OCaml

#37

Post by Dn_Ab »

_random_ wrote: post #17

A bit surprised F# was not even mentioned. I guess they are hardcore meta-programming users?

Why would they? They neither mention other close cousins like Standard ML, second cousins like Haskell or distant relatives like Scala. This is targeted squarely at the 1% of languages that control 60% of mindshare wealth.

Re: Why We Use OCaml

#38

Post by matthewmacleod »

oinksoft wrote: post #33
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…

You speak of "the business case" as if there is only one kind of software business in the world, one that focuses on getting to market quickly with inexpensive developers. Reasons like "OCaml is hard" are short-sighted unless you are only planning for the short term. You wouldn't have to hire for OCaml, just for functional programmers.

That's stupid - all software businesses are (or at least should be) focusing on getting to market quickly, and there's no justification for the view that "a swarm of middling developers" is commonplace.

Re: Why We Use OCaml

#39

Post by dbpatterson »

eridius wrote: post #28

Interesting list. I'm curious if the author has looked at Rust and how they think it stacks up. Rust is obviously still pre-1.0, and it doesn't have an identical feature list, but it seems to me to perhaps be a lot more practical for a lot of work than OCaml (largely because Rust can basically be used anywhere C++ can be, and it has good support for C FFI).

I think that, having used both of them, Rust is going to feel a lot lower level than OCaml. The single biggest thing is that it's pretty hard (slash near impossible) to write Rust code without thinking about memory allocation, which adds non-trivial mental overhead to the work. That isn't to put down Rust - I think they are the first language that actually has a static, type-checkable story about memory allocation, and that's phenomenal, _but_, the reason for this is to be able to write soft-realtime code (for example, browser engines, games, etc). Web code, at least in the early stages, probably usually has lower performance requirements, and most people would probably trade some performance (and I don't mean to say that OCaml is slow, anymore than Go is slow, etc) for not having to even think about that stuff.

Re: Why We Use OCaml

#40

Post by oinksoft »

matthewmacleod wrote: post #38
oinksoft wrote: post #33

Earlier quoted context omitted.

You speak of "the business case" as if there is only one kind of software business in the world, one that focuses on getting to market quickly with inexpensive developers. Reasons like "OCaml is hard" are short-sighted unless you are only planning for the short term. You wouldn't have to hire for OCaml, just for functional programmers.

That's stupid - all software businesses are (or at least should be) focusing on getting to market quickly, and there's no justification for the view that "a swarm of middling developers" is commonplace.

Parent was worried about availability of OCaml developers, and would "pick RoR any day just to eliminate the risk of getting to market late." Never mind that RoR is a web framework, this kind of thinking, that some technology is a silver bullet, or that another is unusable because it is less popular, or that six so-so developers are worth as much as two or three good ones because they're easier to find, is a real problem. It's immature to say out-of-hand that some language, for any application, is "too risky" when it has a good industry track record.
Post reply on HN