My History with Haskell

I have been fascinated with Haskell for years. I started dabbling in it when I worked with Elm several years ago and fell in love with type-oriented programming. Since then, I have studied various introductory materials such as UPenn CIS 194, Learn You a Haskell, as well as a dozen blog posts and articles. Recently, I also read Get Programming with Haskell to refresh my Haskell knowledge.

There are several introductory Haskell books, each with their own strengths and weaknesses. I have tried a few of them, but none really clicked with me except Get Programming with Haskell. This is the introductory Haskell book that I would recommend to other software engineers. If you are a practicing software engineer who wants a quick introduction covering just the right amount of topics to write a weekend project in Haskell, this is the book for you.

Summary

• Define and use custom error types by extending the built-in Error type.
• Always handle errors within the functions where they occur, and return errors as values to let the Typescript compiler handle them.
• Do not introduce Result type as its benefit is not worth the cost.

Property-based testing is a great tool, but it’s sadly underutilized. I believe that it’s superior to unit testing and should be used over unit testing whenever possible. If you are not familiar with it, you should google it. These days all major languages have a library for it, so just look for a resource that uses your favorite language to introduce it. Nevertheless, for the most in-depth introduction I recommend the following videos:

• Testing Asynchronous APIs With Quickcheck by Thomas Arts (slides)
• Don’t Write Tests by John Hughes

After working as a product manager for two years and launching two products, I decided to go back to engineering. While it was a fun ride, ultimately I feel happier with engineering. Here are lessons I’ve learned as a software engineer working in a product manager position.

Like a lot of people, I dream of starting my own business. I actually tried it once quite recklessly and failed - learned lots of lessons but it was quite painful. So I’m taking a more planned approach instead. My decision to work as a product manager is another step in that plan. My goal here was to learn how to envision, plan, and build successful products. After a year and a half working as a PM, it would be a good idea to review what I’ve gained and what the next step would be.

More than two years have passed since I wrote my last post, and in the meantime, many have asked me when I’m writing the next one. Well, I’m finally publishing a new post with a big news. As the title says, I got a new job as a product manager as I moved to a new company.

It all began when I noticed that the Elm code snippets in my posts did not have syntax highlighting. It was easy to figure out what was going on. I had set up my blog using GitHub Pages gem, which included Jekyll and other supporting libraries. The syntax highlighting library rouge, however, was locked to version 2.2.1 that did not support Elm. Forcefully upgrading rouge might have resolved the issue, but then I thought, why not get rid of the GitHub Pages gem and upgrade all the dependencies? So began the yak shaving.

In the Elm Architecture, update function is responsible for changing Model state. Depending on how you structure your Model, Msg, and update, sometimes you may want to call update function again with another Msg after calling update function. Recursively calling update is straightforward.

I’ve been thinking about how to organize Elm’s port functions and here’s two approaches that I’ve put together. I assume that the readers know basics of Elm, including the Elm Architecture and how ports work. I put a working Elm app example in my Github repository. If you want to run it, follow this instruction to set it up: