Alex Mann will be giving a talk at Clojure/conj 2016. He will be speaking about machine learning applied to linguistics in Clojure.
PurelyFunctional.tv: How did you get into functional programming?
Alex Mann: I first started functional programming back in undergrad. We learned Scheme in our introduction to languages course. To be honest, I didn't really "get it", the difference between imperative and functional, at the time. To me it was another tool to do things and I just had to cross my eyes to get the operator in the right place. I think one of the big reasons for this was that I hadn't had to deal with parallelism, or real woes that make the difference apparent. Mapping and reducing felt natural, but it wasn't until I took a position as a "professional Clojure programmer" that I came to understand how in the hell you went from toy examples to web applications...I'm still not really sure I understand this.
PF.tv: What is your talk about?
AM: My talk is focused on using Clojure for machine learning. The task I set about duplicating in Clojure is called tSNE. What this is is reducing the dimensionality of highly dimensional metric spaces in such a way that preserves relationships in the data.
Got all that?
Think of a parking lot. It's a three dimensional, real world thing right? Well let's say we want to reduce it's dimensionality down to 2, similar to how taking a picture. A naive way to go about doing this would be to just remove your depth, and only have height and width. Problem now, is all of the cars are, the same size and have to be either overlapped, or stacked on top of each other so as to keep all of them in our picture.
Obviously, that's not how a real picture works. Cars appear smaller based on how far away they are. Our brains are thus free to say "hey, it's smaller, but I know all of these things are the same size. The smaller ones must be further away." By doing this, you keep the relationship of depth, and distance between the cars, even though you lost a whole dimension.
tSNE does this for metric spaces which are hundreds or thousands of dimensions, and reduces them down to 2 or 3 dimensions. This allows us to understand what relationships exist in a dataset.
PF.tv: What do you hope people will take away from the talk?
AM: My talk wanders through Clojure, to Java, to the JVM, down to unix, so I'm really all over the place on things. My hope in doing such was to spark some ideas across the board for folks. I had the fortune of watching Matt Adereth's talk at last years' Conj, and it was so informative on a number of topics (completely unrelated to Clojure) that his final application to Clojure was really unique and fun. Ultimately, I hope people take away from the talk that Clojure is far from perfect, but it's such an immensely powerful tool. Not least of which is because it's a LISP which is surprisingly useful for modeling linear algebra in code.
PF.tv: What concepts do you recommend people be familiar with to maximize their experience with the talk?
AM: I make a bunch of puns based on various major contributors in the Clojure core scene. I also make a bunch of jokes about parentheses etc. The talk itself is pretty good about being kind to beginners in Clojure.
PF.tv: What resources are available for people who want to study up before the talk?
AM: My GitHub for the talk is probably the best place.
PF.tv: Where can people follow you online?
PF.tv: Are there any projects you'd like people to be aware of? How can people help out?
PF.tv: Where do you see the state of functional programming in 10 years?
AM: (resists temptation to make immutability joke)
I think that functional programming is a really useful paradigm for how to think of your code. I would not be surprised if LISP falls out of favour again and then back and then out etc. etc. But I do think that the core concepts of making functional code will still be around, and of course there will be more flavours of LISP. I think the bigger question will be whether people are still using the JVM in 10 years...or if Clojure is still being used.
PF.tv: If functional programming were a superhero, what superpower would it have?
AM: It would always defeat its foes in the same way no matter changes in location.