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

71–80 of 144 posts

Re: Why We Use OCaml

#71

Post by orbifold »

Dewie wrote: post #31
orbifold wrote: post #23

Earlier quoted context omitted.

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.

What you need is that functions are values in your language. Lambdas are just a notation for function values. Typed lambda calculus is the internal language of cartesian closed categories and function values are then called internal morphisms. The composition above is then the internal composition of internal morphisms. It would be possible for external composition to be already defined by the language, take the unix shell for example, with its buildin "|" operator. But if you want to be able to define function composition within the language, you need to have something like lambda.

Re: Why We Use OCaml

#72

Post by dragonwriter »

avsm wrote: post #69
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…

While your mileage will vary depending on the nature of your startup, I can point you to a paper we wrote summarising our experiences using OCaml to build the XenServer toolstack in a startup environment [1]. You should bear in mind that OCaml represents almost twenty years of continuous development (see the history chapter in Real World OCaml [2]), with a community steeped in some of the most cutting edge technology…

> I find it amusing that so-called "risk-averse" startup managers discount a 20-year old language with legendary stability in favour of relatively new languages.

While I mostly agree with your post, the four languages mentioned as opposed to OCaml in the grandparent post (Ruby, Python, Javascript, and Java) are all older than OCaml (which is 18 years old) -- Java, JavaScript, and Ruby are all 19 years old, and Python is 23 -- so they aren't "relatively new languages" compared to OCaml.

Re: Why We Use OCaml

#73

Post by orbifold »

dllthomas wrote: post #53
tel wrote: post #36

Earlier quoted context omitted.

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

One advantage that gives you, is that you can easily define a monad on top of that and not worry about monad transformers. Jane Streets async library does that in its Deferred module https://ocaml.janestreet.com/ocaml-core/111.17.00/doc/async/...

Re: Why We Use OCaml

#74

Post by avsm »

dragonwriter wrote: post #72
avsm wrote: post #69

Earlier quoted context omitted.

While your mileage will vary depending on the nature of your startup, I can point you to a paper we wrote summarising our experiences using OCaml to build the XenServer toolstack in a startup environment [1]. You should bear in mind that OCaml represents almost twenty years of continuous development (see the history chapter in Real World OCaml [2]), with a community steeped in some of the most cutting edge technology…

> I find it amusing that so-called "risk-averse" startup managers discount a 20-year old language with legendary stability in favour of relatively new languages. While I mostly agree with your post, the four languages mentioned as opposed to OCaml in the grandparent post (Ruby, Python, Javascript, and Java) are all older than OCaml (which is 18 years old) -- Java, JavaScript, and Ruby are all 19 years old, and Python…

Yeah, although I guess it depends if you count Caml or not (1987). The intellectual history of the language can easily be traced back to 70s via the various LCF implementations, although the module system evolved significantly since then.

Either way, you're correct that all of these languages bear the proud scars of being tested for decades...

Re: Why We Use OCaml

#75

Post by mhd »

_random_ wrote: post #17

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

Apart from the reasons already mentioned, there's also the OS dividing line (Mono is still treated like a redheaded stepchild on Unix) and possibly memories of some incessant trolling/spamming a few years ago.

I'm actually more surprised that SML seems to be completely restricted to academia nowadays. Standardized language, several decent compilers available, used in introductory books...

Re: Why We Use OCaml

#76

Post by advocaat23 »

Cool tech, but ...

I went to the About-Page and I got the following message out of it:

"We all want to spend our time dooing meaningful things so we ... bla bla ... have to make an app for that".

Come on, I think this is just bullshit. Yes, the premise is correct, people are working too much on stuff they don't like (and we have to fix that), but solving this problem via some time-managment-assistant-whatever-app (oh, there are surely some contrived ML problems to solve here) is just hilarious.

Re: Why We Use OCaml

#77

Post by tel »

orbifold wrote: post #73
dllthomas wrote: post #53

Earlier quoted context omitted.

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

One advantage that gives you, is that you can easily define a monad on top of that and not worry about monad transformers. Jane Streets async library does that in its Deferred module https://ocaml.janestreet.com/ocaml-core/111.17.00/doc/async/...

But I like transformers... a lot!

Re: Why We Use OCaml

#78

Post by Dewie »

orbifold wrote: post #71
Dewie wrote: post #31

Earlier quoted context omitted.

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.

What you need is that functions are values in your language. Lambdas are just a notation for function values. Typed lambda calculus is the internal language of cartesian closed categories and function values are then called internal morphisms. The composition above is then the internal composition of internal morphisms. It would be possible for external composition to be already defined by the language, take the unix…

> What you need is that functions are values in your language.

Well yeah, that's what I meant by higher order functions.

> Lambdas are just a notation for function values.

But regular (named) functions can still be used as function values. So this doesn't explain why you need things like lambdas in order to implement function composition.

> Typed lambda calculus is the internal language of cartesian closed categories and function values are then called internal morphisms. The composition above is then the internal composition of internal morphisms.

Ok bud.

> But if you want to be able to define function composition within the language, you need to have something like lambda.

Well I could implement function composition without the syntactic construct lambda:

(.) g f x = g (f x)

I am not using any lambdas, in the sense of anonymous functions or closures. To implement function composition with a lambda is more of a stylistic choice, in this case. Granted, maybe functions-used-as-values are also lambdas, for all I know.

Re: Why We Use OCaml

#79

Post by gcv »

tikhonj wrote: post #56
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].…

I've always been curious about Jane Street. It seems like a too-good-to-be-true story. Picking an obscure but powerful alternative to C++ and Java for a highly-competent core team makes sense, and has been done by several banks. But hacking OCaml does not fit the personality profile of (m)any traders I've met — most will happily whip up a spreadsheet to help their work, but writing extensive software and learning Hindley-Milner type systems falls outside their ordinary needs or interests.

Re: Why We Use OCaml

#80

Post by lmkg »

Dewie wrote: post #31
orbifold wrote: post #23

Earlier quoted context omitted.

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.

The function returned by 'compose' is a closure because it captures references to its local environment (the two functions passed to 'compose'). If it did not close over these variables, it would not work. It might be possible to define a limited 'compose' operator in a language without closures that worked at compile-time/define-time, but you wouldn't be able to choose functions to compose at run-time like you could with a capturing 'compose.'

Nitpick: Lambdas and closures are different things. A closure is a semantic notion of a function captures its local environment. A lambda is a mostly-syntactic notion of defining a function without giving a name. Whether a lambda is a closure depends on the language's scoping rules.

Post reply on HN