Claudia Doppioslash Code Mesh 2016 Interview
From OO to Clojure Workshop!
Watch my free workshop to help you learn Clojure faster and shift your paradigm to functional.
Claudia Doppioslash will be speaking at Code Mesh 2016.
PurelyFunctional.tv: How did you get into functional programming?
Claudia Doppioslash: My first exposure to programming was GW BASIC, when I was 3. Fast forward to many years after that. While excitedly pawing through my CS degree's programming languages textbook, I saw the eminently lovable pile of balanced parentheses that is LISP. I immediately knew I wanted to learn that language, above all the others. I guess it's hard to explain why a Lisper likes Lisp, but I'd wager you know what I'm talking about :D
From Common Lisp, I made the jump to Clojure and FP in 2008. And then more recently to pure, statically typed languages.
I also had the nagging feeling that there had to be a better way to do parallelism, than this locking and semaphores business my professors insisted on teaching me. When I encountered Clojure and Erlang, I realised I was right, and that was it.
PF.tv: Very briefly, what is your talk about?
CD: It's a WIP-mortem (it's not quite dead yet) of our company's project, an IDE for a PLC visual language. Our choices, what went right, what gave us trouble. The twist is, we adopted Elm back in version 0.15.1, developed the project mainly in 0.16, and we are now adopting Purescript for the next projects. So it's a longer-term perspective, of our slightly reckless adventures in adopting interesting languages to make frontend less painful.
PF.tv: What do you hope people will take away from the talk?
The awareness that there are a number of languages similar to Haskell that are starting to be viable for production.
That the progression Elm -> Purescript -> Haskell is very good for learning Haskell without burning out.
- Elm: purity, immutability, syntax
- Purescript: adds Functors, Monads, and other fancy types
- Haskell: adds laziness, odd stuff due to historical reasons, topped by even fancier types.
Haskell on its own it's a bit too much for people to digest in one go, and we're losing would-be-FPers to cognitive overload from the attempt.
PF.tv: What is Elmrang?
CD: Our websocket library for Elm 0.16. Elm 0.17 includes websockets, but when we started the project there was no working websockets library.
PF.tv: I'm interested in the domain of the language you're tackling. How much work is it to build an IDE in Elm and PureScript?
CD: A fair bit.
This question probably requires a bit of background:
PLC languages are used for industrial automation, and are supposed to run on very limited hardware. They control machinery, like conveyer belts, and more. We make a compiler, which takes PLC code and compiles to it to our BEAM runtime. The BEAM is running on the hardware nodes, and also carries some awareness of the layout of the program.
Since the nodes are basically running Erlang, it's relatively easy to get debugging information from the nodes, quickly and reliably.
But the logic needed is rather extensive, and since the Elm is so young not many libraries are available.
PF.tv: What concepts do you recommend people be familiar with to maximize their experience with the talk?
CD: Some familiarity with frontend development, and an approximate grasp of Statically Typed Functional Languages. If you've seen some F#, Haskell, Elm, or Purescript before I think you'll be fine.
PF.tv: What resources are available for people who want to study up before the talk?
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?
Our company's latest project is grisp.org, an affordable wireless embedded board, running Erlang on bare metal.
PF.tv: Where do you see the state of functional programming in 10 years?
My pet programming field is gamedev, where FP is having a very hard time taking off. I hope that, by then, we'll have figured out how to sell FP to gamedevs, and have shipped games written entirely in functional languages.
The difficulties are: - performance - writing FP-only game engines (interfacing with existing OOP libraries drags everything back to imperative) - figuring out a nice paradigm for games within FP. I still hope in FRP.
I also hope to see languages like Rust, which are inspired by FP and use types cleverly, supplant C++ as much as possible.
PF.tv: If functional programming were a superhero, what superpower would it have?
CD: It would have a "learn category theory instantly" ray ;)