Today, we‘ll be a bit more geeky than usual. As the date of the Reactive Conf is approaching, we are about to introduce another guest. There is probably no bigger fan of Elm language than Richard Feldman. We talked about his beginnings with the language, about its future, the tips he would give to a programming newbie, as well as about his book on Elm coming out in 2017.
You are one of the Elm technology pioneers. Can we start out with your Elm journey? How did you get to work with the technology?
I was working on a side project and faced some maintainability problems, therefore, I started looking at several different functional compiled JavaScript languages. I saw a blogpost called Blazing fast HTML. It looked like it did all the things that I was looking for, so I decided to give it a try on my Dream Writer project. I completely fell in love with it; it was totally new and awesome experience to me.
Later at my work, I worked on a project that had a lot of familiar problems that Elm had solved on my own project. I thought that we should try using it and see if it can solve the maintainability problems.
We built a really small thing in Elm and introduced it gradually to our production application. Today, Elm is the biggest language in our front-end. It still has not thrown one single runtime exception, it’s just been running smoothly.
What are the advantages of Elm language from your point of view?
The biggest one is reliability. It doesn’t crash often, and the compiler is really good at identifying cases where we missed. Even in cases where our unit tests fail to account for something. Basically, the compiler saves us from things that we don’t usually think to write unit tests for.
Then, there is the maintainability. Elm makes it much easier to refactor code. When we make a big change in the code, having the compiler know all the places where we broke stuff and tell us about it is great. We write a lot of tests: unit tests, generate tests, property based tests, integration tests, but whenever we make a sufficiently large change, all of those tests break, and they are no longer able to save us from making sure that the new thing works. The first thing we have to do is rewrite all the tests and not make any miskates. But our experience with JavaScript has been that it’s usually not the case, whereas Elm’s compiler just works the same way before and after any big change.
I also heard you are writing a book on Elm. What is the main goal and topics you are going to cover?
It’s called Elm In Action, and it will take the reader from only knowing a bit of JavaScript and having a basic understanding of HTML and CSS all the way through knowing Elm enough to build something for production with it. My goal with the book, in particular, is that, after reading it, someone could come to work for us in NoRedInk and already hit the ground running on day one, which currently is not something that we expect.
I don’t have the final publication date yet, but the estimate would be the spring 2017 for the e-book and the summer 2017 for the physical book.
I also did a two-day Frontend Masters video tutorial in September, which was recorded and will be released in a few months. People can watch it by subscribing to Frontend Masters.
You mentioned hirings. Do you also have open remote positions?
We’ve actually been hiring more and more remote people. Now we’ve got to the point where we can open up our remote hiring to anyone in Europe because, essentially, now we have enough people worldwide so that we can accommodate both US and European time zones. Whenever you’re online, you have several other people from the company you can collaborate with.
We are hiring for three engineering positions. The first one is the Senior Front-end Engineer. We also need Senior Full-Stack/Rails Engineer as we use Ruby on Rails on the back-end. People, however, don’t need to be experts in Rails; we are looking for strong engineers. The third one is Senior Back-End/Infrastructure Engineer. We have students use our site to answer millions of questions everyday, and we’ve recently crossed the one-billion-questions-answered mark. So we’ve got a lot of infrastructure needs.
Last year, you visited Bratislava and the first edition of ReactiveConf. Do you have a specific story or memory that comes to your mind?
I always judge conferences first by the quality of the discourse, by the things that happen outside the conference. To me, the most imporant part of any conference is always the content of the conference and the amazing personal discussions between me and a small group of people in hallways.
One of the most amazing memories was a dinner at the Bratislava castle. It was just me and a group of friends – programmers – talking about all the amazing things we had seen at the conference and all the amazing interactions we had.
I love programming, talking about programming and sharing the experiences other people have had from around the world. There is really no substitute for coming together in person at a place where everybody just feels inspired to talk about things they are passionate about. ReactiveConf last year was a huge successful event for me, and I immediately said I’d love to come back next year.
What will you be talking about at this year’s conference?
I’m planning to do an Elm introductory workshop the day before the talk. Then the main talk is about React and Elm. I want to talk through my experience adopting React, adopting Elm, and, in particular, about having them co-exist – what the costs and benefits of such solution are. We introduced Elm incrementally, and so for a very long time, for over a year now, we’ve had React and Elm co-existing side by side at the same current base. I don’t think that’s an experience many people have had.
Where do you see Elm in the future?
That’s a good question. If you look one year out, you’re going to see a lot more API stability. In the past several years, there has been a lot of iterration to try and nail down the design of Elm as well as a lot of big changes based on the learnings on how people have been using it.
Right now, Elm is very reliable. It’s great, but the design release number is still 0.17, which is meant to indicate that we can still expect significant changes. It’s important to recognize that, in some cases, not changing much can be a feature. A year with a lots of polishing, UX improvements, bug fixes, and tooling can be an exciting thing, too. It would mean that now the language would be mature enough to a point where it’s a less early stage, less experimental than it is today.
More years out?
Five years out, there will be Elm on both compilers of JavaScript and also on the server. That’s really exciting stuff, especially because Evan Czaplicki, the language’s creator, wants to really do it right.
So there was sort of a forthcoming road where he had a decision to make. Either to go for some pretty obvious setting up – making it possible to do Elm on the server and in the browser – or think bigger about how can we have the best possible experience of integrating these two. And he said, “Let´s go for the second option, let´s first keep focusing on the browser and then, once we are really happy with that, switch and make the server experience totally amazing.” Therefore, I think that in the next year, we won´t see Elm like a backend language where you can talk to a database. But five years from now, we will see that. Evan has a lot of really awesome ideas on how those two can interact.
I heard that your company has also hired Evan Czaplicki. Is that true?
Yes, it is. You know, when you think about taking a job, you take into consideration the salary, the benefits, the hours. But if you do programming, you also think about the program that you are going to use and how excited working in it is going to make you. We’ve found out that a lot of people have been applying to us since we started to use Elm.
My boss tried to think ahead: “As Elm is getting more and more popular, how can we maintain this advantage of people eager to come work for us? What could set us apart in the world where more and more companies are using Elm?” That was the point where he started to ask if we could hire Evan away from Prezi.
As it turned out, although Prezi does use Elm for production, it is just a very small piece of what they´re doing. In contrast, we already got Elm in production, using it more and more. It made sense to both sides. We would get to maintain our ability to attract people not just through our technology but also through being able to say: “As you work here, you not only get to use Elm, but you can work aside the creator of the language and talk to him about it.” So far, it has been really awesome.
Why do you, personally, like to do programming?
I just really like creating things that make other people happy, and in programming, that sort of manifests as love for user experience. I love making user experience, that´s what has drawn me to the front-end. Although I’ve had a lot of back-end programming experience as well. The front-end is the front line of interaction. The best way to make the best UX is to have a powerful back-end that is capable of replacing very complicated UI doing the same thing. Programming is my favorite way to make people happy:)
What would be your three to five hints for a person who wants to start programming?
That´s a great question, no one’s ever asked me that. The first thing that comes to my mind is to learn multiple languages early on. You should try and get experience, I would say, in three different languages if you can. Maybe start with JavaScript, then, after a few months, start learning Python. Once you´re done with that, you start with some Elm:)
Many language concepts have made a lot more sense to me over the years when I was able to compare how they work in different languages. I didn’t really realize how superficial my knowledge was, until I could use a couple of different languages. I was like “Now I see what the commonalities are between them.” That has strengthened my knowledge of all of them.
Secondly, it is important to figure out what you want to get out of programming and map out the timeline. For example, your goal is just to get a job. It is important to figure out what you want that job to be like. Because there are a lot of different programming jobs. If you are a developing person, you have very different things to worry about than a front-end person. Doing a little bit of research can help.
The third thing – lack of experience doesn’t hurt you as much in programming as it does in most other professions. If you are a doctor or electrician and you compare what the previous decade looked like or how much things have changed, it is not going to be as much and as quickly as things have changed in programming. That means even people who have been in the industry for a long time are still catching up.
If the programming starts to feel overwhelming, you have to remember that a lot of the stuff that other people learned doesn’t matter anymore. I spent a lot of time debugging Internet Explorer 6, 7 and 8, which was a very specific task. All of that doesn’t matter anymore, because nobody supports those browsers today. Somebody, who is starting fresh, is not in any disadvantage.
The interview is brought to you in cooperation with ReactiveConf, which takes place from 26th to 28th October 2016 in Bratislava, Slovakia.
Photos: Richard Feldman
