My take aways from the talk:<p>1. Financial transactions are adversarial and have heavy tails. Testing is not sufficient for Universal Guarantees, type system helps here.<p>2. Whole class of trivial bugs are not there because of Option (Some, None) and SystemF type system<p>3. Type system should be part of design process (which happens in OCaml)<p>4.Precise and Expressive type systems.<p>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<p>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.<p>7. The "python" paradox, esoteric language development helps attract high-quality/better talent<p>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.)
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.<p>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...
Great talk - for me the module system, and functors in particular, are one of the great strengths of OCaml.<p>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.<p>(shameless plug - we're using OCaml for our microservices platform in London and are now hiring - <a href="https://www.stackhut.com/#/careers" rel="nofollow">https://www.stackhut.com/#/careers</a>)
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.<p><a href="http://www.meetup.com/sv-ocaml/events/228367572/" rel="nofollow">http://www.meetup.com/sv-ocaml/events/228367572/</a><p>As incentive I will be giving away Enter the Monad t-shirts courtesy of Jane Street, thank you yminsky!
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)).
"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..."
Related: Jeff Meyerson's audio interview with Yaron Minsky.<p><a href="http://softwareengineeringdaily.com/?s=janestreet" rel="nofollow">http://softwareengineeringdaily.com/?s=janestreet</a><p>It goes into a lot more of the nuts and bolts of JaneStreet and puts the use of OCaml in a more technical context.
Also from Yaron Minsky, in the same vein - <a href="http://queue.acm.org/detail.cfm?id=2038036" rel="nofollow">http://queue.acm.org/detail.cfm?id=2038036</a>
But still no Windows support for OPAM, right? <i>sigh</i><p>That's one of the things that Rust absolutely got right, helping its adoption tremendously.
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.<p>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).<p>Anyway, to that end, what is OCaml's packaging ecosystem like?
Reading about side effects in py I found: <a href="https://github.com/python-effect/effect" rel="nofollow">https://github.com/python-effect/effect</a>
Does making the py recursive miss the point because py isnt guranteed to be immutable?<p><pre><code> def sum(list):
if list:
return list.pop() + sum(list)
return 0</code></pre>