Allanderek's blog

I order groceries online, more or less each week.

Graic has a nice post up discussing left-to-right programming, the main tagline is that “Programs should be valid as they are typed”.

A good summation post perfect web app from Matyáš Racek’s blog yoyo-code.

GPT-5 was released and the general vibe I’m hearing is that it’s a significant upgrade in many areas, but not so much in general intelligence.

I was listening to the Risky Business podcast, in which Maria Konnikova and Nate Silver discuss why you should put your probabilities in numbers rather than words.

For a long time I’ve been sceptical that using the file system to denote modules in a programming language is necessary.

I have previously described using sed to hack together a “poor-person’s functor” to overcome an awkwardness encountered when using elm-program-test to simulate HTTP events in the program being tested.

The following was written for a colleague who suggested I post it more publically, so here we are.

As many did, I participated in pre-tournament prediction competitions for the Euros.

A motivation for why laziness is a good programming language feature.

Do we really need imports?

A very small feature proposal for Elm's type parameters with a motivating situation.

There have been a few proposals for extensible custom types in Elm, the idea is that they are somewhat analogous to extensible record types.

In this post I’m going to describe an awkwardness encountered when using elm-program-test to simulate HTTP events in the program being tested.

A throw-away comment on the elm-radio episode debugging in elm led me to re-evaluate one of my Elm practices.

So I started this blog on the first of January 2021, and have blogged every single day since then.

This is mostly a post for myself to remind myself how to do this.

I had an issue with a computation taking much longer than might have been expected.

Previously I’ve written about immutability bugs which are bugs that are more likely in an immutable language than a mutable one.

When I first started writing web applications I was using Python, and pretty much by default I started using a templating language to actually render the HTML.

Programmers are good at following rules.

I mostly do not use if-then-else.

Sometime in the early part of the century, think about 2004, I saw a talk which analysed source code for defects.

Yesterday I detailed a simple fragment of code that is untyped in traditional Hindley-Milner type systems (such as that employed by Elm), but which is a perfectly reasonable bit of code.

I am a huge fan of polymorphism and of accompanying static type checking.

Global variables have a bad name, mostly for good reason, but as with most things which are considered harmful some have uses, whilst others are symptoms of specific needs.

A small design decision has come up whilst developing with Elm on both the front-end and the back-end.

Pair programming is pretty popular and I’m a fan of it myself.

I’ve spoken before about how great and liberating elm-format is.

I’ve started using Tailwind in anger now, and whilst I cannot say I’ve fully completed a project I have some thoughts on it.

So poleprediction is live, and not with too much time to spare since the first session of the new season was today with the first two practice sessions for the Bahrain grand prix.

I’m a bit surprised that I’ve not spoken about elm-format more on this blog.

As part of a discussion of back-end languages on the Elm discourse someone linked to a post (from 2014) regarding why everyone hates go by Nate Finch.

I came across Dolt which purports to be “Git for Data”: Dolt is a SQL database that you can fork, clone, branch, merge, push and pull just like a git repository.

I was reading, briefly, the ecosystem of the Go programming language, mid-way through it states: A simple language: Consulting the spec, you can find out that Go has only 25 reserved keywords.

I have managed to deploy a version to the server.

As Paul Graham’s blog has been replaying some pretty old posts so have I been reading them.

When first learning source code control, one of the mantras you will hear is: do not check commented out code into the repository I’m not sure why this is so loudly and vehemently exclaimed.

When I started programming in Elm I was already pretty fluent in Haskell and quite used to using the $ operator, which in Elm is written as <| and sometimes called the ’left pizza’ operator.

Sometimes it’s possible to make a kind of judgement of a technology without trying it out, and that’s useful.

I’ve written before about the prospect of compile-time laziness and using elm-review to act as an elm-to-elm compiler pass.

I came across a nice blog post regarding what a modern object-oriented programming language would look like.

Update We have started using Constructor which allows us to do relative issue priority ordering.

Since this blog is being hosted on poleprediction and was originally meant to document some of the effort going into pole-prediction I thought I’d give a summary of where I am.

I wrote a little about Tailwind CSS and then up on my feed popped an article which argues against tailwind.

Back looking Paul Graham’s old posts from 20 years ago, and back to the language design one.

It’s always worth examining the things you love for the reasons why.

I’m not sure if it is intentional or something to do with the RSS configuration on his site but Paul Graham’s RSS feed is going through a redux of posts from 2001.

There are two quite common pieces of advice for Elm programmers: Make impossible states impossible Avoid carrying state state in your messages Impossible states impossible The first is a call to carefully consider the types, mostly in your model and messa…

I really like using Elm’s extensible records.