Haskell Cheat Sheet

I’m always forgetting the little things when I write Haskell, mostly because I rarely write it. So I made myself a cheat sheet where I used Elm as the comparison, both because it’s similar and because I write a lot Elm.

Empathy in Code

When you write code as part of a team, how long does it take your coworkers to understand what you’re writing? How many tools do they have to setup before they can start coding? If they update things, how likely is it that something breaks? If it does break, how difficult is it to determine the cause and the fix? These are all things going through my head when I’m reading and writing code.

Contrary to what some people are willing to accept, some tools are better at this than others. For example, for most use cases Parcel is easier to use than Webpack. It’s as simple as install and run. Meanwhile Webpack requires writing a config and trying to figure out which loaders are required for your setup. This doesn’t mean you should never use Webpack, as it is still a better tool in some cases, but the majority of the time it puts a larger burden on your team.

Another great example is formatting of code. Go has gofmt, Python has black, and Elm has elm-format. All 3 of these tools helps teams by removing the entire discussion around “how to format our code”. For Go and Elm this is most noticeable as there’s no other option. You can read nearly any Go or Elm code and there’s a 99% chance that it’ll look the same as any other Go or Elm code. There’s no debating about 2 spaces or 4, spaces or tabs, where a comma comma goes in a list, or any of those things that in the long run isn’t relevant to what you’re trying to accomplish.

What got me to writing this though, wasn’t those great tools. No, it was reading some code that took me and a friend almost 15 min to figure out. It was a tiny line of code, but in the context of the app there was no way we could be certain about what it did unless we went and read another 4 files. The line was a little bit of Javascript in a very, very large code base:

this.get('some.nested.value', newValue);

With 0 context, we should already see some issues with this. We’re call this.get() but we’re passing it 2 values. Typically, this.get() only takes 1 argument. What happens if we pass it a second argument? That’s hard to say. In Javascript you’re allowed to add unlimited optional arguments. That’s the first thing we need to check. Next is that in our code, this.get() can trigger other code, and that code more code, and so on. That is perfectly fine except that any 1 of those things can do things like make requests to a server or do things in very hidden ways. In fact, triggering hidden code in Javascript is what I would describe as very normal. Now that we have to consider that, now we have to check many more files and try our best to trace the flow of everything. Lastly, because this is Javascript, did someone decide to modify this.get in an unexpected way? To the surprise of some, Javascript allows you to modify existing code at runtime to do unexpected things. These modifications are basically invisible unless you know where to look for them, and in a code base of over a million lines of code that becomes a monumental task.

At this point, you’re probably like “Oh, Wolfgang just hates Javascript because he’s an Elm fanboy.” While yes I do like to use Elm for most of my projects, I do still write and advise writing Javascript in some cases. If you don’t believe me, look at my 3 most popular projects on my GitHub. I also advise writing Python, Go, Java, Crystal, and whatever other language(s) best suit your needs. What I advise against is using Javascript for large, complex applications. It was designed for small pieces of interactivity, like a web component or maybe 1 or 2 forms on your static website. It’s also great for testing out some ideas, like testing out some simple ideas in your browser dev tools or using node to write a simple, single use script. If small and or single use describe what you’re building, then please use Javascript. However, if what you’re building is large and especially if there are going to be multiple people working on it over years, then please choose a better tool. Yes, I would recommend Elm, but I’d also recommend Rust, C#, ReScript, TypeScript, or nearly any other language.

Cake!

Was my wife’s birthday the other day so I made her this awesome cake.

It was a pretty cool cake to make. It’s a 3 layer chocolate mousse cake. The bottom layer is a baked layer and the top 2 are chilled. The bottom layer uses egg whites that are whipped,then folded in. The top 2 layers do the same but with heavy cream. The bottom 2 layers are bitter sweet chocolate while the top is white chocolate with a touch of gelatin to firm it up.

The bottom layer tastes like a brownie, the middle like chocolate mousse, and the top like whipped cream. A really delicious combination!

A surprisingly easy recipe. Most of it was spent waiting on the first layer to cool, about an hour, and then for the whole thing to chill at the end, about 2-½ hours. Otherwise it’s just folding together melted chocolate and whipped eggs/cream.

React is Dead

Yes the title is click bait. So are all of the posts about project X being dead. I’m writing this because I’m tired of reading blog posts about projects being dead when they aren’t as popular as React. This is a horrible metric with no basis in reality.

While we’re here, how about the idea of “Is X enterprise ready?”. This is also a horribly worded question. Microsoft, Google, and thousands if not millions of devs are using TypeScript every day, and yet there are multi-billion dollar companies who are wary of it because it’s not really enterprise enough for them. If TS isn’t enterprise enough, then what is?

Along the same lines, the question “Is it production ready?” is a failure of a question. Is it being used anywhere in production? If yes, then yes it’s production ready. If no, then maybe, because the question is too general. Instead, ask specifics. Ask things like “is it v1.0?” Because we all know you don’t really understand what you need, you just need to check some boxes that your boss told you to check and version is one of them. But versions don’t mean stability, so using them as a marker of stability is just lying to yourself. Gmail was in beta for a really long time while millions of people used it daily. React was serving billions of users well before it hit v15 (because React never had a 1.0). Ember is now on v3.22, but I’d call it anything but stable since the Ember I write today looks basically nothing like the Ember of 3 years ago.

Yes this post was written out of frustration. Frustration from having written Elm for my own projects for years now. Frustration from watching the community grow. Frustration from seeing many other and myself using Elm in production. Yet, people saying things like “Elm isn’t production ready” or “Elm needs to be v1.0 so I can sell it to my boss” or “Elm is dead”. These aren’t failings of Elm, these are failings of the software development community. There are no standards enforcing stability when v1.0 is hit, so it’s just a number. Might as well just use a timestamp instead as it’d be more meaningful. There is no consensus on what “production ready” means, so stop asking about it. It’s production ready for you, when you put it into production. Before then it’s not.

Finally, Elm isn’t dead. It’s as dead as React is. If you’re asking if something is dead, stop and think about what you really want to know and ask that specific question. If you’re writing about X or Y being dead, just stop.