About the Author:

Teamwork with the Compiler: An Interview with a Functional Programmer

March 9th, 2017

Peter Jones is a freelance software developer, instructor for DevelopIntelligence/appendTo, and has an incredible assortment of bow ties. He spends his working hours giving in-person software training for DevelopIntelligence, developing software for clients, and contributing to open source projects. Peter is passionate about functional programming and prefers to work in purely functional languages. We spoke to him about functional programming to understand more about its dramatic rise and appeal.

DevelopIntelligence/appendTo: Hello Peter. Tell us a bit about yourself.

Peter Jones: My background is first and foremost in software engineering. I split my time right now, fifty percent of my work week is writing software as a contractor and then the other fifty percent of the time I spend in training related activities. So I’m half training, half coding.

I’ve been playing with software ever since I was a kid and I’ve been doing it professionally for over twenty years. As far as training goes, I’ve been doing that for over ten years, I actually learned some of the basic skills for teaching while I was in the Air Force. Outside of training, the other big part of what I do is I’m a big advocate of open source and I spend a lot of time contributing to open-source projects.

DevelopIntelligence/appendTo: Cool! Which projects have you worked on in the last year?

Peter Jones: There are a lot of them. One of the projects that I’m probably spending the most time with right now is XMonad. It’s a tiling window manager for Linux. The other thing that I’m just a huge fan of and I’ve been slowly contributing more and more code to is a Linux distribution called NixOS, it’s a functional programming language sitting on top of Linux. As a functional programmer, I really, really like it.

DevelopIntelligence/appendTo: In your freelance work, what are you primarily working in?

Peter Jones: It really varies. I could say that last year it was about 80% functional programming, specifically in Haskell, and about twenty percent in Ruby.

DevelopIntelligence/appendTo: What do you like or not like about the balance between teaching and coding?

Peter Jones: I really, really like teaching but I don’t think I can do it full time. It is a big emotional drain on me because I’m an introvert. I fit really nicely into that stereotype of the software developer who likes to be a hermit and away from everybody. So 50/50 is the perfect balance for me.

I am very, very passionate about learning and teaching highly motivates me to learn things inside and out. It forces you to anticipate your student’s needs and the questions that will come up. I also love socializing with other engineers and getting to have a conversation about different technologies.

But I also really like the times when I’m not teaching because I’m actually kind of practicing what I preach. I’m in the trenches working with the stuff I’m teaching on.

DevelopIntelligence/appendTo: It sounds like one of your main specialities is functional programming. What is your take on it from both a coding and teaching perspective?

Peter Jones: The whole realm of functional programming is really big. It’s a big spectrum and there’s a corner of it where I like to hang out. I like the area of strongly typed and purely functional languages.

The key point of functional programming really comes down to software quality and confidence that what you’re writing is going to work correctly. That it won’t have a lot of bugs that plague other languages. We all make mistakes and it’s nice to have tooling to catch those mistakes for us. That’s what strongly typed purely functional languages bring to the table.

DevelopIntelligence/appendTo: Could you give some examples of this?

Peter Jones: These languages (like Haskell or PureScript) don’t have a lot of the troublesome features that other mainstream languages have. Purely functional languages approach programming totally differently and they don’t have things like the NULL type. They don’t have values that can really cause a lot of havoc in production systems because they sneak into your program at runtime. Non-functional languages really put a big burden on the software developer to make sure they are handling errors and uncertainty in their code. They have to check at every possible moment that a NULL hasn’t snuck in.

These truly functional languages don’t even have that value; it’s just something you don’t have to worry about it at all. Instead of having that feature, they have a type system that says “hey, you’re going to call this function and it may return an error and you must deal with it.”

When the compiler is producing a binary, it will look over your program and tell you places where you’re invoking a function that may fail and not dealing with it correctly. The compiler says, “I’m not going to make the binary for you until you fix this.”

DevelopIntelligence/appendTo: Let’s talk about Haskell, in particular. What has it been like learning it and working with it?

Peter Jones: When I decided to learn Haskell, I kind of had this chip on my shoulder that this won’t be that big of a deal. At that point I could learn any programming language in 24-48 hours pretty easily. I just needed to learn the syntax because I have so many languages under my belt and usually from one language to another, they’re about eighty percent similar. From C++ to Java they’re probably ninety percent similar. From Java to Ruby, same thing. You just have to learn the syntax and a couple of idioms. But for the most part the languages operate very similarly.

But this doesn’t apply to the functional languages. They have a totally different idea of what programming is and what you can do with the programming language. It’s almost like having to relearn programming from scratch. There is almost a kind of wall for people to approach these languages.

With Haskell in particular, the challenge has to do with the fact that the language was kind of born out of an academic environment. And so that kind of leaves a bad taste in engineers mouths when they hear about the language and approach it. They think, “Oh this is just some kind of academic experiment”.

But there’s a lot of industry support as well. Companies like Facebook are using Haskell in small doses There are a lot of financial companies using Haskell and that’s because you end up working with a high quality product at the end of the day. You just have to be willing to adjust your way of approaching the problem. When you use a purely functional language with the strong type system, it means that you can’t just sit down at your keyboard and hack out something and get to some kind of working product. Instead, you actually have to take the time to think about what problem you are solving and how do you want to solve it. You have to think a lot more about the kind of problems you are going to encounter while solving this problem.

It’s really interesting to work in a language that forces you to think more. That’s what these languages do. They force you to work hand in hand with the compiler, the tool that’s going to produce the binary for you. Functional programming makes you work with the compiler closely to get to the end result.

You’re telling the compiler, “This is the part I’m trying to come up with.” The compiler is telling you if you’re there or you’re not there or if you’re going about it the wrong way. It’s kind of this team work you have with this other program running.

DevelopIntelligence/appendTo: Very interesting. Where does Elm come into play? How did Elm come about?

Peter Jones: Elm comes from taking the lessons that have been learned about functional programming and then applying them to a web development. Elm is a replacement for using JavaScript to write web applications. Elm allows you to use a purely functional typed language and then the Elm compiler turns that all into JavaScript, HTML, and CSS. This lets you work with a competent strong language instead of a real loosey-goosey dangerous language like JavaScript.

DevelopIntelligence/appendTo: What is the mental switch that you have to make when you switch from a functional language back to a more object oriented or prototypal language?

Peter Jones: When I go into other languages, I feel like I’m in dangerous territory. I feel I’ve been given enough rope to hang myself and I’m almost encouraged to hang myself in languages like Ruby or C++ and especially in JavaScript. I have to be on my tip toes ensuring that I’m doing the right thing because now I don’t have this compiler or type system that’s helping me.

Sometimes, especially in languages like JavaScript, I feel like it’s actually working against me and I have to go on my own and find the best path. So the mental shift is real. The confidence in my code quality goes way down and I have to compensate for that by writing lots and lots of tests and slowing down and really thinking about all the side effects of the code that I’m writing. I have to think “What could possibly go wrong?” Because the tooling is just not there to give me confidence that the end product is going to work correctly.

Haskell and these other languages have helped me become a better programmer because I’m way more thoughtful then when I’m using these sloppier languages. I’m considering all the pitfalls as I’m writing. Before I knew Haskell, I’d just write the code and run some tests and think that I did the best I could. Now I’m realizing there’s a whole lot more I could be doing and a lot more I need to be thinking about as a programmer.

DevelopIntelligence/appendTo: If it were possible, would you switch most of what you’re doing to work in purely functional languages?

Peter Jones: Absolutely. If I have a contract and the contract involves, JavaScript, my very first question is, “Hey can we use Elm or can we use PureScript?” Both of those languages are purely functional and compile into JavaScript. And I think there’s a really easy and compelling argument to make from the quality and maintainability standpoint.

DevelopIntelligence/appendTo: If you were teaching functional programming to non-functional programmers, what are some steps or tips or ideas on how would you approach the task of having them understand the functional paradigm?

Peter Jones: The way I would approach it is to gently introduce people to the idea and peel back the layers of the onion slowly one at a time. Show them how to accomplish some kind of everyday programming tasks in the language without really describing what’s all going on in the background, especially when it comes to the type checking. Show them how to accomplish some of the same tasks and then once they are able to at least write a few small programs in these purely functional languages, then go back and say, okay let’s talk about why this is happening, why we did this, what is it providing for us, why do these things have weird names.

Because they come from mathematics and not from computer science.

I would help them to understand what are the points of these things and what’s actually going on behind the scenes to make this program work? Give them that kind of more global view of the language and their run time.

And then for tips: find a mentor, chat room, or a community for help when you get stuck. After you’ve tried to work on a problem and if you’re just hitting your head against the wall, then turn to your mentor for help.

About the Author:

Elm: React Without Compromises

March 1st, 2017

The world of front end development has been experiencing a major paradigm shift over the past few years. Frameworks have shifted from Model/View and Object-Oriented paradigm of Backbone, Ember, Angularjs v1, and dozens of similar smaller projects to a new paradigm embracing immutable data structures, virtual DOM, and functional programming. The primary catalyst for this has been Facebook’s React framework powered by the large budgets Facebook poured into engineering and advocacy, and perhaps seizing the opportunity created by the delays and rewrites associated with Google’s AngularJS v2 framework.

React brings a hybrid ideology to the table combining virtual DOM and functional-style components (pass in state, get a rendered DOM result). But beyond that, React itself leaves a lot of paradigm and architectural questions open: state management, effect processing, mutability, etc. Thus some teams that want more functional programming concepts land on a stack of stateless React views, immutableJS data structures, and Redux for state change and application architecture. Within this stack, you are still ultimately coding in JavaScript and can use Flow for type annotations.

If those concepts click for you but you want something more coherent, have a look at Elm. Elm has been around (initially as a PhD Thesis) since 2012 and represents some of the core ideas adopted by React/Redux in a more thorough and integrated way by providing a new programming language that directly integrates these concepts.

With Elm, you get a strongly-typed functional programming language that compiles to JavaScript. An expressive type system allows the compiler to automatically detect many categories of errors such that they can never make it into a shipping Elm application. Elm has immutable data structures and pure functional semantics baked in. This is how it can offer a lot of guarantees about program correctness and also helps it achieve great virtual DOM performance. The strength of the type system enables large scale refactoring of your application without regressions.

So what constitutes an Elm application? First, there are no separate HTML templates and JavaScript code modules. The core library includes an Html module with a composable, functional API for representing a DOM tree. Each HTML element is a function taking a list of attributes and a list of children. These nest naturally so it ends up looking almost like HTML but with direct access to the power of a real programming language. That means your attribute values can be computed by a function, and lists of children can be processed with familiar functional programming list paradigms like map and filter. Ultimately your HTML is represented as a function that takes model data as input and returns the DOM structure as output. This model is composable, scales nicely, and deals well with complexity.

To build application behavior, Elm introduces the “Elm Architecture” where application actions such as clicking on a button, entering some text, or an AJAX response arriving are represented as strongly-typed events. These events (called Messages in Elm) are passed to a central update function whose job is to look at the current state, apply the logic appropriate for the current action message, and return a modified state for the application. This new state is then passed to the view function to render a new DOM tree, and virtual DOM can then efficiently update the real DOM.

This architecture has developers smiling as debugging and bug reproduction become much more consistent and tractable (although the type system prevents many bugs from shipping at all). One of Elm’s killer demos early on was the “time-traveling debugger” where you can navigate backward and forward in the history of application states and observe how the UI changes. This is made possible by the design tenets of the architecture.

Elm ships with a core set of libraries for both key language-level functionality for dealing with data structures as well as basic web application building blocks for HTML, HTTP, and JSON. On top of that, the community contributes packages that can be plugged into your application via the Elm-package tool.

The Elm community is much much smaller than the mainstream React community, and probably always will be. The main corporate sponsor of Elm, No Red Ink, is many orders of magnitude smaller than Facebook. However, there are many active collaboration points including Slack chat, Github, Facebook groups, twitter accounts, blogs, and books. There’s a detailed guide to the community resources below.

Elm is a great tool to sharpen your functional programming chops and it provides a much more pleasant and forgiving experience than other typed functional languages such as Haskell, largely due to Elm’s simpler types and extremely high-quality compiler error messages. At the moment, it is probably not mainstream enough for corporate projects in technology-conservative workplaces. However, it is in production use and can be great for side projects and as a learning tool. The techniques you learn and master in Elm can directly benefit how you write JavaScript in general and React/Redux as well.

Interested in learning more about Elm and exploring a bit? Here’s some key resources.

Essential Elm Resources

DevelopIntelligence Team Training Course on Elm

Elm Home Page has the primary docs

The Elm Guide is the official tutorial

Elm Slack Community has helpful channels especially #beginners

Planet Elm syndicates Elm-related articles and blog posts

Elm for Beginners video course at KnowThen

Elm articles on Medium

Elm FAQ is a community-maintained knowledge base

Elm in Action work-in-progress book by Elm luminary Richard Feldman