Live data from Hacker News

OCaml for the Masses

queue.acm.org

11–20 of 29 posts

Re: OCaml for the Masses

#11
post #3

Seems like financial/quant computing would be a natural fit. The author mentions ocaml being well suited for general programming needs - Anyone using ocaml (or haskell/f#/etc.) for real production code? Edit: should have mentioned this earlier for an example - xmonad is written in haskell

Several investment banks are using these languages in production (BarCap (F#) and Standard Chartered (Haskell) are the names that come immediately to mind). And of course Minsky's employer, Jane Street Capital, writes everything in OCaml. There are plenty of commercial users outside the financial sector too but those users tend to be smaller companies.

Like that small software vendor from seattle http://research.microsoft.com/en-us/um/redmond/projects/z3/m... http://research.microsoft.com/en-us/projects/slam/default.as...

Re: OCaml for the Masses

#12
post #3

Seems like financial/quant computing would be a natural fit. The author mentions ocaml being well suited for general programming needs - Anyone using ocaml (or haskell/f#/etc.) for real production code? Edit: should have mentioned this earlier for an example - xmonad is written in haskell

The compiler for haXe (http://www.haxe.org/) is written in OCaml. That's actually how I ran across OCaml to begin with.

Re: OCaml for the Masses

#13
post #3

Seems like financial/quant computing would be a natural fit. The author mentions ocaml being well suited for general programming needs - Anyone using ocaml (or haskell/f#/etc.) for real production code? Edit: should have mentioned this earlier for an example - xmonad is written in haskell

The compiler for haXe ( http://www.haxe.org/ ) is written in OCaml. That's actually how I ran across OCaml to begin with.

Wow, I had no idea haxe was still around. I looked at using it about 4-5 years ago and dismissed it as not ready for prime time, but that looks like a reasonably active community.

Re: OCaml for the Masses

#14
post #4

To someone who has only just looked at Haskell (and not gotten very far) the syntax looks very similar. Can anyone speak to the differences between the two languages?

Haskell: lazy and essentially pure. In Haskell, an Int is a lazy thunk that returns an Int, so if you write "a = 5 + 6" you're actually creating a thunk that will compute 5 + 6 if needed. For side effects, you use the IO monad and construct an IO Int, a type of a thunk that does I/O (all side effects are treated as IO) and returns an Int. Note that the Int can be evaluated once and its value stored, but the IO Int has to be evaluated again and again (because it may change, and if it's being eval'd multiple times that means we want to enact its side effects multiple times).

Ocaml: strict and impure if needed, but has everything you need to write great functional code (and not much more, which makes Ocaml actually fun to read; I can't say the same of that horror they call C++). I tend to think of it as a functional C. It's a bare-bones, simple language but it's awesome.

Haskell uses type classes for what Ocaml achieves more generally (but also with more work) with functors. Type classes are prettier. Functors handle complex cases (multiple related types) better. Hard call which is "better".

Haskell is more mind-blowing, Ocaml is more practical for most purposes, but probably not as practical as Scala. I like them both (and Scala).

Sadly, I wouldn't bet on either reaching the mainstream. Haskell is lazy, which makes it really hard to reason about memory usage. Ocaml's a great language, but the libraries available are quite poor and the effort to get it ready for multicore is DOA. I wish these languages have more of a future than I think they actually do. Now we're in the "raiding phase" where languages like Scala are borrowing awesomeness from them just like Ruby and Python did to Lisp 15 years ago.

On that, I think Scala's actually a good bet for the next 5 years, and not a bad language at all, although it's hard to learn because most of the online resources are pretty poor. (Odersky's Scala book is great.)

Re: OCaml for the Masses

#15
post #4

To someone who has only just looked at Haskell (and not gotten very far) the syntax looks very similar. Can anyone speak to the differences between the two languages?

ocaml is multiparadigm and eager. in practical terms it has excellent support for just hammering out a solution in an imperative fashion and then refactoring it once it works. i personally find it second only to ruby in terms of getting work done.

Re: OCaml for the Masses

#18
post #3

Seems like financial/quant computing would be a natural fit. The author mentions ocaml being well suited for general programming needs - Anyone using ocaml (or haskell/f#/etc.) for real production code? Edit: should have mentioned this earlier for an example - xmonad is written in haskell

http://cufp.org/ is held every year, and has many interesting stories.

http://www.haskell.org/haskellwiki/Haskell_in_industry has experience reports for Haskell.

Galois and Standard Chartered both have large Haskell teams, for example (I've worked for both).

Re: OCaml for the Masses

#19

"Yet functional languages never really made it to the mainstream" JavaScript development these days is getting pretty darn close to what I would consider 'mainstream' functional programming. Heavy use of both first class and lambda functions, and closures have been standard practices for years now. And thanks to libraries like Underscore.js partial application and the use higher order functions like map/filter/etc ar…

There is a great deal of what functional languages can do that isn't (yet) being absorbed—especially from the statically typed areas, where you can statically verify things like the length of lists using GADTs or other impressively strong compile-time guarantees—but the bits that have been absorbed are useful enough and general enough that those elements of functional languages are already conferring huge benefits to 'mainstream' programming. I suspect that, by the very nature of 'mainstream' programming, it tends to absorb some but not all features of other paradigms, leaving things that are strongly esoteric aside but still grabbing useful features. This happened before with object-oriented programming, where the Java/C++ world incorporated somewhat watered-down elements of Smalltalk. We still don't see full-blown message-passing OOP in most mainstream languages, but we see enough useful features of OOP to make a difference.

I don't know, in general, that they're the "most useful" if utility is defined as conferring the ability to write better programs more quickly, more understandably, &c. But they are "most useful" in the sense that they confer such benefits with a minimum learning curve and with little deviation from the already understood mainstream programming paradigm. For example, monads are an incredibly useful feature, but the (perceived) barriers to understanding are high enough that no mainstream language will feature them as centrally as Haskell does.

I don't mean this as a sleight against anyone, at all—merely as a description. There are a lot of useful things which are outside the purview of the mainstream, and there's no reason to expect that nonetheless useful features of fp will necessarily make it into the mainstream. (And there are certainly cases where functional programming as a whole, and not just cribbed features, is desirable and advantageous, as in Jane Street's case, so I do hope that more non-academics come to see it as a valid paradigm for certain tasks.)

Re: OCaml for the Masses

#20
post #3

Seems like financial/quant computing would be a natural fit. The author mentions ocaml being well suited for general programming needs - Anyone using ocaml (or haskell/f#/etc.) for real production code? Edit: should have mentioned this earlier for an example - xmonad is written in haskell

John Carmack mentioned OCaml and Haskell at the last QuakeCon (on the topics of game scripting and static analysis), citing performance and hiring issues: https://www.youtube.com/watch?v=4zgYG-_ha28 (1:10ish)

I'm not sure about the performance issue. If it stays within a reasonable (low single-digit) factor I think the hit is worth the quality guarantees you can get out of it. The hiring/education issue is probably the #1 reason so few attempts are made in this direction.

Post reply on HN