Simon Belak Lambda World 2016 Interview

Simon Belak will be speaking at Lambda World in September 2016.

Follow him on Twitter and GitHub.

PurelyFunctional.tv: How did you get into functional programming?

Simon Belak: My first exposure to functional programming was Mathematica at uni, but that class was about theory of computation, so the focus was on term rewriting. I was already using lisp at the time and the more I developed my personal poetics/aesthetics, the more I was driven to conciseness. Not necessarily in the sense of using the least amount of characters, but more in terms of using the least amount of concepts/constructs and in Common Lisp such solutions tend to be functional. My first truly functional programming language was Qi (an obscure lisp dialect with a Turing-complete type system built on top of the integrated functional Prolog implementation). I moved to Clojure soon after and to this day Clojure remains the language that best meshes with how I think.

PF.tv: Very briefly, what is your talk about?

SB: It's about how to think about working with data. About the division between engineering/programming and data science, where it makes sense and where it's harmful. It's about the tools I'd like and the tools I've built (and the design decisions behind these). It's about Clojure, but not because I think everybody should be doing data science in Clojure, but because it was Clojure that advanced (and also shaped) my thinking on these topics; and because Clojure offers a radically different set of tradeoffs than the majority of other environments used for doing data science and that is always something worth exploring.

PF.tv: What do you hope people will take away from the talk?

SB: New ways of thinking how to approach working with data. Both in terms of tools and processes and how the two are connected. For the more practically minded I will cover what is my go-to data layer architecture and how to overcome the ecosystem problem of fledging languages (spoiler: DSLs that compile to other languages).

PF.tv: What concepts do you recommend people be familiar with to maximize their experience with the talk?

SB: The talk won't go into theory or arcane concepts. Just reflect on the last couple of times you were working with data. What annoyed you? Where did you spend more time fighting your tools rather than your problem? Is the way you approach a data science problem different than other programming? Why? Do you see tradeoffs being different when doing data science than with other programming? Why?

PF.tv: What resources are available for people who want to study up before the talk?

SB: The greatest resource are your past experiences. Aside from that, watch some of Bert Victor's talks (I particularly like Media for Thinking the Unthinkable) and become deeply unsatisifed with the tools (and I mean that in the broadest sense, including languages) we currently have.

PF.tv: Where can people follow you online?

SB: I'm [@sbelak on Twitter]twitter. I've already released some of the ideas as code and hope to do more in the comming months.

PF.tv: Are there any projects you'd like people to be aware of? How can people help out?

SB: huri is the library that encapsulates some of the ideas I'll be talking about (any and all contributions welcome!). But fundamentally I think we are at the stage where the most important thing is for people to experiment: build tools, experiment, question best practices. A recurring theme of my talk is that I don't have a clue. I occasionally glimpse how things could be, but I don't know how to get there (yet). For a large class of problems the hard part is not in the steps needed to arrive at a solution, but finding a solution in the first place. The best approach here is to try and expand our minds and for that a silly throwaway weekend project can be transformative.

PF.tv: Where do you see the state of functional programming in 10 years?

SB: My aesthetics are heavily influenced by the lisp tradition, so one area I'm very excited about is the intersection between program manipulation and types, and "multi-layer" programming. What I mean by this (and I know the terminology is woefully random) is some application of the design principles behind Racket (composing languages, but see The Racket Manifesto for the treatment it deserves) and things such as Idris (prove invariants), Quickcheck (generate tests from properies/invariants), Quickspec (infer equational laws). How will this play out in 10 years? I have no idea. There is some convergence in this direction happening with things like clojure.spec, but at the same time there are still so many unexplored ideas left from the lisp and Smalltalk systems of the 70s that I'm wary of prophesying grand shifts even if --- living in one specific bubble --- it seems we are on the cusp of one. One thing I can certainly see happening is functional programming becoming an empty distinction. Mainstream programming languages are borrowing more and more from functional languages and the functional approaches are becoming seen as idiomatic. I think that's a very good thing. Right now functional programming is simply so much better that it has become somewhat incestuous. The majority of PL research is clustered around (or even tacitly presupposes) functional programming pushing it so far ahead it has become almost impossibly for ideas to travel in the opposite direction and when talking about tools for thought (what programming languages essentially are), that's never good.

PF.tv: If functional programming were a superhero, what superpower would it have?

SB: Some sort of telepathy, like Professor X from the X-Men has --- seeing the hidden "state" of the entire world in his mind. Or perhaps the better emphasis would be on keeping it (machine-aided) in his head.