Forem: Jon Skulski

Field Report: Elm

Jon Skulski — Mon, 17 Oct 2016 15:56:01 +0000

A few years ago I took Elm for a spin.

Elm?

In brief, Elm is a functional language from the ML-family that compiles to javascript to run in the browser. It is at creating scalable web applications. Elm inspired parts of Redux. The mental models are similar.

The community does a great job explaining itself at http://elm-lang.org/

My experience is brief, but I liked what I saw.

I spent a couple days with Elm building the game ‘snake’. I find the game to be a good exercise for learning user input and events in a new language or tool. So I gave it a shot:

Success, sort of! I’m still working on it, but the code is available here.

Elm is an exciting project. It has a lot of things going for it. Many of the technical aspects have been laid out by Mr. Rishi Goomar in his post “Why I think Elm is the Future of Front End Development”.

I also see a lot of promise with Elm.

Developer experience is a first class citizen

My experience was that of fast feedback and minimal context switching. I was either looking at a compiler error or I was playing my game. Even though, I just picked it up, I felt like I could make meaningful progress at each step.

I was shocked that the claim of “no runtime exceptions” was actually true. When I introduced behaviors I wasn’t expecting, it was because my mental model was wrong (row, column vs column, row etc). There wasn’t side-effect-y bugs.

Because of the bold claim, I skipped writing tests. I wanted to see how it held up. No regressions. Each time I added a feature it stayed there.

Compiler messages are detailed and accurate. The only times I felt lost, I wasn’t reading the compiler message correctly. That’s the truth.

Shoutout to vscode and its elm plugin. Without configuration, these compiler messages start showing up as you write code without having to run a command or context switch to another window.

Elm has a stated goal to bring the benefits of functional programming to the masses. Which _requires d_eveloper user experience is a first class citizen. Elm delivers on that.

In the real world?

Is Elm academic (yes) or can it be used in the real world? Great question! Here are some of my thoughts.

Some companies are reporting big wins

Futurice reports their switch here. No Red Ink has been loud about their use since adoption. The topic is discussed in the beginning of the following Q&A Panel:

Limits talent pool?

A concern that I had was limiting the number of candidates to hire. Engineering teams need to grow, and if the pool of workers is small that can be a business problem. You have to either train or hire competitively. Interestingly enough, No Red Ink (in the video posted above) reports that after ‘being loud with their use of Elm’ the quality of candidates skyrocketed.

Isn’t that incredible? Limiting your candidate pool and the number of people you want to hire increases?

I find that fascinating. Paul Graham talked about this in his article, The Python Paradox. To me, it makes some clown sense. Great engineers want to work with great tooling, so they go to places where they can.

But /this is only true for a limited window of time./ In reference to the article, on a long enough timeline, python is the new java.

Similar to React/Redux

Since Elm is essentially React/Redux enforced at the language level, I can see a team gaining a lot of productivity. It is the same tool with better and faster feedback that prevents anti-patterns, without limiting what you can build.

The cost of switching could be pretty low. I have built a few apps in react and redux so I had a few hours of ‘oh this is that’ and then I was off to the races. I’d imagine that would be similar for a team used to react/redux.

Of course, rewriting an app from react/redux to elm would make little business sense. There’s a number of tools to piece-meal change over a react app, including a React component that runs an Elm app. (Or vice versa) So you can work in chunks.

Young language and has limited tooling

Elm is still figuring itself out. For example, in the v0.17 they changed the naming of a central concept from ‘Action’ to ‘Msg’ (Message). A small change, but a main part of the mental model (of the Html.App part of the language). It’s good to get that stuff right, of course, but reveals youth.

The tooling is great but since the project is only 4 years old, tooling can be sparse. For example, I used VSCode which was a nice experience, but lacked proper syntax grammar files so I stared at lots of white text with blue variable names. That will get better with time.

Getting stuck with Elm

My biggest concern would be adopting Elm and it being ‘over’. And now you have a codebase in a language that nobody uses.

Now it’s open source and the spec exists, so you can always write your own toolchain. But for very sound reasons, most web application shops don’t want to support a language. So, let’s say that adoption would depend on continued community or big-facebook-style-company support.

So let’s just count this one as an all around risk. While the community is vibrant and active (5k chatting away in the slack, active meetups, a conference), it is young and small so there’s a chance this all goes away.

That said, I think there’s /significant/ /competitive advantage/ to a business whose engineering team can reliably deploy web apps without errors or regressions. And Elm promises that.

Active friendly community

I mentioned the community above, but I want to highlight how big of an asset this is. Communities are great indicators of adoption + success.

I found the community to be warm, helpful and active. The documentation and tutorials are thorough, the modules to choose are (mostly) obvious. Help on the slack channel was fruitful and supportive. Answers to technical and design questions came quickly. Thanks, everyone!

(PS If you’re in SF there is a regular hack night this Wednesday. I’ll be there! Say hi!)

(PPS There is also remote meet up happening on Oct, 24th.)

Conclusion

I would like to try Elm out in a small app with a team to test these claims.

Currently, there’s not much incentive to move away from React/Redux. It works pretty well and we sorta, uh, just got here, man. There’s non-trivial risk in choosing Elm. So it doesn’t make sense to move to Elm wholesale. The push/pull thing doesn’t equal out. So that puts me in the camp of early adopter, and I’m okay with that. The benefits that are next-level.

With most of my time with Elm, I felt directed toward solutions and never stuck on problems. Feedback was instant, I never felt stuck. When I wanted to change the structure to fit the new problem, I just did it and returned the program to a working state.

Can you imagine the productivity of a whole team working with no runtime exceptions, minimal regressions and defect-free refactoring?

Happy building!

The Rush and Falsehood of Greenfield Projects

Jon Skulski — Wed, 08 Oct 2014 20:59:57 +0000

Originally written in 2014, republishing for the dev.to community

I used to love the idea of a green field project. I was envious at those who got to start from scratch. This time, everything will be right.

When I was stuck on problems in university, when I couldn’t get the program to do what I needed, I would routinely delete my entire project and start over. Sometimes it was effective, but most of the time I would just code myself right back to where I was.

The times it worked reinforced the belief that programs were tight rope walks. That early missteps in thought, would cause the project to crumble. That to successfully complete a project, every decision needed to be right and just and holy.

I’ve changed my mind about all this now. I’m a bit older now (that’s how it usually goes). I’ve clocked a good number of hours in the cockpit, so to speak. Now, projects seem to me like big ships. They have a weighty inertia that you’ll have to control. Powering on in one direction might get you way of course, but you can almost always slowly turn the ship back on course.

Undeniably, sometimes, the practice of restarting is very effective. Why? Well there’s the rush of getting to start over. But the more important factor was because I had re-think about the problem. I stepped through the problem again, this time thinking a little deeper.

I try to keep that part of it. Starting to think about the problem again, knowing nothing. But this time I keep my code around. Beginner’s mind, not beginner’s project.

Refactoring, Rewriting and Lead Climbing

Jon Skulski — Thu, 02 Oct 2014 17:58:59 +0000

Originally written in 2014, republishing for dev.to

I’ve thrown the word refactor around a lot. I’m like this:

“What are you working on for the next three weeks?”

“I am going to refactor the login system”

M. Fowler, in his wonderful book Refactoring, gives the definition of ‘a change made to the internal structure of software…without changing its observable behavior’

So technically, alright. Go ahead, me, refactor the login system for three weeks. But words and accuracy are important. Perhaps I should just say I’m rewriting the login system.

Fowler also gives this definition:

applying a series of refactorings without changing its observable structure.

I’m having more success with this definition. It’s safer and warmer and more comforting. If it’s a multiweek process without releasing to production, I’ll call that a rewrite. And rewrites are hard and scary and riskier. So I try to avoid ‘em.

Lead climbing. Many anchor points, several discrete releasable points.

When I conceive of a refactoring as a series of discrete steps to improve the quality of the code, I take those small steps. By discrete, I mean releasable to production.

Extract a method. Create a small class. Rename a variable. Add a type hint. Make a small, safe, confident commit in the right direction.

Small steps carry us a long way.

Hello World

Jon Skulski — Sat, 01 Jan 2000 01:01:01 +0000

"If I had one wish that I could wish this holiday season, it would be for all the children of the world to join hands and sing together in the spirit of harmony and peace. And to publish a blog with git.

If I had two wishes that I could wish for this holiday season, the first would be for all the children of the world to join hands and sing in the spirit of harmony and peace.. and the second would be for $30 million a month to be given to me, tax-free in a Swiss bank account."