Programming

I’ve written before regarding the conflict between using Elm’s Html.lazy and extensible records. Today I wish to highlight a similar mild conflict between Elm’s Never type and Html types that forces an unnecessary Html.map. To explain this though I may as well briefly explain the Never type in Elm, and how it is used in the context of the Html type. So I will start with that, and then I’ll show why the type system forces us to call Html.map in a situation where it’s not at all necessary. ...

Martin from Spottt has written an article about their new Elm compiler written in Rust. The article details the reason for their decision to rewrite the Elm compiler in Rust, basically build times: Elm 0.19.2 made builds much faster for many projects, but not for ours: our application is probably an outlier for the Haskell compiler. I wonder if they have the same issue that we had at Pakk, which I realise now I never blogged about before. Our issue was the use of large record types. The Elm compiler expands these record types and crucially stores that expanded type in the incremental build files .elmi and .elmo. That meant that these files became very large, and it was the parser of these files that was taking a long time in the compilation. That was why even for an incremental build the compiler would still sometimes take a long time. We had a simple script to find large .elmi files: ...

A very detailed and thorough post regarding named and optional arguments, in particular a proposal to include them in Rust. Until reading this, I hadn’t really thought of named/optional arguments as much of a big deal. I’ve used them in Python, but rarely, and of course Elm doesn’t have them at all. I’ve always thought of them as being a small quality of life improvement but easy to live without them. Throughout this I’ll use named arguments and optional arguments as interchangeable. ...

Viral instruction wrote a blog post way back in 2021 explaining the difference between union and sum types. I had always used these terms pretty much interchangeable, but this explanation makes sense. I guess I was using ‘union type’ as a bit of a short hand for tagged-union type. I think that Elm has even wrestled with this terminology and they settled on “custom union type”, which I’m not overly fond of, but I can see they are going for clarity. ...

Vaibhav Sagar gave a talk at ZuriHac Why Do Companies Stop Using Haskell?. If I’m honest, I found the talk a little difficult to follow, and I’m not sure if I understand any better why companies stop using Haskell or any other functional programming language. It’s an interesting question, one point that Vaibhav makes during the talk is: Many large projects fail, those written in Haskell may have their failure unfairly attributed to Haskell. ...

Dan Luu, who is now fast becoming for me an unmissable blogger, has written-up another excellent study in using coding agents. In this post he explores how well coding agents make use of various testing and verification techniques when instructed to do so. It’s a fascinating read, highly recommended. The sort of tl;dr is: Agents are not really very good at using testing and verification techniques and when doing so their coding accuracy (on hidden tests) is not a significant upgrade on no particular instructions. In fact, most of the techniques under-performed the default of no instructions, and some increased the cost whilst providing no major benefit. ...

Pranoy Dutta has written a post describing three good features of programming languages. I love such posts. It’s also good to hear of good features that seem somewhat orthogonal to the point of the language. For example, laziness may or may not be a useful feature, but how well it might work is definitely dependent on the otherwise shape of the language. Whereas many languages have minor quality-of-life improvement features that should work in most languages. For example, some language some time ago started allowing large numbers to contain underscores, so that 1000000 can be written as 1_000_000, making it a bit easier to read. That’s obviously fairly independent of how the rest of the language works and as such several languages have copied that. Of course this is something of a spectrum, you may find a feature that works pretty well in any functional language for example. ...

Austin Henley has written a post titled: Type inference has usability problems. I’m not quite sure he demonstrates the title, but it’s definitely a good thought provoking post. Answers to specific points Specific points in Austin’s post: Go You might think, “ok, I’ll just not use it” if it is bad. But if you try to avoid it in Go, you will get warnings! Go’s linter says that you “should omit type X from declaration of var Y; it will be inferred from the right-hand side”. Moreover, all of the examples from Effective Go follow this practice. ...

Zach Kehs has written an interesting post titled: There’s no limit to how bad code can get. The re-architectures were always a failure: The system required years of study to properly understand and was constantly changing. It’s not politically viable to take so long to design a fix for the system, so naturally everyone attempting to fix things must work with incomplete information. Some of this impatience is from within: If you are trying to design a grand fix for such a prominently painful architecture, you are doing it in part because you want a promotion (and you don’t want to wait too long for a promotion). ...

Nimin has a post regarding the use of the M4 macro processor. It reads nicely as it builds the reader from a straightforward httpd.conf file to one written using the M4 macro processor. M4 is a posix utility here is the man page. I think it’s a reasonable choice for a macro processor, as Nimin states: It is generally found on all Linux distros and (more relevantly to this post) on all the BSDs, including OpenBSD. ...

Jim Nielsen has written regarding uptime percentages. He makes a compelling point that reporting uptime percentages isn’t a very useful measure for a human to ingest. He suggests a much better one: So how about, and I’ll just throw this out there, instead of: “GitHub Actions: 98.31% uptime.” We say something like: “GitHub Actions: 12 hours affected in the last 30 days (98.31% uptime).” One requires you to understand the nonlinear significance of numbers near 100%. The other requires knowing what an hour is. ...

The new gren-format tool does not remove unnecessary parentheses. First of all, this is very nicely documented within a list of settled decisions. This decision might seem surprising, but I think it’s right. Why would you put unnecessary parentheses in, unless you thought they increased clarity? In my first year of a computer science degree (last century), I recall an exam which included questions about operator precedence in C programs. I recall thinking this was a dumb exam question that tested recall and nothing important. As young and foolish as I was then I think I got that assessment right. I’m still unsure if I could accurately state the operator precedence rules in most of the languages I use. Firstly, I typically do not write complicated mathematical expressions without giving names to intermediate results. Secondly, if I’m at all unsure I just put the parentheses in and, there is no problem. I often put the parentheses in even if I am sure. I know that * binds more tightly than +, but still I don’t see the problem in writing: ...

Gilbert Ramirez has written a good post-mortem on the challenges of writing Gren format. I’m a huge fan of formatters, and the kind of opinionated formatter that is gren-format (and elm-format) are especially good. I promise, even if you have strong opinions about formatting and think that you won’t get on well with a non-configurable formatter it is well worth getting over that initial grinding of gears. The amount of cognitive load that is reduced by not having to being able to think about formatting decisions is larger than certainly I predicted. ...

Ladybird adopts Rust In the original post I discussed the fact that Ladybird, a full web browser written in C++ had overtaken Servo, a web rendering engine written in Rust, in web platform tests passing. I was surprised by this since my prior would have it that using the Rust language over C++ would be a strong advantage in terms of productivity. I attempted to explain why I might continue to hold that belief in the face of the new evidence given by the Ladybird project overtaking the Servo project. I didn’t fully convince myself, but in February of this year Ladybird announced that they were adopting Rust. This post is an attmepting to understand what’s happening and see if we can draw any conclusions. ...

I have written about lambdas several times: First regarding lambda syntax in Python Then again about lambda syntax in Elm Then again critiquing a post about Python lambdas The common theme in all of these is roughly: Does lambda syntax really need to exist? I think the answer is quite clearly, “no”. We could get by just fine if we were forced to use definition syntax to create all functions. However, that doesn’t necessarily mean we should remove lambdas from the syntax. On the Gren discord there is a thread in the language design channel proposing an alternative to removing lambdas, that is; removing function definition syntax. ...

Mojo is now open source, via Simon Willison. I was also struck by the same quote as Simon in the Mojo road map: As Mojo matures through phase 3, we believe it will become increasingly compatible with Python code and deeply familiar to Python users, but more efficient, powerful, coherent, and safe. Mojo may or may not evolve into a full superset of Python, and it’s okay if it doesn’t. ...

A great small post python’s pre-declared constants are kinda weird examining Python’s constants. The interesting thing here is that the constants are not treated the same way and hence have slightly different behaviour. It’s a little hard to see how this came about. It’s relatively clear that there is no good reason for the constants to behave differently in this way and that the differences are likely an historical anomaly. ...

The Google developers blog has published a post Why Go is an Ideal Language for AI-Assisted Software Engineering. How to say this nicely, I don’t think much of this post. First of all, I think this is a great area of active research. Just as we aren’t terribly sure about what makes a good programming language for humans, we also do not know exactly what makes a good programming language for LLMs. It does seem that it is useful to have a lot of code from a programming language in the training data for an LLM, but I think that’s a slightly different (if more pragmatic) question than what makes a fundamentally good programming language for an LLM. But note also, if we determined some kind of fundamentally good programming language (even a new one) for an LLM we could probably get over the lack of training data in several ways. ...

In a somewhat non-specific titled blog post: What’s the best programming language for coding agents?, Dan Luu takes the time to actually investigate the question of which programming languages are more efficient in their token usage. Well technically the token usage of LLM models when writing in those programming languages. Primarily he’s interested in the claims that dynamic programming languages are more token efficient because the model needn’t write any type annotations. He is skeptical and I think the skepticism is warranted: ...

Link: I Tried Gleam for Advent of Code, and I Get the Hype Nice, short and thoughtful blog post regarding trying out Gleam for the advent of code this year, and liking it. I think this is quite a good advert for generally using the advent of code as a way to try out new programming languages and tools. This makes me want to try out Gleam as well, something that’s been on my to do list for a while, perhaps it will make my new year’s resolution list. ...

Self-recommending absolutely bangning post from Simon Willison regarding combining HTML, Javascript, and CSS into a single file, which can then be served on static hosting. The post itself is obviously worth reading, but additionally you can browse his extensive collection of HTML tools: You can explore my collection on tools.simonwillison.net—the by month view is useful for browsing the entire collection. Some excellent tips including a collection of API resources that provide open CORS headers (which means you will be able to call the API from your HTML file hosted on a different domain name to the API). ...

A good blog post on avoiding space leaks in Haskell showed up on my feed today. First of all I think it provides some useful and important advice for Haskell programmers. I think it touches on some of the same issues that I wrote about recently in a post regarding stacks and laziness. The author starts off stating (correctly) that lazy languages are not the norm, nor particularly popular: Haskell is a purely functional lazy programming language. The world doesn’t have a lot of lazy-by-default PLs. In fact, all mainstream languages have eager evaluation models. ...

Cindy Sridharan writes an interesting post which questions the wisdom of keeping functions small. Although the author uses the provactive title “Small functions considered harmful” that is actually not their point, which is better stated in the conclusion: This post’s intention was neither to argue that DRY nor small functions are inherently bad (even if the title disingenuously suggested so). Only that they aren’t inherently good either. I’ve long had a feeling that an urge to keep functions small is counter-productive in many cases, particularly in Elm, and other languages which have nested functions. I think the key point is that you wish to decompose problems into sub-problems well, but that that doesn’t have to mean that a function is necessarily short. In this post I’m going to attempt to argue for this by comparing code fragments which are clearly pretty similar structurally but in which one has a single long function and the other does not. In this way I will argue that a simple measurement of how long a function is, is not particularly helpful. ...

Lovely blog post from Herman who operates the bear blog blogging service. He details a little project of his to mess with the badly behaving bots, but I think it also works well as a read of simply spending some time going down a rabbit hole, mostly enjoying oneself, and also reflecting a little. He is concerned mostly with the real bad-folk of the Internet, the ones that are looking for exploits: ...

I sometimes find that developers do not really have a good grasp on the point of laziness in a programming language, believing that it is mostly an optimisation. It’s not really an optimisation, it’s a way of writing generic code which doesn’t need to be specialised for a particular use case. I’ve made an attempt before to explain why laziness can result in cleaner or less complicated code. In this post I wish to attempt to explain another example where laziness can solve a complexity issue in code, but it comes at some cost, and understanding that cost can go a long way to explaining why laziness is not the norm (aside from the fact that purity is also not the norm). ...

Previously I reported on long Elm compilation times and that being related to large .elmi files. In an Elm discourse thread Warry links to their new package elm-stuff for decoding .elmi and .elmo files. So if you are having Elm compilation time woes, you could potentially use this, to inspect the large .elmi files and see exactly what may be causing them to be so large. This may guide you to the best large record files to make opaque to reduce your application’s compilation time.

This post details a problem with the Elm compiler that results in long compilation times or large memory usage (and possibly OOM issues) and a possible way to fix it, as in change your application so that your compilation times are shorter. I have a large (~150k lines) Elm application and it can take over 2 minutes to compile. One reason for this is the stored state that the Elm compiler stores in order to avoid some recompilation (or at least re-type-checking) code that hasn’t changed. It stores this information in .elmi and .elmo files. The .elmo files do not seem to grow overly large but the .elmi files can. ...

Using Claude code I noticed something a little strange, which I at first thought might give some insight into how LLMs are manipulating code, but turns out is probably nothing to do with that an merely how it displays those changes to the user. Here is a diff proposed by Claude, the task involves removing a link from the navbar of application. ● Update(src/View.elm) ⎿ Updated src/View.elm with 6 removals 58 |> ifLoggedIn 59 , Html.li [] 60 [ Html.a 61 - [ Route.href Route.ImportOpml ] 62 - [ Html.text "Import OPML" ] 63 - ] 64 - |> ifLoggedIn 65 - , Html.li [] 66 - [ Html.a 61 [ Route.href Route.OrganiseFeeds ] 62 [ Html.text "Organise Feeds" ] 63 ] The logical thing a human would do would be: ...

Syntax highlighting is having something of a moment. Three posts have popped up on my feed: Niki is sorry, but everyone is getting syntax highlighting wrong Words and Buttons speak about Lexical differential highlighting Hillel Wayne complains that Syntax highlighting is a waste of an information channel. Sorry, but everyone is getting syntax highlighting wrong In the first post Niki allows themselves to wander a little from the main point with several interesting syntax-highlighting related points. However, I think the main point is made with: ...

An interesting post on the Unplanned Obsolescence blog.I’ve asked before what dynamically typed languages are good for and one answer I’ve come up with is meta-programming. In the linked post the answer is essentially ‘glue’ code. It is very much worth reading the entire thing, but the author is firstly making the claim that you should mostly stick to using the web DSLs, rather than language extensions/frameworks that seek to abstract away from those DSLs. The DSLs in question are HTML, CSS, and SQL. The author then states, that when you have to glue between these DSLs in your general purpose programming language you are necessarily crossing type boundaries, as a result, you mostly lose the guarantees of a statically typed language, but that statically typed language forces you through some hoops which ultimately obscures the actual logic of what you’re attempting to achieve. ...

The Entropic Thoughts blog has a new post: “Non-Obvious Haskell Idiom: ViewPattern Argument Transform” regarding something I didn’t know existed in Haskell, and it touches upon something I’ve written about before so I’d like to say how they are related, and wonder whether this is the correct solution, I don’t have a better one. So first the new feature in Haskell is a “ViewPattern argument transform”. What is one of those? Well suppose you have a function such as: ...

Martin Janickek has a great post “Elm Queues Shootout” which is well worth reading. He uses property based testing to test several Elm queue libraries. He then benchmarks those libraries as well, though he is cautious to note that for the most part queuing libraries are fast enough and you don’t really need to worry about performance unless you have queues of many items in a hot loop somewhere: I need to preface this with: this is all on a nanosecond scale. Don’t be wooed by the absolute differences here - does your webapp really care about 0.2ns vs 3ns? Which operations will it do often? The O(1) vs O(N) time complexities will probably be more instructive, though again you have to think about the realistic sizes of your queues. Are they going to hold more than a few hundred items? ...

Dillon Kearns of elm-pages and elm-radio fame has a really good analogy for feature requests, whether they be feature requests for an end-user application or API changes to a software library, or even say changes to a programming language. His analogy is legal standing. Legal standing, in the US, is the requirement that a person bringing a case to court must have a sufficient connection to the issue. This usually means that the plaintiff must show: ...

Cracking post on the Elm discourse by john_s in response to rupert’s question regarding “intensely monadic code”. In his response john_s details some findings from a review of 300k lines of Purescript/Haskell code: In surveying over 300K lines of PureScript / Haskell code in 4 large applications I believe the most genuinely needed monadic binds I ever saw in any properly sized function was 4 and was 1 on average!!!. In other cases, ...

I’m interested in programming languages and often look at the websites for new/isoteric programming languages. Today, after reading Moonbit developers are lying to you I was interested in the moonbit language and so I visited the website. I noticed a few things on the website that I find relatively common when looking at programming language websites and thought I would detail them here. This will seem like a bit of a negative post, but remember I’m going over a website here, I’m not critiquing the actual language which I have not yet tried. If anyone from moonbit were to read this, take this as a light constructive critique. ...

The success of Ladybird (C++) overtaking Servo (Rust) challenges some assumptions I have about the programming language productivity, particularly with respect to strong, static typing, and the lack of a satisfying explanation allows me to update my priors a little. This post was triggered by watching the latest update video from the Ladybird team, in this we learn that according to the web-platform-tests Ladybird has now overtaken the Servo project in terms of tests passing. According to this HackerNews comment in August of 2024 the Servo project was quite far ahead. ...

A couple of weeks back after the GPT-5 release, I wrote a skeptical post that the fact that the GPT-5 model picker release was botched was something of a bearish sign for llm-assisted programming: Okay, but if OpenAI cannot utilise their own models in coding/dev-ops to avoid a high-profile failure on a very high importance launch, what chance do other companies have? Why hasn’t the A.I. enabled OpenAI to improve their development/deployment strategies to avoid such techincal glitches? ...

Graic has a nice post up discussing left-to-right programming, the main tagline is that “Programs should be valid as they are typed”. I agree with this idea, the main thing that the post points out, is that if definitions come after use, it is difficult for the IDE to help with auto-completion and/or hints (such as undefined variables). The first example is Python’s list comprehensions when typing out the line: ...

A good summation post perfect web app from Matyáš Racek’s blog yoyo-code. I think this neatly sums up how difficult it is to write a good, well working web application. It’s good to have all this in one place. In particular I think this nicely shows some of the trade-offs between traditional server-side rendered multi-page applications and client-side rendered single-page applications. For example: It [the app] should work in a limited way offline. and The app should work without JavaScript enabled (progressive enhancement) Those are both not straightforward on their own, and pretty difficult to achieve both at the same time. ...

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. To recap briefly the issue is that using elm-program-test, means that the update function returns an Effect rather than a Cmd Msg. When we apply this update function to Browser.element|document|application we need to create a function,perform, which translates the Effect type into a Cmd Msg. The reason we do this, is because for testing we instead create a function, simulate, that translates the Effect into a SimulatedEffect which can be simulated by elm-program-test and also interregated to test that we have produced the intended set of Effects for the test in question. ...

The following was written for a colleague who suggested I post it more publically, so here we are. We’re going to compare dynamically and statically typed languages in the context of writing admin panels for a variety of data stores. We assume that the data is actually stored within a relational SQL database, but that’s not important because we further assume that we need to send/receive JSON data. First a point of terminology This section is skippable, but defines the difference between the statically-dynamically and weakly-strongly typed axes. If you’re sure you know, you can skip this. ...

In this post I’m going to show a good example of where laziness would work well. This is of course not an argument that lazy programming languages are somehow better than strictly evaluated programming languages. Rather what I wish to do here is answer the question, what is laziness good for? My example here comes from the justinmimbs/time-extra Elm package. The main purpose of this library is to provide a means for working with the standard library’s Time.Posix values. Functions are provided to calculate the difference between two time values, and also to add/minus a given interval from a given time value. So for example it provides a convenient way to take a given time value and add one day, or two hours, or six months. ...

Imports in most languages always seem like a bit of an add-on, a separate language to the actual language. Today’s post is a thought experiment regarding removing imports from Elm/Gren. Ultimately I think it’s probably worthwhile having the import statements there, but this is an interesting (and quick) thought experiment. If we remove import statements from the head of a module file the first thing to note is that a file then becaomes one module declaration line followed by simply a list of top level declarations. However, we would obviously need someway to refer to values and types defined in another module. ...

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 wish to give a proposal for how to make custom types ’extensible’ that could play well with opaque types. The key point is that we need not focus on extensibility so much as the distinction between structural and nominal types. The slightly longer summary is to say that we can make custom union types structural types. This means that custom union type declarations are actually type aliases, just as record type definitions are in Elm. Two record types can share the same field, and thus it is trivial to make two record types one of which is a sub-type of the other. Similarly if custom union types are structural, and their associated definitions type aliases, two such custom union types can share a constructor, and again it is trivial to create two custom union type definitions one of which is a sub-type of the other. With this apparatus we can implement opaque types by choosing to expose a type either nominally or structurally, this gives us opaque types in which the underlying type can be a primitive type, a function type, a record type or a custom union type. ...

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. I will then describe ML functors, a feature of the SML/Ocaml module system and show how these would solve the awkwardness. I’ll then show how it’s pretty simple to hack together a “poor-person’s-functor” and use that to solve the aforementioned awkwardness. An awkwardness when simulating HTTP for testing If you haven’t used elm-program-test to test an entire Elm program I recommend trying it out. I’ve found that it not only does the obvious part of helping to build robust tests for Elm programs, but also helps me structure the Elm program in a way that is better for testing, but also just generally better. ...

A throw-away comment on the elm-radio episode debugging in elm led me to re-evaluate one of my Elm practices. The comment concerned writing a type signature for values/names defined in a let-in scope. I’ve always done this in what seemed to be a traditional accepted practice. That is omitting pretty much any and all signatures on names defined within a let-in scope. If you look at most Elm code you can find on the web, in particular in the elm-lang guide, and in documentation for elm libraries, you will find the same style. ...

So I started this blog on the first of January 2021, and have blogged every single day since then. This is the 100th day of the year. That was the target I set myself, blog something every single day for 100 days. It seems impossible when you start out. At first you have a few topics you’ve always wanted to write down but never gotten around to it, but after that you think there is no way you will make it to 100 days. ...

This is mostly a post for myself to remind myself how to do this. I typically program on a remote server. I ssh in via the terminal and use tmux to manage sessions. I then edit code in neovim. This setup has a bunch of advantages and a bunch of disadvantages as well. One of the disadvantages is that I found it difficult to copy and paste from the tmux session in my terminal, to a completely different program running on my local machine, such as say my web-browser, or a chat client. ...

I had an issue with a computation taking much longer than might have been expected. It turned out to be caused by a use of the function greedyGroupsOf from the list-extra library, and it was solved by writing my own, naive, implementation. I haven’t quite gotten to the bottom of why the library version of greedyGroupsOf of is so much slower than my naive version, but the reason it is slower is mostly to do with DRY or don’t repeat yourself. ...

Previously I’ve written about immutability bugs which are bugs that are more likely in an immutable language than a mutable one. I think these are relatively rare, but they do exist. A good example has come up on the Elm discourse. The person asking the question wants to create new unique identifiers for items in their model. To do this you can simply keep a count of the number of identifiers you have thus far created. So you can do something like the following: ...

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. There are quite a number of templating languages (or frameworks) for Python, I tried a few and found them to be mostly much of a muchness, that is to say I couldn’t quite work out why so many existed since the difference between them seemed minimal to me. ...

Programmers are good at following rules. Rules make for reducing the number of decisions you have to make. That’s why we like rules such as “do not have functions that are longer than 300 lines of code” much better than “try not to have your functions too long, but sometimes you need it, so it’s a judgement call”. You might think that kind of rule gives you more flexibility, but just means you have to make more decisions. Should I really refactor this function it seems fine? That is easy to answer with the first rule, much more difficult with the second rule. ...

I mostly do not use if-then-else. Part of this is just a common Elm feeling of desiring to keep the language small, and since we have case expressions we do not really need if-then-else. But there is another part to it, I can order the branches anyway I like, I do not have to have the True branch first. Why would I wish to do this? My feeling is that as you’re reading code, there is only so much you can keep on your “stack”. So if you have a large branch of an if-then-else and a small trivial one, I tend to place the small trivial one first. ...

Sometime in the early part of the century, think about 2004, I saw a talk which analysed source code for defects. They had used, what was at the time fairly new, online source code repositories for open source programs. They determined that a piece of code was buggy if it was changed in a commit which fixed a bug. The authors analysed the code (which was all written in Haskell) to see if they could determine differences between ‘buggy’ code and ’non-buggy code’. I wish I could remember the authors or the title, but I cannot. ...

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 think of this as a minor irritation and quite easy to live with. I term it a blind-spot of polymorphism, because in general I find that polymorphic Hindley-Milner style type systems map pretty well on to the types of programs that I wish to write. Aside from the issue of meta-programming, but that’s quite a separate issue. ...

I am a huge fan of polymorphism and of accompanying static type checking. I find that, meta-programming aside, I mostly do not wish to write the kinds of things that are allowed by dynamic typing but disallowed by static typing. There are two exceptions, or blind spots to this and I thought I would detail the first one. Suppose you have a data structure with several Maybe fields: type alias Preferences = { favouriteFood : Maybe Food , favouriteBand : Maybe Band , favouriteColor : Maybe Color , favouriteNumber : Maybe Int , favouriteName : Maybe String } Now suppose you want to count how many of these are set: ...

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. Elm of course, being a purely functional language (by which I mean it is devoid of any side-effects), does not have global variables. It does have global constants. I feel like there is a missing feature in between these two. A global constant that is initialised on startup, perhaps by the program flags. ...

A small design decision has come up whilst developing with Elm on both the front-end and the back-end. The issue concerns an input that has some UI state, that doesn’t need to be transfered from front-end to the back-end (or vice versa). So I’m going first explain an example of an input that might have some associated UI state that you need to keep track of. Then I’m going to explain how you might represent this has part of a larger entity that needs to be encoded into JSON, and decoded from JSON to send to and from the front-end and back-end. ...

Pair programming is pretty popular and I’m a fan of it myself. It certainly feels as if there is a productivity boost from pair-programming, but I’m not entirely sure why. I have two theories: It’s not actually more productive it just feels more productive Pair programming actually just forces both of you to focus for the entire time you’re pairing. I tend towards the second explanation. I’ve paired sometimes for three hours, even if two people pairing are no more productive than a single developer, I suspect you might struggle to actually get those two developers to independently work solidly for more than an hour and half each, within those three hours. There is probably some combination of factors going on here. So maybe for example two programmers pairing are no more or less productive than two developers working independently, but pairing just forces both of them to focus on development for that period of time. Additionally, it’s more difficult to interrupt two developers pairing than it is to do so for either one independently developing. ...

I’ve spoken before about how great and liberating elm-format is. Once you cede control of the formatting of your source code, other possible features arise. Some of these could potentially take the burden away from the code editor tools. An obvious example would be the formatting of multi-line comments. When you change a multi-line comment, you often have to do a bit of formatting if you wish to keep the lines under a given character count. ...

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. The first thing is, I do not hate it. I can see how for a certain kind of development team, in particular single developers who are going to do the styling themselves anyway, doing the styling in whatever language you’re using to generate your HTML is quite liberating. In particular I do not have quite the same fear I have of changing the styling. In large projects I find they get to the point where I start adding more and more class names to the elements so that I do not have to modify the current CSS but rather add more. That way I’m more confident of not breaking anything that is currently working. However, of course that’s not a sustainable path forward. So I’m pretty pleased that the tailwind approach is seeing me more willing to change the current styling. ...

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 technically didn’t need to be ready until tomorrow since that represents the first session for which we are predicting. Mostly everything has gone through without a hitch. A small problem with emailing, in which I cannot seem to validate my domain with mailgun, so I’m still using the sandbox which means I can only send to 5 pre-verified recipients. In addition one of them is, for some reason, not receiving the emails promptly, I suspect the issue is with Yahoo rather than mailgun, but I do not know. ...

I’m a bit surprised that I’ve not spoken about elm-format more on this blog. I did write a post which mentions it, but that’s more about Elm’s frugal syntax and how that facilitates a formatter. The benefits of a formatter are surprisingly numerous, and many are voiced in this elm-radio episode. The main thing I like is that the trivialities of how code should be formatted are taken away from me, that’s great, I can focus my attention on things that matter more. For the most part formatting decisions are just taken away from me. ...

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. The author links to a Paul Graham post regarding identity, and he links the two. So Paul’s post states that people form identities regarding religion and politics and that’s why it is so difficult to have a meaningful debate about either. Considering the alternative view point questions your identity. ...

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. Connect to Dolt just like any MySQL database to run queries or update the data using SQL commands. Use the command line interface to import CSV files, commit your changes, push them to a remote, or merge your teammate’s changes. ...

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. Which got me first wondering whether that was a lot or not, a brief search and I found a bunch of places offering keyword counts. They’re not completely accurate, one place has Haskell in with 25 and another 55, but for the most part sound about right. One place has Elm with 25, I make it a few less, since that seems to be based on the exports from the Parse.Keyword module in the compiler, which has four or five exports which are not keywords. Nonetheless I was kind of surprised that Go and Elm were roughly on a par here, and indeed 25 is comparatively fewer than most languages. ...

I have managed to deploy a version to the server. You can login with your email address, which it sends a login code to. With this the last weekend before the start of the formula one season, I’m cutting things mighty finely. The major thing left to do before Friday, is make the site look nice, or at least reasonable. Give it some styling. My plan is to experiment with elm-tailwind-modules. ...

As Paul Graham’s blog has been replaying some pretty old posts so have I been reading them. A recent one was the python paradox. I think this applies pretty well to Elm at the moment. The Python Paradox was written in 2004 when Python, was still what one might call an esoteric language, that is, it wasn’t particularly popular. Whereby popular, we mean, used by many people, rather than liked by those that used it. Even at the time Python was very much loved by its users. Anyway the basic idea in the Python Paradox, is that programmers at the time did not learn Python because it was good for their resume, or it was good to find a job, because there were no python jobs. Because of this, it means that they were learning Python purely for the love of programming, and perhaps because Python seemed a bit different. Such programmers are nearly always good programmers, at the very least programmers with potential. Therefore companies should use Python in order to attract such developers, or at least require Python experience. ...

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. I’m not even sure it should be a general rule. I realise that the code you are commenting out is available in the repo should you need it. But if so, you at least need to add a comment suggesting that some code that would otherwise be right here and commented out is available in the repository history, where to find it, and what it does. I also see that it adds to the general untidyness. But having said that, I just don’t see that it is so very harmful. On top of that there are clearly cases in which the rule should be broken for specific reasons, and I fear making such a vehement and strict rule against this will lead to it not happening. ...

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. Somehow, over time I started to use the |> (right pizza) operator more and more. I think this first came about through the use of the builder pattern which very naturally maps the building up of a data structure which thus just got me comfortable with post-fix application of a function. ...

Sometimes it’s possible to make a kind of judgement of a technology without trying it out, and that’s useful. In this sense you’re judging a book by its cover, see Paul Graham’s pre-critique of Java. Because of the recent release of Tailwind modules for Elm I’ve been trying to judge the cover of Tailwind before I jump in and start using it. One way of judging a technology without trying it, is to look at critiques of that technology. Do those comments hit home for you? A prominent critique of Tailwind came up on my feed. I think the author of this critique just doesn’t share similar problems to the ones I typically face, and, I think are typically faced by Elm developers. So I’m going to go through most of the points in the critique article and roughly state why I don’t think they really apply for Elm developers. ...

I’ve written before about the prospect of compile-time laziness and using elm-review to act as an elm-to-elm compiler pass. Obviously one way to implement compile-time laziness would be to fork the compiler. As I said previously the use of elm-review to do this instead is something of a low-risk route into this. If this works out particularly well it could be translated fairly easily into an internal compiler pass. An internal compiler pass would have the benefit that the output of the pass might not necessarily have to be valid Elm. It might also be faster because it would not involve the expensive operations of unparsing and re-parsing the Elm code. ...

I came across a nice blog post regarding what a modern object-oriented programming language would look like. Not now, nor never really, having been an object-oriented programmer, I’m not going to comment on how suitable the proposed language features would be. However, I thought it was an interesting exercise, many of the programming languages I fail to appreciate have made similar mistakes of ignoring things we seem to have learnt pretty conclusively about programming languages. But that’s not what I wish to talk about, what I want to talk about today is the list of five non-negiotable features the author lists for any new object-oriented language (though I think he roughly means these would be non-negotiable features for any application programming language. Here are the five that the author lists: ...

Update We have started using Constructor which allows us to do relative issue priority ordering. The team are very responsive to feedback as well which is great. Recommended. For projects involving more than one person, I’m typically using github or gitlab, either has a pretty usable issues feature. For the most part with issues all I want is the ability to write some text, preferably in markdown. The ability to add screenshots is a major plus. The checkboxes are nice as well, but I’d be happy to write those myself in markdown, ie. I don’t really need the ability to check a checkbox with the mouse, but it’s a nice touch I guess. ...

I wrote a little about Tailwind CSS and then up on my feed popped an article which argues against tailwind. There are of course many reasons why two people can see what seems like the same information and reach different, and possibly entirely opposite, conclusions. But one quite obvious reason, when we’re talking about choices of technology, is that both have different advantages and disadvantages, and for some reason the two people are weighing those differently. Often it means that there is no ‘right answer’ in general, and unfortunately no way to combine the advantages of both. I sometimes think of this in terms of horiztonal and vertical. In this post I’m going to try to give an example of this distinction. ...

Back looking Paul Graham’s old posts from 20 years ago, and back to the language design one. There is a section on pitfalls and the first pitfall is about clients: This is just a guess, but my guess is that the winning model for most applications will be purely server-based. Designing software that works on the assumption that everyone will have your client is like designing a society on the assumption that everyone will just be honest. It would certainly be convenient, but you have to assume it will never happen. ...

It’s always worth examining the things you love for the reasons why. Could something you think is improving your productivity actually be harming it? Perhaps in a way that makes it feel like you’re being productive. Continuing the look at some of Paul Graham’s older posts, this one regarding object-oriented programming languages popped up on my feed. I think it stands up pretty well over the previous two decades. I wouldn’t say object-oriented programming has been debunked, but it has certainly lost some of its hype. I thought about Elm when reading the following third point: ...

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. Some of these are interesting to read with the 20 years worth of perspective. Back in 2001 he thought that Java didn’t smell great, a point he made without trying the language. I think for the most part this post has stood up well to time other than the frequent use of Perl as a counter-balance. ...

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 messages. So do not have a Maybe User type used anywhere where you consider it impossible for the value to be Nothing. So for example, you might have a message, such as the liking of a post, that requires a logged in user, because the request takes in the authorisation token: ...

I really like using Elm’s extensible records. There is a little debate about how best to utilise them. It seems clear they should be used for narrowing the types of function arguments. Narrowing the type of an argument to a function often makes it significantly more general. Here’s a quick example, suppose you have a User type in your application, you might have only a few of them, say a list of friends of the current user or something. So you might write a function to find a particular user in a list: ...

A Tailwind CSS package was announced on the Elm discourse which lead me to checking out Tailwind which in turn led to this post by the author of Tailwin. In it he makes an excellent point which I’m going to try to distill into a smaller form, though you’re well advised to read the entire original article. The author’s main point is that try as you might to separate the semantic concern of the HTML from the display concerns of CSS, one or the other will depend upon the other. In particular when using semantic classes in your markup, your CSS becomes a mirror of your markup structure. That means that if you change the HTML you likely have to change your CSS. Note, when I say CSS here, I mean, however you write your styles, using LESS, or Sass, or, if you prefer, vanilla CSS. ...

I use neovim to edit code and I’m mostly editing Elm code, so the missing feature I’m about to describe is missing from neovim and for editing Elm code, I don’t know of any other IDE that has this, but it wouldn’t entirely surprise me if, for example, the Elm plugin for the IntelliJ IDE has this feature. I also think this feature would benefit most programming languages. Anyway, this feature regards editing the imports at the top of an Elm file. What I really want to be able to do is just press some key combination to bring up a dialog which allows me to edit the imports from where I am, without having to scroll up to the edits. What I mostly do now, is just edit code as if I had already edited the imports, press save, which tells me what imports I’m missing (and also if I scroll up there, which imports are no longer necessary). So I guess this is not a terribly needed feature, but I find myself wishing for it quite commonly. ...

A while back a colleague and I started developing a Go based web framework, in which all the HTML was generated on the server. The client webpage was essentially a thin client that sent all messages, via a websocket, to the server which then returned the new HTML to be displayed. I had previously helped with a very similar technique done in Python. This general technique is being experimented with in various places, most notably in Phoenix Live View (an Elixir based effort), and Hotwire. ...

I noticed a sort of surprising syntax thing in Elm yesterday. When you think about it, it’s not all that surprising, but the question is, can it be made of use? So what I noticed is that the in expression of a let-in expression can itself be a let-in expression. So the following is valid syntax: ... let x = 1 in let y = 2 in x + y That’s because the syntax of let-in is let <def-list> in <expr> and let-in is itself a valid <expr>. So you can have as many let-in blocks chained as you see fit. Clearly, you can just delete the middle two in-let lines and you still have a valid expression. The question then is, what is this useful for? ...

A little tip for restricted text input in Elm. I’ve coded up the general idea in an ellie. This is really a general HTML tip, that I didn’t know existed, but for some reason I feel it works pretty well in Elm. The sitation is that you wish to restrict a text input to one of several possibilities, but there are many possibilities, so a select element is probably not correct. You may or may not wish to prevent any output not in the list of suggestions. What I didn’t know is that you can define a datalist element that has all the suggestions and the browser will interpret that appropriately provided you set the list attribute on the input element. As for invalidating it, you could use a pattern attribute, but I think in Elm you’re probably doing your own invalidation anyway. ...

A couple of decades ago Java was riding pretty high in programming language circles. It used the JVM, and back at the turn of the century it seemed that pretty much any language was going to end up being run on some kind of virtual machine. Two decades on and it’s a little difficult to say what the point of a virtual machine is, any longer. At the time, it was not easy to see that most of the software we use was going to be moved into the cloud, and whilst somethings are interacted with using smartphone applications, much of it is done using a web-browser. In a sense, the web-browser has replaced the need for a virtual machine. Most of us did indeed see the value in compiling one application and being able to run that application on different machines. Although the virtual machine concept never really paid-out that kind of cross-platform dividend. Even if so, you have to wonder whether it really was easy to develop a virtual machine for different platforms, rather than just develop a compiler-target for different platforms. ...

I will admit that before I tried my first programming language that used significant whitespace, I thought it would be horrible. I cannot remember why. I was thinking about this whilst reading An incomplete list of complaints about real code. In this the author doesn’t like signficant white space, here is what they say: I don’t like meaningful whitespace. If a tab means one thing and a space means another and they both print the same way (i.e., NOTHING, a big blank space on the screen), I’m not going to be happy. Also, if the amount of whitespace somehow controls branching or blocking of code, you better believe I’m not going to be happy when it trips someone up. ...

When I started programming almost all programs were built using make, which is basically a domain specific language for writing down dependencies and compilation instructions. It seems to have mostly fallen out of fashion, I think largely because many languages take the hard part of figuring out what depends on what out of the hands of the programmer and just do the correct thing when you call the compiler against the single file which hosts the main (or equivalent) of the program. You could still use make files for things like documentation, but what people tend to do instead is just use a script, they don’t worry too much about dependencies for things other than compilation, because you can generally just always run everything. ...

This site is the blog of a developer of a site which is a game about predicting formula one results. So it is no surprise that I might frequent the site of Formula-E. What I want to talk about is evident on this site, if you go to the standings page, the one linked here is specifically for the ’teams’ standings, rather than driver standings, but the point is basically the same, although more pronounced because there are half as many teams as their are drivers. ...

Mostly notes for myself on how I setup nextcloud on Time4VPS. I was mostly following this article but found it was slightly wrong in a couple of places and missed out the odd thing. Install the dependencies sudo apt install apache2 mariadb-server libapache2-mod-php unzip sudo apt install php-gd php-json php-mysql php-curl php-mbstring php-intl php-imagick php-xml php-zip Download nextcloud Navigate here to find out the latest verison. Then (substituting in the latest version for 21.0.0): ...

Once again today I had a github issue close accidentally on me. I’m kind of at a loss for how this feature is designed, programmers use github, we’re happy being explicit, why make it ‘smart’? So to explain the issue. Suppose you have an issue, say issue number 312. If your commit message looks to github as if it has fixed the issue then it will automatically close the issue for you. What does “looks to github has if it has fixed the issue” mean? Good question. If your commit message contains something like “close #312” or “fix #312” then that will look like it is meant to close the issue. You can also replace the “#312” part with the actual url of the issue, it seems to work even if the url targets a particular comment on the issue rather than the whole issue, which is particularly vexing. ...

There is no denying that Go, the programming language is pretty popular. I’ve never understood this popularity. The most commonly cited reason appears to be that Go is simple/easy language designed for beginners. I don’t feel this at all when I have had to dip into Go. This post will necessarily be quite negative for Go, but try to think of this as the writing of someone who accepts that the popularity of Go is entirely warranted, and that they just cannot see the merits. ...

Dan McKinley has an interesting site based around a talk of his in which he extorts the value in choosing boring technology. He fully admits that this is something of a click-baity title, what he is really talking about is old known technology as opposed to new unknown technology. Having read the site I feel that it really has two separate points. The first point is about old, boring technology as opposed to new/exciting technology. The second point is about trading-off pain now for pain later. ...

A blog post popped up on my feed, which has the main point that tagged union types (called custom types in Elm) are overrated for implementing intermediate representations. To be clear the author is not saying that tagged union types are in general overrated, but their suitability for intermediate representations within compilers is just not that big of a win. It’s easy to see why tagged union types are thought of as perfect for internal representations of code in compilers. The grammar of a language kind of looks like a tagged union type already. You might represent the grammar of an elm expression in Elm’s custom types something like the following: ...

I think mutation testing is a pretty fine idea. The idea of mutation testing is to deliberately add a bug into the program and then check that the test suite catches that bug. We add the bug into the program by mutating a part of it, since if you change code that you believe is all correct, then presumably it cannot still be correct. Of course mutating the program can be mechanised and hence we can test many many mutant programs. Mutation testing does not test your program code, but how effective your test-suite is. Mutation testing is used to improve your test-suite. ...

Today I’m going to talk about a language feature that I think is missing from most languages. I know of at least one in which it exists, I do not know of any functional langauges in which it exists. The language feature I’m talking about is the removal of a name from the scope. Let me first talk about a situation that is ripe for bugs, and then introduce the idea of removing a name from the scope so that you do not use it mistakenly. ...

Coury Ditch reported on the trickiest Elm bug he’s ever seen. It’s a good read and a good caution against holding stateful information into your Elm messages. When I was very new to Elm one of the first things I had to do at a new company was figure out a bug that basically had the ‘Stale message’ anti-pattern as main reason behind it. So I’m going to described the bug and the solution. ...

Someone asked on the Elm discourse how to embed HTML into an Elm app. There are basically two approaches, which I will try to describe along with advantages and disadvantages. Translate the HTML to Elm Either by hand, or you can use an online tool. As the original poster seemed to find, there is a limit to how sophisticated such a tool is, but it’s probably worth a shot. However, this is only going to work if the HTML you are trying to display is not going to change. In the discourse posts, the HTML was what was presented to them from a legal website drafting a set of Terms and Conditions. But if say that HTML was being produced by some wysiwyg HTML editor, then unless you can automate the translation of the HTML to Elm this isn’t going to work. It obviously will definitely not be able to display dynamically generated HTML. ...

When you hold an opinion, particularly when you know that other sane people hold the opposite opinion, it’s good practice to try to come up with the best argument possible for the opposite opinion. I’m going to do that today with weak typing. I typically think that a weakly typed language is basically useless. As in, I would always prefer a language with strong typing over an equivalent one with weak typing. So in this post I’m going to try to come up with a reasonable scenario in which choosing a weakly typed language over a strongly typed one would make reasonable sense. ...

Popping up on my feed was an article on learning Python by looking through the gotchas and unexpected things that happen in Python. It’s a nice enough article, and clearly a lot of time has been spent polishing it off and even publishing a package to accompany it. What is a little disconcerting though is the sheer number of surprising snippets. A pretty reasonable goal for a language would be to have as few surprising parts as possible. That’s another advantage of having a very small language, there are fewer things that could have been designed in a surprising way, and perhaps more importantly, there are fewer moving pieces that can combine to produce strange or surprising behaviours. ...