
Why OCaml? [video] - arto
https://blogs.janestreet.com/why-ocaml/
======
sremani
My take aways from the talk:

1\. Financial transactions are adversarial and have heavy tails. Testing is
not sufficient for Universal Guarantees, type system helps here.

2\. Whole class of trivial bugs are not there because of Option (Some, None)
and SystemF type system

3\. Type system should be part of design process (which happens in OCaml)

4.Precise and Expressive type systems.

5\. Right tool for right job, but with OCaml is in sweet-spot to write huge
range of programs * little scripts * mini langs for configs * big trading
system

6\. Teaching/Learning: * a good percentage of traders with a month long
bootcamp were able to learn with a good level of competence * MIT and Harvard
students were able to achieve competence in 3-4 week internships.

7\. The "python" paradox, esoteric language development helps attract high-
quality/better talent

8\. Tools and libraries OCaml would not be great if you have to reinvent lot
of libraries ala. web development, but has good reasonable ecosystem for
customized solutions (like trading systems etc.)

~~~
solipsism
I'm not sure I understand the _adversarial_ part or why that should matter. He
mentioned it being a zero-sum game, with some having to lose for others to
win. I don't get why that's relevant to the programming language choice.

I think what he should have said is that financial transactions are
_important_ , and that it's _expensive_ to screw up. This is of course as true
or more for, say, NASA's flight software (which is not problem that's not
adversarial in the way he means) as it is for financial trading software.

~~~
jleader
The difference is that if NASA screws up, there's a certain percentage chance
that the bug will be exposed, and cause a problem. That percentage usually
stays constant over the lifetime of the system, regardless of how many times
the bug has already bitten them. In an adversarial situation, there's a
percentage chance that the bug will be exposed, and after that a 100% chance
that adversaries will exploit it.

~~~
mmsmatt
Pick up "Capital Markets for Quantitative Professionals" \- a great resource -
and get a taste of this as early as the preface! The author writes about a bug
he introduced in a program making markets in treasuries. It cost his firm $30k
every trade, and the errant trades piled up as other participants recognized
his mistake.

------
nons3nse
I am learning Haskell but it is very s-l-o-o-o-w to get to a point where I
feel I am actually able to write useful software (probably my fault in
fairness!). I have looked over the fence at OCaml and it seems it hits a sweet
spot between practicality and rigor.

Can anyone advise on whether learning OCaml is worth it when compared to
Haskell, considering I am on my way with Haskell, if only slowly? The lack of
tooling on Windows (I write cross platform desktop software) and the maturity
of the web frameworks (compared to Haskell) has put be off learning OCaml in
the past...

~~~
ignoramous
You might want to start with: [http://blog.ezyang.com/2010/10/ocaml-for-
haskellers/](http://blog.ezyang.com/2010/10/ocaml-for-haskellers/) and explore
the languages for what they are yourself.

I haven't tried Haskell apart from the very basic stuff, but if you have tried
your hand at it for too long, and aren't able to make any headway, then you
might as well invest time in learning OCaml/F# or Erlang or Idris or Rust or
Elm instead. I hear Rust and Elm are pretty good too.

OCaml doesn't do mutli-core, I think [0], whilst Haskell has great support
parallelism, concurrency [1]. Erlang, of course, is absolutely amazing at that
too.

I primarily learn languages to expand my understanding of various programming
constructs. It feels liberating to know that things are much easier in certain
languages due to presence of certain constructs absent in other languages. For
instance, OCaml is insanely good for compiler design and/or static analysis
primarily due to 'variants' and the type system; Go (channels)/Erlang (actor-
based programming, hot-plug code)/JVM-based languages (Clojure/Scala et al
running on vastly optimized vm) for building massively concurrent systems;
Ruby for being expressive, powerful, and simply awesome; JavaScript for...
well... getting a taste of event-driven programming.

The challenges faced when using some of these languages are fascinating and at
some point, it all comes together, as you try searching for a language in
another language (like trying to mimic functional/reactive paradigms in Java 7
or below when faced with problems in handling "streaming data" for example).

In my personal experience, I have found strongly-typed languages to be easier
to master and adopt in production than dynamically-typed languages.

\----

[0]
[https://news.ycombinator.com/item?id=9582980](https://news.ycombinator.com/item?id=9582980)

[1]
[https://ghcmutterings.wordpress.com/2009/10/06/parallelism-c...](https://ghcmutterings.wordpress.com/2009/10/06/parallelism-
concurrency/)

~~~
rbehrends
> OCaml doesn't do mutli-core, I think

Yes and no. Currently, OCaml has only cooperative or GIL-restricted multi-
threading support, but multi-process/distributed systems work just fine
(largely due to its built-in near universal serialization mechanism, which
handles even closures).

It's not perfect, but it's still functional.

~~~
pathsjs
Can you expand on this point? When I tried OCaml a little time ago, it was a
pain even to have a polymorphic print function. I would be surprised if there
was a serialization mechanism that produces a binary form that cannot be
adapted to produce a textual form

~~~
rbehrends
Have a look at the Marshal module. Marshal can be polymorphic because it has
compiler support and can rely on runtime internals (similar to how comparison
is polymorphic or the Printf module can work). It works for pretty much
everything where the representation is known to OCaml (the exceptions are
things like extern C types wrapped in OCaml types).

Example:

    
    
      let f x = 2 * x + 1
      let s = Marshal.to_string f [ Marshal.Closures ]
      let g: (int -> int) = Marshal.from_string s 0
      let () = Printf.printf "%d\n" (g 2)
    

Note: this may not work in the REPL and you may have to put it in a file and
compile it.

Note also that serialization need not be polymorphic. See e.g. the
s-expression mechanism [2], which relies on metaprogramming facilities.

[1] [http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Marshal.ht...](http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Marshal.html)

[2] [https://realworldocaml.org/v1/en/html/data-serialization-
wit...](https://realworldocaml.org/v1/en/html/data-serialization-with-s-
expressions.html)

~~~
pathsjs
Thank you. s-exps are a pain, because you have to manually specify the
function sexp_of_t for any type t that you want to support

~~~
rbehrends
No, that's what the ppx rewriter is for (the metaprogramming I mentioned). You
write _type foo = ... with sexp_ and those functions will be generated
automatically for you. Mind you, the whole Jane Street Core machinery is still
a bit heavyweight for my taste, but that particular concern shouldn't be an
issue. For example, in utop:

    
    
      utop # #require "core";;
      utop # #require "core.syntax";;
      utop # open Core.Std;;
    
      utop # type foo = int * string with sexp;;
      type foo = int * string
      val foo_of_sexp : Sexp.t -> foo = <fun>
      val sexp_of_foo : foo -> Sexp.t = <fun>                                         
    
      utop # sexp_of_foo (1, "foo");;
      - : Sexp.t = (1 foo)

------
mands
Great talk - for me the module system, and functors in particular, are one of
the great strengths of OCaml.

I'm hoping increases usage by Jane Street, Facebook and Bloomberg, along with
the Unikernels/Docker tie-up will lead to increased uptake and visibility. I
personally find it more suitable to systems space than Go, but with far more
features to help build correct code.

(shameless plug - we're using OCaml for our microservices platform in London
and are now hiring -
[https://www.stackhut.com/#/careers](https://www.stackhut.com/#/careers))

------
e_d_g_a_r
For people curious about OCaml and wanting to actually learn the language, aka
build something useful, then come to the next OCaml meetup at the Climate
Corporation in San Francisco. Its a workshop from idea to opam publishable
package. We'll build a command line tool to do bread and butter coding, aka
HTTP requests and Json manipulation. You'll have reusable code and a starting
point so you don't waste time with building code and actually spend time
writing code.

[http://www.meetup.com/sv-ocaml/events/228367572/](http://www.meetup.com/sv-
ocaml/events/228367572/)

As incentive I will be giving away Enter the Monad t-shirts courtesy of Jane
Street, thank you yminsky!

------
agentgt
One thing I love about OCaml is named parameters. I am an explicit kind of guy
and ironically even with all the type inferencing OCaml has it is damn
explicit of a language (although I sort of prefer ad-hoc poly but oh well). It
seems like a pretty trivial thing to have named parameters but there are so
many languages that do not have this feature (or have this feature and it
breaks something (scala->java)).

------
hellofunk
"Raise your hands if you know who John Carmack is." (long pause) "Raise your
hands if you've ever played Quake, or Rage, or Doom..." (pause) "...or if
you've ever heard of them." (pause, blank stares) "Oh! Well, I guess it's been
awhile..."

------
brudgers
Related: Jeff Meyerson's audio interview with Yaron Minsky.

[http://softwareengineeringdaily.com/?s=janestreet](http://softwareengineeringdaily.com/?s=janestreet)

It goes into a lot more of the nuts and bolts of JaneStreet and puts the use
of OCaml in a more technical context.

------
krat0sprakhar
Also from Yaron Minsky, in the same vein -
[http://queue.acm.org/detail.cfm?id=2038036](http://queue.acm.org/detail.cfm?id=2038036)

~~~
mark_l_watson
Thanks, great article. I am learning Haskell, but this article on OCaml is
generally useful.

------
Tomte
But still no Windows support for OPAM, right? _sigh_

That's one of the things that Rust absolutely got right, helping its adoption
tremendously.

~~~
e_d_g_a_r
You could turn that sigh into a PR. You want it, then make it happen, this is
open source after all.

Here is something that might help in the mean time,
[https://www.typerex.org/ocpwin.html](https://www.typerex.org/ocpwin.html).

~~~
Tomte
That's a stupid reply. I don't question the right of the Ocaml/OPIE developers
to ignore platforms they don't like and use. I question the wisdom in doing
so.

Asking people who aren't invested in the slightest in your language so far to
start hacking on your tooling before they can try and learn your language is
an interesting onboarding strategy.

~~~
e_d_g_a_r
No one has a vested interest in your interests other than you.

~~~
Tomte
Counterexample: the Rust team.

I'll leave it at that. You're simply not reasonable.

~~~
rdc12
That is a fairly bad counter example, considering that Rust is primarily
backed by Mozilla with the view to use in Firefox which pretty much requires
Windows support to be worthwhile.

------
jfaucett
IMHO the biggest factors when evaluating a new programming language boils down
to "modules" i.e the methods for creating reusuable units of code, and
"package management" i.e. how easy is it require previously built units of
code and combine them to create compound units. I wish he had talked more
about those aspects.

For me, any language that misses these two is not worth the effort unless you
have really good reasons (i.e. every clock cycle counts in an embedded
program).

Anyway, to that end, what is OCaml's packaging ecosystem like?

~~~
a0
Im my experience OCaml has the best modularity abstractions out there. OCaml
modules are unique since they allow you to work with blocks of code (and
types) on a higher level.

Composing and extending modules, passing modules as parameters to other
modules and this way adapting the code to your need.

And the nice thing is that all the modules are evaluated at compile-time.
Which means you don't have to sacrifice performance for modularity and still
get a very flexible framework for Metaprogramming[1].

[1]:
[https://ocaml.org/learn/tutorials/modules.html#Functors](https://ocaml.org/learn/tutorials/modules.html#Functors)

------
jakeogh
Reading about side effects in py I found: [https://github.com/python-
effect/effect](https://github.com/python-effect/effect)

------
jakeogh
Does making the py recursive miss the point because py isnt guranteed to be
immutable?

    
    
      def sum(list):
          if list:
              return list.pop() + sum(list)
          return 0

~~~
scardine
Python lacks the tail recursion optimizations common in functional languages
like lisp. Seems like the language designers favor iteration instead of
recursion, because recursion is limited to a depth of ~1000 on the default
implementation (see sys.getrecursionlimit).

It is always possible to convert recursive into iterative, and most of the
time doing so is trivial. I recommend doing this unless your algorithm is
O(log n) or better.

~~~
jakeogh
For anyone curious, @ 15 min
[https://www.youtube.com/watch?v=r75X4Vn_E9k](https://www.youtube.com/watch?v=r75X4Vn_E9k)
discusses a recursive sum() and why getrecursionlimit() is there.

~~~
scardine
Excelent resource! I could not put it better than Gavin Bong in this talk
"Functional Programming in Python for the Uninitiated". Thanks!

------
systems
is multi core ocaml still being considered to merge into the main ocaml
distribuition

~~~
agravier
Yes, with an alpha due soon [source:
[https://www.reddit.com/r/ocaml/comments/3z7zvx/eta_on_403mul...](https://www.reddit.com/r/ocaml/comments/3z7zvx/eta_on_403multicore/)]

