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

81–90 of 144 posts

Re: Why We Use OCaml

#81

Post by dllthomas »

Dewie wrote: post #78
orbifold wrote: post #71

Earlier quoted context omitted.

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

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

Interesting. I might say that partial application is a kind of closure. Certainly, it winds up the same - "function carrying some data that it uses internally". I think you are correct that compose and apply does not require closures of any sort.

Re: Why We Use OCaml

#82

Post by dasil003 »

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…

What about the risk of hiring schlubs who can watch enough Railscasts to duct tape things together, but don't know anything about writing solidly-engineered, maintainable code?

The hiring pool is absolutely swimming with these guys because demand for Rails developers is so high right now. You are more likely to find a better OCaml developer for cheaper than you can find an equivalently skilled Ruby developer just by virtue of being a place offering professional work in OCaml. To attract a similar caliber of Ruby developer you need to offer some crazy perks like sponsored open-source work or some really interesting problems which 90% of early-stage startups don't actually have.

You might think it's foolish to worry about the quality of code when you are just trying to rush to market, but as soon as you get to market you need to start iterating, and that's where you find yourself immediately saddled with technical debt. Worse—and I say this as a professional Ruby developer for nearly a decade—Ruby provides very little in the way of guarantees that developers won't do really stupid things. If you don't have a solid test suite you are dead in the water for maintaining a large app because the interpreter by itself gives you nothing. All those awesome libraries which exist for Ruby but not OCaml? The half-life on those things is like 18-months in the Rails community, meaning you are in constant maintenance mode to keep up with the flavor of the month or else face maintaining an old stack yourself once the original creators abandon it and the community moves on.

Not that this doesn't come with benefits, but you're overselling them to justify picking the modern no-one-ever-got-fired-for-buying-IBM choice compared to the risk of using something less well-known but certainly with critical community mass and much better maintainability characteristics.

Re: Why We Use OCaml

#83

Post by tel »

JamesBarney wrote: post #42
jonsterling wrote: post #32

Earlier quoted context omitted.

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.

Hey Jon, being an F# user who is not very familiar with OCAML, I'd love to know a little more about what specifically F# lacks that makes OCAML superior. I want to know what I'm missing out on.

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

Re: Why We Use OCaml

#84

Post by tel »

ALee wrote: post #63

Hey HNers, I'm the CEO of Esper - there's been a lot of questions regarding the business case for OCaml and I think it'd be helpful to write here: 1) It's practical - for our team, we had developed in it before and had deployed a large system in it - we could get to where we wanted quickly. 2) we think it's a competitive advantage (see OP and PG's Beating the Averages essay) - additionally, since we deal with large a…

I'd love to hear about point (2), in particular how OCaml helped with dealing with large volumes of data.

Re: Why We Use OCaml

#85

Post by JamesBarney »

argentpyro wrote: post #70
JamesBarney wrote: post #42

Earlier quoted context omitted.

Hey Jon, being an F# user who is not very familiar with OCAML, I'd love to know a little more about what specifically F# lacks that makes OCAML superior. I want to know what I'm missing out on.

I've never used F#, but I found an SO question [0] which provided the following: - Functors ( https://realworldocaml.org/v1/en/html/functors.html ) - OCaml-style objects ( https://realworldocaml.org/v1/en/html/objects.html ) - Polymorphic variants ( https://realworldocaml.org/v1/en/html/variants.html#polymorp... ) - The camlp4 preprocessor ( https://realworldocaml.org/v1/en/html/the-compiler-frontend-... ) - Stronger…

Thanks, this was super helpful. I'll have to spend the time going through functors this weekend to try to grok them. But also F# doesn't allow null values, it uses the Option type as well.

Re: Why We Use OCaml

#86

Post by undershirt »

ALee wrote: post #63

Hey HNers, I'm the CEO of Esper - there's been a lot of questions regarding the business case for OCaml and I think it'd be helpful to write here: 1) It's practical - for our team, we had developed in it before and had deployed a large system in it - we could get to where we wanted quickly. 2) we think it's a competitive advantage (see OP and PG's Beating the Averages essay) - additionally, since we deal with large a…

> languages get popular because the companies that use them are popular ... We'd like to be part of the group that helps make the industry more efficient.

It seems true that technology can only go mainstream if there are companies taking the risk to use it in production.

Re: Why We Use OCaml

#87

Post by quacker »

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…

by joining the Caml Consortium (very cheap), we got access to the core developers and a yearly face-to-face. We're talking about Xavier Leroy and Damien Doligez here. Do you get that with Java?

What do you find most useful about talking to core OCaml devs? If you were developing in Java, do you think you would see a similar benefit from talking to core Java devs?

How do you find the OCaml standard library compares to standard libraries from other languages? Is it expansive? Do you find yourself reaching for 3rd party libraries frequently (or writing your own)?

Re: Why We Use OCaml

#88

Post by seliopou »

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

Your Haskell program doesn't use the C stack, so using gdb may tell you something about the Haskell runtime you're using or some C library you called into, but it won't tell you much about the state of your actual program.

Re: Why We Use OCaml

#89

Post by MichaelGG »

JamesBarney wrote: post #85
argentpyro wrote: post #70

Earlier quoted context omitted.

I've never used F#, but I found an SO question [0] which provided the following: - Functors ( https://realworldocaml.org/v1/en/html/functors.html ) - OCaml-style objects ( https://realworldocaml.org/v1/en/html/objects.html ) - Polymorphic variants ( https://realworldocaml.org/v1/en/html/variants.html#polymorp... ) - The camlp4 preprocessor ( https://realworldocaml.org/v1/en/html/the-compiler-frontend-... ) - Stronger…

Thanks, this was super helpful. I'll have to spend the time going through functors this weekend to try to grok them. But also F# doesn't allow null values, it uses the Option type as well.

F# most definitely allows null values. They might not be encouraged, you can't always assign a literal null to a type, but null is very much a first class concept in F#.

You're far less likely to run into them in F# code compared to C#, though.

Re: Why We Use OCaml

#90

Post by jonsterling »

tel wrote: post #83
JamesBarney wrote: post #42

Earlier quoted context omitted.

Hey Jon, being an F# user who is not very familiar with OCAML, I'd love to know a little more about what specifically F# lacks that makes OCAML superior. I want to know what I'm missing out on.

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).
Post reply on HN