From now and then, I found myself having to write some mechanical and repetitive code. The usual solution for this is to write a code generator; for instance in the form of a ppx rewriter in the case of OCaml code. This however comes with a cost: code generators are harder to review than plain code and it is a new syntax to learn for other developers. So when the repetitive pattern is local to a specific library or not widely used, it is often not worth the effort. Especially if the code in question is meant to be reviewed and maintained by several people.
The talk covers the history of Incremental, a library for building efficient online algorithms. The need to update computations incrementally is pretty common, and we’ve found Incremental to be useful in creating such computations in a number of different domains, from constructing efficient financial calculations to writing responsive, data-rich web UIs.
The ideas behind Incremental aren’t new with us; there is a lot of prior art, most notably the work from Umut Acar’s work on self-adjusting computations, on which Incremental is most directly modeled.
Are you thinking about applying to Jane Street for a developer role? Or already have a phone interview scheduled but unsure what to expect? Read on as we walk through an example phone interview with you.
We want to give you some insight into what a typical Jane Street phone interview looks like and give you a chance to prepare. We’re going to take a look at a question we call “Memo” which we used to ask regularly (but of course don’t ask anymore so no need to memorize anything on this page!). As such this post is meant to be a specific case analysis. If you haven’t yet seen it, we recommend reading this blog post for a general overview what we are looking for in candidates.
Our first Jane Street Tech Talk went really well! Thanks to everyone who came and made it a fun event.
Now it’s time for another. We’re planning for the series to feature a combination of voices from inside and outside Jane Street. This one is of the latter variety: on March 6th, Arjun Guha will be presenting On Verification for System Configuration Languages, which is about using static verification techniques for catching bugs in Puppet configs.
I’ve known Arjun for years, and he’s a both a good hacker and a serious academic with a real knack for finding good ways of applying ideas from programming languages to systems problems. Also, he has excellent taste in programming languages…
UPDATE: We are full up. Tons of people signed up for the talk, and we’re now at the limit of what we feel like we can support in the space. Thanks for all the interest, and if you didn’t get into this one, don’t worry, we have more talks coming!
We’re about to do the first of what will hopefully become a series of public tech talks in our NY office.
The first talk is on February 2nd, and is an overview of the architecture of a modern exchange. The talk is being given by Brian Nigito, and is inspired by our work on JX, a crossing engine built at Jane Street. But Brian’s experience is much broader, going all the way back to the Island ECN, which in my mind marks the birth of the modern exchange.
Spacetime is a new memory profiling facility for OCaml to help find space leaks and unwanted allocations. Whilst still a little rough around the edges, we’ve found it to be a very useful tool. Since there’s not much documentation for using spacetime beyond this readme, I’ve written a little intro to give people an idea of how to use it.
Generating a profile
As an example of Spacetime in action let’s get a profile for the
js_of_ocaml compiler. First we’ll need a Spacetime-enabled OCaml compiler:
$ opam switch 4.04.0+spacetime $ eval `opam config env`
Using this compiler we build the executable. In this case we just let opam build it for us:
Ppx is a preprocessing system for OCaml where one maps over the OCaml abstract syntax tree (AST) to interpret some special syntax fragments to generate code.
Ppx rewriters get to work on the same AST definition as the compiler, which has many advantages:
The AST corresponds (almost) exactly to the OCaml language. This is not completely true as the AST can represent programs that you can’t write, but it’s quite close.
Given that the compiler and pre-processor agree on the data-type, they can communicate between each other using the unsafe [Marshal] module, which is a relatively cheap and fast way of serializing and deserializing OCaml values.
I was recently invited to do the keynote at the Commercial Users of Functional Programming workshop, a 15-year-old gathering which is attached to ICFP, the primary academic functional programming conference.
You can watch the whole video here, but it’s a bit on the long side, so I thought an index might be useful. (Also, because of my rather minimal use of slides, this is closer to a podcast than a video…)
Anyway, here are the sections:
- Two worlds, three ideas, about the difference between dynamically and statically typed functional languages.
- Still not popular About the state of functional languages in industry.
- Lipstick on a pig How functional languages are in industry most often used to improve other languages rather than being used directly.
- The evidence isn’t in, or why it’s hard to find convincing experimental evidence as to the relative efficacy of programming languages.
- You can’t value what you don’t understand About how hard it is to assess the utility of language features you haven’t really used.
- The right tool for the organization, an alternative to “the right tool for the job”..
- You broke it, you bought it, or, the plight of having been successful using a minority technology, and how to contribute to the community you now depend on.
- Academia isn’t academic, on the relevance of academia’s ideas about programming.
- Teach your children well Some thoughts on the place of functional programming in the university curriculum, and how much tools matter there.
- Use the advantage On evangelism versus just using FP.
Hope you enjoy!
Now that the interns have mostly gone back to school, it’s a good time to look back at what they did while they were here. We had a bumper crop — more than 30 dev interns between our London, New York and Hong Kong offices — and they worked on just about every corner of our code-base.
In this post, I wanted to talk about just one of those areas: building efficient, browser-based user interfaces.
Really, that’s kind of a weird topic for us. Jane Street is not a web company, and is not by nature a place that spends a lot of time on pretty user interfaces. The software we build is for our own consumption, so the kind of spit and polish you see in consumer oriented UIs are just not that interesting here.
Recruiting talented people has always been challenging.
In some years that meant competing with a hot new company that aggressively courted every fresh graduate with promises of stock options and IPO glory. In other years there wasn’t a specific company so much as an entire rising industry looking for people (I’m looking at you cloud services, driverless cars, and peer-to-peer sharing). Either way, we understood the yearly back and forth. Our job was to explain to candidates how we stacked up, and more importantly, why a career at Jane Street might be the right choice for many of them.
But this year I got to learn a new name for a new challenge. “Unraveling”.