EMPEX Interviews: Jeffrey Smith
This is part of a series of interviews with Empire City Elixir event speakers. Today, Troy Denkinger talks with Jeffrey Smith. Join us on October 27th, 2016 to hear Jeff’s talk entitled Characterizing Intelligence with Elixir.
[Troy] When I contacted you to schedule a time to talk, you handed me off to your assistant, Amy Ingram. And it took me an email exchange to realize I wasn’t interacting with a human. Can you talk a bit about your work with AI?
[Jeff] I work at x.ai, where we make artificial intelligence personal assistants who schedule meetings using text, in this case email. That was Amy Ingram, who functions as my personal assistant but is entirely an autonomous software agent — sort of specialized, verticalized AI. She does one task, schedule meetings.
People sign up with us to have a personal assistant take over all of that scheduling stuff for them and it’s a great choice for people who could never afford the tens of thousands of dollars for a human working for them. It’s much easier to justify financially.
People on conference calls ask where she sits in the office. She gets asked out on dates at least once a month. People have sent her flowers, chocolates, alcohol.
You have a new book coming out from Manning, I see. The title is “Reactive Machine Learning Systems.”
Yes, we’re in the Manning Early Access Program, so it’s available for sale now with the first six chapters already published. I think we’ll be shipping the seventh chapter to people within the next week or so. I’m hoping to have the final manuscript late this year or early next year.
Based on the description, I admit to finding the subject matter daunting but I’m also intrigued. Who is the audience for your book?
There are two closely related audiences.
One of them is a software engineering audience that may have knowledge of functional programming, distributed systems, and general backend skills who is looking to see how that knowledge can be applied to the machine learning context.
The other audience comes from the complete other perspective, which would be someone with knowledge of machine learning and artificial intelligence but perhaps without that real world production grade experience. This person may not know how to fit all of these pieces together into a complete, wholly autonomous, artificial intelligence system.
So, this book is meant to bridge that gap. It’s meant to give you real world perspective on things like functional programming, the actor model, message passing, supervision hierarchies, etc. How do those connect up to the actual implementation of a complete machine learning system that has a lot of really desirable properties mandatory a for successful technology implementation in 2016.
In looking through your blog posts it appears you do a lot of work in Scala.
At x.ai we use Scala as our core production language — we’ve given talks and blogged about that. There are a couple reasons for [using Scala.] Having a functional programming language as a unifying concept for how we build abstractions has been very powerful for us. It really allows us to get the tech team to share a view of the world. It also gives us a way of building systems that function at scale with an intrinsically complicated domain that we’re incrementally evolving our understanding of.
That’s the core reason we chose Scala. I, personally, had been working in functional programming languages before Scala. I have previously used Clojure to evolve legacy Java applications to add more modern properties. Then, due to Spark and its relationship to large scale distributed machine learning applications, I converted to focusing on Scala professionally.
Almost all of the code in “Reactive Machine Learning Systems” is written in Scala. Portions of it uses Spark for distributed data processing as well as for machine learning functionality. There’s also some stuff around how to use the Actor Model. And the supervision-based functionality is implemented in Akka, which is influenced by Erlang. That is kind of what led me to Elixir, Erlang, and BEAM systems.
What drew you to the BEAM ecosystem?
There are conceptual questions: Why do we want to build distributed systems in certain ways? Why do we want to use things like supervision trees? Why do we want to communicate by immutable message passing? Why do we want to have strong models of containment? How can we prevent error propagation across our knowable scopes of work?
In looking at how you can do that today in modern implementations, it’s clear that a lot of tool chains don’t give you obvious, easy answers to those questions. The BEAM ecosystem has a lot to offer — it has many years of having worked in these specific domains and problems. It has convincing solutions to these questions.
I’ve been very impressed with what Elixir, Erlang, and the BEAM, have to offer someone who wants to really think about distribution and concurrency as core principles and still have functional programming available to you at all times. Really exciting to me are developments around more core abstractions like GenServer and GenStage that seem actually very close to the heart of the abstractions needed to work on the sorts of problems that interest me.
Are you using Elixir in production?
I’m not using Elixir in production at x.ai. Right now my main usages are really exploring things related reactive machine learning. I gave one public talk at Google Dev Group showing how to design an autonomous AI like Amy using Elixir as the language of explanation. Next month [November, 2016] I’ll be in Belgium at Devoxx where I’ll be introducing the connection between JVM-based Scala/Clojure and BEAM perspectives on building distributed artificial intelligence. I’ll be talking about how the different ecosystems are addressing things, what are the lessons we can learn from them, etc. That’s really been my focus, working on how can we explore these concepts in the community given that I work in an existing code base and we’re not changing the language of that anytime soon.
Any parting words?
I’ve been very impressed by the Elixir community. I think, as someone choosing to engage in technology outside of my working hours, that I’ve been impressed to see a really open and collaborative community that is clearly doing a lot of innovation and really thinking about the problems that I want to think about. Looking at the next generation systems we’re going to need to build, it’s great to be with a group of people who are thinking not just about simple syntax-y things. I see exciting progress and innovation coming from the Elixir community, and it’s very attractive for someone who’s choosing where to spend time.