3 ms·
> Jane Street > they were consistently building things with just one or a handful of people that would have taken multiple teams at other organizations I've se
by pushfoo 3y ago
> Jane Street
> they were consistently building things with just one or a handful of people that would have taken multiple teams at other organizations I've seen.
> you develop a shared mental model of the system you're developing
How much of this was due using OCaml?
Despite some language-specific quirks, trying Elm has almost convinced me that dynamic typing is a mistake for any parts of a project which don't need to be used from a REPL context.
- tikhonj 3y agoI like to think their choice of language definitely helped, but I'm also pretty biased :) In particular, I've found that having an expressive type system makes it easier to develop and communicate this kind of mental model, as well as to maintain a close mapping between the concepts you use to understand the system and the code itself. I'm convinced that this is a powerful approach that can be incredibly effective and is hard to reproduce in "normal" languages, but it's hard to state this too confidently since it is entirely based on my own qualitative experience with programming.
- pushfoo 3y agoThis tracks with how I've seen "normal" languages converge on similar, flawed imitations of better type systems through tools and repurposed syntax. Thank you for confirming. Do you have any recommendations or warnings regarding general languages which reach in the opposite direction? Reason[1] and F#[2] are both examples: they attach pre-existing ecosystems and compile-for-$PLATFORM tools to OCaml-like typing. OCaml itself is also intriguing. However, I'm concerned that suggesting it for non-personal projects will go over poorly. The "GPL" in its standard library's LGPL license may scare people despite both the linking exception and Jane Street's MIT alternative. 1. https://reasonml.github.io/ https://reasonml.github.io/ 2. https://fsharp.org/ https://fsharp.org/