We have a new tech talk coming up on May 17th, from our very own Dominick LoBraico. This one is about how to represent configurations with programs. In some sense, this is an obvious idea. Lots of programmers have experienced the dysphoria that comes from watching your elegant little configuration format metamorphize into a badly constructed programming language with miserable tools. This happens because, as you try to make your configs clearer and more concise, you often end up walking down the primrose path of making your config format ever more language-like. But you never really have the time to make it into a proper language.
It’s often surprising just how much software performance depends on how the software is deployed. All the time and effort you’ve invested in optimization can be erased by a few bad decisions in scheduler policy, affinity, or background workload on a server.
So here are a few things I check for when an app’s performance is unexpectedly bad. These are things that should apply to any OS running on a modern server, but the specific tools I’ll mention are for Linux.
Are you running the binary you think you are?
It’s funny how often seemingly bizarre problems have simple explanations. So I start by checking that I’m really running the right binary. I use
md5sum to get a hash:
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!